← ClaudeAtlas

trackerlisted

Working with the issue tracker — verifying auth, reading a ticket, commenting, transitioning, attaching proofs, and linking the branch and PR to the ticket.
vsdudakov/troika · ★ 0 · AI & Automation · score 57
Install: claude install-skill vsdudakov/troika
# Tracker Generic tracker rules. Profile owns URL, auth, commands, and allowed writes. **Kind** reference · **Used by** [architect](../../agents/architect.md) (develop-flow step 1) · [releaser](../../agents/releaser.md) (step 7) · **When** reading a ticket, commenting, transitioning, or attaching a proof · **Ends with** the ticket read or updated, with the response checked ## Verify auth before blaming the ticket Run the profile's **real API call** and expect a 200 — a CLI's "who am I" usually echoes local config and succeeds with a dead token. A stale token reads back as "issue does not exist" or "no projects found", never a clear 401, so suspect the token before the ticket key. Check the **exported** environment variable, not the file meant to export it. ## Read Read requirements, state, ordered comments, attachments, fields, and every link. Never plan from title. ## Comment [Commenter](../../agents/commenter.md) writes one factual comment per event. Post through a quoted heredoc. <a id="transitions"></a> ## Transition — only if the profile declares one Profile alone authorizes and names transitions: | Profile says | What every "transition the ticket" instruction in `troika/` means | | --- | --- | | Transitions exist, with names | run the named transition at the step that calls for it | | **No transitions** — the board's state is the humans' | do nothing to the state; the profile names the equivalent write instead (usually a comment), and that is the whole obliga