refiners-update

Name: refiners-update
Author: techygarg

165stars12forks

How to install refiners-update?

techygarg/lattice/refiners-update

$npx -y skills add techygarg/lattice --skill refiners-update

Installs into the current project.

Summary

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 'up

Files · 1

View on GitHub

SKILL.md

1	# Refiners Update
2
3	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.
4
5	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.
6
7	## Required Skills
8
9	Read, apply:
10
11	1. `framework:knowledge-priming` -- Load project context. Understand what the project is and how the code has drifted from the current standards (always).
12
13	## What This Does (and does not)
14
15	- Does: coordinate revising one or more existing standards documents after a change, and append a change note to each.
16	- 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.
17
18	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.
19
20	## Refiner → standards document map
21
22	\| Standards doc (in `.lattice/standards/`) \| Refiner to revise it \| Config key \|
23	\|---\|---\|---\|
24	\| `knowledge-base.md` \| `/knowledge-priming-refiner` \| `paths.knowledge_base` \|
25	\| `language-idioms.md` \| `/language-idioms-refiner` \| `paths.language_idioms` \|
26	\| `architecture.md` \| `/architecture-refiner` \| `paths.architecture` \|
27	\| `ddd-principles.md` \| `/ddd-refiner` \| `paths.ddd_principles` \|
28	\| `clean-code.md` \| `/clean-code-refiner` \| `paths.clean_code` \|
29	\| `review-standards.md` \| `/review-refiner` \| `paths.review_standards` \|
30	\| `requirement-standards.md` \| `/requirement-forge-refiner` \| `paths.requirement_standards` \|
31
32	> 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.
33
34	## Workflow
35
36	### Step 1: Scan existing standards
37
38	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.
39
40	Present the result:
41
42	```
43	## Current Standards
44	- knowledge-base.md: [exists (overlay, last updated 2026-05-02) / not found]
45	- language-idioms.md: [exists / not found]
46	- architecture.md: [exists / not found]
47	- ddd-principles.md: [exists / not found]
48	- clean-code.md: [exists / not found]
49	- review-standards.md: [exists / not found]
50	- requirement-standards.md: [exists / not found]
51	```
52
53	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.
54
55	### Step 2: Capture what changed
56
57	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.
58
59	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.
60
61	Prompt with the common change types if the user is unsure:
62	- Architecture shift (new layer, moved to CQRS, dropped a pattern)
63	- Language or framework change
64	- New or revised domain rules (aggregates, invariants)
65	- New review or quality policy
66	- Project identity / stack / directory layout change
67	- A learning that should become a standing rule
68
69	### Step 3: Map the change to affected standards
70
71	From the trigger, propose which existing standards are likely affected and why. Present the proposed set with reasoning; do not silently decide the scope.
72
73	\| Change type \| Likely-affected standards \|
74	\|---\|---\|
75	\| Architecture shift \| `archite

People who liked this also viewed

6 picks

Type

refiners-update

165stars12forks

View on GitHub

How to install refiners-update?

techygarg/lattice/refiners-update

$npx -y skills add techygarg/lattice --skill refiners-update

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Refiners Update
2
3	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.
4
5	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.
6
7	## Required Skills
8
9	Read, apply:
10
11	1. `framework:knowledge-priming` -- Load project context. Understand what the project is and how the code has drifted from the current standards (always).
12
13	## What This Does (and does not)
14
15	- Does: coordinate revising one or more existing standards documents after a change, and append a change note to each.
16	- 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.
17
18	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.
19
20	## Refiner → standards document map
21
22	\| Standards doc (in `.lattice/standards/`) \| Refiner to revise it \| Config key \|
23	\|---\|---\|---\|
24	\| `knowledge-base.md` \| `/knowledge-priming-refiner` \| `paths.knowledge_base` \|
25	\| `language-idioms.md` \| `/language-idioms-refiner` \| `paths.language_idioms` \|
26	\| `architecture.md` \| `/architecture-refiner` \| `paths.architecture` \|
27	\| `ddd-principles.md` \| `/ddd-refiner` \| `paths.ddd_principles` \|
28	\| `clean-code.md` \| `/clean-code-refiner` \| `paths.clean_code` \|
29	\| `review-standards.md` \| `/review-refiner` \| `paths.review_standards` \|
30	\| `requirement-standards.md` \| `/requirement-forge-refiner` \| `paths.requirement_standards` \|
31
32	> 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.
33
34	## Workflow
35
36	### Step 1: Scan existing standards
37
38	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.
39
40	Present the result:
41
42	```
43	## Current Standards
44	- knowledge-base.md: [exists (overlay, last updated 2026-05-02) / not found]
45	- language-idioms.md: [exists / not found]
46	- architecture.md: [exists / not found]
47	- ddd-principles.md: [exists / not found]
48	- clean-code.md: [exists / not found]
49	- review-standards.md: [exists / not found]
50	- requirement-standards.md: [exists / not found]
51	```
52
53	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.
54
55	### Step 2: Capture what changed
56
57	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.
58
59	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.
60
61	Prompt with the common change types if the user is unsure:
62	- Architecture shift (new layer, moved to CQRS, dropped a pattern)
63	- Language or framework change
64	- New or revised domain rules (aggregates, invariants)
65	- New review or quality policy
66	- Project identity / stack / directory layout change
67	- A learning that should become a standing rule
68
69	### Step 3: Map the change to affected standards
70
71	From the trigger, propose which existing standards are likely affected and why. Present the proposed set with reasoning; do not silently decide the scope.
72
73	\| Change type \| Likely-affected standards \|
74	\|---\|---\|
75	\| Architecture shift \| `archite

People who liked this also viewed

6 picks

Type