cavekit is a Claude Code plugin that organizes software changes through a compact, spec-driven workflow stored in a SPEC.md file. It is for developers who want to plan, research, review, and build changes while preserving project context across sessions; the catalogue entries are its skills, commands, plugin configuration, and workflow rules.
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 JuliusBrussee/cavekit --skill backpropgit clone --depth 1 https://github.com/JuliusBrussee/cavekitWrote 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/juliusbrussee/cavekit/backprop)<a href="https://agentmods.dev/skills/juliusbrussee/cavekit/backprop"><img src="https://agentmods.dev/badge/skills/juliusbrussee/cavekit/backprop/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/juliusbrussee/cavekit/backprop"><img src="https://agentmods.dev/badge/skills/juliusbrussee/cavekit/backprop.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- Socket pass
- Snyk pass
- NVIDIA SkillSpector pass
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.00076 | $0.00730 |
| Opus 5.5 | $0.00030 | $0.00292 |
| Sonnet 5.5 | $0.00015 | $0.00146 |
| Haiku 4.5 | $0.00008 | $0.00073 |
Grade A, and why
backprop 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 1mo 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 — 90 lines — stays where its author put it; the contents beside it link to each section on GitHub.
backprop — bug → spec
Plan-then-execute fixes the code & forgets. SDD fixes the code AND edits spec so recurrence is impossible. That edit is backprop.
WHEN TO BACKPROP
- Test failed at
/buildverification. - User reports bug.
- Post-mortem after production incident.
/checkflags VIOLATE with root cause found.
SIX STEPS
1. TRACE
Read failure output / bug report. Find exact file:line of wrong behavior. Name root cause in one caveman sentence.
2. ANALYZE
Ask three questions:
- Would a new §V invariant catch this class of bug? (most common: yes)
- Is §I wrong — did spec claim shape the code cannot deliver? (sometimes)
- Is §T wrong — did we build the wrong thing? (rare but real)
3. PROPOSE
Draft the spec change. Never skip §B; §V/§I/§T are case-by-case.
Template:
§B row: B<next>|<date>|<root cause>|V<N>
§V line: V<next>: <testable rule that would have caught it>
Example:
§B row: B3|2026-04-20|refund job ran twice on retry|V7
§V line: V7: ∀ refund → idempotency key check before charge reversal
4. GENERATE TEST
New invariant without test = lie. Add failing test first.
Name test so it cites the invariant: TestV7_RefundIdempotent.
5. VERIFY
Fix code. Run test. Must pass. Run full suite. Must not regress.
6. LOG
Commit spec edit + test + code fix together.
Commit msg: backprop §B.<n> + §V.<N>: <one-line cause>.
WHAT MAKES A GOOD INVARIANT
- Testable in code (grep-able or assert-able).
- Scoped to a behavior, not a file.
- Stated positively when possible (
! holdover⊥ forbid). - References §I surface where it applies.
Bad: V8: code should be correct. Good: V8: ∀ pg_query ! params interpolated via driver, ⊥ string concat.
WHEN NOT TO ADD §V
- Bug was purely mechanical typo with no class (
i++vsi--in throwaway). - Fix is a one-time migration.
- Root cause is external dep (upgrade deps instead, note in §C).
Still append §B entry — record that this failure mode was considered. Future bug with same smell → §B search shows precedent.
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.
- 1mo ago First seen · 90 lines · 76 tokens per session scan A 35eb93f05ef6
backprop is a skill published in the GitHub repository JuliusBrussee/cavekit (1,156 stars, last pushed 2mo ago), licensed MIT. It adds 76 tokens to every session and 730 once invoked, about $0.0003 per session on Opus 5.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-30.
Other skills, from other repositories
bug-investigator
Use when encountering any bug, test failure, or unexpected behavior during spec-superflow execution, before proposing fixes. Invoked automatically when build-executor hits a blockage.
speq-audit
Audit a speq project's health — spec-library structure, feature/decision-log/plan validation, ADR noise, mission-to-spec sync, unrecorded plans, and gitignore hygiene — then guide fixes. Use when the user asks to audit, health-check, doctor, lint, or sanity-check the specs or repo, or after cloning or inheriting a…
critical-review
4-phase adversarial review protocol: pre-flight analysis, adversarial execution check, self-correction loop, and [VALIDATION] report.
diagnosing-bugs
Diagnosis loop for hard bugs and performance regressions. Use when the user says diagnose/debug, or reports broken/failing/slow behavior.
gke-workload-scaling-troubleshooting
Diagnoses GKE HorizontalPodAutoscaler (HPA) failures — metrics showing as , FailedGetResourceMetric / FailedGetScale / FailedComputeMetricsReplicas events, missing Pod resource requests, custom/external metrics-pipeline breakage (FailedGetExternalMetric / FailedGetCustomMetric, unavailable metrics adapter…
gke-ai-troubleshooting-jobset-interruption
Diagnoses GKE JobSet interruptions, restarts, and preemptions for AI/ML training workloads autonomously. Use when troubleshooting JobSet restart loops, spot VM preemptions, node readiness failures, host VM issues, or coordinator worker crashes. Don't use for general GKE cluster creation, basic workload deployment, or…