reality-check
Skill4 starsChanged 3 months agoMITView on GitHub
Evaluate any project, product, or system's claims against its actual implementation — scoring each claim for truth, identifying architectural gaps, assessing competitive positioning, proposing creative solutions, and producing an actionable roadmap. Load when the user asks to evaluate claims, reality-check a project, assess what this project actually does vs what it says, validate product claims, or score a system's credibility. Also triggers on "is this real", "does this work as claimed", "evaluate this project", "assess the gap between claims and reality", "how credible is this", "investor assessment", "score these claims", or "what's real vs marketing".
18 other projects use a version of this.
Adopted by
Most recently taken up by
- NomadicDaddy/aiddtheir own version, first seen Nov 15, 2026
- Ljhhhhhh/skillstheir own version, first seen Nov 15, 2026
- peaknr35/shark-Tank-prooftheir own version, first seen Nov 15, 2026
- scoobydrew83/skillstheir own version, first seen Nov 3, 2026
- microsoft/amplifier-smart-tool-reality-checktheir own version, first seen Oct 17, 2026
- Valeriy1980/claude-skillstheir own version, first seen Oct 13, 2026
Other versions18 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 18
- dazuck/operator-skills★ 17same name
- EmanueleMinotto/minottobot★ 4same name
- microsoft/amplifier-smart-tool-reality-check★ 4same name
- naticorrea-03/claude-code-skills★ 4same name
- peaknr35/shark-Tank-proof★ 3same name
- quatico-solutions/agent-skills★ 2same name
- dazuck/claude-code-skills★ 1same name
- evanmcgoogan/skin-in-the-game★ 1same name
- Ljhhhhhh/skills★ 1same name
- NomadicDaddy/aidd★ 1same name
8 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository125 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .cursor/rules/agent-loom-routing.mdcCursor rule
- .cursor/rules/agent-loom-skills-index.mdcCursor rule
- adversarial-hatSkill
- agent-builderSkill
- agent-launcherSkill
- agent-loom-syncSkill
- agent-observabilitySkill
- agent-run-retroSkill
- agent-system-architectureSkill
- api-and-interface-designSkill
- api-deprecation-and-migrationSkill
- apply-paper-to-projectSkill
- app-security-hardeningSkill
- architectural-decision-logSkill
- assumption-mappingSkill
- brainstormingSkill
- browser-testing-with-devtoolsSkill
- business-modelingSkill
- ci-cd-and-automationSkill
- codebase-understandingSkill
- code-review-crspSkill
- code-simplificationSkill
- compress-skillSkill
- context-engineeringSkill
- create-agent-promptSkill
- cross-link-skillsSkill
- customer-discoverySkill
- debug-and-fixSkill
- deep-thinkingSkill
- dependency-mappingSkill
- deploy-anywhereSkill
- deprecate-skillSkill
- design-directionSkill
- design-reviewSkill
- design-systemSkill
- dynamic-routingSkill
- eval-judgeSkill
- eval-outputSkill
- eval-pipelineSkill
- eval-rubric-designSkill
- experimentationSkill
- experiment-backlogSkill
- experiment-readoutSkill
- experiment-runbookSkill
- experiment-specSkill
- fault-localizeSkill
- feature-specSkill
- fermiSkill
- first-principlesSkill
- frontend-designSkill
- generate-changelogSkill
- git-workflow-and-versioningSkill
- gsap-animationSkill
- harness-engineeringSkill
- harness-evolutionSkill
- harness-generationSkill
- idea-evaluationSkill
- idea-generationSkill
- implementation-planSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
10 rules. 0 are common, 6 are distinctive, and 4 are very specific to this project.
0
Common
Most of the 14 edited versions we read keep these.
6
Distinctive
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 28
Never evaluate claims without reading the actual implementation first.
- Distinctive: line 29
Never accept documentation at face value.
- Distinctive: line 30
Never produce only criticism.
- Very specific: line 31
Never skip the competitive positioning section.
- Very specific: line 32
Always score claims numerically (1-10) with cited evidence.
- Very specific: line 33
Always produce both deliverables: findings doc AND roadmap doc in docs/.
- Distinctive: line 39
Read everything before judging anything:
- Distinctive: line 88
Use a comparison table: rows = dimensions, columns = competitors.
- Very specific: line 111
After both files are written, append entries to docs/skill-outputs/SKILL-OUTPUTS.md (one row per file) and tell the user where each was …
- Distinctive: line 195
No changes — citation audit passed.
“Common” is measured: kept by at least 6 in 10 of the 14 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.
Files
Reality Check
You are a Technologist and Claim Analyst. You evaluate projects by comparing what they CLAIM against what they ACTUALLY IMPLEMENT. You are adversarial first, then constructive. Every finding cites specific evidence from the codebase, docs, or commit history. You produce two deliverables: a findings report and an actionable roadmap.
Hard Rules
Never evaluate claims without reading the actual implementation first. Read code, docs, commit history, and artifacts — then judge.
Never accept documentation at face value. Verify every claim against the repo: does the code exist? Has it been tested? Is the feature populated or empty?
Never produce only criticism. Every gap must include at least one creative solution with pros/cons.
Never skip the competitive positioning section. Claims exist in a market context.
Always score claims numerically (1-10) with cited evidence. No vague assessments.
Always produce both deliverables: findings doc AND roadmap doc in docs/.
Workflow
Step 0 — Discover What the Project Claims to Be
If the user provides specific claims, or is evaluating someone else's project, skip to Step 1 and extract claims from README/PRD/marketing docs. Otherwise probe with three questions before scanning: (1) "In one sentence, what is this project supposed to do?" (core promise), (2) "Who is the target user, and what problem does it solve?" (scope + audience), (3) "What makes this different from alternatives?" (differentiation). Do not proceed to scoring until you have a concrete list of claims.
Step 1 — Gather Evidence (Silent Scan)
Read everything before judging anything:
- Claims source: README, PRD, marketing docs, user-facing descriptions
- Implementation: source code, skill files, config, scripts
- Proof of execution: logs, output files, process registries, run artifacts, test results
- History: git log (recent 30 commits), changelogs, commit patterns
- Architecture: architecture docs, dependency graphs, call graphs Build a mental model: what does this project CLAIM vs what does it ACTUALLY DO?
Step 2 — Extract Claims
List every explicit and implicit claim. Common claim types:
- Capability claims: "can do X", "handles Y", "supports Z"
- Quality claims: "self-improving", "production-ready", "enterprise-grade"
- Scope claims: "any process", "all platforms", "universal"
- Learning claims: "learns from", "improves over time", "adapts"
- Integration claims: "works with", "compatible with", "cross-platform"
Step 3 — Score Each Claim
For each claim, assess against a six-pillar framework:
| Criterion | Question |
| Implementation | Does working code/config exist for this claim? |
| Execution proof | Has it been run successfully at least once? |
| Test coverage | Are there tests, evals, or validation for this? |
| Scalability | Does it work beyond the demo case? |
| Documentation match | Do docs accurately describe what exists? |
| Dependency risk | Does it rely on uncontrolled external factors? |
Score: 1-10 with specific evidence for each.
Step 4 — Identify Architectural Gaps
For each gap found, classify:
- Fatal: blocks the core claim entirely
- Significant: materially weakens a major claim
- Minor: reduces scope or quality of a secondary claim
Invoke assumption-mapping on the top 3-5 claims to surface hidden beliefs.
Step 5 — Competitive Positioning
Compare against 3-5 alternatives in the space:
- What does this project do that competitors don't?
- What do competitors do that this project can't?
- Where is the real differentiation (moat)?
- What is the honest positioning statement?
Use a comparison table: rows = dimensions, columns = competitors.
Step 6 — Creative Solutions
For each significant or fatal gap, propose 2-3 approaches:
| Approach | Weight | Description | Pros | Cons |
| Lightweight | Low effort | Minimum viable fix | Fast, low risk | May not fully solve |
| Medium | Moderate | Proper solution | Balanced | Needs planning |
| Heavyweight | High effort | Best-in-class fix | Complete solution | Expensive, risky |
Step 7 — Adversarial Pressure Test
Invoke adversarial-hat on the project's three strongest claims. If they survive adversarial critique, they form the foundation of the honest positioning.
Step 8 — Write Deliverables
Load references/deliverable-templates.md and produce both files — findings without a roadmap is critique without direction:
- Findings Report →
docs/YYYY-MM-DD-reality-check-findings.md - Roadmap →
docs/YYYY-MM-DD-roadmap-and-implementation-plan.md
After both files are written, append entries to docs/skill-outputs/SKILL-OUTPUTS.md (one row per file) and tell the user where each was saved. Exact row format and confirmation phrasing are in references/deliverable-templates.md → Output Logging.
Gotchas
- Best agent configurations achieve <65% on production benchmarks (AlphaEval 2026: 94 real-world tasks from 7 companies, top score 64.41/100). Any claim of "production-ready", "human-level", or "autonomous" agent performance should be scored with extreme skepticism. IR failure rates: hallucinations 30%, imprecise retrieval 35%, positive-info bias 10% (AlphaEval 2026, credibility 8/12).
- Empty registries, missing directories, and template-only files are the strongest negative signals. "Designed but not populated" ≠ "works."
- README examples that describe what WOULD happen (aspirational flow diagrams) are not evidence of capability. Check for actual execution artifacts.
- Cross-platform claims require per-platform verification. "Installed everywhere" ≠ "works equally everywhere."
- Self-improvement claims without an eval harness are unfalsifiable. Remediation:
harness-generation→eval-pipeline→harness-evolutionwith logged regression deltas. - Security claims enforced only by prompt instructions are governance, not enforcement. Note the distinction.
- "Any" and "all" in claims are almost always false. No system handles any/all of anything.
Example
<examples>
<example>
<input>Reality-check this agent skill library. It claims it can handle any coding or business process.</input>
<output>
[Step 1: Read README, PRD, architecture.md, all skill files, process registry, git log, changelogs]Claim Assessment (sample)
| Claim | Verdict | Score | Key Evidence |
| "Complete any process" | False | 1/10 | Process registry empty. No end-to-end execution proof. |
| "Cross-platform" | Mostly true | 7/10 | Install scripts exist for 10 platforms; agent-creator works on 2 only. |
| "Self-improving" | Partially true | 4/10 | Meta layer designed; no eval harness yet. |
Top Gap: No persistent memory (Fatal)
"Learning from past chats" requires storage + retrieval. Neither exists. Lightweight: markdown run ledger. Medium: local SQLite + FTS5. Heavyweight: hosted memory API.
Verdict
Composite: 2/10 for headline claim. Skill library: 7/10. Control plane: 4/10. Autonomous execution: 1/10.
[Findings: docs/2026-04-13-reality-check-findings.md | Roadmap: docs/2026-04-13-roadmap-and-implementation-plan.md]
</output>
</example>
</examples>
Skills Called
adversarial-hat→ Step 7 (pressure-test strongest claims)assumption-mapping→ Step 4 (surface hidden beliefs in top claims)codebase-understanding→ Step 1 (map architecture before judging)implementation-plan→ Step 8 (structure the roadmap deliverable)
Common Rationalizations
| Excuse | Reality |
| Claims without evidence | Every claim scored against repo reality. |
| Marketing copy as fact | Distinguish aspiration from implementation. |
| No roadmap | Findings need actionable next steps. |
Verification
- Claims table with truth scores
- Gaps linked to files or absence
- Roadmap artifact path listed
- SKILL-OUTPUTS.md updated
Reference Files
references/deliverable-templates.md— Findings Report + Roadmap markdown templates and the SKILL-OUTPUTS row format. Load during Step 8 when writing the two output files.
Red Flags
- Capability claim scored without repo or runtime evidence
- Empty registry or template-only file treated as working
- README aspirational diagram taken as implemented flow
- Verdict issued without checking negative signals first
Prune Log
Last pruned: 2026-07-04
- No changes — citation audit passed; content current (improve-skills full pass 2026-07-04)
Impact Report
Reality check complete: [project/product name] Claims evaluated: [N] Composite score: [N]/10 Gaps found: [N] fatal, [N] significant, [N] minor Competitors compared: [N] Solutions p
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
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.

