| name | intent-clarifier |
| description | Use when a user request is vague, broad, risky, underspecified, or likely to produce the wrong result unless the real intent is clarified first. Especially useful before feature design, refactoring, architecture changes, safety/compliance work, product planning, document generation, and multi-file coding tasks. |
Intent Clarifier Skill
Purpose
Evaluate whether the user's prompt contains enough intent to proceed responsibly. If not, ask minimal clarification questions and/or create an Intent Brief before doing the work.
Core rule
Do not ask questions for every prompt. Ask only when missing intent would materially change the output, architecture, implementation, safety/compliance posture, cost, risk, user experience, or definition of success.
Workflow
1. Extract the apparent task
State internally or briefly in the response:
Apparent task: [one sentence]
2. Infer likely intent
Identify the likely real-world purpose behind the task.
Likely intent: [one sentence, or "unclear"]
3. Score intent strength
Use:
- Strong
- Moderate
- Weak
- Missing
- Conflicting
4. Check intent dimensions
Look for:
- Intended user / audience
- Desired outcome
- Problem being solved
- Decision supported
- Scope
- Constraints
- Required context
- Success criteria
- Risks / failure modes
- Verification method
- Escalation rules
Do not expose the full checklist unless it helps the user.
5. Decide whether to proceed
Proceed when the task is simple, assumptions are obvious, and risk is low.
Ask 1–3 clarification questions when missing intent would materially change the work.
Stop and clarify before acting when the request affects safety, compliance, legal, finance, security, privacy, destructive operations, major architecture, or major scope.
6. Ask minimal clarification
Ask the smallest number of questions needed. Prefer questions that collapse multiple unknowns.
Good examples:
- "Who is this for, and what decision should it help them make?"
- "Is the priority speed, correctness, maintainability, security, or user experience?"
- "Should this be an MVP path or a production-grade implementation?"
Avoid long questionnaires unless the user asks for discovery.
7. Offer a recommended default
When helpful, propose a default assumption.
Example:
My recommended default is to treat this as an MVP first, with production-grade security boundaries documented but not fully implemented yet.
8. Create or update an Intent Brief
For substantial work, create or update an intent brief under:
docs/intent/
Use this structure:
# Intent Brief: [Name]
## Original Prompt
## Clarified Intent
## Primary User / Beneficiary
## Problem Being Solved
## Decision Supported
## Desired Outcome
## Scope
## Constraints
## Required Context
## Success Criteria
## Assumptions
## Open Questions
## Risks / Failure Modes
## Human Review / Escalation Rules
## Intent Status
Draft | Clarified | Approved | Superseded
## Last Updated
9. Execute against the intent
Once intent is clear enough, use the Intent Brief as the controlling artifact for planning, coding, writing, and review.
10. Final intent check
Before finishing, verify:
Does this output satisfy the clarified intent?
If not, correct course or explain the remaining gap.
