Observed. `engram learn runbook` (and the learn skill's kind=runbook handoff to write-memory) captures `situation`, `done_when`, and `body` (steps). It never asks what people get wrong doing the procedure. The runbook-vs-skill eval (dev/eval/cumulative/runbook_vs_skill/phase2, 2026-09-13) showed the skill-written history-rewrite carrier, whose red flags name task-specific failure modes ("filter-branch on all refs sweeps your backup branch"), went 2/3 on end result where the bare-steps runbook and fact notes went 0/3.
Context. Design decision (explore session 2026-09-13, Joe): behavioral rules split by what they know. General rules (don't skip steps, the urge to shortcut is the cue to reread) live in the CLAUDE.md shim and apply to every runbook uniformly. Task-specific red flags live in the note, in a new optional structured field (option 1: a `watch_for`/`red_flags` field alongside situation/done_when/body, not a conventional heading in body). The runbook-shim change will add the field; this issue covers the capture side.
Expected. When the learn skill crystallizes a runbook (kind 4b confirmed approach, runbook shape), its handoff to write-memory asks for and passes runbook-specific red flags: "what did people get wrong doing this, that a general 'follow the steps' rule would not catch?" `engram learn runbook` accepts the corresponding flag. Notes must NOT restate general rules (that is the drift the shim layer exists to prevent). Skill edits via superpowers:writing-skills TDD.
Repro. Run the learn skill's runbook path on any confirmed procedure; observe no prompt for failure modes and no field to hold them.
Related. #735 (task-start cue), #719 (runbook kind), the runbook-shim change (to be filed).
Observed. `engram learn runbook` (and the learn skill's kind=runbook handoff to write-memory) captures `situation`, `done_when`, and `body` (steps). It never asks what people get wrong doing the procedure. The runbook-vs-skill eval (dev/eval/cumulative/runbook_vs_skill/phase2, 2026-09-13) showed the skill-written history-rewrite carrier, whose red flags name task-specific failure modes ("filter-branch on all refs sweeps your backup branch"), went 2/3 on end result where the bare-steps runbook and fact notes went 0/3.
Context. Design decision (explore session 2026-09-13, Joe): behavioral rules split by what they know. General rules (don't skip steps, the urge to shortcut is the cue to reread) live in the CLAUDE.md shim and apply to every runbook uniformly. Task-specific red flags live in the note, in a new optional structured field (option 1: a `watch_for`/`red_flags` field alongside situation/done_when/body, not a conventional heading in body). The runbook-shim change will add the field; this issue covers the capture side.
Expected. When the learn skill crystallizes a runbook (kind 4b confirmed approach, runbook shape), its handoff to write-memory asks for and passes runbook-specific red flags: "what did people get wrong doing this, that a general 'follow the steps' rule would not catch?" `engram learn runbook` accepts the corresponding flag. Notes must NOT restate general rules (that is the drift the shim layer exists to prevent). Skill edits via superpowers:writing-skills TDD.
Repro. Run the learn skill's runbook path on any confirmed procedure; observe no prompt for failure modes and no field to hold them.
Related. #735 (task-start cue), #719 (runbook kind), the runbook-shim change (to be filed).