Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
juliusbrussee avatar

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)
At a glance

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
From the docs

What backprop says it does

SDD fixes the code AND edits spec so recurrence is impossible.
SKILL.md
New invariant without test = lie. Add failing test first.
SKILL.md
Commit spec edit + test + code fix together.
SKILL.md
npx skills add https://github.com/juliusbrussee/cavekit --skill backprop

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs2.4k
repo stars1.1k
Security audit3 / 3 scanners passed
Last updatedJune 18, 2026
Repositoryjuliusbrussee/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

SKILL.mdMarkdownGitHub ↗

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 /build verification.
  • User reports bug.
  • Post-mortem after production incident.
  • /check flags 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 (! hold over ⊥ 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++ vs i-- 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.

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.