Reebeecka write-ticket
Turns a settled plan into tickets. One ticket = one testable goal. A plan may become N tickets. The chain is grill-me → write-ticket → close-ticket.
API calls and credentials: ../ticket-platform/PLATFORM.md. This skill is the workflow.
Never start building. The skill ends when approved tickets exist (or the user stops at the draft).
When to grill first
If the goal is still vague, offer grill-me and wait.
Exception: the user explicitly says to put this up as a ticket (e.g. "lägg upp detta som en ticket"). Then draft anyway and list assumptions in the ticket instead of forcing a grill.
Backend
Read last-used backend from the platform file. If none, ask: GitHub or Jira.
| GitHub | Jira | |
|---|---|---|
| Title / summary | Verb + object (Add match list on Rugby page) |
User story every time: As a <role>, we need <X>, so we can <Y> |
| Body | Markdown | Wiki markup (h2., *) |
| Id in git | #12 |
PROJ-123 |
No labels, no estimates, no assignee.
Slice
Input is the grill-me summary if one exists, otherwise the conversation. Cut into tickets where each ticket is a vertical slice — a demoable path through the layers the feature actually reaches — sized as one testable goal. A ticket nobody can demo on its own is two half-tickets; re-cut it.
Fields (every ticket)
GitHub body (markdown):
## What & why
<what changes and why it matters, 2–4 sentences>
## Acceptance criteria
- [ ] <concrete, checkable statement — one per line>
## Out of scope
<from grill-me Rejected/parked, plus anything this ticket deliberately skips>
## Git
- branch: `feat/<slug>` or `fix/<slug>`
- commits: `Add match list on Rugby page (#N)`
- PR: `Closes #N`
Jira description (wiki markup):
h2. What & why
<what changes and why it matters, 2–4 sentences>
h2. Acceptance criteria
* <concrete, checkable statement — one per line>
h2. Out of scope
<from grill-me Rejected/parked, plus anything this ticket deliberately skips>
h2. Git
* branch: feat/PROJ-123-<slug> or fix/PROJ-123-<slug>
* commits: Add match list on Rugby page (PROJ-123)
* PR: PROJ-123 in title and body (do not transition to Done)
Also record dependencies: which of the drafted tickets block this one.
Acceptance must be testable. Not "the page should feel nice". Prefer "given empty matches, the Rugby page shows the empty state".
Gate
Show the full draft: every ticket verbatim, plus the blocking edges. Then ask numbered control questions, each with a recommended answer, covering:
- Granularity — any ticket to split or merge?
- Blocking edges and order
- Anything missing or to cut
The user's go is the only path to Create — for a single ticket too.
Create
Create in dependency order (blockers first) using the platform file. Capture each new id. Add blocking links (Jira issue links; GitHub: Blocked by / Blocks in the body). Update last-used backend.
Done when every approved ticket exists with its links, each reported back by browse URL — and nothing beyond the approved list was touched.
Reconcile
When the plan behind existing tickets has changed: fetch open tickets (platform file), compare against the new plan, and draft a proposal — create, update, or close each affected ticket. The whole proposal passes the same Gate before anything is touched.