backprop — bug → spec

backprop

Bug → spec protocol. When a bug is found or a test fails, trace the cause, decide whether a new §V invariant would catch recurrence, append to §B. This is the one non-obvious thing SDD does that plan-then-execute doesn't. Triggers on test failure, bug report, post-mortem, or explicit user ask.

juliusbrussee/cavekit·2.6Kinstalls1.1Kstars

SKILL.md

Full skill instructions

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:

§B entry (always).
§V entry (usually).
Test file (when §V added).
Code fix.
One commit.

No dashboards. No log files. SPEC.md + git is the full history.

Install skill

Copy and run in your terminal

npx -y skills add https://github.com/juliusbrussee/cavekit --skill backprop

View on GitHub

backprop

caveman
Ultra-compressed communication mode cutting token usage ~75% while preserving technical accuracy.
559K installs
caveman-commit
Terse, conventional commit messages that prioritize reasoning over description.
392.8K installs
caveman-review
Ultra-compressed code review comments: location, problem, fix on one line each.
388.8K installs
caveman-compress
Compress natural language memory files into caveman-speak to reduce input tokens.
387.7K installs

More skills from juliusbrussee

juliusbrussee/caveman

caveman-help

Quick-reference card for caveman modes, skills, and commands with one-shot display.

109.9K 379.4K

View

juliusbrussee/caveman

cavecrew

Delegate code tasks to compressed subagents that shrink context by ~60% per delegation.

109.9K 335.7K

View

juliusbrussee/caveman

caveman-stats

Real token usage and estimated savings metrics from your Claude Code session log.

109.9K 334.9K

View

juliusbrussee/caveman

compress

Compress natural language memory files into caveman-speak to reduce input tokens.

109.9K 46.9K

View

juliusbrussee/skills

caveman

Ultra-compressed communication mode. Cuts token usage ~75% by speaking like caveman while keeping full technical accuracy. Supports intensity levels: lite, full (default), ultra, wenyan-lite, wenyan-full, wenyan-ultra. Use when user says "caveman mode", "talk like caveman", "use caveman", "less tokens", "be brief", or invokes /caveman. Also auto-triggers when token efficiency is requested.

160 3.5K

View

juliusbrussee/cavekit

caveman

1.1K 2.8K

View

juliusbrussee/cavekit

build

1.1K 2.7K

View

juliusbrussee/cavekit

spec

1.1K 2.7K

View

juliusbrussee/cavekit

check

1.1K 2.7K

View

juliusbrussee/skills

grill-me

Calibrated grilling session for stress-testing a plan, design, idea, or decision. First assesses the user's topic knowledge, confidence, and desired pressure level, then asks one question at a time with recommended answers. Use when user says "grill me", "stress-test this", "challenge my plan", "interview me", or wants a plan probed without being overwhelmed.

160 2.6K

View

juliusbrussee/skills

junior-to-senior

Adversarial senior-engineer review for agent-generated plans, designs, and architectures. Treats the current output as junior work, constructs a senior reviewer whose domain expertise comes from live codebase research plus web research of current best practices, diagnoses altitude failures (too vague or too granular), then rewrites the plan into a scoped, state-of-the-art version. Use when the user says "junior to senior", "senior review", "review this like a staff engineer", when a plan feels hand-wavy or lost in details, or before committing to any agent-written plan.

160 2.5K

View

juliusbrussee/skills

interface-kit

Authoritative guide for implementing stunning, accessible, performant UI. Synthesizes design engineering philosophy, accessibility standards, animation principles, spatial design, typography, color systems, and component craft into a single actionable reference. Complements the design-system skill (which covers DESIGN.md spec writing) by covering the HOW of implementation. Trigger phrases: "build UI", "create component", "landing page", "make it look good", "frontend", "design", "polish UI", "implement design", "make it beautiful", "UI implementation", "component styling", "animation", "accessibility"

160 2.1K

View