What
The capture skill's "Do Not Save" table and the audit skill's DROP categories describe the same six rejection reasons in two files:
| continuous-learning |
memory-audit |
| Historical record of a one-time shipped change |
category B |
| Naming/prefix decision once enforced |
category C |
| One-time bug fix self-evident in current code |
category D |
| Generic engineering wisdom with a token project example |
category E |
| Research artifact for deferred or dormant work |
category F |
| One-line rule that belongs in CLAUDE.md |
category G |
Nothing checks that the two stay consistent, and two pairs had already drifted before anyone looked. Only the audit side knew that a project without version control keeps its history nowhere else, and a Swift-specific example survived on the capture side after being replaced on the audit side.
Naming conventions and staleness signals are duplicated the same way: "Memory Categories" against C.1, and "Staleness Prevention" against C.5.
Why a SYNC block does not solve it
The repo already has a mechanism for shared text, with three locked blocks verified in CI. It does not fit here.
The two skills need different shapes. Capture wants one line and a bad example. The audit wants the same category plus a "keep only when" exception clause that capture has no use for. Forcing the text to be identical would drop the exceptions.
Capture also cannot point at the audit skill instead. techpack.yaml marks continuous-learning as isRequired: true and memory-audit as optional, so capture has to work on machines where the audit skill is not installed.
Options
- Document the pairs in
SYNC-BLOCKS.md as a "change one side, check the other" list. Cheap, no CI, and it relies on the maintainer reading it.
- Reformat the audit's categories into the capture table's shape so a real locked block becomes possible. Hard guarantee, but the exception clauses need somewhere else to live.
- Accept the drift and catch it in review.
Option 1 was drafted once and reverted along with a larger change set. Worth picking one deliberately rather than by default.
What
The capture skill's "Do Not Save" table and the audit skill's DROP categories describe the same six rejection reasons in two files:
Nothing checks that the two stay consistent, and two pairs had already drifted before anyone looked. Only the audit side knew that a project without version control keeps its history nowhere else, and a Swift-specific example survived on the capture side after being replaced on the audit side.
Naming conventions and staleness signals are duplicated the same way: "Memory Categories" against C.1, and "Staleness Prevention" against C.5.
Why a SYNC block does not solve it
The repo already has a mechanism for shared text, with three locked blocks verified in CI. It does not fit here.
The two skills need different shapes. Capture wants one line and a bad example. The audit wants the same category plus a "keep only when" exception clause that capture has no use for. Forcing the text to be identical would drop the exceptions.
Capture also cannot point at the audit skill instead.
techpack.yamlmarkscontinuous-learningasisRequired: trueandmemory-auditas optional, so capture has to work on machines where the audit skill is not installed.Options
SYNC-BLOCKS.mdas a "change one side, check the other" list. Cheap, no CI, and it relies on the maintainer reading it.Option 1 was drafted once and reverted along with a larger change set. Worth picking one deliberately rather than by default.