| name | cross-validation |
| description | Use when user says "validate this", "get feedback", "cross-validate", "what are we missing", when seeking external review before committing to major decisions, when stress-testing a design with senior reviewers, or when reviewer responses need to be synthesized into actionable changes. |
Cross-Validation
Overview
Two-phase skill with a human step in the middle. Phase 1: compile a self-contained prompt that any reviewer can assess without prior context. Phase 2: synthesize responses into consensus levels and actionable changes. The prompt must stand alone — a reviewer should need zero prior context.
When to Use
- Major architectural or product decisions need external validation
- User wants to check blind spots before committing to a direction
- Multiple reviewers (human or AI) will assess the same document
- High-stakes decisions where being wrong is expensive
When NOT to Use
- Quick sanity check on a small decision — just ask directly
- Code review — use
code-review-and-quality
- No
.forge/prd.md or .forge/architecture.md exists yet — produce artifacts first
Common Rationalizations
| Thought | Reality |
|---|
| "We've already thought about this enough" | Internal teams develop blind spots. External eyes catch what you've normalized |
| "The prompt doesn't need full context" | If a reviewer has to ask clarifying questions, the prompt failed |
| "Three reviewers said it's fine, so it's fine" | Unanimous approval is less valuable than one specific objection |
| "Disagreements mean someone is wrong" | Disagreements reveal hidden assumptions — both sides may be partially right |
| "We can synthesize informally" | Informal synthesis loses minority opinions. Structured synthesis surfaces them |
Red Flags
- Prompt requires prior context to understand (not self-contained)
- Questions are generic ("is this good?") instead of specific ("does the auth model handle session revocation within 5 seconds?")
- Synthesis ignores dissenting opinions
- All reviewers agree on everything (questions were too soft)
- Synthesis doesn't distinguish consensus levels
Core Process — Phase 1: Generate Prompt
Re-entry check: If .forge/cross-validation-prompt.md already exists and the user provides reviewer responses, skip to Phase 2.
Step 1: Identify what to validate
Read available .forge/ artifacts. With the user, identify:
- Which decisions are highest-risk (most expensive if wrong)
- Which assumptions have the least evidence
- What specific aspects need external eyes
Step 2: Compile self-contained context
Extract from .forge/ artifacts into a single document that a reviewer can read cold:
- Problem statement (from PRD)
- Key architectural decisions (from architecture.md)
- Trade-offs made and alternatives rejected (from ADRs)
- Current approach summary
Self-containment test: can someone who has never seen this project understand the context and give useful feedback? If not, add more context.
Step 3: Structure questions
Write 10+ specific questions across categories:
- Architecture decisions and trade-offs
- Security and data handling
- Scalability and performance assumptions
- Business model and pricing
- Missing requirements or edge cases
- Risk assessment
- Technical debt implications
Each question must be specific and answerable. Not "is the architecture good?" but "given the multi-tenant requirement, is schema-per-tenant or RLS the better isolation strategy for ?"
Step 4: Define output format
Tell reviewers exactly how to structure their response: numbered answers matching the questions, confidence level per answer, and a "what did we miss?" section.
Step 5: Write the prompt
Write .forge/cross-validation-prompt.md with: context, questions, and response format. Prepend a forge:meta header (generated_by: cross-validation, generated_at: <ISO 8601 UTC with Z>, depends_on: [.forge/prd.md, .forge/architecture.md, …any other artifacts embedded in the prompt] — paths only, never hashes, generated_from: {<each path>: <upstream content_hash AT generation time>}, content_hash: <sha256 first 8 of THIS file's body>). See forge-dependency-graph.
Pause: "Prompt written to .forge/cross-validation-prompt.md. Send this to your reviewers. When you have responses, run /validate again with the responses to generate the synthesis."
Core Process — Phase 2: Synthesize Responses
Step 6: Categorize consensus
For each question, classify the responses:
- Unanimous: all reviewers agree — high confidence in this direction
- Strong consensus: most agree, minor variations — proceed with noted caveats
- Split: roughly even disagreement — requires deeper analysis
- Dissent: one reviewer disagrees strongly — investigate their reasoning
Step 7: Extract actionable changes
From disagreements and suggestions, produce:
- Must change: issues multiple reviewers flagged independently
- Should consider: good ideas from at least one reviewer with strong reasoning
- Monitor: concerns that don't require immediate action but should be tracked
Step 8: Write synthesis
Write .forge/cross-validation-synthesis.md with: consensus summary per question, actionable changes list, and a "best ideas we hadn't considered" section. Prepend a forge:meta header (generated_by: cross-validation, generated_at: <ISO 8601 UTC with Z>, depends_on: [.forge/cross-validation-prompt.md, …reviewer-response files] — paths only, never hashes, generated_from: {<each path>: <upstream content_hash AT generation time>}, content_hash: <sha256 first 8 of THIS file's body>).
Verification
