Problem
★ Insight candidates are harvested from ordinary session narrative and drained by
skills/knowledge-flush. Nothing distinguishes the highest-signal source there is:
a defect that review actually caught and that was then fixed.
That is a near-miss — a bug that was real, was diagnosed, and never shipped. It
comes with its own trigger (the diff signal that should have raised it), its own
mechanism, and its own evidence (the rework round that fixed it). Today it is
recorded only in reviews/<task>-rN.md and disappears when the run ends.
Proposal
When a Phase 4 review round finds a real defect — not style, not preference —
and the rework lands, the coordinator emits an ★ Insight candidate whose:
trigger = the diff signal that should have routed a reviewer to it
("a change adds a CLI flag not present in the pinned CI image's version"),directive = what a future reviewer should do on seeing that signal,evidence = the review round and the fix.
This closes the loop that #81 opens: review reads the wiki → review finds what the
wiki did not cover → that gap becomes a wiki page → the next review catches it
earlier. The pipeline already exists; only the emission point is missing.
Why
"Reviewing code is a skill"
proposes exactly this as its second experiment — a standing near-miss
post-mortem, where engineers record caught bugs and their context during
retrospectives, because the lesson otherwise stays with the one reviewer who
caught it. dev-loop's equivalent of "stays with one reviewer" is "stays in a
reviews/ file inside a worktree that gets pruned".
Scope
Evidence status
The pipeline's existence is verified. That review findings are a better wiki
source than generic session narrative is a design argument, not a measurement —
worth revisiting after one wave produces candidates from this path.
Source
Problem
★ Insight candidates are harvested from ordinary session narrative and drained by
skills/knowledge-flush. Nothing distinguishes the highest-signal source there is:a defect that review actually caught and that was then fixed.
That is a near-miss — a bug that was real, was diagnosed, and never shipped. It
comes with its own trigger (the diff signal that should have raised it), its own
mechanism, and its own evidence (the rework round that fixed it). Today it is
recorded only in
reviews/<task>-rN.mdand disappears when the run ends.Proposal
When a Phase 4 review round finds a real defect — not style, not preference —
and the rework lands, the coordinator emits an ★ Insight candidate whose:
trigger= the diff signal that should have routed a reviewer to it("a change adds a CLI flag not present in the pinned CI image's version"),
directive= what a future reviewer should do on seeing that signal,evidence= the review round and the fix.This closes the loop that #81 opens: review reads the wiki → review finds what the
wiki did not cover → that gap becomes a wiki page → the next review catches it
earlier. The pipeline already exists; only the emission point is missing.
Why
"Reviewing code is a skill"
proposes exactly this as its second experiment — a standing near-miss
post-mortem, where engineers record caught bugs and their context during
retrospectives, because the lesson otherwise stays with the one reviewer who
caught it. dev-loop's equivalent of "stays with one reviewer" is "stays in a
reviews/file inside a worktree that gets pruned".Scope
skills/orchestrate/SKILL.mdPhase 4 (emission point + the real-defect vsstyle distinction).
★ Insight format is unchanged.
Evidence status
The pipeline's existence is verified. That review findings are a better wiki
source than generic session narrative is a design argument, not a measurement —
worth revisiting after one wave produces candidates from this path.
Source
post-mortems)