feat: route consume knowledge to two channels (#9-#14)
Reworks the consume skill around two acceptance axes and two destinations, implementing the six issues filed from the first real consume run as one design. - Add trigger-ability as a second acceptance axis alongside generalizes, with its two premises; a pull-channel note now requires both (#9). - Give consume a push channel — the target's own CLAUDE.md — for knowledge that fails an axis but is still useful: specific residue or proactive rules (#10). - Name the general-lesson/specific-residue split and route each half (#12). - Make the step-5 plan report a complete ledger with a per-note trigger line, push write-set, ref-fixes, flagged-not-authored, and drops (#13). - Extend project cleanup to reconcile CLAUDE.md (capture-gated removal/trim) and fix references to deleted files wherever they land (#11). - Encode a branch-owned output location: project notes flat under 01 sources/claude/projects/, honoring any pre-existing grouping (#14). Records the resolved vocabulary in .claude/CONTEXT.md and the two-channel write decision in .claude/adr/0001. Closes #9 Closes #10 Closes #11 Closes #12 Closes #13 Closes #14
This commit was merged in pull request #15.
This commit is contained in:
54
.claude/CONTEXT.md
Normal file
54
.claude/CONTEXT.md
Normal file
@@ -0,0 +1,54 @@
|
||||
# Skills
|
||||
|
||||
A personal collection of Claude Code skills.
|
||||
The language below covers the knowledge-mining pipeline — the `consume` (write) and `wiki` (read) pair that move knowledge into and out of the user's Obsidian vault.
|
||||
|
||||
## Language
|
||||
|
||||
### Places
|
||||
|
||||
**Vault**:
|
||||
The user's personal Obsidian knowledge base, read through `wiki` and written only within one area by `consume`.
|
||||
_Avoid_: notes folder, Obsidian
|
||||
|
||||
**Pull channel**:
|
||||
The vault area holding reusable knowledge, retrieved on demand by a future agent that goes looking for it.
|
||||
_Avoid_: wiki proper, retrieval store
|
||||
|
||||
**Push channel**:
|
||||
The target's own always-loaded documentation (its `CLAUDE.md`), whose value is being in front of an agent unprompted.
|
||||
_Avoid_: proactive store, always-on docs
|
||||
|
||||
**Target**:
|
||||
The single source `consume` ingests in one run — currently a project directory.
|
||||
_Avoid_: source (reserve for the raw material within the target), input
|
||||
|
||||
### Acceptance axes
|
||||
|
||||
**Generalizes**:
|
||||
A mined fact's property of teaching something true on a *different* target, not only the one it came from.
|
||||
_Avoid_: reusable, transferable (use only informally)
|
||||
|
||||
**Trigger-able**:
|
||||
A mined fact's property of having a recognizable symptom, error, or task that would send a future agent to retrieve it.
|
||||
_Avoid_: searchable, useful
|
||||
|
||||
### What a source line yields
|
||||
|
||||
**General lesson**:
|
||||
The transferable principle split out of a source line.
|
||||
_Avoid_: concept, insight
|
||||
|
||||
**Specific residue**:
|
||||
The concrete, target-only answer left after the general lesson is split off.
|
||||
_Avoid_: leftover, detail
|
||||
|
||||
**Proactive rule**:
|
||||
A mined fact that generalizes but is not trigger-able — a verification-discipline or design-stance rule whose value is firing unprompted.
|
||||
_Avoid_: habit, guideline
|
||||
|
||||
### Planning
|
||||
|
||||
**Contribution map**:
|
||||
The many-to-many record of which consumed file fed which planned note, with the exact contributing sections, including files that fed nothing.
|
||||
_Avoid_: provenance table, coverage map
|
||||
17
.claude/adr/0001-consume-writes-target-push-channel.md
Normal file
17
.claude/adr/0001-consume-writes-target-push-channel.md
Normal file
@@ -0,0 +1,17 @@
|
||||
# Consume writes the target's push channel, not only the vault
|
||||
|
||||
`consume` was scoped to write only inside the vault's `01 sources/claude/` area.
|
||||
A real run showed that most mined knowledge is not wiki-shaped — specific residue and proactive rules belong in the target's own always-loaded `CLAUDE.md` — and dropping it lost real signal, while redoing the target-doc edits by hand after each run was toil.
|
||||
We decided `consume` writes a second channel outside the vault, the target's `CLAUDE.md`, rather than only planning those edits for the user to apply.
|
||||
|
||||
## Considered Options
|
||||
|
||||
- **Plan-only** — spell the target-doc edits out in the report and have the user apply them by hand.
|
||||
Rejected: the whole value is not redoing what the run already worked out.
|
||||
- **Auto-write both channels (chosen)** — apply the target edits too, but present them as a distinct, independently-approvable write-set under the one plan-approval gate, so a write outside the vault is never a surprise.
|
||||
|
||||
## Consequences
|
||||
|
||||
`consume`'s blast radius now includes files outside the vault and outside the spec/task scaffolding it deletes.
|
||||
The plan-approval gate is what keeps that safe: the target write-set is approved separately from the vault write-set, and a declined target write-set degrades to flagged suggestions.
|
||||
Destructive edits to `CLAUDE.md` are gated on capture — an entry is removed or trimmed only when its general part is present in the wiki.
|
||||
Reference in New Issue
Block a user