bvandeusenandClaude Opus 5.5
a72a422534
Until now only the tool arguments knew moments existed. The guidance surfaces described rules as reached by resemblance alone: - using-scribe: a short reflex paragraph and a new reference file, moments.md. It covers reading "at <moment>, reached by <action>", the reply held once at reply.report, map_action / unmap_action offered in one line, and the step 7 proposal line answered with judge_rule_moments. - writing-records: asks WHEN a rule applies as well as what it is about. A rule, preference or process about a point in the work gets moments=[...] as it is written, and the trigger stays as the net. - missed-retrieval: a missed WHEN is mounted or mapped, not reworded. A misfire is unmounted or unmapped. - _INSTRUCTIONS: one clause (list_moments; mount rules about WHEN), 1594 of 1600 chars. - static context: injected lines include the rules mounted on a moment that was reached. - test_guidance_ownership: three owned topics, so the text cannot quietly drop out. Plugin minted. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
3.4 KiB
Moments — rules that arrive when the work reaches a point
Part of the using-scribe 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, and when a line proposes mounting 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 line proposes a mount
A rule that keeps being opened just after the same moment, across several
sessions, probably belongs on that moment. A line says so, naming the rule,
the moment and how often. It is a question for the operator, not a change you
make: offer it in one line, and 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
writing-records.md says how.