// Create or update repository workflow tickets. Use when the user asks to write, create, edit, promote, drop, or close a ticket, or when a discussion needs to be captured as a durable ticket.
[HINT] Download the complete skill directory including SKILL.md and all related files
| name | lead-write-ticket |
| description | Use when the user asks to create, edit, promote, drop, close, or durably capture a repository workflow ticket. |
Target: user request
ws/convention.read(name: "ticket-conventions") - path format, status flow, phase rules, stem rules, templates.read a ticket file other than the current target - use ws/subquery(question: "<focused ticket-inspection question>"), then ws/agents.result(name: <subquery-key>, timeout_seconds: 600), for any other ticket inspection.Classify category/status; apply judge: spec-gate only when the operation creates or moves a non-epic, non-research ticket into ready/.
If user request references an existing ticket, read it.
Create (new ticket):
a. Determine category from the topic.
b. Choose initial status directory (idea/ for vague, todo/ for accepted actionable backlog - see judge: initial-status).
c. Write the ticket using the frontmatter template and a clear problem/goal statement. Populate related-mental-model with the mental-model stems (filename without .md) that were consulted or arose during the current session - recovery hint for future sessions, not a validated link. Omit if no mental-model docs were relevant.
d. If category is epic: write only scope, non-scope, child ticket board, cross-child decisions, and done/drop/defer criteria; reference existing/planned children and start a separate ws:lead-write-ticket invocation for any child creation or child edit.
e. If category is not epic and multiple phases are warranted (see judge: phase-need), structure as ### Phase N: <title> sections. Note inter-phase dependencies explicitly.
f. After drafting, verify scope - see judge: ticket-scope.
g. If status is ready/: add an entry to the ## Ticket Queue section in ai-docs/_index.md. Format: `stem` - one-line purpose and dependency notes.
Edit (existing ticket):
a. Read the ticket first.
b. Apply the requested changes (update phase, move status).
c. If the target is an epic, keep edits at board level; for detailed implementation discussion, stop after the epic edit and start a separate ws:lead-write-ticket invocation for the child ticket.
d. For moves, use native git mv and add completed: date in frontmatter (-> .done/).
Phase content - for non-epic actionable tickets, capture goals, constraints, rationale, rejected alternatives, and suggested approaches. Leave codebase-derived details (paths, type reuse, integration patterns, signatures, testing classifications) to the plan.
Intent review - re-read the written/edited ticket against the preceding conversation:
Spec-stem check - skip epic and research:
a. If status is todo/: preserve any existing spec: links as optional recovery hints; do not require stem discovery, do not fire judge: missing-spec-entry, and do not suppress the proceed prompt.
b. If status is ready/: use ws/specs.find or ws/specs.status to confirm canonical stems.
c. If status is ready/: ensure the ticket frontmatter spec: field lists every stem the phases implement. Add missing stems. If a phase implements behavior with no spec entry, see judge: missing-spec-entry.
d. If status is ready/: remind that commits implementing this ticket should include a ## Spec section with those stems.
Commit - call ws/git.commit(paths: ["<ticket-path>"], title: "<title>", ai_context: ["<bullet>"]); include ai-docs/_index.md when the queue changed. If separate child invocations changed child tickets, those invocations own their own commits and outputs.
Proceed prompt - if the ticket is epic, do not suggest proceeding on the epic path; suggest creating, promoting, or proceeding a child ticket instead. Otherwise suggest ws:lead-proceed as the next step after ticket authoring, unless judge: missing-spec-entry fired in step 6. Proceed routes to skeleton, plan, or implementation based on artifacts and session warmth.
Emit the created ticket path on its own final line: Ticket: ai-docs/tickets/<status>/<stem>.md. For epics, also state that this path is a board artifact, not an implementation target. Callers such as ws:lead-proceed capture this path from prefix-stage output.
Fires on any non-epic, non-research action that creates or moves a ticket into ready/. idea/ creation and idea/ -> todo/ triage are ungated.
Identify the relevant spec file for the topic.
Use ws/specs.find or ws/specs.status if a relevant spec file or stem is identifiable.
If no relevant spec file exists, or no entry covers this behavior -> stop. Name the uncovered behavior; suggest ws:lead-write-spec before continuing.
Place in idea/ when the topic is exploratory or underspecified; place in todo/ when the scope and goal are accepted actionable backlog. todo/ spec: links are optional recovery hints; ready/ is the spec-gated implementation queue. When uncertain, prefer idea/ - triage is cheap.
Over ~200 lines is a soft signal; over 300 lines, act. First, prune plan-level detail (file paths, function signatures, integration specifics) - that belongs in a plan document. If an epic is still large, move details into child tickets; if a non-epic is still large, introduce an epic and split into child tickets.
Applies only to non-epic actionable tickets. Prefer more phases over fewer inside one cohesive child ticket; split unrelated reviewable units into separate child tickets. Single-component, single-concern work may be one phase.
Fires when a phase implements caller-visible behavior with no entry in any spec file. Stop the authoring flow, tell the user which phase surfaces un-specced behavior, and suggest ws:lead-write-spec before continuing. Skipping this loses traceability for the new behavior and bypasses the canonical chain's spec-impact gate.
A ticket is the primary context-recovery artifact. Every choice optimizes for recoverability of intent: capture decisions, constraints, and rejected alternatives when writing so downstream skills never re-derive settled context. When ambiguous, preserve recoverability.