| name | design-validator |
| description | Stress-test a feature design or PRD with diverse simulated user personas. Triggers include "validate this design", "stress test this PRD", "run user validation", "user persona feedback", "design review with personas", or when the user has a design document and wants adversarial feedback before committing to implementation. Runs 5 rounds of iterative refinement with an adversarial Skeptic who actively tries to reject the design. |
Design Validator
Run simulated user research on any design document. Generates diverse user personas (including an adversarial Skeptic), iterates through 5 rounds of feedback, and produces a validation report showing how the design evolved and where confidence is high or low.
Requires: ruflo MCP (hive-mind).
This is the standalone version of Feature Forge's Phase 1.5. It works on any PRD, design doc, or feature spec — it does not require the full Feature Forge workflow.
Input
The user provides one of:
- A path to an existing document (
docs/prd/my-feature.md, or any markdown file)
- A design described inline in the conversation
- A Figma URL or other design artifact to analyze
If the input is a file path, read it. If inline, capture it verbatim.
Workflow
Design Document
│
▼
1. Generate Personas (5-7, domain-specific)
│
▼
2. Validation Rounds (up to 5)
Present → React → Synthesize → Decide → Revise → Convergence Check
│
▼
3. Validation Report
Round-by-round evolution, Skeptic's verdict, confidence assessment
│
▼
4. Offer to update the original document (ask user)
Step 1: Generate Personas
Analyze the design to identify the domain, then generate 5-7 personas from these archetypes. See ../references/user-personas.md for detailed guidance on instantiating each.
| Archetype | Role |
|---|
| Power User | Depth, scale, configurability |
| Newcomer | Discoverability, onboarding, terminology |
| Skeptic | Adversarial. Must find a reason to reject. |
| Edge-Case User | Accessibility, i18n, boundary conditions |
| Reluctant Adopter | Migration path, switching cost |
| Adjacent Stakeholder | Downstream effects, audit, permissions |
| Domain Expert | Correctness, standards, professional quality |
Give each persona a name, specific role, daily workflow, and success/failure criteria.
Step 2: Validation Rounds
Initialize the hive-mind:
mcp__ruflo__hive-mind_init(queenId: "validator", topology: "mesh")
mcp__ruflo__hive-mind_spawn — one per persona
mcp__ruflo__hive-mind_memory(action: "set", key: "current-design", value: "<design content>")
Each Round
Present — Broadcast the current design (plus what changed since last round):
mcp__ruflo__hive-mind_broadcast(
message: "Review this design from your persona's perspective. Design: <content>. Changes since last round: <changes>. Provide structured feedback using the template.",
priority: "high"
)
React — Each persona returns structured feedback:
- First Reaction, What I Like, What Confuses Me, What's Missing, Deal-Breakers, Suggestion
- Skeptic additionally: Reason to Reject (mandatory)
Synthesize — Identify:
- Consensus themes (3+ personas)
- Minority reports (1 persona, potentially important)
- Contradictions (design tensions needing trade-offs)
- Skeptic's rejection (evaluate honestly — highest priority if valid)
Decide — For each theme: Accept (revise), Reject (document rationale), Defer (future), or Investigate (next round).
Revise — Update the design. Record what changed, who triggered it, why.
Convergence Check — Count material changes. Two consecutive rounds with zero → stable, exit early. Round 5 still has changes → flag unresolved tensions.
Persona Rotation (Rounds 3+)
Optionally drop a persona whose concerns are fully addressed and add one that tests a new dimension revealed by earlier feedback.
Step 3: Validation Report
Write to docs/prd/<name>-validation.md (or alongside the input file):
# User Persona Validation Report: <Name>
**Date**: <date>
**Rounds completed**: <N> (converged at round <M> / did not converge)
**Source document**: <path or "inline">
## Personas Used
| Name | Archetype | Context | Rounds Active |
|------|-----------|---------|---------------|
## Round-by-Round Evolution
### Round 1
**Feedback themes**: ...
**Changes made**: ...
**Changes rejected**: ... (with rationale)
## Skeptic's Verdict
<What the Skeptic tried to reject, whether the design survived, and their final assessment>
## Design Changes Summary
| # | Change | Triggered By | Round | Rationale |
|---|--------|-------------|-------|-----------|
## Convergence Analysis
- Stabilized at round: <N>
- Total material changes: <count>
- Change velocity: <trend>
## Confidence Assessment
### High Confidence (strong persona consensus)
### Medium Confidence (some disagreement)
### Low Confidence (unresolved tensions — needs real user testing)
## Recommendations for Real User Testing
<What simulation couldn't resolve>
Step 4: Offer Update
Ask the user: "Would you like me to update the original document with the validated changes, or keep it as-is with the validation report alongside?"
If yes, update the document inline, marking changes with [Validation Round N] annotations.
Reference Files
These are shared with the Feature Forge skill:
../references/user-personas.md — Persona archetypes, adversarial Skeptic instructions, feedback template
../references/phase1.5-user-validation.md — Detailed loop mechanics, convergence tracking, report format