backprop

Traces bugs to root causes and appends preventive invariants to a specification file.

1|Updated May 6, 2026
One-click install
npx skills add https://github.com/surfingalien/FinSurfing --skill backprop-surfingalien
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: backprop
Source: https://github.com/surfingalien/FinSurfing/tree/main/.claude/skills/ck%3Abackprop
Command: npx skills add https://github.com/surfingalien/FinSurfing --skill backprop-surfingalien

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When a bug is fixed, most workflows patch the code and move on, letting the same class of bug recur later. This Skill turns every bug, test failure, or post-mortem into a permanent specification update so the failure mode cannot silently return. ## Core Features & Use Cases - Six-step bug-to-spec protocol: Trace the root cause, analyze whether a new invariant would catch it, propose the spec edit, generate a failing test, verify the fix, and commit everything together. - Invariant quality guidance: Distinguishes testable, behavior-scoped invariants from vague rules, with concrete good and bad examples. - Scope judgment rules: Defines when not to add a new invariant (mechanical typos, one-time migrations, external dependency issues) while still logging the incident in the bug ledger. - Use Case: A refund job runs twice on retry. The Skill guides you to record the incident in the bug ledger, add an idempotency invariant to the spec, write a failing test named after that invariant, fix the code, and commit all four artifacts in one commit. ## Quick Start Ask the AI to run the backprop protocol on the failing test or bug report and update the spec with a new invariant and regression test.

Frequently Asked Questions about backprop

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I prevent the same bug from recurring after fixing it?

Run the backprop protocol: trace the root cause, add a testable invariant to the specification's invariant section, write a failing regression test named after that invariant, then fix the code and commit everything together. The spec becomes a permanent record of failure modes.

What is spec-driven development backpropagation?

Backpropagation in spec-driven development means feeding bug findings back into the specification rather than only patching code. Each incident appends a bug ledger entry and usually a new testable invariant, so future changes are checked against accumulated failure knowledge.

When should I not add a new invariant for a bug?

Skip the invariant when the bug is a purely mechanical typo with no recurring class, a one-time migration, or caused by an external dependency. Still record the incident in the bug ledger so future similar bugs show a documented precedent.

What makes a good testable invariant in a specification?

A good invariant is testable in code through grep or assertions, scoped to a behavior rather than a file, and stated positively where possible. For example, requiring idempotency key checks before charge reversals is testable, while stating code should be correct is not.

How do I write a regression test for a fixed bug?

Write the failing test before fixing the code, and name it after the invariant it enforces, such as TestV7_RefundIdempotent. Then fix the code, confirm the test passes, and run the full suite to check for regressions.