Greatpractice
Full spec (AI-readable): Greatpractice.md →
A codification system. Memory notes become the trigger; recurring patterns get promoted into auto-enforced practices.
Memory-triggered codification discipline. memory feedback → maturation gate → ratified entry in a 3-tier tree, enforced by 7-event lifecycle hooks. Frontmatter governance SSoT.
The problem Greatpractice solves
What Greatpractice is
Memory notes are the trigger. Patterns that recur in memory with sufficient cost get promoted into auto-enforced practices.
Memory feedback in → 5-axis maturation gate → 3-tier macro/mezzo/micro tree out, enforced by 7-event lifecycle hooks. phronesis_boundary protects un-codifiable work.
The core idea
Central thesis
Quiet omissions aren't a memory problem — they're missing automation. Greatpractice watches memory and promotes solid patterns into automation.
Memory is the input signal, not the storage. Promotion moves obligations from memory-readable to hook-enforceable. Frontmatter schema is the single largest lever.
How it grew — from the first cut to now
Scope history — v0.1.0 first cut → v0.3.x current
Current: v0.3.4. Since the first cut: nine mid-level practices + twenty atoms, research appendices backfilled from primary sources (two first-draft claims retracted where the evidence did not support them), and a first callable command — /routinize. The description below is the original first cut, kept because it states the module's purpose most clearly.
Current: v0.3.4 (spec v0.3.3). Delta since v0.1.0: 1 → 9 mezzo → 20 micro atoms; §B.5/§B.6 backfilled from primary sources (two v0.1 over-claims corrected); /routinize shipped. The v0.1.0 scope below is retained as the canonical statement of intent.
First cut keeps moving parts minimal: the full design doc + one obligation actually promoted out of memory into the runtime + the small machinery that makes it real.
v0.1.0 scope: spec (2220 lines) + 1 mezzo + 1 micro + 1 hook. v0.2-v0.4 roadmap defined (manifest hash / renderers / voice linter / MESI / CMMI L4 effectiveness).
The first ratified rule — Outbox JSON Validation
Reference entry: outbox-json-validation
An obligation that lived in memory moved into the runtime. Now the system blocks the unsafe path before it can run.
Memory signal → notability gate (3 + 2 independent + verifiable) → 5-axis maturity score 21/25 → ratify. Backing PreToolUse contact hook + 1-line memory redirect stub.
Install
Add the EstreGenesis marketplace to Claude Code. You only need to do this once per machine — afterwards every EG plugin installs by name.
/plugin marketplace add SoliEstre/EstreGenesisInstall the Greatpractice plugin from the marketplace. It ships the ratified-entry registry + the lifecycle hooks that turn recurring memory signals into runtime-enforced rules.
/plugin install greatpractice@estregenesis-pluginsExample prompts
When you notice the same step keeps slipping through (e.g. forgetting to update the README before a release), have Greatpractice review the routine and promote the missing step into an enforced practice so it stops dropping in future cycles.
When I did the npm publish last time, didn't I forget to check whether the README was updated first? Review my release routine and codify it through Greatpractice.When you suspect a pattern is recurring often enough to deserve formal codification but you are not sure, ask Greatpractice to run the 5-axis maturation gate (frequency + depth + recency + cost + predictability) and tell you the score.
This pattern keeps coming up — run the Greatpractice maturation gate on it and tell me whether it should be promoted.How it gets used — turning "don't forget to do X" into rules the computer enforces
Use cases — 5 worked examples of memory-to-runtime promotion
Five real-life examples showing how Greatpractice takes a small chore that the AI has been forgetting and turns it into a rule the system itself watches for.
Five worked examples mapping memory signals → 5-axis maturation gate → ratified entry + backing hook. Covers all three poka-yoke subtypes + phronesis_boundary.
Stopping messages from disappearing without anyone noticing
Outbox JSON validation — contact-subtype PreToolUse hook
When the artificial intelligence (AI) helpers in this project send messages to each other, sometimes the message goes out in a wrong shape and ends up empty inside — but no one notices at the time, so the actual content is lost.
A2A messages to collab/outbox.jsonl require valid single-line JSON per row. Bash HEREDOC redirects silently inject trailing content, malforming the row + triggering bridge fallback to say transport.
- The first time the problem happens, write a short note about it in the memory folder (a folder where the AI keeps reminders for itself).
- Each time the same problem comes back, add a note about what was different that time — was it a different kind of work? a different time of day? — so we can see whether the pattern is real or just a one-off.
- When the same problem has happened at least 3 times, in at least 2 different situations, and we can actually measure how much trouble it caused — the system automatically writes up a draft rule.
- Confirm the rule and mark it as "must follow" (so the system will block any attempt that breaks it, not just warn).
- Hook up a small checker (a tiny background program that runs at the right moment) that examines every outgoing message before it leaves, and refuses to send if the shape is wrong.
- Replace the original memory note with a single line that just points to the new rule — so nothing is duplicated, but anyone who looks at the note still knows where the rule lives.
- First incident → write
memory/feedback_outbox_json_validation.mdcapturing context + recovery cost. - Each recurrence → append delta (different cycle phase? different payload class? same shell?) to support cross-context independence check.
- Notability gate: ≥3 occurrences + ≥2 independent triggers + verifiable effect (recovery cost in agent-cycles).
- 5-axis maturity score: frequency 3 + depth 4 + recency 5 + cost 4 + predictability 5 = 21 (threshold ≥ 18). Ratify as mezzo with enforcement_level=mandatory.
- Wire PreToolUse contact hook (
plugins/greatpractice/hooks/contact/outbox-json-validate.cjs): matches Write tool onoutbox.jsonl+ Bash tool referencing it; blocks HEREDOC pattern + direct shell redirect; allowsscripts/eg_outbox_push.cjspath. Exit 2 + voice-checked block message on violation. - Replace raw memory file with 1-line redirect stub pointing at
greatpractice/mezzo/outbox-json-validation.md— preserves cross-reference graph without duplicate content.
Making sure the work session can't start with something broken
SessionStart bridge-liveness probe — fixed-value blocking hook
When you start a work session with the artificial intelligence (AI), there's a connection that needs to be alive — a bridge that lets different AI helpers talk to each other. If the bridge is dead and the session starts anyway, you only find out later when something silently fails. We want the session to refuse to start until the bridge is confirmed alive.
Session resume / IDE reboot / cold boot leaves the Constellation WS bridge unspawned. Outbox pushes during the dead-bridge window succeed at file-write but never reach the server. Captured at feedback_session_resume_bridge_spawn.md.
- Write a rule that says: "When a session starts, first check that the bridge is alive."
- Mark this rule as "must follow" so that until the bridge check passes, the AI can't use any of its tools — no editing files, no running commands, nothing.
- The check runs at the very moment the session starts. If the bridge is alive, work proceeds normally. If not, the session is blocked with a friendly explanation (no scolding — just "here's what's wrong and here's how to fix it").
- Keep a small tally of how often the check actually catches a dead bridge, so we can see if the rule is earning its keep or if the underlying problem has been fixed and we can retire the rule.
- Ratify mezzo entry
greatpractice/mezzo/session-resume-bridge-spawn.mdwith trigger.if="SessionStart event fires" · trigger.then="verify WS bridge process + outbox connectivity before any tool admission" · enforcement_level=mandatory. - Wire SessionStart blocking hook (
plugins/greatpractice/hooks/fixed-value/bridge-liveness.cjs) — fixed-value subtype: probescollab/.bridge-pid+ sends a heartbeat ping to the WS endpoint, asserts both succeed before returning continue. Exit 2 + injected guidance message on failure; all subsequent tool calls suppressed until reverification. - Block message follows §6 blameless template: surfaces the spawn command (
node collab/collab-client.cjswith required env vars) + reference to the canonical entry; no agent-fault attribution. - Telemetry: hook-fire count + block-vs-pass ratio logged to
collab/practice_telemetry.jsonl(deferred to v0.2). Feeds §10.5 retirement-eligibility evaluation should bridge spawn become harness-automatic.
Catching the moment when copies fall out of sync with the original
N-way SSoT propagation — PostToolUse motion-step hook
When you change a main document (like an official entry, or the version number shown on the homepage), there are usually a few other places that quietly show the same information — other webpages, settings files, short summaries. They're all supposed to update at the same time. But sometimes one or two get forgotten, and now the original says one thing while the copies still say the old thing — and nobody notices for a while.
EG N-way sync registry (AGENTS.md §5.8): version + module-version bumps touch multiple downstream surfaces. SSoT update without propagation produces silent staleness across the doc surface.
- Write a rule that says: "Whenever someone changes the original document, check all the copies that should match it."
- When the original is changed, the system goes through every copy and notes which ones still have the old date and which were updated together.
- Mark this rule as "strongly suggested" rather than "must follow" — falling out of sync is a real problem, but it's not the kind of thing where you want to slam on the brakes mid-work. A clear warning is enough to make sure no one misses it.
- If someone ignores the warning more than once, the system gets gradually firmer: first a clear reminder, then asking the person to revert and acknowledge, and if it keeps happening, a full discussion is triggered.
- The check fires right after the original is saved — that way the warning appears at exactly the moment the person is still thinking about the change, not hours later when they've moved on.
- Ratify mezzo entry
greatpractice/mezzo/ssot-propagation.mdwith sync_registry frontmatter field enumerating dependent surfaces. - Wire PostToolUse motion-step hook (
plugins/greatpractice/hooks/motion-step/ssot-propagation.cjs): on Write/Edit to a registered SSoT path, diff the registry against the current commit's working tree + emit warnings for surfaces not co-modified within the same commit boundary. - enforcement_level=recommended (not mandatory) — sync drift is real but not the class to hard-block mid-work; a clear warning surfaces the gap. Aligns with §6 voice (no blame, multi-causal framing).
- Progressive escalation ladder (§10): repeat misses bump severity — clear reminder → revert-and-acknowledge prompt → full Hyperbrief escalation. Tracked via miss_count field (deferred to v0.2).
- PostToolUse lifecycle event timing (immediately after SSoT write) maximizes context-correction win — warning surfaces while the change is still in working memory, not hours later when context has rotated.
Making sure the steps happen in the right order — every time
Pre-send inbound check — PreToolUse motion-step ordering hook
When a job has several steps that must happen in a specific order — first check the mailbox, then read the new messages, then send your reply, then mark the mailbox as "up to date" — and the artificial intelligence (AI) sometimes skips or shuffles a step. Skipping or shuffling causes messages to get lost or for the system to think it's caught up when it isn't.
Constellation A2A: probe → read → classify → incorporate-or-abort → emit → advance cursor. A2A has no in-flight rejection — stale sends silently "succeed". Captured at feedback_pre_send_inbound_check.md.
- Write a rule that knows the correct order of steps and quietly keeps track of which step was finished last in this session.
- When the artificial intelligence (AI) is about to do a step (say, "send the reply"), the rule pauses for a moment and checks: "Was the previous step actually finished first?"
- The rule also confirms that the step it's about to do matches what was just read — so it can't accidentally reply to the wrong message.
- Mark this rule as "must follow" — getting the order wrong can quietly lose work, so the system needs to actually stop the wrong-order step from happening, not just warn.
- If the order is wrong, the step is blocked, and a gentle message explains what the correct next step should be — no scolding, just helpful guidance.
- Ratify mezzo entry
greatpractice/mezzo/pre-send-inbound-check.mdwith dual-check trigger.then + enforcement_level=mandatory. - Wire PreToolUse motion-step hook (
pre-send-inbound.cjs): on outbox-emit signature, dual-check (a) cursor mtime > previous-emit (prerequisite-completion) + (b) payload references latest surfaced message-id (payload-match). Exit 2 on either failure. - State tracking:
collab/.last-emit-cursorcompanion file records cursor-mtime per successful emit; hook compares current.last-surfaced-cursorto detect missing probe-between-emits. - enforcement_level=mandatory — at-most-once + no in-flight rejection means warning-only is insufficient (failure structurally undetectable post-emit). Block-then-guidance preserves agent agency.
- Block message (§6): surfaces missing antecedent + canonical sequence; multi-causal framing; no attribution.
Leaving room for judgment when a rule shouldn't be absolute
phronesis_boundary — explicit non-codification carve-out
Some patterns happen a lot, and they really do cost something when missed — but the right thing to do depends on the situation. "Always do X" sounds clean, but in real life X is right for most cases and wrong for a few. If we force the rule to be absolute, we take away the artificial intelligence (AI)'s ability to make the right call in the cases where the rule shouldn't apply.
Dual failure: under-codification + over-codification. Judgement-heavy patterns (rare + high-context + stakeholder-balancing) shouldn't graduate to mandatory enforcement; blind enforcement strips judgement-capacity precisely where it's needed.
- When the system is deciding whether to promote a memory note into a rule, also check three questions: does this only come up in unusual situations? does the same trigger lead to opposite decisions depending on context? does the right answer involve weighing several people's needs against each other?
- If two or more of those are true, mark the rule as "needs judgment" — a clear flag that this is the kind of pattern where blind enforcement would do harm.
- Even if the rule otherwise scores high enough to be made mandatory, mark it as "informational only" instead — never "must follow."
- At the moment the pattern would apply, the system quietly shows the rule and the reasoning behind it as a note in the corner — the AI can read it, take it into account, and still decide for itself what to do.
- An automatic format-checker makes sure no one accidentally turns a "needs judgment" rule into a "must follow" rule later — that combination is blocked at the configuration level.
- At maturation evaluation, run 3-question phronesis screen: (a) rare-context (<10% of nominal cases)? (b) context-inverting (same trigger → opposite right-action across contexts)? (c) stakeholder-balancing?
- If ≥2 of (a)/(b)/(c) hold, set
phronesis_boundary: truein frontmatter — declarative flag marking the pattern as non-codifiable-as-mandatory regardless of maturity score. - Schema constraint:
phronesis_boundary: trueforcesenforcement_level: informational— JSON Schema validator rejects other combinations. Maturity score + tier unaffected; only enforcement axis is locked. - At fire moment, hook injects entry reasoning as context note (not block) — agent reads, considers, retains decision authority. UserPromptSubmit lifecycle event (§4.1 event #2) with path-scoped inject is the typical surface.
- Manifest validator checks (
phronesis_boundary,enforcement_level) tuple at lint time — invalid combinations fail CI. Prevents subsequent-edit drift.
If you'd like to read more
Read the full spec
The full design document is on GitHub — 12 chapters plus 3 appendices. It covers, in plain order: how rules are organized into big / mid / small-step groups; how the system enforces rules so the AI doesn't have to remember them; how the check decides whether a memory note is ready to become a rule; and how we mark off work that needs judgment.
Greatpractice.md = the spec (v0.3.2 current). reports/2026-06-04-greatpractice-research/ = research backing (~8108 lines).