docs(commands): add tool-availability and ceremony scale to start-work

Two audit fixes. A "Tool availability" section degrades gracefully when Linear MCP, gh, /voice, or Playwright are missing: do what the available tools allow, surface what couldn't run, don't fail the phase. A "Ceremony scale" section sizes the process to the work, so a trivial fix skips the ticket, branch, and gates unless asked. Separately, the claim now splits by tracker: personal todo claims wait until after the Justify gate (no rollback needed if killed), while Linear and GitHub claims happen first to signal intent but record prior state so a killed task restores cleanly.

1 files changed, 41 insertions, 5 deletions

diff --git a/.claude/commands/start-work.md b/.claude/commands/start-work.md
index 1da2f89..d99a9dc 100644
--- a/.claude/commands/start-work.md
+++ b/.claude/commands/start-work.md
@@ -16,6 +16,27 @@ Three review gates separate the phases. The user can redirect or kill the work a
 6. **Ready to commit (gate 3).** Report, stop for approval.
 7. **Hand off** to the Review-and-Publish flow in `commits.md`.
 
+## Tool availability
+
+The full flow assumes Linear MCP, the GitHub CLI (`gh`), the `/voice` skill, and the Playwright skills are present. None is required. When an assumed tool is missing, degrade gracefully — do not block the task on it.
+
+- **Linear MCP unavailable.** Treat the task as unticketed for tracking purposes (Phase 1 "Unticketed", Phase 7 status moves skipped). Note in the session and the final report that Linear state was not updated, so the user can sync it by hand.
+- **`gh` unavailable.** Skip the GitHub claim/assign and the `gh pr create` step. Commit locally and report that the PR must be opened manually, with the suggested title and body from the Phase 7 draft.
+- **`/voice` unavailable.** Draft the commit and PR text directly and flag that the voice pass did not run, so the user reviews the prose more closely at the gate.
+- **Playwright skills unavailable.** Fall back to the scripted-manual verification mode in Phase 5 even for browser UI, and note the missing automation.
+
+In every case: do the work the available tools allow, and surface what could not be done rather than failing the phase.
+
+## Ceremony scale
+
+Match the ceremony to the size of the work. The full path — ticket, branch, three approval gates, commit-per-phase — fits a real change with review surface. A trivial local fix does not need it unless the user asks.
+
+- **Trivial fix** (a typo, a one-line correction, a config tweak with no behavior surface): skip the ticket, the branch, and the gates. Make the change, verify it, report. Apply the full flow only if the user asks for it.
+- **Small change** (one file, contained, low risk): keep the gates but collapse them — a single combined justify-and-approach note is enough, and one commit covers it.
+- **Standard change** (the default): the full flow as written below.
+
+When in doubt, ask the user which scale fits rather than defaulting to maximum ceremony on a two-line fix. The gates protect against wasted work and scope creep, not against small obvious edits.
+
 ## Usage
 
 ```
@@ -88,11 +109,16 @@ If the existence check finds nothing conclusive, that's the expected case. Proce
 
 ## Phase 1: claim
 
-Make ownership explicit before any other work starts. The exact steps depend on where the task lives.
+Make ownership explicit. *When* the claim happens depends on where the task lives, because the cost of a wrong claim differs.
+
+- **Personal todo tasks** carry no signal to anyone else, so there is nothing to gain by claiming before the work is justified. **Defer the todo.org claim to after the Justify gate (Phase 2).** Nothing changes in the file until the user has approved the task. If the gate kills the task, there is no rollback to do.
+- **Team trackers** (Linear, GitHub) signal intent to teammates — "someone is on this" prevents duplicate work. Here claiming first earns its keep, so the claim happens now. But a claim that the Justify gate later reverses must roll back cleanly, so **record the prior state before changing it** (see each subsection), and the Phase 2 rollback restores exactly that state.
+
+The exact steps depend on where the task lives.
 
 ### Linear ticket
 
-1. Fetch the ticket with the Linear MCP tools.
+1. Fetch the ticket with the Linear MCP tools. **Record the prior state** — current status, assignee(s), and label — so the Phase 2 rollback can restore exactly it.
 2. Move status to **In Progress**.
 3. Assign the user. If another assignee is already present, add the user as a second assignee. If the Linear API does not accept multiple assignees, post a comment ("Picking this up alongside <existing assignee>") and proceed.
 4. Verify the ticket has exactly one of these labels: **Bug**, **Test**, **Chore**, or **Feature**. If missing or wrong, ask the user which applies and set it.
@@ -100,17 +126,21 @@ Make ownership explicit before any other work starts. The exact steps depend on
 
 ### GitHub issue
 
-1. Fetch with `gh issue view <n> --json title,body,state,assignees,labels`.
+1. Fetch with `gh issue view <n> --json title,body,state,assignees,labels`. **Record the prior assignee(s) and labels** from that output for the Phase 2 rollback.
 2. Assign to the user: `gh issue edit <n> --add-assignee @me`.
 3. Verify the Bug / Test / Chore / Feature label. Add if missing.
 4. Post a comment noting you are starting work.
 
 ### Todo.org task
 
+Deferred to after the Justify gate — no change to the file in Phase 1. Once Phase 2 is approved:
+
 1. Locate the heading the user referenced.
 2. Change the TODO keyword to `DOING`.
 3. Add exactly one tag: `:bug:`, `:feature:`, `:test:`, or `:chore:`. Ask the user which applies if none is obvious. Todo.org is personal, so there is no assignee step.
 
+Because nothing was claimed before the gate, a killed task needs no todo.org rollback.
+
 ### Unticketed
 
 1. Note in the session that the work is unticketed.
@@ -141,7 +171,13 @@ Present the justification to the user. Stop. Wait for questions and explicit app
 
 Do not generate the approach while waiting. The user may kill the task at this gate, and any pre-generated approach would be wasted work.
 
-If the user kills the task, roll back the Phase 1 claim: move the ticket back to its prior status, remove the assignment you added, and remove the label you added (if any).
+**On approval**, do the deferred personal claim now: for a todo.org task, run the Phase 1 "Todo.org task" steps (keyword to `DOING`, add the one tag). Team-tracker claims already happened in Phase 1, so there is nothing more to do for them here.
+
+**If the user kills the task**, roll back only the team-tracker claim made in Phase 1, restoring the prior state recorded there:
+
+- **Linear:** move the status back to the recorded prior status, remove the assignment you added (keep any pre-existing assignee), remove the label you added (only if it was absent before), and delete the "picking this up" comment if you posted one.
+- **GitHub:** `gh issue edit <n> --remove-assignee @me`, remove any label you added that was absent before, and delete the start-work comment.
+- **Todo.org:** nothing to undo — the claim was deferred and never ran.
 
 ## Phase 3: approach (gate 2)
 
@@ -303,7 +339,7 @@ Follow `commits.md` exactly. Summary of the flow:
 - **Taking the ticket's word that the problem still exists.** Tickets age. Read the source. A `git log --grep` for a fix commit is a hint, not a check — fixes ship under all kinds of commit-message wording, and the buggy behavior may be gone for reasons that never landed in a commit titled "fix." Five minutes of source-read at Phase 0.3 saves an entire Justify-and-Approach cycle on a phantom problem.
 - **Skipping the Justify gate.** "This is obviously worth doing" is exactly what the gate exists to verify. If the answer really is obvious, the gate takes thirty seconds.
 - **Skipping the Approach gate.** Implementation without a plan is how scope creep happens. It is also how the user loses the chance to redirect.
-- **Marking a task In Progress before Phase 2 approval.** If the Justify gate kills the task, the Claim should roll back cleanly.
+- **Marking a personal todo task DOING before Phase 2 approval.** Personal claims carry no teammate signal, so they wait until the gate clears — a killed task then needs no rollback. Team-tracker claims (Linear, GitHub) are the exception: they happen in Phase 1 to flag intent, but only after the prior state is recorded so the gate can restore it cleanly.
 - **Blurring the gates.** Write the justification, stop, wait. Do not pre-generate the approach while waiting. The user may kill the task and the pre-work gets wasted.
 - **Treating Feature tasks as skippable on the Approach gate.** Features especially need the migration, backwards-compat, and feature-flag questions answered up front.
 - **Letting the TDD cycle drift.** If the test passes before the implementation is written, the test is wrong. Confirm the red before moving to green.