/prep

name: prep
description: Spec a ticket before it is dispatched. Brainstorms it, decides everything it can recommend an answer for, asks a present human about the little that survives, and leaves the spec, the decisions and anything still open as one ticket comment. No worktree, no branch, no pull request, and the ticket stays where it was.
when_to_use: "/csw:prep 1088", "prep ENG-1088", "spec ENG-1088 before tonight's batch", "is this ticket ready to dispatch?"
argument-hint: "[ticket-ref]"

Prep a ticket for dispatch

**Announce at start:** "Using csw:prep to spec <ticket> without touching the repo."

Invocation: $ARGUMENTS

A batch loop only compounds *after* a failure: a ticket blocks, the question lands on the ticket, and the next dispatch starts from a better brief — so one wasted dispatch is the price of every question discovered. Prep moves that discovery in front of the dispatch, where it costs a comment instead of a night.

Prep does not implement anything. It reads, it decides everything it can defend a recommendation for, it asks about the little that survives that test, and it writes one comment carrying all of it.

**Prep is an interactive command**, and that is the design centre rather than a variant of it. The person who can answer typed the invocation and is sitting there for the whole run, so a run ends in one of two states, both of which leave the ticket **dispatchable**:

• Every question that would block an autonomous build has an answer, recorded on the ticket in

the run that asked it.

• There were none, and prep says so.

The second is the common one and the one to aim for. A question left in a comment for someone to notice tomorrow is not a third state — it is the first state, deferred by a day, and that day is exactly what prep exists to remove.

Step 0: Read the config

csw-config json
csw-config path

If `csw-config path` prints nothing, this repo has no `.claude/csw.json`. Say so and show the defaults you are about to use. Prep runs nothing destructive, so this is a note rather than a stop — but `tracker` is the one key it genuinely needs, because it decides where the comment goes.

Step 1: Resolve the ticket

csw-ticket normalize "<the reference from the invocation>"

If the invocation carried no reference, ask which ticket. Do not pick one.

If normalisation exits non-zero, report its message and stop. Prepping the wrong ticket is worse than prepping none: the comment lands somewhere a later dispatch will read it as its brief.

Step 2: Read the ticket — and only read it

Read it from the tracker named by `csw-config get tracker`:

• `linear` — the Linear MCP tools. Fetch the issue and its existing comments.
• `github` — `gh issue view <number> --json title,body,labels` and

`gh issue view <number> --comments`.

• `none` — ask for the ticket text.

Read the **whole** description, not the title. Ordering constraints and "replace, do not delete" style requirements live in prose and are invisible to structured queries — and those are exactly the requirements a dispatch discovers too late.

**Do not claim it.** `csw:work` Step 2 moves the ticket to In Progress because it is about to do the work; prep is not. A prepped ticket that left Todo is a ticket the batch loop no longer pulls, which removes it from the very column prep exists to improve.

Read the existing comments too, and read them before brainstorming rather than after. A question already asked and answered in the thread is a decision, not an open question, and re-asking it in the prep comment tells the next dispatch to go and re-litigate it. If a prior `**CSW prep**` comment is already there, this run supersedes it: carry its decisions forward, say which of its questions are still open, and do not repeat the ones that have since been settled.

Step 3: Brainstorm it, in surface-the-questions mode

Run **superpowers:brainstorming** against the ticket.

Its usual mode designs the implementation. This is not that mode: prep runs in **surface-the-questions mode**, and the difference is the whole point of the command. The design belongs to the dispatch, which will have a worktree to try it in and tests to find out whether it was right. What prep produces is the set of things that dispatch would otherwise stop on.

You may read anything in the repo. Reading is not a side effect. Check what the ticket asserts against what the code actually does — a ticket that names a file, a flag, or a function that has since moved is a dispatch that will spend its run discovering that.

What to come out with:

• **A first-pass spec.** What the change is, in the terms the codebase actually uses.
• **The candidate questions** — the ones that must be answered before this can run

*unattended*. That is the bar. "Which of these two names is nicer" does not stop a dispatch; "does this replace the existing path or sit alongside it" does. They are *candidates*: Step 4 decides which of them prep answers itself and which are worth a human's attention.

• **Contradictions.** Anything the ticket asserts that the codebase contradicts, quoted from

both sides so a human can adjudicate it without going and looking.

If the superpowers skills are not installed, say so once and do the same work by hand. The skill is a strong recommendation, not a hard dependency.

Step 4: Triage — decide what you can defend, keep only what you cannot

Take every candidate from Step 3 and apply one mechanical test:

> **If you can mark an option "(Recommended)", you have your answer.** Do not ask — decide, > and record the decision with the reasoning that made it one.

That test is not a judgement call about how important the uncertainty feels. It is something prep can apply to itself: if you find yourself writing an option list whose first entry is the obvious one, that list is a decision you have not finished making. It comes from measurement — prep run over four tickets asked 4-6 questions on every one o