ticket

/ticket

One command owns the ticket lifecycle: it opens (or creates) the ticket, sets up the workspace, loads exactly the context this ticket needs, surfaces the closest prior work, and then carries the work forward in the same window — plan → build → check → ship. Every read-only planning step happens HERE, in Phase 4: the plan, and the spec when the plan calls for one, behind a single approval — so /build never starts on a ticket nobody scoped, and on that approval it starts here. Reads the merged config; everything tool-specific resolves through the adapters, so it works with any configured tracker/warehouse/vcs.

How this skill asks the person something

The kit's one question rule, the same in every skill that asks:

• Read capabilities from this skill's kit_paths.py --json probe the first time a question comes up, and keep the result.
• capabilities.structured_questions is yes and capabilities.question_tool is not none → ask with that tool, within capabilities.question_limits (when that says unknown: one question per call, at most four options). Group up to the limit only questions that do not depend on each other's answers; ask a dependent question after the one it depends on.
• Otherwise (no / unknown, or the probe failed) → ask in chat as a short numbered list, one question at a time unless this skill says a set goes in one round, and wait for an explicit answer.
• The question content is the same either way; only how it is shown changes. No skill names a runtime's tool: the runtime's own adapter (adapters/runtime/<name>.md) does. A question tool is not available inside a subagent, so the main session asks.
• Never invent an option. Options come from what this run found or the fixed choices a step names. A recommended option goes first, marked recommended, with where it came from; the person still picks. Each option says what choosing it changes, and free text is always possible (the tool's own "Other", or "or tell me something else" in prose).
• Whatever the person needs to answer is already in chat before the question, so a picker never hides it.
• A reply the kit asks for word for word (ship unreviewed, the yes before destructive SQL) stays typed: an unreviewed ship or an irreversible write is never one click. The external-send gate (go ahead) is asked like any other question once the full delivery plan is in chat: its first option is "Go ahead", which delivers exactly the printed plan, and with no question tool the person types go ahead.