Engineering
Commit message from a diff
Write a commit message from a diff: a subject line that states what was found, then prose explaining why the change was made.
Add in the app
Engineering · For your bots
Break a spec into tickets
Split a spec, plan or thread into small tickets that each ship on their own, with order, dependencies and a check for done. Shown before anything is filed.
In Lobstack: Skills › Library › Add
Download LobstackWhen to use it
A spec or a settled plan has to become work in a tracker — Linear, GitHub Issues, Jira.
What your bot will do
- 01
Read the whole spec and list its open questions first. A ticket built on an open question gets built twice.
- 02
Cut the work into pieces one person could finish and ship in a day or two, each leaving the product working. Cut by what a user can do, not by layer: "can export one invoice as PDF", not "backend for export".
- 03
For each ticket: a title that is a verb and a result, two or three lines of context, and an acceptance check someone else could run to agree it is done.
- 04
Mark dependencies, and order the list so nothing waits on a later ticket. Put risky or unknown work first.
- 05
Leave non-goals out. If the spec says "not in this release", no ticket.
- 06
Search the tracker for tickets that already cover a piece, and link them rather than filing duplicates.
- 07
Show the full list as a document and wait for a yes. Only then create the tickets, and report their links.
Twenty small tickets beat five vague ones. A title that needs the word "and" is usually two tickets.
The file
---name: spec-to-ticketsdescription: "Split a spec, plan or thread into small tickets that each ship on their own, with order, dependencies and a check for done. Shown before anything is filed."metadata: title: "Break a spec into tickets" category: engineering tags: [planning, tickets]--- ## When to use this A spec or a settled plan has to become work in a tracker -- Linear, GitHubIssues, Jira. ## How 1. Read the whole spec and list its open questions first. A ticket built on an open question gets built twice.2. Cut the work into pieces one person could finish and ship in a day or two, each leaving the product working. Cut by what a user can do, not by layer: "can export one invoice as PDF", not "backend for export".3. For each ticket: a title that is a verb and a result, two or three lines of context, and an acceptance check someone else could run to agree it is done.4. Mark dependencies, and order the list so nothing waits on a later ticket. Put risky or unknown work first.5. Leave non-goals out. If the spec says "not in this release", no ticket.6. Search the tracker for tickets that already cover a piece, and link them rather than filing duplicates.7. Show the full list as a document and wait for a yes. Only then create the tickets, and report their links. Twenty small tickets beat five vague ones. A title that needs the word "and" isusually two tickets.