backprop

A bug-to-spec protocol for spec-driven development (SDD). Where plan-then-execute workflows fix the code and forget, this skill fixes the code and edits the spec so the same class of failure cannot recur. That spec edit is what the skill calls backprop, described as the one non-obvious thing SDD does that plan-then-execute does not.

It triggers on a test failure, a bug report, a post-mortem after a production incident, or when a `/check` flags a VIOLATE with a root cause found. The workflow follows six steps: TRACE the failure to the exact file and line and name the root cause in one sentence; ANALYZE whether a new invariant would catch the class of bug, whether the interface spec is wrong, or whether the wrong thing was built; PROPOSE a spec change, always appending a row to the bug ledger (§B) and usually adding an invariant (§V); GENERATE a failing test named after the invariant (for example `TestV7_RefundIdempotent`) before fixing; VERIFY by fixing the code, passing the new test, and running the full suite without regression; and LOG by committing the spec edit, test, and code fix together in a single commit.

Guidance is provided on what makes a good invariant: testable in code, scoped to a behavior rather than a file, stated positively when possible, and tied to the interface surface where it applies. The skill also notes when not to add an invariant, such as a purely mechanical typo with no class, a one-time migration, or a root cause in an external dependency. Even then a bug-ledger entry is still appended so that future bugs with the same smell surface the prior precedent. The output of every run is a §B entry, usually a §V entry, a test file when an invariant is added, a code fix, and one commit; the spec file plus git history is the full record, with no dashboards or log files.