bvandeusenandClaude Opus 5.5
7faaa311d7
The signal counted every get_rule open against every moment from the previous three minutes, so a rule a search arm had just shown was proposed for whatever moment happened to fire. All nine pending signal proposals were wrong. - The hook skips an open of a rule a hook named this session, and sends the last three acts from 90 seconds instead of 30 from 180. - A rule already mounted anywhere gathers no signal evidence. - A signal pair keeps the actions that reached its moment and shows them as its why. - The proposal line says it is co-occurrence, not a recommendation, and asks the reader to check the rule against the moment before offering it; moments.md says the same. Plugin 2026.10.26.2029. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
5.0 KiB
Moments — rules that arrive when the work reaches a point
Part of the using-grimoire skill. Read it when a line says a rule arrived at a moment, when a reply is held for one read, when an action reached the wrong moment or none, when a mounted rule arrived and did not apply, and when a line proposes mounting or unmounting a rule.
What a moment is
Most rules reach you by resemblance: what you are doing looks like what the
rule is about. A rule about WHEN — finishing, delivering, verifying,
reporting — resembles nothing said at that point, so resemblance misses it.
Such a rule is mounted on the moments of work it belongs to, and arrives
by lookup whenever an action reaches one. list_moments names them, each
with what is happening at it and the kinds of action that typically reach it:
work.deliver when work is sent beyond the place it was made, work.finish
when a piece of work is declared done, reply.report at the reply that ends a
turn, and so on. A named procedure is its own moment, skill.<name>, reached when it is
loaded.
Which ACTIONS reach a moment is the install's: one operator delivers with a push, another with a deploy script. Shipped defaults cover the common ones, and each install corrects them for itself.
Reading a line that arrived at a moment
The line names the moment and the action that reached it — "at work.deliver,
reached by git push" — and the rule, with get_rule(N) to read it. Read it
as you would any rule that arrived beside your work: it binds just as hard,
and it came because of what you are doing now, not because of what you said.
The reply that ends a turn is a moment too. When a rule mounted at
reply.report has not been opened this session, the reply may be held once
with its name: open it, then send the reply — unchanged, if it already does
what the rule asks. The same rule is never held twice.
When the moment is wrong — correct it in the session
A moment can fire on an action that is not that moment here, or an action can plainly be a moment and fire nothing. Either way the fix is one call, and it belongs in the session that noticed, not on a settings page:
- An action reached the wrong moment — the line names a moment that is not
what you did: offer
unmap_action(tool, moment, match, reason). - An action was a moment and nothing arrived — the operator ships with
their own script, and nothing mounted on
work.delivercame: offermap_action(tool, moment, match, reason).
Offer it in one line, the way the operator would say it ("that deploy script
is a deliver and nothing fired — map it?"), and make it on their yes. The
correction lasts for every later session on the install; list_moments shows
what each action reaches now.
When a mounted rule arrives and does not apply
A mount delivers its rule at every occurrence of the moment, so a mount that
is wrong is noise every time — and a rule you read and set aside leaves no
trace anyone else can see. When a rule arrived at a moment, you read it,
and it has nothing to do with what you were doing there, say so with
rule_misfired(rule_id, moment, why, reached_by): one call, nothing asked of
the operator. Name the action the line said reached the moment, and say what
you were doing, because the reports are what the operator decides from —
whether the rule does not belong at the moment, or one action is reaching it
that is not that moment here.
Reports gather across days. Once a rule has them on three, the response
carries a line asking you to offer the fix, and the operator sees it under
Settings › Moments too: judge_rule_moments reject takes the rule off,
unmap_action stops the action reaching the moment, and confirm keeps the
mount and ends the question. A rule that applied — even one you were already
following — is not a misfire, and a rule that arrived by its words rather
than a mount is fixed through its trigger instead.
When a line proposes a mount
A rule that sessions keep going and opening just after the same moment —
without a hook having shown it to them first — may belong on that moment. A
line says so, naming the rule, the moment, the action that reached it and how
often. That is co-occurrence, not a recommendation, so judge it before it
reaches the operator: read the rule's trigger against what the moment means
(list_moments). Offer it only when the rule governs that point in the work
whatever the work is about, as a question with your reason; a rule about a
subject (a library, a file, a style) is reached by meaning, and the line is
left alone. Record their answer with judge_rule_moments — confirm mounts
the rule, reject with their reason stops the question being asked again.
The same tool answers proposals from a pass over the rules
(rules_to_mount, propose_rule_moments, rule_moment_proposals): a pass
proposes, and only the operator's yes mounts. Writing a NEW rule is different
— its moments are part of writing it, and the
skill's guide to writing records says how.