Menu
Go from a Jira ticket (usually the current branch name) to a shared understanding of what to build, before any implementation.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Coordinate parallel ticket workers as an event-driven control plane through repos worktrees, Pi sessions, delegated pull-request review, squash merges, and filesystem tracker frontiers. Use when orchestrating implementation tickets rather than implementing or reviewing one ticket directly.
Implement one ticket handed off by the orchestrator and open a PR for review.
Manage work in the local Tickets filesystem tracker. Use when the user asks to inspect, search, create, claim, update, move, rename, complete, or lint a Tickets project or ticket.
Plan a huge chunk of work — more than one agent session can hold — as a shared map of decision tickets on your issue tracker, and resolve them one at a time until the way to the destination is clear.
Provides comprehensive code review guidance. Helps catch bugs, improve code quality, and give constructive feedback. Use when: reviewing pull requests, conducting PR reviews, code review, reviewing code changes, establishing review standards, mentoring developers, architecture reviews, security audits, checking code quality, finding bugs, giving feedback on code.
Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.
| name | work |
| description | Go from a Jira ticket (usually the current branch name) to a shared understanding of what to build, before any implementation. |
| disable-model-invocation | true |
The branch is named after a Jira ticket. Reach shared understanding with the user about what this ticket really asks for — before discussing how to build it.
Use the jira-acli and confluence-acli skills for any Jira/Confluence reads. Use the project's domain glossary and respect any ADRs in the area you're touching.
Derive the ticket key from the branch name and read the story. If it belongs to an epic, read the epic for the larger goal — a small one-off may have none. Follow any doc links (Confluence, design docs, external references); for research/design tickets the real spec usually lives outside Jira.
If the ticket is a jira ticket and it is not in the active sprint move it into the active sprint. If it is not yet assigned to me assign it to me.
Explore the repo for the docs, existing implementation, and the pieces this ticket will touch or build on. Pull only what bears on this ticket; skip the rest. You're done when you can state what exists today and where this ticket fits, without guessing.
State your understanding back to the user — short and punchy, never walls of text:
Check this with the user. Once they've confirmed or corrected it, run a /grilling session to sharpen the approach, then hand off when the approach is agreed.
