implement-ticket
Installation
SKILL.md
implement-ticket
Essential Principles
- Both modes run this same skill. Local mode executes the workflow in this session; spawn mode hands the new session a prompt naming this skill, and that session recognises itself as the ticket's agent and self-selects local mode - so the guardrails reach whichever session executes.
- One agent per ticket. A live agent already named after the ticket almost certainly means the ticket is being worked - re-triggering would re-assign, re-plan, and collide with its worktree, so the mode script stops instead. This is also the recursion backstop: if self-detection ever failed, the dispatched session halts here instead of prompting itself.
- The workflow must run from the ticket's repo - the worktree is created relative to it, and a spawned session inherits only cwd.
Parameters
| Param | Required | Notes |
|---|---|---|
ticket_id |
yes | Ticket ID; the script uppercases it. Names the spawned agent and tab, with the repo's name prefixed for a bare issue number (agent-skills-42) since Herdr names are unique across all workspaces. In the tracker's own form (ABC-123, #42) - Step 2 works out which tracker |
model |
no | Spawn mode only; passed to spawn-agent verbatim - never guess a value the user didn't give. When the mode comes back local, say it can't apply to an already-running session and continue locally |
Arguments are positional - ticket_id first, then model: /implement-ticket ABC-123 sonnet. There is no flag for choosing the mode; the script decides it from where it runs.