| name | 5d-refine |
| description | Stress-test the plan through adversarial review and edge case analysis. Use when: (1) After PLAN phase in 5D-SDD workflow, (2) User wants to 'validate,' 'review,' or 'check' a plan, (3) Before committing significant resources to implementation, (4) Plan exists but hasn't been challenged. This phase catches plan-level errors before they become code-level errors. |
| user-invocable | true |
REFINE Phase
Stress-test the plan before committing to specification.
Stress Test Methods
1. Inversion Attack
Argue against the plan:
- "Here's why this will fail: [reasons]"
- "The hidden dependencies are: [list]"
- "This assumes X, but what if X is false?"
Force the user to defend or amend.
2. Edge Case Probing
For each core behavior, ask:
- "What happens when [unusual input]?"
- "What if [dependency] is unavailable?"
- "How does this behave at [scale extreme]?"
Document answers or flag as "needs resolution."
3. Stakeholder Simulation
Roleplay different perspectives:
Skeptical Engineer: "This seems over-engineered. Why not just [simpler approach]?"
Impatient PM: "When will this ship? What's the MVP?"
Confused User: "I don't understand how to [core action]."
Ops On-Call: "How do I debug this at 3am?"
4. Dependency Audit (Height)
List everything the plan depends on:
- External services
- Team knowledge/skills (what capabilities must exist?)
- User behaviors
- Business conditions
- Adjacent domain skills that might block progress
Rate each: stable / risky / unknown
5. Quadrant Stress Test
Probe each quadrant for weaknesses:
| Quadrant | Stress Question |
|---|
| Individual Inner | "What understanding gaps exist?" |
| Collective Inner | "Where might stakeholders disagree?" |
| Individual Outer | "What artifacts are under-specified?" |
| Collective Outer | "What system constraints are ignored?" |
6. Time Trajectory Check
- "How have similar plans failed historically?"
- "What's changing in this domain that affects the plan?"
- "Does this plan transcend and include current approaches, or just replace them?"
7. Level Check (Depth)
Ask yourself: Is refinement improving the plan, or is the user defending their original idea with better words?
Signs of defensive refinement:
- Adding complexity to protect core assumptions
- Dismissing objections rather than addressing them
- "That won't happen" without evidence
If defensive: return to SPAR.
Output Format
## Refinement Summary
**Stress tests passed:**
- [test]: [how addressed]
**Edge cases documented:**
- [case]: [planned handling]
**Dependency risks:**
- [dependency]: [risk level] - [mitigation]
**Plan amendments:**
- [change made based on refinement]
**Unresolved issues:**
- [issue]: [why deferred / needs more info]
**Ready for SPEC phase:** [yes/no]
Exit Criteria
Proceed to SPEC when:
- Major objections have responses (not dismissals)
- Edge cases are documented (even if handling is "error out")
- No high-risk dependencies without mitigation
- Plan text has been updated with refinements
