New

---
description: Create one or more tickets. Aborts at any gate save to inbox (if an inbox stage is configured); full completion lands in the pickable stage.
argument-hint: [optional starting description; otherwise the user is prompted]
---

# /ticket:new

Run the ticket creation workflow per `.claude/config.yaml`. There is a single entry point for new tickets: this command. A request may resolve to **one ticket** or **a small slate of dependent tickets** (typically 2–3). Claude decides this silently at step 3 — the user is **not** gated on the split decision. The default is one ticket; split whenever keeping it as one would push effort past the project's `effort.pickable_allowed`. Backlog hygiene is a hard constraint: every ticket landing in a `pickable`-roled stage must satisfy `effort.pickable_allowed` — no exceptions.

**Alignment is a first-class goal.** A ticket is only as good as the shared understanding behind it. Before any ticket is committed, an interview pass (step 2.5) walks the decision tree and resolves every material ambiguity — so what lands on the backlog reflects what the user actually wants, not the AI's best guess. The two understanding gates (steps 1 and 2.5) are where the user's view and the agent's understanding are reconciled.

The user's starting input: $ARGUMENTS

If $ARGUMENTS is empty, ask the user "What do you want to capture?" and use their reply as the starting input before proceeding.

## Engine dependency

This command delegates every read/write to the `ticket-engine` skill. Invoke it once at the start (loads + validates config) and as needed for each operation. The engine resolves:

- The `inbox` role → stage (if any). **If null, the "Save as inbox" option is omitted from every gate** and the save-as-inbox semantics block below is unreachable.
- The `pickable` role → stage. New tickets land here when fully committed.
- The active `types` map (and which type-specific gates apply — see § Type-specific gates).
- The `effort.pickable_allowed` set used as the size cap.
- References (`references.architecture`, `references.roadmap`, etc.) — silent-skip if null/missing.

If the engine reports `"No .claude/config.yaml found"`, stop and tell the user `"Run /ticket:init first."`

## Workflow

> All gates below are asked via the `AskUserQuestion` tool — present the listed `question` / `header` / `options` directly. Never prompt the user to type one of the option labels. Free-text follow-ups remain inline asks.

### Step 0 — assign an ID

Call the engine's `assign_next_id()` to get the next ID. If the work splits at step 3, call `assign_next_id(slate_size=N)` later to reserve consecutive IDs at that point. Slug generation (filesystem only) is the engine's concern; the command never invents filenames.

On GitHub backend: IDs are assigned by GH at issue-create time, not here. The engine `create_artifact` operation handles this; this step is a no-op.

### Step 1 — understanding gate

Restate the user's request in 2–4 sentences. Include:

- What is being asked for (your interpretation).
- Best-guess `type` (one of `types:` keys from config).
- Best-guess `milestone` from `references.roadmap` if defined and present; otherwise `unscoped`.

End with the gate, asked via `AskUserQuestion`:

- **question:** "Does this match what you meant?"
- **header:** "Understanding"
- **options** (omit **Save as inbox** if no inbox role exists):
  - **Continue** — proceed to step 2.
  - **Edit** — revise; ask what to change (free-text follow-up), loop until continue or save.
  - **Save as inbox** — invoke `save_as_inbox`; commit; stop. (Omitted if no inbox role.)
  - **Abort** — discard. Nothing is committed.

### Step 2 — current implementation analysis

Identify and read the files relevant to this ticket. For features, the existing primitives the new work builds on. For bugs, the suspected root-cause file plus surrounding context. For tech, the smell or capability area.

Output a 5–10 line summary:

- Files involved.
- Which extension surface this lands on (project-specific).
- Which invariants from `references.architecture` apply (skip this line if the reference is null or missing).

End with the gate, asked via `AskUserQuestion`:

- **question:** "Does the analysis look right?"
- **header:** "Analysis"
- **options** (omit **Save as inbox** if no inbox role exists):
  - **Continue** — proceed to alignment grilling.
  - **Edit** — revise; ask what the analysis got wrong (free-text follow-up), re-analyze, and re-gate.
  - **Save as inbox** — invoke `save_as_inbox` and stop.
  - **Abort** — discard. Nothing is committed.

### Step 2.5 — alignment grilling

**Purpose:** reconcile the user's intent with the agent's understanding *before* scope is locked. The freshly-read code (step 2) means most open questions can now be answered from the source rather than asked. This step is where the ticket stops being a guess.

**Method — interview the user about this ticket until you reach a shared understanding.** Walk down each branch of the decision tree, resolving dependencies between decisions one at a time. The grilling is scoped to *this ticket*, bounded by the constraints below — not an open-ended interrogation of the whole design.

1. **Build the decision tree.** From the user's request + the step 2 analysis, enumerate the open questions whose answers would change *what gets built, how it's typed, what "done" means, or how big it is* — i.e. anything that moves `type`, scope, acceptance criteria / regression test, `effort`, `priority`, `risk`, or the split decision. Order them so a question never depends on one asked later (resolve parents before children).

2. **Answer from the codebase first.** If a question is answerable by exploring the repo, explore and answer it — do **not** ask the user. If it's genuinely new, do quick research first so your recommendation is grounded. Only the residual, genuinely-undecided, material questions reach the user.

3. **Ask one branch at a time, each via `Ask