Most "AI slop" isn't a code problem. It's an upstream problem. The model built the wrong thing, correctly, because nobody was sure what the right thing was in the first place.
These skills fix the upstream. They turn a vague idea into a specification you can actually hand to an AI (or a human) and get back what you meant, not what you happened to type.
They're built for Claude and Claude Code, and they compose into a chain:
[ vague idea ]
│
▼ /discovery ← surface what you actually need
[ Discovery.md ] ← a portable artifact, not a chat log
│
▼ /specify ← turn it into a real spec
[ SRS.md / ADD.md ]
│
▼ build
[ software that does the right thing ]
│
▼ /falsify ← prove it does, by trying to break it
[ a verdict with evidence, not "looks good" ]
Each stage produces a portable markdown artifact that survives a context reset and feeds the next stage. You are not trusting the model to remember. You are building a paper trail on purpose.
There's a good tool already out there for making your code right: Matt Pocock's grill-me, which stress-tests a plan you've already formed. These skills are the step before that. grill-me makes sure you built it right. discovery makes sure you're building the right thing at all.
The mechanics here are a fork of Pocock's grill-me (relentless interview, recommend-an-answer, walk the decision tree, prefer evidence over speculation), with a requirements-engineering discipline layered on top. Full attribution and the original are preserved in each skill's NOTICE.txt.
You have an idea. You're too close to it to see it clearly. /discovery is the outside perspective that refuses to accept your first framing.
It walks you through six phases, one question at a time, and it will not let you hide:
- Root motivation - Five Whys to the actual cause, not the symptom you noticed
- Stakeholders + scope - who's affected, who decides, who pays, and what's explicitly out
- Scenarios - "walk me through one specific day where this matters"
- Failure modes - including "describe a version of this you'd technically call a success but would actually hate"
- Prioritization - MoSCoW, and it forces you to put something in Won't and to not put everything in Must
- Acceptance criteria - observable, testable, Given/When/Then. If you can't write a test for it, it isn't a criterion.
It catches you hedging in two ways: the easy lexical tells ("maybe," "probably," "I think") and the harder semantic ones (long answers that never actually pick, restating the question instead of answering it, generating a tangent to avoid a decision). When you dodge, it names the dodge and makes you commit before moving on.
Out the other end you get a Discovery.md you can hand to a developer, feed to /specify, or use to check whether the thing you're about to build is the thing you actually need.
You've done the discovery. Now you need a document a developer can build from and a stakeholder can sign off on. /specify takes your Discovery.md and produces the formal spec the work actually needs.
The trick is that "the spec the work needs" isn't always the same document, and most people can't tell which one they need. So /specify decides for you and tells you why:
- A Software Requirements Specification (SRS) when the work is about what the system must do - behaviors, testable requirements, multiple parties who have to agree on "done." IEEE 830 / ISO 29148 aligned.
- An Architecture Decision Document (ADD) when the work is about how and why it's built - the significant choices, the alternatives you rejected, the rationale a future maintainer will need. ISO 42010 aligned.
- Both, when the scope genuinely earns two documents (it recommends this sparingly - two documents is twice the upkeep).
- Neither, when your discovery is already enough and a formal spec would be ceremony. This is a real answer, and often the right one. Recommending a fifty-page document nobody needs is its own kind of slop.
It recommends, explains the recommendation from your discovery's actual contents, and lets you override - but only if you can say why in one sentence that's about the work, not your preference. Then it interviews you against the chosen document's structure, refusing untestable requirements ("the system should be fast" gets sent back until it's "95th-percentile under 200ms at 50 concurrent users") and decisions with no rejected alternative ("we chose X" is an assumption until you can say what you chose it over).
Out the other end: a numbered, traceable SRS or ADD you can hand off, review, and measure the build against.
The AI says it's done. The fix works, the tests pass, the migration's complete. You want to believe it. That wanting is the problem.
/falsify takes any claim - a completion, a review finding, a line in a document, a system-behavior assertion - and runs a falsification procedure against it instead of nodding along:
- Restate the claim as something that could be false. "It works" isn't testable. "For every input X, Y happens" is. A claim that can't be made falsifiable isn't verified - it's unverifiable, and that's the finding.
- Construct the proof that doesn't exist yet. Most verification only runs a test that's already there.
/falsifybuilds the missing one - because "there's no easy way to test this" is not a reason to believe it. - Demand the artifact, not the assertion. "It passed" is a claim. The actual output is evidence. A cleanup that succeeds at deleting an empty list still reports success and does nothing - so read what actually happened, not the word "passed."
- Attack the unstated boundary. Every claim assumes things it never says: clean input, staying in the sandbox, the record being there. Find the assumption that isn't enforced, only hoped for. That's where correct-looking work fails.
- Return a verdict with evidence - Confirmed (here's what I tried to break and couldn't), Refuted (here's the failing case), or Unverified (here's exactly what's missing). Never "looks good."
It's built for the failure mode the other verification tools miss: the claim that's plausible, confidently stated, and wrong. For high-stakes claims it can escalate to a different-vendor model, because same-lineage models share blind spots - but the procedure stands on its own in one model. This complements runnable-proof verifiers; it doesn't replace them. It's the discipline of withholding belief until the evidence forces it.
Drop the skill folder where your Claude tooling looks for skills.
Claude Code: copy discovery/, specify/, and falsify/ into ~/.claude/skills/ (or your project's .claude/skills/), then invoke them with /discovery, /specify, and /falsify.
claude.ai (Projects / Skills): add the skill through your skills settings and call it by name.
That's it. No dependencies, no build step, no runtime. It's markdown and a disciplined interview.
The chain runs discovery -> specify -> build -> falsify. The build step is deliberately left to you and your existing tooling (or to Pocock's grill-me to stress-test the plan first). Everything around it - deciding what to build, specifying it, and proving it does what you specified - is here. More instruments may join the catalog over time.
Watch this repo, or follow the thinking behind it at The Systems Thinker.
Campbell Consulting Services of Tallahassee (CCST). We build governance and verification tooling for teams putting AI into real work - the kind of work that has to answer to a client, an auditor, or a regulator. This is the free, open front porch of that discipline.
Apache 2.0. Use it, fork it, ship it in your own tools. See LICENSE and each skill's NOTICE.txt for attribution.
Built on the shoulders of Matt Pocock's grill-me (MIT).