Loading...
Loading...
Prevents premature execution on ambiguous requests. Analyzes request clarity using 5W1H decomposition, surfaces hidden assumptions, and generates structured clarifying questions before work begins. Use at the start of any non-trivial task, or when a request could be interpreted multiple ways. Triggers on "뭘 원하는건지", "요구사항 정리", "clarify", "what exactly", "scope", "requirements", "정확히 뭘", "before we start".
npx skill4agent add whynowlab/swing-skills swing-clarifyAddresses the cognitive failure of Premature Closure — AI interprets ambiguous requests using defaults and assumptions instead of asking, producing confident output that answers the wrong question.
| Dimension | Question | Example Gap |
|---|---|---|
| What | What exactly is being built/changed? | "Build auth" — login? signup? password reset? SSO? |
| Who | Who uses this? What roles/permissions? | "Users can edit" — all users? admins only? owners? |
| Where | Where does this live? What system/service? | "Add to the API" — which API? new endpoint? existing? |
| When | What triggers this? What's the lifecycle? | "Send notifications" — real-time? batched? on what event? |
| Why | What problem does this solve? What's the success criteria? | "Improve performance" — latency? throughput? cost? |
| How | Are there constraints on implementation? | "Use the existing stack" — which parts? any exceptions? |
**Q[N]: [Specific question]**
Options: (a) [option] (b) [option] (c) [option]
My default: (b) — [why this is the reasonable default]
Impact: [what changes depending on the answer]## Scope Analysis: [Request Summary]
### 5W1H Decomposition
| Dimension | Status | Detail |
|:----------|:-------|:-------|
| What | Clear / Assumable / Ambiguous | [extracted or missing info] |
| Who | Clear / Assumable / Ambiguous | [extracted or missing info] |
| Where | Clear / Assumable / Ambiguous | [extracted or missing info] |
| When | Clear / Assumable / Ambiguous | [extracted or missing info] |
| Why | Clear / Assumable / Ambiguous | [extracted or missing info] |
| How | Clear / Assumable / Ambiguous | [extracted or missing info] |
### Ambiguity Score: [N]/6 → [Green light / Quick clarify / Must clarify]
### Questions (if any)
**Q1: [Question]**
Options: (a) ... (b) ... (c) ...
My default: (b) — [reason]
Impact: [what changes]
**Q2: ...**
### Clarified Scope (after answers)
- [bullet 1]
- [bullet 2]
- [bullet 3]
### Remaining Assumptions
- [assumption 1] — rated Assumable because [reason]User: "Build me an auth system"
AI: I have a few questions before we start:
1. What programming language would you like to use?
2. What database do you prefer?
3. Do you want tests?
4. What's your timeline?
5. How many users do you expect?
6. Should it be containerized?
7. What CI/CD platform do you use?User: "Build me an auth system"
## Scope Analysis: Auth System
### 5W1H Decomposition
| Dimension | Status | Detail |
|:----------|:-------|:-------|
| What | Ambiguous | "Auth system" — login only? signup? password reset? SSO? |
| Who | Ambiguous | User roles not specified — single role or RBAC? |
| Where | Clear | Next.js app (inferred from project structure) |
| When | Clear | Standard request-response auth flow |
| Why | Assumable | Secure user access (standard) |
| How | Assumable | Project uses TypeScript + Prisma (from codebase) |
### Ambiguity Score: 2/6 → Quick clarify
**Q1: What auth flows are needed?**
Options: (a) Email/password login only (b) Login + signup + password reset (c) Full OAuth2 with Google/GitHub providers
My default: (b) — most apps need the complete basic flow
Impact: (a) = 2 hours, (b) = 4 hours, (c) = 8 hours + provider setup
**Q2: User roles?**
Options: (a) Single role — all users equal (b) Admin + User (c) Custom RBAC with permissions
My default: (a) — add roles later when needed (YAGNI)
Impact: (c) requires permission tables, middleware, and role management UI