Scoping

Scoping

Turn a vague ask into something a plan can be written against.

When to trigger

Proactively, whenever the request is missing any of:

• Trigger condition (when does this happen / when should it happen?)
• Expected behavior
• Actual behavior (for bugs)
• Specific user flow or entry point
• Environment (dev / staging / prod)
• Measurable success criteria

Don't guess. Claude's guesses become scope creep later.

The clarification checklist

Ask only the questions whose answers aren't already clear. Typical set:

1. What is the user trying to do? (business outcome, not technical symptom)
2. What happens now? (current behavior, reproduction steps if a bug)
3. What should happen? (target behavior with acceptance criteria)
4. Which users or flows? (scope of impact)
5. Which environment? (local, staging, prod)
6. How will we know it's done? (test or observation)
7. What's explicitly out of scope? (prevents "while you're at it")

Output

Append the clarified scope to the plan artifact under a Clarifications section. If no plan exists yet, create one via the plan skill using the clarified inputs.

What this skill must NOT do

• Do not fill in ambiguous fields with plausible-sounding defaults.
• Do not ask every question every time — only the ones not already answered.
• Do not proceed to Plan until the blocking ambiguities are resolved.

References

• skills/plan/SKILL.md
• templates/plan.md