5d-refine

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