scope

name	scope
description	Exploratory workflow for understanding problem spaces and drafting feature proposals, refactorings, or complex bug-fixes. Creates detailed tickets in your issue tracker without doing implementation work.
model	opus

Scope - Problem Space Exploration & Ticket Creation

Helps you thoroughly understand a problem space through codebase exploration and iterative dialogue, then creates a well-specified ticket for future implementation.

This skill does NOT write code. It explores, questions, understands, and documents.

Workflow

1. Initial Discovery

Understand what the user wants to explore:

• What feature are they considering?
• What refactoring are they contemplating?
• What bug needs detailed investigation?
• Is this greenfield or modifying existing code?

Ask clarifying questions:

• Scope and boundaries
• Problem statement
• Desired outcome (not implementation details yet)

Output: Clear understanding of what problem space to explore.

2. Codebase Exploration

Use exploration tools to understand context:

• Spawn Explore agent (set thoroughness based on scope: "quick", "medium", "very thorough")
• Use Grep to find relevant code patterns
• Use Read to examine key files identified
• Map out the current architecture/implementation

For third-party dependencies:

• Use WebFetch to read API documentation
• Clone relevant repositories to /tmp for examination if needed
• Understand integration points and constraints

Exploration goals:

• Where does this change fit in the architecture?
• What existing code will be affected?
• What patterns/conventions are already established?
• What are the integration points?
• What similar features exist that we can learn from?

Output: Comprehensive understanding of the relevant codebase areas.

3. Iterative Refinement

Use AskUserQuestion to refine understanding:

• Present what you've learned from exploration
• Ask about approaches (if multiple valid options exist)
• Clarify edge cases and requirements
• Discuss trade-offs between approaches
• Validate assumptions about existing code

Loop until both Claude and user have:

• Precise understanding of what to build
• Clear rationale for approach chosen
• Identified edge cases and constraints
• Agreed on acceptance criteria

Important: This is collaborative design, not just requirements gathering. Challenge assumptions, propose alternatives, discuss trade-offs.

Output: Shared, precise understanding of the work to be done.

4. Ticket Synthesis

Draft ticket content adaptively based on type:

For feature proposals:

• Problem statement (what problem does this solve?)
• Proposed solution (high-level approach)
• Acceptance criteria (specific, testable)
• Technical notes (implementation considerations, affected components)
• Security considerations (if the change introduces new attack surface, handles user input, touches auth/authz, or affects trust boundaries — note what controls will be needed. Consult the sec-blue-teamer agent if the implications are non-obvious.)
• Out of scope (what explicitly won't be done)
• Open questions (if any remain)

For refactorings:

• Current state (what's problematic about existing code)
• Desired state (what we want it to look like)
• Motivation (why is this worth doing)
• Approach (high-level refactoring strategy)
• Risk assessment (what could go wrong)
• Affected areas (files/modules that will change)

For complex bug fixes:

• Bug description (observed behavior)
• Root cause (from your exploration)
• Proposed fix (high-level approach)
• Why this happened (what allowed the bug)
• Verification plan (how to confirm fix works)
• Regression prevention (tests/checks to prevent recurrence)

Format guidelines:

• Use markdown
• Be specific, not vague
• Include code references (file paths, line numbers, function names)
• Link to relevant documentation or issues
• Make it actionable (someone else should be able to implement from this)

Output: Draft ticket content for user review.

5. Review & Refine Ticket

Present draft to user:

• Show complete ticket content
• Highlight any areas of uncertainty
• Ask if anything is missing or unclear

Iterate if needed:

• Adjust based on feedback
• Add missing details
• Clarify ambiguous sections

Output: Approved ticket content ready to create.

6. Create Ticket

Detect the issue tracker and create the ticket per references/trackers.md (Detection Procedure + "Create" operation). Capture and present the resulting ticket URL.

Output: Created ticket with URL.

Skill Boundaries

This skill will:

• Explore code extensively
• Ask lots of questions
• Synthesize understanding into tickets
• Challenge your assumptions
• Propose alternatives
• Create issues in your issue tracker

This skill will NOT:

• Write production code
• Make commits
• Run tests or linters
• Modify files (except ticket creation)
• Implement features

Notes

Exploration thoroughness:

• Quick exploration: ~5 minutes, high-level understanding
• Medium exploration: ~15 minutes, detailed component analysis
• Very thorough: ~30 minutes, comprehensive system understanding

Ticket quality over speed:

• Take time to understand deeply
• Don't rush to ticket creation
• Better to ask more questions than create vague tickets

Integration with /implement:

• These skills are separate and complementary
• /scope creates the ticket, /implement implements it
• Ticket created by /scope can be handed to someone else or tackled later with /implement