Work Ticket

---
description: Pick up and work on the next ticket from the Ready column
---

Launch the github-ticket-worker agent to implement the next prioritized ticket.

> **Reference**: See `docs/TICKET-FORMAT.md` for the expected ticket format.

## Pre-Flight Verification (REQUIRED)

Before starting work on any ticket, verify the following. STOP and report to
the user if any check fails — do not continue with partial tooling.

1. **`gh` CLI is authenticated and the repository is accessible** — Run
   `gh auth status` and `gh repo view --json nameWithOwner`. If either fails,
   STOP and instruct the user to fix the issue.
2. **GitHub account is correct** — Run `gh auth status` and confirm the active
   account matches the expected worker/bot account. If only a personal account
   is active, STOP and instruct the user to run `scripts/ensure-github-account.sh`.
3. **Claude hooks are registered** — Check that hook files referenced in
   `.claude/settings.local.json` exist and are executable. WARN if any hook is
   missing or not executable.
4. **Project board is accessible** — Attempt to read the project board. If
   access is denied or the board does not exist, STOP and report.

## Drain Mode Pre-Flight (REQUIRED when `DRAIN_CONTEXT` is set)

If `DRAIN_CONTEXT=true` is set in the environment (the signal that
`/work-ticket` was invoked from `/drain` — the drain orchestrator),
additionally verify:

1. **Safety class is present** — Run `gh issue view <N> --json labels`
   and confirm exactly **one** `safety:*` label is set. If zero or more
   than one, STOP with `safety:unclassified — abort`, leave the ticket
   in place, and signal the drain orchestrator to continue with the
   next ticket (greedy failure semantics — a missing classification is
   the operator's call to make, not the worker's).
2. **Safety class is drain-eligible** — The single label must be one of
   `safety:flagged`, `safety:internal`, or `safety:reversible`. If the
   label is `safety:hot`, STOP with `safety:hot — refused by drain`,
   leave the ticket in Ready, and signal continue. Hot tickets are a
   feature, not a failure; they wait for the operator.

Standalone `/work-ticket` (when `DRAIN_CONTEXT` is unset, e.g. a human
runs the skill directly) does NOT require a safety label — this preserves
backward compatibility for human-driven work. The two drain-mode checks
above are gated on the env var exactly so this guarantee holds.

See [`docs/safety-classes.md`](../../docs/safety-classes.md) for the
taxonomy decision tree and worked examples.

**Pre-substitution placeholder check.** If you see any of the four
bootstrap-time templated values (documented in
[`docs/PLATFORM-GUIDE.md`](../../docs/PLATFORM-GUIDE.md) §
"Bootstrap-time templated values") still in their raw `{{ ... }}` form
anywhere in this file or other `.claude/commands/*.md` files when you
read them, STOP with a message pointing the operator at
`bootstrap-workflow.md` — the substitution step hasn't run yet. Re-run
`bash scripts/substitute-config-placeholders.sh` (or re-bootstrap)
before proceeding. This avoids the failure mode where unsubstituted
template strings leak into runtime instructions.

## Critical Rules

1. **Branch from main**: `feature/issue-{number}-short-description`
2. **Move ticket to In Progress** on the project board before starting work
3. **All tests must pass before pushing** — never use `--no-verify`
4. **Monitor CI after PR creation**: `gh pr checks <PR_NUMBER> --watch` — fix failures up to 3 times
5. **Move ticket to In Review** only when CI passes
6. **Auto-handoff to `pr-reviewer` on green CI** — once CI is green and the ticket is in In Review, launch the `pr-reviewer` agent via the Task tool immediately. Do not pause for human approval; green CI means the human is out of the loop until the GO/NO-GO is posted. (Solo mode only — swarm mode skips this; the orchestrator handles review timing.)
7. **Never merge PRs** — human reviewer does this
8. **Never commit directly to main** — always use feature branches and PRs

## Workflow Steps

1. **Select Ticket** — Find top priority in Ready column, verify Definition of Ready, confirm no blockers
2. **Validate Ticket Format** — Check the ticket body for the 4 Power Sections:
   - **A. Environment Context**, **B. Guardrails**, **C. Happy Path**, **D. Definition of Done**
   - If any section is missing or empty:
     1. **STOP** and report to the user exactly which sections are missing —
        make the upstream formatting failure visible as a process problem
     2. Read `docs/TICKET-FORMAT.md`, `docs/TECHNICAL-ARCHITECTURE.md`,
        `docs/AGENTIC-CONTROLS.md`, and the parent epic
     3. Draft the missing sections following `docs/TICKET-FORMAT.md` exactly
     4. Present the draft to the user with a clear diff showing what was added —
        **do not proceed until the user explicitly approves**
     5. Update the GitHub issue with the user-approved version
   - If all 4 sections are present → proceed normally (no delay)
3. **Load Context from Past Sessions** — Query Memory MCP for relevant
   institutional knowledge (silently skip if Memory MCP is not configured
   or returns no results):
   - Extract domain keywords from the ticket title and labels
   - `search_nodes` for `Pattern-` matching those keywords (cap: 3 results)
   - `search_nodes` for `Lesson-` matching those keywords (cap: 3 results)
   - If the ticket has a parent epic, `search_nodes` for `CompletedTicket-`
     in that epic (cap: 4 results, most recent first)
   - Total cap: 10 entities. Summarize findings in a brief
     "Context from past sessions" note before proceeding.
   - If no relevant entities found, produce no output — proceed silently.
4. **Setup** — Create branch, move to In Progress
5. **Implement** — Follow CLAUDE.md standards, write clean code, follow existing patterns
6. **Test Locally** — Run lint and tests. Do NOT push if any fail.
7. **Push** — If pre-push hook fails, fix and retry (see Reference below)
8. **Crea