Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add shashankreddy509/claude-tdd-kit --skill prove-pre-existinggit clone --depth 1 https://github.com/shashankreddy509/claude-tdd-kitWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/shashankreddy509/claude-tdd-kit/prove-pre-existing)<a href="https://agentmods.dev/skills/shashankreddy509/claude-tdd-kit/prove-pre-existing"><img src="https://agentmods.dev/badge/skills/shashankreddy509/claude-tdd-kit/prove-pre-existing/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/shashankreddy509/claude-tdd-kit/prove-pre-existing"><img src="https://agentmods.dev/badge/skills/shashankreddy509/claude-tdd-kit/prove-pre-existing.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00105 | $0.00994 |
| Opus 5 | $0.00053 | $0.00497 |
| Sonnet 5 | $0.00021 | $0.00199 |
| Haiku 4.5 | $0.00011 | $0.00099 |
Grade A, and why
prove-pre-existing scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 11d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 66 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Prove Pre-Existing
One job: attribute a failure. Given a build/compile/test that is currently failing, determine whether YOUR working-tree change introduced it or whether it was already broken on the clean base. This is a Verification check on a failure — it does NOT fix the failure, refactor, or change scope. Output is a verdict with evidence.
Input
- What's failing and how it's run (the exact command). If unclear, ask for it. Identify the repo of the change (usually the cwd, but confirm).
- Detect the stack from the command / repo so you read traces correctly:
- Python / pytest: e.g.
.venv/bin/python -m pytest tests/.... Read the bottom of the traceback — the realE AssertionError/ImportErrorline, not the collection noise above it. - Kotlin / Gradle: e.g.
./gradlew :module:testDebugUnitTest. Read kapt/Gradle traces bottom-up — the realCaused by/e:lines. - Other stacks: find the real failing line, not the summary. Most runners print the useful signature furthest from the invocation.
- Python / pytest: e.g.
Steps
-
Capture the failure as-is. Run the failing command and save the exact error signature (the real failing line, not the noise around it). Note which files the errors point at.
-
Confirm what's yours.
git -C <repo> status --short. List the files YOU changed. If the errors point at files NOT in your change set, that is already strong evidence of pre-existing breakage — call it out. -
Stash your edits (scope to your files, keep the rest of the tree intact):
git -C <repo> stash push -- <yourfile1> <yourfile2> ...For an untracked new file (e.g. a new test), move it aside instead (mvto the scratchpad), since stash won't take untracked paths by default. -
Re-run the SAME command on the clean base. Compare the error signature to step 1:
- Same errors remain → the failure is PRE-EXISTING; your change is not the cause. Capture the identical signature as proof.
- Errors gone → your change IS implicated; report which of your files, and the specific error each introduces.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 11d ago First seen · 66 lines · 0 tokens per session scan A 12faeaffc346
prove-pre-existing is a skill published in the GitHub repository shashankreddy509/claude-tdd-kit (2 stars, last pushed 18d ago), licensed MIT. It adds 105 tokens to every session and 994 once invoked, about $0.0005 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
manage-skills
A maintenance workflow for checking whether project verification skills still cover the code and rules that changed during a session.
systematic-debugging
Structured debugging methodology — use before proposing fixes for any error or failure. Covers: code bugs, build errors, deploy failures, config conflicts, dependency issues, infra problems. Also use when previous fix attempts failed or root cause is unclear.
review-loop
Run the adversarial verification loop — implement, then hand the change to a fresh checker that did not write it, fix what it finds, and re-dispatch until APPROVE. Use before claiming any behavioural change is done, and on requests like "review loop", "adversarial review", "independent review", "get this verified"…
create-issue
Transitional alias — prefer /prflow:specs, which runs the same issue-drafting pipeline. Use when a rough user story, bug report, feature idea, piece of feedback, or an implementation plan should be recorded as a GitHub issue rather than built right now. This command name is retained so existing /prflow:create-issue…
docs-release-notes
Use when a change needs a user-visible release-note, changelog, or changeset entry — "add a release note", "add a changeset for this", "what goes in the changelog?", "write up what shipped", "note this for the next release" — or when finalizing a branch whose customer-visible features, bug fixes, or UI changes should…
retrospective-audit
Stage B of /prflow:retrospective-weekly: given a most-recent-first subset of one recurring pattern's occurrence-PR context bundles (bounded by auditbundlecap), re-derive the root cause and return one JSON object carrying a ranked findings array (one to three sub-patterns) — no edits, no worktree. Invoked as a subagent…