Agent skill
validator
Synthesizes validation analysis into a structured 8-section report with clear verdict (GOOD / NEEDS MAJOR WORK / BAD), strengths, critical flaws, blindspots, and actionable path forward. Use after assumption-challenger and antipattern-detector have produced their analyses, or standalone for quick validations. Produces the final deliverable for /validate.
Install this agent skill to your Project
npx add-skill https://github.com/kwiggen/claude-code-plugin/tree/main/skills/validator
SKILL.md
Validator — Report Synthesis
Transforms raw validation analysis into a structured, actionable 8-section report. The report provides an unambiguous verdict and specific guidance.
Report Structure
Section 1: Verdict
Purpose: Unambiguous assessment with confidence level.
Options:
- GOOD: Ready for implementation (may have minor suggestions)
- NEEDS MAJOR WORK: Fundamentally sound but has significant gaps
- BAD: Should not proceed without fundamental rethinking
Include: Clear verdict, confidence level (High/Medium/Low), one-sentence rationale.
Section 2: What You Got Right
Purpose: Acknowledge genuine strengths (builds trust for criticism).
- 2-3 specific things done well, with why each matters
- What to preserve in revisions
- No generic praise — everything must be specific
Section 3: Critical Flaws
Purpose: Expose fatal or near-fatal weaknesses.
For each flaw:
- Flaw: What's wrong
- Why It Matters: Business/technical impact
- Consequence: What happens if not addressed
Prioritized list, most critical first. Specific evidence, not vague concerns.
Section 4: What You're Not Considering
Purpose: Surface blindspots and hidden assumptions.
Types to check:
- Unstated assumptions treated as facts
- Ignored failure modes
- Missing stakeholders
- External dependencies not accounted for
- Scale implications not considered
Section 5: The Real Question
Purpose: Reframe if solving wrong problem.
Use when:
- Problem definition is too narrow or broad
- Symptoms treated instead of root cause
- Constraint accepted that should be challenged
- Solution in search of a problem
Format: "You're asking [stated question], but the real question might be [reframed question]."
Skip if problem is correctly framed — state this explicitly.
Section 6: What Bulletproof Looks Like
Purpose: Define measurable success criteria for revision.
For this to be ready:
- [ ] [Criterion 1]
- [ ] [Criterion 2]
- [ ] [Criterion 3]
Section 7: Recommended Path Forward
Purpose: Concrete next steps based on verdict.
- If GOOD: Minor improvements, what to monitor, validation checkpoints
- If NEEDS MAJOR WORK: Specific areas to revise, suggested approach for each
- If BAD: Alternative approaches, what fundamental rethinking is needed
Section 8: Questions to Answer First
Purpose: Information gaps blocking progress.
| Question | Who Can Answer | What It Blocks |
|---|---|---|
| [Question] | [Person/Team] | [Decision] |
Verdict Criteria
GOOD if:
- Core assumptions are valid or validated
- Timeline is realistic (includes buffer)
- Resources are adequate or plan accounts for gaps
- Risks are identified and manageable
- No fundamental anti-patterns
- Team can execute with current capabilities
NEEDS MAJOR WORK if:
- Core approach is sound but...
- Significant gaps exist in 2+ areas
- Timeline or budget needs adjustment
- Some assumptions need validation before proceeding
- Addressable anti-patterns detected
BAD if:
- Core assumptions are invalid
- Fundamental anti-pattern detected (e.g., Startup Death Spiral)
- Timeline is fantasy (off by >2x)
- Budget is unrealistic by >50%
- Team cannot execute even with adjustments
- Wrong problem being solved
Tone Calibration
| Verdict | Tone |
|---|---|
| GOOD | Affirming with constructive suggestions |
| NEEDS MAJOR WORK | Direct and constructive — "here's what to fix" |
| BAD | Brutally honest but respectful — "here's why to stop" |
Be direct. Be specific. Be constructive. No sugarcoating, no hedging.
Quality Checklist
Before delivering the report, verify:
- Verdict is clear and justified with evidence
- Strengths are genuine, not inflated
- Flaws are specific with concrete evidence
- Blindspots go beyond surface-level issues
- Reframe is warranted (or explicitly skipped with reason)
- Success criteria are measurable, not vague
- Path forward is actionable with specific steps
- Questions are answerable and necessary
- Tone matches verdict severity
- Every point is specific — zero generic feedback
Examples
WRONG vs. CORRECT: Success Criteria
WRONG — vague and unmeasurable:
For this to be ready:
- Team should be confident in the solution
- Performance should be acceptable
CORRECT — specific and verifiable:
For this to be ready:
- P95 latency ≤ 200ms under 500 concurrent users (load test documented)
- Zero critical/high findings in security review
- Rollback procedure tested in staging with < 5 min recovery
Output Format
# Validation Report: [Title]
**Subject**: [What was validated]
**Date**: [Date]
---
## 1. Verdict
### VERDICT: [GOOD / NEEDS MAJOR WORK / BAD]
**Confidence**: [High / Medium / Low]
[One-sentence summary]
---
## 2. What You Got Right
[2-3 specific strengths with why they matter]
---
## 3. Critical Flaws
### Flaw 1: [Title]
**Why It Matters**: [Impact]
**Consequence**: [What happens if not addressed]
---
## 4. What You're Not Considering
[Blindspots, hidden assumptions, ignored scenarios]
---
## 5. The Real Question
[Reframe or "Problem is correctly framed because..."]
---
## 6. What Bulletproof Looks Like
For this to be ready:
- [ ] [Criterion 1]
- [ ] [Criterion 2]
- [ ] [Criterion 3]
---
## 7. Recommended Path Forward
[Specific next steps based on verdict]
---
## 8. Questions to Answer First
| Question | Who Can Answer | What It Blocks |
|----------|---------------|----------------|
| [Question] | [Person/Team] | [Decision] |
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
gemini-reviewer
Dual code review: gets independent reviews from both Claude and Gemini API, then synthesizes agreements, unique findings, and a verdict. Use when users say "gemini review", "dual review", or want a second-perspective code review. Requires GEMINI_API_KEY environment variable to be set.
pr-writer
This skill should be used when the user asks to "create a PR", "open a pull request", "write a PR description", "push and create PR", or needs to generate a best-in-class pull request description based on commits. Provides industry-standard PR description formatting following conventional commits, Microsoft Engineering Playbook, and HackerOne best practices.
code-reviewer
Reviews code for logic flaws, edge cases, performance bottlenecks, security vulnerabilities, maintainability concerns, architecture best practices, and adherence to local patterns and CLAUDE.md guidelines. Use when users ask for code review or analysis, including reviewing uncommitted changes, the last local commit, unpushed code, or a specific GitHub pull request.
antipattern-detector
Detects common failure patterns in proposals, architectures, plans, and decisions. Use when reviewing any plan to identify red flags before they become problems. Covers architecture, timeline, team, process, and technology anti-patterns. Works on any domain — not just code.
github-insights
Provides team GitHub activity insights including merged PRs, contributor leaderboards, merge velocity, review participation, and PR size analysis. Use when users ask about team productivity, who merged PRs, code contribution stats, review patterns, or developer activity.
teach-me
Pedagogical code walkthrough that teaches developers about their own code. Explains choices, tradeoffs, alternatives, and refactoring opportunities. Use when users say "teach me", "explain my changes", "walk me through", "what did I build", or want to understand their code at a deeper level. Works on uncommitted changes, last commit, unpushed commits, or a PR.
Didn't find tool you were looking for?