How it’s checked

It checks its own work before you see it.

Left alone, Claude will sometimes fill a gap with a plausible guess, or say it checked something it didn’t. Every skill sold here runs a separate check on what it built. If the check fails, you get the reason, not the document.

See what it catches.

Remove an owner. Reword a quote. Add six more items. It won’t hand you a document that fails a check.

Add a mistake

The three mistake buttons need JavaScript. With it off, this is the document as it would be sent: every check passes.

Ready to send

3 of 3 checks pass

Ridgeline · Operations

Action list: Ops sync

Tue, Nov 3, 2026

Owner	Action	Due	From the notes
Dana R.	Send the vendor list	Fri, Nov 6	“Dana to send vendor list by Fri”“Dana will coordinate vendor outreach this week”
Marcus L.— no owner	Draft the onboarding checklist	Mon, Nov 30	“Marcus will draft the onboarding checklist, target end of month”
Beth S.	Write the go-live announcement	When IT sends dates	“Beth owns the go-live comms, needs dates from IT”
Dana R.	Confirm the training room	Fri, Nov 13	“confirm the training room”
Marcus L.	Update the shift calendar	Fri, Nov 13	“update the shift calendar”
Beth S.	Send badge requests	Fri, Nov 13	“send badge requests”
Dana R.	Book the vendor demo	Fri, Nov 13	“book the vendor demo”
Marcus L.	Review the floor plan	Fri, Nov 13	“review the floor plan”
Beth S.	Collect PTO requests	Fri, Nov 13	“collect pto requests”

Needs an ownerCall facilities about the east lobby badge reader “someone call facilities”

Parked: budget question, moved to next week.

↓ runs onto page 2

Checks passedEvery action traced to the notes · 1 page Held back · not sent Page 1 of 1Page 1 of 2

Ridgeline is a fictional company built for this example.

In plain terms

Seven things every skill here has to do.

A skill is a set of instructions Claude loads so it does one job the same way every time. Each one sold here is checked against these seven points.

01It fixes a specific thing Claude gets wrong or does inconsistently on its own.
02It starts when you ask for it, not when it guesses.
03It checks its work before it hands you anything. The check is a separate step that can say no, not a request to be careful.
04When a document has a limit, like one page or a character count, it counts before it claims to have met it.
05When you ask for something outside its job, it says so and tells you what to do instead.
06It works the same the hundredth time as the first, in any conversation, without you explaining anything again.
07Its worked example shows it catching a mistake, not only the easy case going right.

Then it’s run

Tested the way you’ll use it, before it ships.

Reading a skill file can’t tell you whether Claude will keep its promises. Only running it can.

Every promise becomes a test

Each thing a skill says it will refuse is turned into a request built to trigger it. If the promise is reworded, the test has to be rewritten before it will run.

Run on what you download

Each test runs in a fresh conversation with nothing loaded but the packaged skill, the same file a buyer receives.

Graded by what happened

Which files appeared, whether the skill’s own check passed them, what it said. A failure counts only when a second fresh run repeats it.

The checks are tested too

Each rule a check enforces is broken on purpose, in a throwaway copy, and the tests have to notice.

No pass, no ship

A pack ships only when every skill in it passes on its current files. When a file changes, everything that change could reach is tested again.

Why there are no reviews here

Check it instead.

There are no testimonials here, no ratings, no customer count, and no founder to vouch for. This is a one-person studio and it intends to stay one.

What is offered instead can be inspected. The standard on this page is the one every skill sold here has to clear. The setup guides and worked examples are readable without a purchase. The changelog is dated. If that isn’t enough evidence to spend $79, then it isn’t enough. Buy nothing until it is.

Technical · for people who build skillsThe full standard, and a real run of the checker

A skill is craftsman-class only where it reliably makes the model do the thing that does not survive being done from memory — the step the model, left alone, would forget, skip, fudge, or confabulate. The operational form of the same test: remove the feature and ask whether the output changes. If it does not, the feature is not craftsmanship. It is packaging.

Pass/fail. A skill that fails any gate is a prompt, not a product.

Written for people who build skills. Terms, glossed once: a trigger is what starts a skill; a hard-fail is a check that stops it before it hands you anything; an exit code is the number a check returns — here, pass, needs a look, or fail.

Names the gap

Can you state in one sentence the specific thing the model gets wrong or does inconsistently without this skill?

Deterministic entry

Does the skill have a hard trigger — a prefix or an unambiguous condition — that fires it without relying on keyword guessing?

Enforced hard-fails

Is every stated hard-fail backed by a check that returns a real signal — exit code, count, diff — before the skill emits, not by prose alone?

Verify before voice

Is any output with a countable or specified constraint written around a verified result rather than asserted and hoped?

Loud failure, named exit

Does each scope boundary say "if X, refuse and do Y" rather than "try to stay in scope"?

No prior-chat references

Does the procedure stand without a conversation it does not contain — no "as we discussed", no "like last time" — given that a fresh session never had it?

Deciding example

Does at least one worked example show the skill catching a case that would otherwise go wrong, rather than the happy path succeeding?

Gate 2 may be supplemented by a keyword list but is not satisfied by one. Gate 3 passes only if every claimed hard-fail is mechanically checked — one unenforced hard-fail fails the gate.

The floor checks how a skill is built. This checks whether it does what it says.

A skill file makes promises: "if the output fails the check, it does not ship", "asked for a PDF, hand off to the PDF skill". The floor confirms those promises are written down and backed by a check. It cannot tell you whether the model, handed the skill, actually keeps them. Reading the file never answers that. Only running it does.

Every promise becomes a test

Each hard-fail and each scope boundary the skill states is quoted from its own file and turned into a request built to trigger it. If the sentence changes, the test refuses to run until it is rewritten. A test cannot drift away from the promise it checks.

Run cold, on what you download

Each test runs in a fresh session with nothing loaded but the packaged skill, the same archive a buyer receives, not the working copy it was built from. A pass comes from the file, not from the conversation around it.

Graded by result, not by opinion

What counts is what happened: which files appeared, whether the skill's own checker passed them, what the skill said. A failure is recorded only when a second fresh run repeats it. A pass that needed a second try is not trusted, and the test runs again next time.

The checkers are tested too

A check that never fails proves nothing. Each rule a checker enforces is broken on purpose, in a throwaway copy, and its tests have to notice. A break the tests let through is a gap. It gets closed before the checker is trusted.

No pass, no ship

A pack ships only when every skill in it passes on its current files. When a file changes, every promise that change could reach is tested again.

A real run of the checker.

This is the free skill audit grading its own skill file, pasted from the run. PASS means the point is met, REVIEW means it needs a look, FAIL means it is not met, NOT CHECKABLE means the file gives that point nothing to test, so it does not count toward the verdict.

skill_audit — skill-audit SKILL.md scripts: skill_audit.py [D] Upload-safe description PASS description is 781 of 1024 chars and holds no XML-tag shape. [R] References resolve PASS All 1 bundled path(s) resolve. (1 workspace path(s) skipped — not this skill's to resolve) [1] Names the gap PASS A gap/failure-mode statement is present. [2] Deterministic entry PASS A deterministic entry (prefix or unambiguous condition) is present (`audit:`). [3] Enforced hard-fails PASS Hard-fails are present and the skill ships a script (skill_audit.py). [4] Verify before voice NOT CHECKABLE No countable/spec'd constraint detected; gate not applicable. -> If the skill does have a hard constraint (a count, a spec), make sure it's verified, not asserted. [5] Loud failure, named exit PASS Scope boundaries name an explicit exit (if X, refuse and do Y). [6] No prior-chat references PASS No phrasing that leans on an earlier chat ("as we discussed", "like last time"). [7] Deciding example PASS A worked example is present and shows a catch, not just the happy path. FAIL 0 REVIEW 0 NOT CHECKABLE 1 PASS 8 VERDICT: PASS Every gate the lint can decide came back clean. One gate it cannot decide is marked NOT CHECKABLE above — read its -> line. Not graded: whether the skill works in a fresh session. The lint reads files; only a run shows what a model does with them. -> Open a session where your own project instructions do not load, install the skill from its archive, give it a real task that starts with `audit:`, and check what it does against what the skill promises.

The free audit tool, version 2.0.0, run against its own skill file on 2026-10-27. Every gate it can check came back clean. The last line of the run is the part to read: a lint reads files, so it cannot tell you whether a skill works in a fresh session. The tool prints that limit instead of leaving it out, and so does this page.

Write your own skills? The same checker is free: free skill audit →