Backprop
Turn test failures and bug reports into spec updates—§B backprop rows and §V invariants—so the same bug class cannot recur under spec-driven development.
Overview
backprop is an agent skill most often used in Ship (also Build pm, Operate iterate) that converts bugs and test failures into §B backprop entries and §V invariants so recurrence is spec-blocked.
Install
npx skills add https://github.com/juliusbrussee/blueprint --skill backpropWhat is this skill?
- Six-step bug → spec protocol: trace, analyze, propose, generate test, amend spec, verify
- Appends §B backprop rows and optional §V/§I/§T edits—never skips §B
- Root-cause analysis asks whether invariants, intent (§I), or targets (§T) failed
- Triggers on test failure, user bug reports, post-mortems, and `/check` VIOLATE findings
- Requires a failing test for each new §V invariant before spec claims stick
- Six-step protocol: trace, analyze, propose, generate test, amend spec, verify
- Three analyze branches: §V invariant, §I intent, or §T target corrections
Adoption & trust: 5 installs on skills.sh; 1k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You fix bugs in code but the spec never learns, so the same failure mode keeps returning across builds and deploys.
Who is it for?
Builders practicing spec-driven development who already maintain §B/§V sections and want failures to harden the spec automatically.
Skip if: Quick patch workflows with no spec file, or trivial one-line typos where a new invariant would add noise without preventing recurrence.
When should I use this skill?
Test failure at build verification, bug report, post-mortem, `/check` VIOLATE with root cause, or explicit user ask to backprop.
What do I get? / Deliverables
Each incident yields a §B backprop row, an enforceable §V invariant with a failing-then-passing test, and updated spec text—then verification is re-run.
- New or updated §B backprop row with dated root cause
- §V invariant line plus associated failing-then-passing test
- Re-run verification result after spec amendment
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Ship/testing is the canonical shelf because the skill explicitly fires on failed `/build` verification and test output, where specs must be tightened before release. Testing subphase matches invariant-first test generation and verification loops rather than one-off hotfixes without documentation.
Where it fits
After `/build` verification fails on idempotency, trace the refund job and draft §V7 plus a §B row before continuing implementation.
A CI test flags duplicate charge reversal; run backprop to add the invariant test first, then amend §V.
Post-mortem on a retry storm documents root cause in §B and tightens §V before the next deploy.
How it compares
Use instead of fix-and-forget debugging when your process treats the spec as the source of truth, not just a one-time plan.
Common Questions / FAQ
Who is backprop for?
Solo and indie teams using Blueprint/SDD specs who want agents to encode lessons from test failures and bugs into §B and §V.
When should I use backprop?
When `/build` verification fails; when a user reports a bug; after a production post-mortem; when `/check` returns VIOLATE with root cause; and during Operate iteration on recurring incidents.
Is backprop safe to install?
It guides spec and test edits in your repo—review diffs like any planning skill; see the Security Audits panel on this Prism page before auto-committing spec changes.
SKILL.md
READMESKILL.md - Backprop
# 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.