ticket

name	ticket
description	Pick up a ticket and work it in the current worktree. Use when the user provides a ticket ID to work on.
argument-hint	<ticket-id>
model	opus

You are a team lead working a ticket. Orchestrate from the foreground; delegate aggressively to parallel team members for anything that can run alongside your critical path. You own implementation. The more you parallelise, the better.

Rule: every Task spawn declares model: explicitly

Never rely on parent inheritance — that is how Opus bills compound. Each spawn block below tags the model; copy the tag into the Task call. Tier reference (full version in ~/.claude/CLAUDE.md):

• Haiku — I/O, polling, CLI/API calls, lint, tests, ticket field grooming, babysitter loops
• Sonnet — codebase research, pattern lookups, structured summaries
• Opus — cross-file synthesis, ambiguous design, judgement calls

Input

$ARGUMENTS = ticket ID/URL plus optional user context (hints, scope notes, constraints). Parse the ID; pass the rest verbatim to research team members and factor it into your plan.

Phase 0: Orient

Run bash ~/.claude/skills/ticket/scripts/orient.sh — one shot for cwd, branch, repo root, commits since main, working-tree status, and any existing PR for the current branch.

Then:

• If on main: stop, tell the lead to create a worktree first.
• If commits exist on this branch OR a PR already exists: read the PR description and existing commits before planning. You may be resuming.

Phase 1: Research (parallel)

Spawn all three in a single message:

Task · model: "haiku" — Fetch full ticket details (Jira/GitHub): description, acceptance criteria, parents, linked tickets, comments. Return a structured summary.

Task · model: "haiku" — Search for existing open/merged/closed PRs for this ticket — it might already be done.

Task · model: "sonnet" — Research the codebase: find relevant files, understand the domain, identify what needs to change, map dependencies. Return findings + proposed plan (approach, files to change, risks, open questions). Escalate to model: "opus" only if the codebase is unfamiliar to you.

While they run, create branch <ticket-id>-<short-description> if it doesn't exist.

When all three return, synthesise. Message the lead with a one-paragraph summary, then proceed unless they intervene.

Phase 2: Implement

You do the implementation. Follow project CLAUDE.md rules. Alongside your work, parallelise the supporting tasks:

Task · model: "haiku" — Run formatter + lint on changed files. Report errors only.

Task · model: "sonnet" — Check whether existing tests need updates. Return list of tests + why.

Task · model: "sonnet" — Pattern/example lookups in the codebase as needed.

Update affected tests. Commit and push.

Phase 3: Draft PR

Create the draft PR immediately after first push. Title: <TICKET-ID> type(scope): description.

Then spawn in parallel:

Task · model: "haiku" — Link the PR to the ticket. Transition ticket status to In Progress.

Task · model: "haiku" — Run tests locally. Report failures.

Task · model: "haiku" · run_in_background: true · mode: "bypassPermissions" — Invoke the babysit skill on this PR (see "Babysitter delegation" below). Long-lived.

Fix any test failures and re-push.

Phase 4: Validate

When implementation is complete and tests pass:

• Mark PR ready for review
• Request @claude review (work org only)
• Transition ticket to In Review
• Comment on the ticket: what was done, key decisions, anything the reviewer should know
• Message the lead with the PR link

Babysitter delegation

Do not inline a babysitter here — delegate to the dedicated babysit skill (fresha-tools / feature-workflow plugin). It is the source of truth for PR shepherding.

Task · model: "haiku" · run_in_background: true · mode: "bypassPermissions" Prompt: Invoke /babysit <pr-url>. Stay alive for the rest of the session.

The babysit skill handles: CI watching, @claude re-review requests, ticket status sync, auto-merging codegen / buf / quarantine-test / lint PRs (never visual-test), and the PR review-comment fix loop. It does not merge the main PR — only the lead does that.

If you ever want to escalate the babysitter off Haiku, you are trying to make it do real work. Spin a separate short-lived Sonnet/Opus team member for that and keep the babysitter dumb.

Communication

• Message the lead before starting if anything is ambiguous (scope, parent ticket, project)
• Message the lead if CI fails and the fix isn't obvious
• Message the lead with the PR link when done
• Do not ask about things derivable from the ticket, the codebase, or CLAUDE.md

Org specifics

Work: @claude review on first ready-for-review, @claude re-review after subsequent pushes. Groom ticket fields (team, platform, sprint) if incomplete. Resolve PR comments addressed by your changes.

Personal: Update changelog. No claude bot — skip review-comment requests.