session-observer

Session Observer

guard learn already turns repeated Bash approvals into policy-allow proposals. This skill generalizes the same idea across the WHOLE session — not just tool approvals, but corrections, repeated workarounds, and "actually, do it this way" moments — so they become durable, reviewable proposals instead of evaporating with the context window.

What to capture

At natural checkpoints (a task finishes, a fix loop converges, the user corrects your approach), write ONE episodic observation via memory_write when you notice:

• A correction. The user rejected an approach and stated why. Capture the why, not just the what — that's the reusable part.
• A repeated pattern. The same workaround, the same clarifying question, the same shape of bug fix — twice is a coincidence, three times is a pattern worth a proposal.
• A judgment call that worked. The user accepted an unusual choice without pushback. Silence after a nonstandard decision is a confirmation signal — capture it too, not only failures.

How to capture it

memory_write({ type: "decision", text: "<the pattern + why, in one or two sentences>", ts: <now> })
memory_write({ type: "failure", text: "<the approach that didn't work + why>", ts: <now> })

Use "decision" for a correction or judgment call (what to do, and why); use "failure" for an approach that was tried and rejected (so a later fresh-context subagent doesn't re-walk the same dead end). Both types are exempt from consolidation's prune-to-cap pass — they're kept in full, not summarized away, because the specifics are the value.

Keep it factual and specific enough that a future session (or a human reviewing the episodic store) can act on it without re-deriving the context. A vague "user prefers clean code" is useless; "user rejected mocked DB in integration tests — prior incident where mock/prod divergence masked a broken migration" is a proposal a human can ratify.

Boundary (this is observation, not authority)