Implement Ticket

---
name: implement-ticket
description: Implement a Linear ticket end-to-end using TDD inside a dedicated git worktree. Verifies the spec is complete, writes tests first, then implements, iterates until passing, and opens a PR.
---

Implement a Linear ticket using a test-driven, spec-driven workflow inside an isolated git worktree. Stop immediately and flag any ambiguity — never guess at missing spec.

## Input

The user provides a ticket ID (e.g. `OPE-12`). If not provided, ask for it before proceeding.

---

## Step 1 — Load and verify the ticket spec

Use the Linear MCP to fetch the issue: title, description, status, labels, comments.

Evaluate the ticket against this gate. **Every item must pass before any code is written.**

**Context & Goal**
- [ ] Clear problem statement or user story
- [ ] Explicit, verifiable acceptance criteria

**Implementation Plan**
- [ ] Files or modules to create/modify are named
- [ ] Approach is described (not just "implement X" — the _how_ is specified)
- [ ] Edge cases and error handling are defined

**Test Cases**
- [ ] At least one happy-path test with concrete inputs and expected outputs
- [ ] At least one edge-case or error-path test

**If any item fails:**
Print a `SPEC INCOMPLETE` block listing every gap, e.g.:

SPEC INCOMPLETE — cannot proceed

Missing:

• No acceptance criteria defined
• Implementation plan does not name which files to change
• No error-path test cases

Run /refine-ticket OPE-12 to complete the spec first.

Stop. Do not create a worktree. Do not write any code.

**If all items pass:** print `SPEC VERIFIED — proceeding to implementation` and continue.

---

## Step 2 — Derive the worktree name

1. Read the git user from `git config user.name` and convert to initials (e.g. "Jan Matter" → `jm`). If not set, ask the user for their author tag.
2. Slugify the ticket title: lowercase, replace spaces and special characters with hyphens, max 50 characters (e.g. "Add payment hook for batch settlement" → `add-payment-hook-for-batch-settlement`).
3. Compose the branch name: `<author-tag>/<ticket-id>/<slug>` (e.g. `jm/OPE-12/add-payment-hook-for-batch-settlement`).
4. Compose the worktree path: `branches/<author-tag>/<ticket-id>/<slug>` relative to the repo root.

---

## Step 3 — Create the worktree and branch

Run from the bare repo root (the directory containing `branches/`):

```bash
git worktree add branches/<author-tag>/<ticket-id>/<slug> -b <author-tag>/<ticket-id>/<slug>

Confirm the worktree was created. All subsequent file reads and writes happen inside this worktree.

Update the Linear ticket status to "In Progress" using the MCP.

---

Step 4 — Understand the codebase

Before writing any code, read the relevant parts of the worktree:

1. Read CLAUDE.md for conventions, test framework, and tooling
2. Locate existing test files to understand the test style and runner (use Glob/Grep)
3. Read the files named in the implementation plan
4. Identify the test command (e.g. go test ./..., pytest, npm test)

If you cannot determine the test command, look for a Makefile, package.json, or CI config. If still unclear, ask the user — do not guess.

---

Step 5 — Implement the tests first

Write all test cases from the spec before writing any implementation code.

Rules:

• Place tests in the correct location for this codebase (mirror the file structure or use _test conventions as appropriate)
• Cover every test case in the spec: happy path, edge cases, error cases
• Use concrete, exact values for inputs and expected outputs as defined in the spec
• Tests must fail at this point (no implementation yet) — confirm they compile and fail as expected
• Do not write any production code yet

If a test case in the spec is ambiguous (e.g. "expected output is correct") and cannot be translated to a concrete assertion:

SPEC AMBIGUITY — cannot write test

Test: <test name>
Problem: <what is ambiguous>
Action needed: <what the spec needs to clarify>

Pause and wait for clarification before continuing.

---

Step 6 — Implement the code

Implement the production code to satisfy the tests, following the implementation plan in the spec exactly.

Rules:

• Only implement what is specified — do not add unrequested features or abstractions
• Follow the file structure and naming conventions of the codebase
• Do not modify test files during this step
• If the spec requires a design that is technically impossible or contradicts existing architecture, stop and flag it:

SPEC CONFLICT — cannot implement

Issue: <what the spec asks for>
Conflict: <why it cannot be implemented as written>
Options:
  A) <alternative approach>
  B) <alternative approach>

Pause and wait for direction before continuing.

---

Step 7 — Run the test loop

Run the test command and iterate until all tests pass.

Each iteration:

1. Run the test command and capture output
2. If all tests pass → proceed to Step 8
3. If tests fail:
   • Read the failure output carefully
   • Identify whether the failure is a bug in the implementation or a sign the spec is wrong
   • If implementation bug: fix the production code and loop
   • If the fix would require changing the test (i.e. the spec is wrong): stop and flag it:

SPEC CONFLICT — test cannot pass as written

Test: <test name>
Failure: <exact error>
Analysis: <why the spec and reality conflict>

Pause and wait for direction.

Loop limit: After 10 iterations without all tests passing, stop and report:

• Which tests are still failing and why
• What has been tried
• What is blocking progress

Ask the user how to proceed rather than spinning indefinitely.

---

Step 8 — Commit the changes

From inside the worktree, commit all changes:

git add <relevant files>
git commit -m "<imperative-mood summary of what was implemented>

Implements <ticket-id>: <ticket title>

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>"

Follow the commit style conventions in `C ```