refiners-update

Refiners Update

The update-mode counterpart to lattice-init. Where lattice-init detects missing standards and routes you to refiners to create them, this molecule detects existing standards and routes you to each refiner's revise mode to update them after a significant change — then records what changed and why.

It orchestrates the refiners; it never reimplements their interviews. Versioning is git-native: history lives in commits, and each revised document gets a one-line change note. No version numbers are introduced.

Required Skills

Read, apply:

1. framework:knowledge-priming -- Load project context. Understand what the project is and how the code has drifted from the current standards (always).

What This Does (and does not)

• Does: coordinate revising one or more existing standards documents after a change, and append a change note to each.
• Does not: create standards that do not exist yet (that is lattice-init + the relevant refiner), reimplement any refiner's interview, or introduce version numbers.

If the change requires a standard that does not exist yet (e.g. the team just adopted DDD but there is no ddd-principles.md), that is creation — direct the user to /lattice-init or the relevant refiner to create it, and note it in the summary.

Refiner → standards document map

Maintainer note: This table mirrors the refiner inventory. When a refiner is added or removed, update this table (and lattice-init's refiner list). skill-align flags inventory drift across docs.

Workflow

Step 1: Scan existing standards

Read .lattice/config.yaml. For each row in the map above, resolve the path (use the config key's value if set, otherwise the default .lattice/standards/{file}) and check whether the document exists. For each existing document, read its footer to note the current mode (overlay/override) and any prior "Last updated" line.

Present the result:

## Current Standards
- knowledge-base.md:      [exists (overlay, last updated 2026-05-02) / not found]
- language-idioms.md:     [exists / not found]
- architecture.md:        [exists / not found]
- ddd-principles.md:      [exists / not found]
- clean-code.md:          [exists / not found]
- review-standards.md:    [exists / not found]
- requirement-standards.md: [exists / not found]

STOP: If no .lattice/config.yaml exists, or no standards documents are found: there is nothing to update. Tell the user: "No existing standards found. Run /lattice-init to create them first." Do not proceed.

Step 2: Capture what changed

Ask the user what changed and why — in one or two sentences. This is the trigger. It becomes the change note recorded on each revised document and drives which standards are affected.

If the answer describes more than one distinct change (e.g. an architecture shift and a language switch together), capture each as its own short reason instead of one merged sentence. Each affected standard's change note (Step 4) must carry only the reason(s) that actually apply to it — a doc should never be stamped with a reason for a change that did not touch it.

Prompt with the common change types if the user is unsure:

• Architecture shift (new layer, moved to CQRS, dropped a pattern)
• Language or framework change
• New or revised domain rules (aggregates, invariants)
• New review or quality policy
• Project identity / stack / directory layout change
• A learning that should become a standing rule

Step 3: Map the change to affected standards

From the trigger, propose which existing standards are likely affected and why. Present the proposed set with reasoning; do not silently decide the scope.

Ask the user to confirm or adjust the set before proceeding. Only documents that actually exist (from Step 1) are eligible — for anything that should change but does not exist yet, follow the creation note above.

If Step 2 captured more than one distinct change, tag each affected standard with which of those change(s) justifies its inclusion — a doc can be justified by more than one. Carry this doc-to-reason tagging into Step 4; it determines what each doc's change note says.

Step 4: Revise each affected standard

Execution model: You — the AI running this molecule — drive each revision yourself: load and apply the refiner skill's revise flow as part of this molecule's execution, then return here to append the change note before moving to the next standard. Do not hand control back to the user and end your turn between revising and noting — the change note is this molecule's responsibility and must be written while you still hold control. (If a refiner is instead run as a separate session, the note will be missed — re-invoke /refiners-update afterward; its idempotent re-scan re-detects the revised document so the note still gets recorded.)

For each confirmed standard, in the order it appears in the map:

1. Offer the choice: Revise now, Skip, or Skip all remaining.

2. On Revise now: apply the corresponding refiner's revise path — its own "Check for existing documents → Revise" flow, which loads the existing document and updates only the sections the change touched. Reference and apply the refiner skill; do not copy its interview here. Tell the user: "Applying {refiner} in revise mode to update {doc}."

3. When the refiner's revision completes and control returns here, append (or update) the change note as the final line of the document's existing footer, matching the footer's own plain-italic style (*...*) — not a blockquote:

   *Last updated: {YYYY-MM-DD} — {this doc's tagged reason(s) from Step 3}*
   

   Use the current date, and only the reason(s) tagged to this specific doc — not the full multi-change text from Step 2 when other captured changes did not touch it. If a prior "Last updated" line exists, replace it with the new one.

4. On Skip: move to the next standard. On Skip all remaining: jump to Step 5.

Step 5: Summary

Report:

## Standards Updated
- [doc]: revised — [one-line reason]
- [doc]: skipped
- [doc]: needs creation — run /{refiner} (did not exist)

Remind the user:

• History is git-native — there are no version numbers. The change note carries the "why"; git log carries the "when".
• Commit the revised standards together with a message that names the change (e.g. chore(standards): revise architecture + review after move to CQRS).

Session behavior

This molecule is idempotent and re-runnable. It owns no living document of its own — every invocation re-scans the current state in Step 1, so running it again after a partial pass simply re-detects what exists and what changed. There is no partial-session document to resume.