/refiners-update

name: refiners-update
description: "Update existing Lattice standards after a significant change — the update-mode counterpart to lattice-init. Scans .lattice/standards/, asks what changed, and routes each affected standard to its refiner's revise mode, recording a git-native change note. Use when the user says 'update refiners', 'refiners update', 'our standards changed', 'update our standards', 'the architecture changed, update the standards', 'we switched languages, update the standards', 'revise standards after a big change', or 're-run the refiners'."

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

| Standards doc (in `.lattice/standards/`) | Refiner to revise it | Config key | |---|---|---| | `knowledge-base.md` | `/knowledge-priming-refiner` | `paths.knowledge_base` | | `language-idioms.md` | `/language-idioms-refiner` | `paths.language_idioms` | | `architecture.md` | `/architecture-refiner` | `paths.architecture` | | `ddd-principles.md` | `/ddd-refiner` | `paths.ddd_principles` | | `clean-code.md` | `/clean-code-refiner` | `paths.clean_code` | | `review-standards.md` | `/review-refiner` | `paths.review_standards` | | `requirement-standards.md` | `/requirement-forge-refiner` | `paths.requirement_standards` |

> **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.

| Change type | Likely-affected standards | |---|---| | Architecture shift | `architecture.md`; `review-standards.md` if it gates on architecture rules | | Language / framework change | `language-idioms.md`; `clean-code.md` if limits are language-specific | | Domain rules | `ddd-principles.md`; `architecture.md` if the domain layer's placement changed | | Review / quality policy | `review-standards.md`; `clean-code.md` | | Project identity / stack / layout | `knowledge-base.md` | | Requirement / spec policy | `requirement-standards.md` | | A learning promoted to a standing rule | whichever standard the rule belongs to — `clean-code.md`, `review-standards.md`, or `architecture.md` |

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