scope

name

scope

description

Front door of the eng pipeline. Takes a task description, explores the codebase deeply, decides (with the user) whether it needs a Jira ticket and whether to split into one or many tickets, then writes a planning doc per ticket into the project's .plan folder — including real file:line touchpoints, house conventions, and open questions for the next step. Use when the user describes a feature/task and wants it scoped, broken down, or turned into Jira tickets. Triggers: "scope this", "break this down", "turn this into tickets", "plan this feature".

scope — explore, decide ticket breakdown, draft the planning docs

You are the first pass of a five-skill pipeline. Everything downstream (grill, eng-review, tdd, execute) reads the docs you produce, so the quality of your exploration and the sharpness of your open questions determine whether the rest of the pipeline succeeds.

First, read the doc schema at ${CLAUDE_PLUGIN_ROOT}/SPEC.md and obey it exactly — file layout, section headings, frontmatter keys.

Steps

1. Understand the task

Take the user's task description verbatim. If it's a one-liner, that's fine — your job is to expand it through exploration, not to demand a spec upfront.

2. Explore the codebase — do this thoroughly

This is the highest-value part of the skill. Do not skim.

• Find the files, modules, and existing patterns this task touches.
• Record real file:line references, not vibes ("modify the parser" is useless; match.ts:42 is gold).
• While exploring, note house conventions relevant to the task: how are APIs defined here? how are React components structured? how are tests written? where does config live? Capture these with file refs — they go in the ## Conventions & Patterns section so downstream code matches house style.
• For broad codebases, consider dispatching parallel Explore agents to map different areas, then synthesize.

3. Decide the ticket breakdown — ASK, never guess

Once you understand the scope, present a proposal to the user with the interactive question tool. Cover:

• Does this even need a Jira ticket? (some work is trivial / a chore)
• One ticket or many? If many, propose the specific boundaries and why these and not others, with a one-line rationale each.
• Let the user confirm, merge, split, or override.

This is the single highest-leverage moment in the pipeline. Getting the breakdown wrong wastes everything downstream. Show your reasoning; let them decide.

4. Write the docs

Create <project-root>/.plan/<feature-slug>/:

• README.md — feature index per the schema: original task, breakdown decision
  • rationale, and the ticket table (phase scoped).
• One <NN>-<ticket-slug>/doc.md per ticket per the schema. Fill: Problem, Scope (in/out), Codebase Touchpoints, Conventions & Patterns, and most importantly Open Questions.
• Set frontmatter phase: scoped, needs-jira, depends-on.

5. Open Questions are the handoff — invest in them

Every ambiguity you couldn't resolve from the code becomes an Open Question. Be specific and code-aware ("the CSV import at import.ts:88 has no dedupe — what should happen on a duplicate asset ID?"). These are grill's starting ammunition. A vague question here = a weak grill later.

6. Hand off

Tell the user what you created (paths), summarize the breakdown, and end with: "Run /grill next to resolve the open questions and sharpen scope."