agentleFS
kwiggenkwiggen/claude-code-plugin/skills/validator/SKILL.md

validator

Skill1 starsChanged 4 months agoMITView on GitHub

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.

4 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

3 rules. 0 are common, 3 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 3 edited versions we read keep these.

  • 3

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    BAD: Should not proceed without fundamental rethinking

    line 23
  2. Distinctive:

    No generic praise — everything must be specific

    line 32
  3. Distinctive:

    Before delivering the report, verify:

    line 134

“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
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.

QuestionWho Can AnswerWhat 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

VerdictTone
GOODAffirming with constructive suggestions
NEEDS MAJOR WORKDirect and constructive — "here's what to fix"
BADBrutally 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] |

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.