---
id: gh-backprop
name: "backprop"
url: https://skills.yangsir.net/skill/gh-backprop
author: juliusbrussee
domain: ai-code-generation-quality
tags: ["bug-fixing", "spec-management", "quality-assurance", "software-engineering", "test-generation"]
install_count: 2600
rating: 4.40 (120 reviews)
github: https://github.com/juliusbrussee/cavekit/tree/main/skills/backprop
---

# backprop

> backprop 是一种结构化的缺陷修复流程，通过追踪、分析、更新规范和生成测试，确保代码质量并防止缺陷再次发生。它将每次缺陷修复转化为对系统规范的改进，从而提升软件的长期稳定性。

**Stats**: 2,600 installs · 4.4/5 (120 reviews)

## Before / After 对比

### 减少重复缺陷率

**Before**:

在没有结构化流程的情况下，缺陷修复往往是临时的，导致相同或类似问题反复出现，浪费大量开发资源。

**After**:

通过 backprop 流程，每次缺陷修复都伴随规范更新和测试生成，从根本上杜绝重复缺陷，显著提升代码质量和开发效率。

| Metric | Before | After | Change |
|---|---|---|---|
| 重复缺陷率 | 30% | 5% | -83% |

## Readme

# 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.


---
*Source: https://skills.yangsir.net/skill/gh-backprop*
*Markdown mirror: https://skills.yangsir.net/api/skill/gh-backprop/markdown*