| name | work-ticket |
| description | Work ONE ticket from a .scratch/<feature>/issues/ local-tracker backlog end to end, in a single command, so each implementation session is one step instead of many. Runs the Soloist start-of-session protocol, picks the next open+unblocked ticket (or the one you name), claims it, implements it test-first via /implement (tdd → gates → code-review → commit), then updates the ticket Status and PROGRESS.md. Use when the user says 'work the next ticket', '/work-ticket', 'do the next PRD/issue', or names a ticket number to implement. One ticket per invocation. |
work-ticket — one command per implementation session
Purpose: the user does not want to re-run the per-session ceremony by hand. This skill does the
whole loop for one ticket so a fresh session is a single command.
Default backlog: .scratch/stability-audit-2026-07/issues/ (the stability & security audit). If
the user names a different .scratch/<feature>/ or ticket, use that instead. Tracker conventions
are in docs/agents/issue-tracker.md (one file per ticket NN-<slug>.md; a Status: line and a
Blocked by: line near the top; frontier = lowest-numbered ticket that is open + unblocked +
unclaimed).
Do these steps in order. Do exactly one ticket, then stop.
1. Select the ticket
- If the user passed a ticket number or path, use that ticket.
- Otherwise scan the backlog's
issues/ and pick the frontier: the lowest-numbered ticket
whose Status: is not done/resolved, that is unblocked (every id in its Blocked by:
line is a ticket already done/resolved), and unclaimed. Print which ticket you chose and why.
- If nothing is unblocked, report the state (what's blocking what) and stop.
2. Soloist start-of-session protocol (MANDATORY — root CLAUDE.md §1)
Before writing any code:
- Read
PROGRESS.md (current state) and this repo's CLAUDE.md.
- Read the ticket in full.
- Read the behavior + design contracts for the area the ticket touches:
plan/05 (Solo
behavior), plan/04 and plan/06 (architecture/blueprint), and ARCHITECTURE.md. Invoke any
matching tauri-* skill and /impeccable if the ticket touches Tauri config or UI (per
CLAUDE.md §5). Confirm the ticket's plan still matches the code before starting.
3. Claim it
- Set the ticket's
Status: line to claimed and save, so a parallel session won't grab it too.
- Confirm you are on the working branch
fix/stability-audit-2026-07 (the audit tickets live
there). If the branch is missing or you're on another branch, tell the user and let them
choose — do not silently switch or branch.
4. Implement it — invoke /implement on the ticket
Run /implement against the ticket file. It drives /tdd at the seams named in the ticket's Test
plan (a failing test first, then make it pass, slice by slice), runs typecheck + single test files
as it goes and the full suite at the end, then /code-review on the diff, then commits to the
current branch. While implementing, hold to the ticket's Fix approach, Test plan, and
Acceptance; honor the locked owner decisions recorded in the ticket and the audit README; do
not pull later-scope in; never weaken or skip a test to go green (CLAUDE.md §12/§15).
5. Gates (project definition of done)
Run the real gates and paste the outcome:
just lint (fmt, clippy -D warnings, tsc, eslint, prettier, dependency-direction) — exit 0.just test (or the crate/UI subset the ticket touched, plus the full suite once).
If anything is red, stop: leave the ticket Status: claimed, report the failure with output,
and do not mark it done. Never report green you did not see.
6. Close out
On green:
- Set the ticket
Status: to done and append a short ## Comments note: what changed, the gate
results, and the commit sha.
- Update
PROGRESS.md per CLAUDE.md §10 — a factual, evidence-backed entry (ticket id, what was
done, tests/gates run). Commit that doc update too.
- If the ticket needs live/runtime verification this headless session can't do (e.g. a GUI walk or
real-runtime check — currently tickets 02 and 08), implement + unit-test it, set
Status: needs-human-verify instead of done, and tell the user exactly what to check in
the running app (just dev).
7. Report
End with: the ticket you closed (or why you stopped), gate results, the commit sha, and the next
frontier ticket so the user knows what the following session will pick up. Then stop — one ticket
per invocation.
