Files
FabledScribe/plugin/skills/using-scribe/moments.md
T
bvandeusenandClaude Opus 5.5 8afd6da8af
CI & Build / Python lint (push) Successful in 3s
CI & Build / Plugin hooks (push) Successful in 14s
CI & Build / TypeScript typecheck (push) Successful in 56s
CI & Build / integration (push) Successful in 59s
CI & Build / Python tests (push) Successful in 2m11s
CI & Build / Build & push image (push) Successful in 41s
docs(plugin): reference files point at each other in words, not links - one level deep (milestone 458 step 8, #4926)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-05 16:44:22 -04:00

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.deliver came: offer map_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 the skill's guide to writing records says how.