ruling-capture

Ruling Capture

A user says "always expand a delete command before running it" or "route that kind of review to a different model" or "stop asking, just do it and tell me after." That is a ruling: a standing decision meant to bind every future session, issued in conversation and recorded nowhere. When the session ends it is gone, and the next session cheerfully does the thing it was told not to.

A ruling is durable only when a future session can find and apply it without access to the conversation that produced it.

How this differs from the two nearby skills

failure-mode-capture starts from an incident and requires a concrete consequence. Its own text says that a rule without one "is a style preference, and belongs in the bundle or a code review, not here." Many rulings are exactly that: a preference, a priority call, a scope boundary, a judgment about how the user wants to work. Real, binding, and outside that skill's stated scope.

context-layering says where a fact belongs and sets the ceiling on AGENTS.md. It does not say how a ruling gets out of the conversation and into a file. This skill is that procedure, for the specific case where the source is the user talking rather than a bug.

Rule of thumb: a bug taught you something, use failure-mode-capture; a person told you something, use this.

Where a ruling goes

Into the tracked document that owns its subject. That might be a conventions file, an architecture decision record, a runbook, or an area's COMPASS.md. Create a focused document when none owns the subject yet.

The main instructions file gets a one-line pointer and nothing more: what the rule is about, and the path to the document holding it. See TEMPLATE-pointer.md for the line and TEMPLATE-ruling-doc.md for the document.

Putting the full text inline because that file is always loaded charges every unrelated session for it, forever. That is how an instructions file grows past the ceiling context-layering sets.