review-refiner

Name: review-refiner
Author: techygarg

165stars12forks

How to install review-refiner?

techygarg/lattice/review-refiner

$npx -y skills add techygarg/lattice --skill review-refiner

Installs into the current project.

Summary

Facilitate a structured conversation to customize how the review molecule works -- atom loading rules, severity classification, report format, scope rules, insight capture, and health logging. Produces a formal review-standards.md document that the review molecule will use as its

Files · 1

View on GitHub

SKILL.md

1	# Review Refiner
2
3	## What This Produces
4
5	- Output: `.lattice/standards/review-standards.md` (or custom path from `.lattice/config.yaml` → `paths.review_standards`)
6	- Two modes:
7	- Overlay (`mode: overlay`): A slim document containing only sections that differ from the defaults. The review molecule reads its embedded defaults first, then applies this document's sections on top. This is the expected common case.
8	- Override (`mode: override`): A comprehensive standalone document that fully replaces the molecule's embedded defaults. For teams with fundamentally different review processes.
9	- Default mode: Overlay -- produces only what the user wants to change
10	- Config key: `paths.review_standards` in `.lattice/config.yaml`
11	- Consumed by: The review molecule (NOT an atom -- this is the first molecule-level config)
12	- Template: Read `./assets/template.md` for the full document structure, default content, and interview guidance comments
13
14	### Scope Clarification
15
16	This refiner configures the review process -- how the review molecule orchestrates atom output. It does NOT configure what atoms check for.
17
18	\| Belongs here (process orchestration) \| Belongs in atom refiners (quality standards) \|
19	\|---------------------------------------\|----------------------------------------------\|
20	\| Which atoms load and when \| What checks an atom runs \|
21	\| Severity level definitions \| What constitutes a violation \|
22	\| Report format and grouping \| Checklist items and anti-patterns \|
23	\| Delta scope rules \| Layer definitions, naming rules \|
24	\| Insight capture preferences \| Domain modeling rules \|
25	\| Health log format \| Security check thresholds \|
26	\| Custom review dimensions \| Atom-specific validation logic \|
27
28	If a user asks about changing what an atom checks for, redirect them to the appropriate atom refiner (architecture-refiner, clean-code-refiner, ddd-refiner).
29
30	## Before You Begin
31
32	### Check for existing documents
33
34	Before starting the interview, check whether a custom document already exists:
35
36	1. Read `.lattice/config.yaml` — does `paths.review_standards` point to a file?
37	2. If yes, read that file. Ask the user:
38	- "You already have a review standards document. Would you like to revise it (update specific sections), start fresh (new interview), or add to it (add new sections)?"
39	- Revise: Load the existing document, walk through only the sections the user wants to change, and update in place.
40	- Start fresh: Proceed with the full interview flow below.
41	- Add to it: Skip to the sections the user wants to add (e.g., custom dimensions).
42	3. If no config or no existing document, proceed with the full interview flow.
43
44	### Scan for context
45
46	Look for signals that inform the conversation:
47
48	- Existing review history: Check `.lattice/reviews/review-log.md` — what atoms have been loading? What severity patterns exist? Are there recurring findings?
49	- Existing learnings: Check `.lattice/learnings/operational-learnings.md` — what patterns have been captured? Is the file growing dense in any category?
50	- Project structure: What does the codebase look like? Are there directories that should be excluded or always-scanned?
51	- Existing atom refiners: Which atom refiners have been run? (Check `.lattice/config.yaml` for `paths.architecture`, `paths.clean_code`, `paths.ddd_principles`) This tells you which atoms the team cares about.
52
53	Share relevant findings with the user at the start: "I looked at your review history and noticed [patterns]. I'll use that as context for our conversation."
54
55	If the project is new with no review history, proceed with defaults as the starting point.
56
57	## Choosing the Mode
58
59	The first decision in the conversation. Present the three options:
60
61	"How would you like to configure your review process?
62
63	1. Customize specific sections (overlay) — Keep the defaults and change only what differs for your project. This produces a slim document. Most teams choose this.
64	2. Define everything from scratch (override) — Walk through all sections and produce a comprehensive standalone document.
65	3. Add project-specific sections only (overlay with additions) — Keep all defaults as-is and add new sections for your team's specific rules (e.g., custom review dimensions).
66
67	The defaults cover a solid review workflow. Option 1 is recommended unless your review process needs to be fundamentally different."
68
69	Map the choice:
70	- Options 1 and 3 → `mode: overlay`
71	- Option 2 → `mode: override`
72
73	## Facilit

People who liked this also viewed

6 picks

Type

review-refiner

165stars12forks

View on GitHub

How to install review-refiner?

techygarg/lattice/review-refiner

$npx -y skills add techygarg/lattice --skill review-refiner

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Review Refiner
2
3	## What This Produces
4
5	- Output: `.lattice/standards/review-standards.md` (or custom path from `.lattice/config.yaml` → `paths.review_standards`)
6	- Two modes:
7	- Overlay (`mode: overlay`): A slim document containing only sections that differ from the defaults. The review molecule reads its embedded defaults first, then applies this document's sections on top. This is the expected common case.
8	- Override (`mode: override`): A comprehensive standalone document that fully replaces the molecule's embedded defaults. For teams with fundamentally different review processes.
9	- Default mode: Overlay -- produces only what the user wants to change
10	- Config key: `paths.review_standards` in `.lattice/config.yaml`
11	- Consumed by: The review molecule (NOT an atom -- this is the first molecule-level config)
12	- Template: Read `./assets/template.md` for the full document structure, default content, and interview guidance comments
13
14	### Scope Clarification
15
16	This refiner configures the review process -- how the review molecule orchestrates atom output. It does NOT configure what atoms check for.
17
18	\| Belongs here (process orchestration) \| Belongs in atom refiners (quality standards) \|
19	\|---------------------------------------\|----------------------------------------------\|
20	\| Which atoms load and when \| What checks an atom runs \|
21	\| Severity level definitions \| What constitutes a violation \|
22	\| Report format and grouping \| Checklist items and anti-patterns \|
23	\| Delta scope rules \| Layer definitions, naming rules \|
24	\| Insight capture preferences \| Domain modeling rules \|
25	\| Health log format \| Security check thresholds \|
26	\| Custom review dimensions \| Atom-specific validation logic \|
27
28	If a user asks about changing what an atom checks for, redirect them to the appropriate atom refiner (architecture-refiner, clean-code-refiner, ddd-refiner).
29
30	## Before You Begin
31
32	### Check for existing documents
33
34	Before starting the interview, check whether a custom document already exists:
35
36	1. Read `.lattice/config.yaml` — does `paths.review_standards` point to a file?
37	2. If yes, read that file. Ask the user:
38	- "You already have a review standards document. Would you like to revise it (update specific sections), start fresh (new interview), or add to it (add new sections)?"
39	- Revise: Load the existing document, walk through only the sections the user wants to change, and update in place.
40	- Start fresh: Proceed with the full interview flow below.
41	- Add to it: Skip to the sections the user wants to add (e.g., custom dimensions).
42	3. If no config or no existing document, proceed with the full interview flow.
43
44	### Scan for context
45
46	Look for signals that inform the conversation:
47
48	- Existing review history: Check `.lattice/reviews/review-log.md` — what atoms have been loading? What severity patterns exist? Are there recurring findings?
49	- Existing learnings: Check `.lattice/learnings/operational-learnings.md` — what patterns have been captured? Is the file growing dense in any category?
50	- Project structure: What does the codebase look like? Are there directories that should be excluded or always-scanned?
51	- Existing atom refiners: Which atom refiners have been run? (Check `.lattice/config.yaml` for `paths.architecture`, `paths.clean_code`, `paths.ddd_principles`) This tells you which atoms the team cares about.
52
53	Share relevant findings with the user at the start: "I looked at your review history and noticed [patterns]. I'll use that as context for our conversation."
54
55	If the project is new with no review history, proceed with defaults as the starting point.
56
57	## Choosing the Mode
58
59	The first decision in the conversation. Present the three options:
60
61	"How would you like to configure your review process?
62
63	1. Customize specific sections (overlay) — Keep the defaults and change only what differs for your project. This produces a slim document. Most teams choose this.
64	2. Define everything from scratch (override) — Walk through all sections and produce a comprehensive standalone document.
65	3. Add project-specific sections only (overlay with additions) — Keep all defaults as-is and add new sections for your team's specific rules (e.g., custom review dimensions).
66
67	The defaults cover a solid review workflow. Option 1 is recommended unless your review process needs to be fundamentally different."
68
69	Map the choice:
70	- Options 1 and 3 → `mode: overlay`
71	- Option 2 → `mode: override`
72
73	## Facilit

People who liked this also viewed

6 picks

Type