
Backprop
- 2.4k installs
- 1.1k repo stars
- Updated June 18, 2026
- juliusbrussee/cavekit
backprop traces bugs, proposes section B and section V spec edits, adds tests, fixes code, and commits together under SDD.
About
The backprop skill implements a bug-to-spec protocol for Spec-Driven Development. When a test fails, a user reports a bug, a post-mortem runs, or /check flags a VIOLATE with a known root cause, the agent traces the failure to file and line, analyzes whether a new section V invariant would catch recurrence, and drafts spec edits in sections B and V. Step three proposes the change using a template row and testable invariant line. Step four adds a failing test named after the invariant before fixing code. Step five verifies the fix and full suite, then logs one commit combining spec, test, and code with message backprop section B plus section V and one-line cause. Good invariants are testable, behavior-scoped, and positively stated. Skip new section V for mechanical typos, one-time migrations, or external dependency issues, but still record section B. Output is always section B entry, usually section V, test when added, code fix, and one commit with no dashboards.
- Six steps: trace, analyze, propose, generate test, verify, log in one commit.
- Section V invariants must be testable; new invariant requires failing test first.
- Analyze whether section I shape or section T scope was wrong, not only section V.
- Always append section B; skip section V only for typos, migrations, or external deps.
- Triggers on test failure, bug report, post-mortem, or /check VIOLATE with root cause.
Backprop by the numbers
- 2,435 all-time installs (skills.sh)
- +75 installs in the week ending Aug 5, 2026 (Skillselion tracking)
- Ranked #53 of 782 Skill Development skills by installs in the Skillselion catalog
- Security screen: LOW risk (skills.sh audit)
- Data as of Aug 5, 2026 (Skillselion catalog sync)
backprop capabilities & compatibility
- Capabilities
- root cause trace to file and line · section b and section v spec draft proposals · failing test generation before code fix · full suite verification after fix · single commit bundling spec test and code
- Use cases
- debugging · testing · documentation
What backprop says it does
SDD fixes the code AND edits spec so recurrence is impossible.
New invariant without test = lie. Add failing test first.
Commit spec edit + test + code fix together.
npx skills add https://github.com/juliusbrussee/cavekit --skill backpropAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 2.4k |
|---|---|
| repo stars | ★ 1.1k |
| Security audit | 3 / 3 scanners passed |
| Last updated | June 18, 2026 |
| Repository | juliusbrussee/cavekit ↗ |
How do I fix a bug and update the spec so the same class of failure cannot recur?
Trace bugs to root cause, append spec invariants, add failing tests, and commit spec plus fix together under SDD backprop protocol.
Who is it for?
SDD projects where SPEC.md plus git history should capture every bug class and its prevention rule.
Skip if: Skip for one-off typos with no class, external dependency bugs needing upgrades only, or plan-then-execute without spec files.
When should I use this skill?
Test fails at /build, user reports bug, post-mortem, or /check VIOLATE with identified root cause.
What you get
Section B entry, optional section V invariant with test, code fix, and single backprop commit.
- Updated spec invariants
- Root-cause trace documentation
By the numbers
- Follows a 6-step bug-to-spec protocol
- Appends invariants to §B after root-cause analysis
Files
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 reversal4. 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.
OUTPUT SHAPE
Every backprop run produces: 1. §B entry (always). 2. §V entry (usually). 3. Test file (when §V added). 4. Code fix. 5. One commit.
No dashboards. No log files. SPEC.md + git is the full history.
Related skills
How it compares
Pick backprop over ad-hoc bug fixes when a maintained spec should gain permanent invariants after every failure.
FAQ
When should I skip adding a new section V invariant?
Mechanical typos, one-time migrations, or external dependency failures; still log section B.
What must every backprop run produce?
Section B entry always; usually section V, test when V added, code fix, and one combined commit.
How should tests reference invariants?
Name tests after the invariant, e.g. TestV7_RefundIdempotent, and add failing test before the fix.
Is Backprop safe to install?
skills.sh reports 3 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.