review

Name: review
Author: techygarg

165stars12forks

How to install review?

techygarg/lattice/review

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

Installs into the current project.

Summary

Perform a structured code review by composing validation checklists from relevant atoms based on what code changed. Loads atoms conditionally -- clean-code always, architecture/DDD/security/tests only when the delta touches their domain. Produces a severity-ordered report with sp

Files · 1

View on GitHub

SKILL.md

1	# Review
2
3	## Required Skills
4
5	Load/apply skills based on scope (see Step 2 for conditional loading):
6
7	1. `framework:knowledge-priming` -- Load project context (tech stack, architecture, conventions) to evaluate against real standards (always loaded)
8	2. `framework:learning-harvest` -- Load prior operational learnings inform review; harvest new patterns at session end (always)
9	3. `framework:collaborative-judgment` -- Surface borderline findings with both interpretations instead of silently classifying (always loaded)
10	4. `framework:clean-code` -- Code craft: SRP, naming, complexity, error handling (always loaded)
11	5. `framework:architecture` -- Structural: layer rules, dependency direction, architectural flows (conditional)
12	6. `framework:domain-driven-design` -- Domain modeling: aggregates, entities, value objects (conditional)
13	7. `framework:secure-coding` -- Security: trust boundaries, injection, secrets, input handling (conditional)
14	8. `framework:test-quality` -- Test: AAA structure, isolation, assertions, naming (conditional)
15
16	## Config Resolution
17
18	Review molecule supports optional config thru review-standards doc from review-refiner (or hand-written). Configures review process — not what atoms check (that's atom-level config via atom refiners).
19
20	Resolution steps:
21
22	1. Look for `.lattice/config.yaml` in repo root.
23	2. Check for config key `paths.review_standards`.
24	3. If doc exists at path, read & check YAML frontmatter for `mode`:
25	- `mode: overlay`: Read embedded defaults first, then apply doc's sections on top. Sections matched by heading — custom replaces matching defaults, new appended.
26	- `mode: override` (or no mode): Custom doc full precedence. Must be comprehensive.
27	4. If no config or no review-standards doc found, use embedded defaults thruout workflow (full backward compat — identical to review with no config).
28
29	Review-standards doc has 7 sections map to workflow steps:
30
31	\| Section \| Affects step \|
32	\|---------\|-------------\|
33	\| §1 Atom Loading Policy \| Step 2 (Load Relevant Atoms) \|
34	\| §2 Severity Classification \| Step 4 (Produce Report) \|
35	\| §3 Report Preferences \| Step 4 (Produce Report) \|
36	\| §4 Scope Rules \| Step 1 (Identify the Delta) \|
37	\| §5 Insight Capture Preferences \| Step 5 (Harvest Learnings and Log Review) \|
38	\| §6 Health Log Preferences \| Step 5 (Harvest Learnings and Log Review) \|
39	\| §7 Custom Review Dimensions \| Step 3 (Run Targeted Validation) \|
40
41	Each step notes where config applies with "Config override" callouts.
42
43	## Workflow
44
45	### Step 1: Identify the Delta
46
47	Use `framework:learning-harvest` Load behavior. Focus hint: "review session — focus: all categories".
48
49	Determine what code reviewing & establish scope.
50
51	- PR or commit: Use `git diff` for changed files/lines. Delta is changes, not entire codebase.
52	- Set of files: User specifies files. Delta is those files.
53	- Feature or module: User points to feature. Identify relevant files from codebase.
54
55	Classify delta:
56
57	1. Which architectural layers touched? (per loaded architecture rules) -- determines if `architecture` loads.
58	2. Is domain code included? (files in configured `domain_folder` or containing aggregates, entities, value objects) -- determines if `domain-driven-design` loads.
59	3. Security-sensitive areas touched? (auth, authz, input handling, DB queries, external API calls, file I/O, config, secrets) -- determines if `secure-coding` loads.
60	4. Test files included? -- determines if `test-quality` loads.
61
62	Config override (§4 Scope Rules): If review-standards doc defines scope rules, apply after identifying delta:
63	- Directory exclusions: Remove files matching exclusion patterns from delta before classification.
64	- Directory inclusions (always-full-scan): When delta touches file in always-full-scan dir, expand delta to include all files in that dir.
65	- Surrounding-code policy: Use configured policy (strict/default/expansive) instead of default.
66	- Dependency expansion: If enabled, also include files that directly import from changed files.
67
68	### Step 2: Load Relevant Atoms
69
70	Always load: `framework:clean-code` -- applies to all code regardless of layer/purpose.
71
72	Conditionally load based on delta classification:
73
74	\| Condition \| Load \|
75	\|-----------\|------\|
76	\| Delta touches multiple layers, adds new files, or changes file locations \| `framework:architecture` \|
77	\| Delta includes files in domain folder or modifies domain objects \| `framework:domain-driven-design` \|
78	\| Delta touches trust boundaries

People who liked this also viewed

6 picks

Type

review

165stars12forks

View on GitHub

How to install review?

techygarg/lattice/review

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

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Review
2
3	## Required Skills
4
5	Load/apply skills based on scope (see Step 2 for conditional loading):
6
7	1. `framework:knowledge-priming` -- Load project context (tech stack, architecture, conventions) to evaluate against real standards (always loaded)
8	2. `framework:learning-harvest` -- Load prior operational learnings inform review; harvest new patterns at session end (always)
9	3. `framework:collaborative-judgment` -- Surface borderline findings with both interpretations instead of silently classifying (always loaded)
10	4. `framework:clean-code` -- Code craft: SRP, naming, complexity, error handling (always loaded)
11	5. `framework:architecture` -- Structural: layer rules, dependency direction, architectural flows (conditional)
12	6. `framework:domain-driven-design` -- Domain modeling: aggregates, entities, value objects (conditional)
13	7. `framework:secure-coding` -- Security: trust boundaries, injection, secrets, input handling (conditional)
14	8. `framework:test-quality` -- Test: AAA structure, isolation, assertions, naming (conditional)
15
16	## Config Resolution
17
18	Review molecule supports optional config thru review-standards doc from review-refiner (or hand-written). Configures review process — not what atoms check (that's atom-level config via atom refiners).
19
20	Resolution steps:
21
22	1. Look for `.lattice/config.yaml` in repo root.
23	2. Check for config key `paths.review_standards`.
24	3. If doc exists at path, read & check YAML frontmatter for `mode`:
25	- `mode: overlay`: Read embedded defaults first, then apply doc's sections on top. Sections matched by heading — custom replaces matching defaults, new appended.
26	- `mode: override` (or no mode): Custom doc full precedence. Must be comprehensive.
27	4. If no config or no review-standards doc found, use embedded defaults thruout workflow (full backward compat — identical to review with no config).
28
29	Review-standards doc has 7 sections map to workflow steps:
30
31	\| Section \| Affects step \|
32	\|---------\|-------------\|
33	\| §1 Atom Loading Policy \| Step 2 (Load Relevant Atoms) \|
34	\| §2 Severity Classification \| Step 4 (Produce Report) \|
35	\| §3 Report Preferences \| Step 4 (Produce Report) \|
36	\| §4 Scope Rules \| Step 1 (Identify the Delta) \|
37	\| §5 Insight Capture Preferences \| Step 5 (Harvest Learnings and Log Review) \|
38	\| §6 Health Log Preferences \| Step 5 (Harvest Learnings and Log Review) \|
39	\| §7 Custom Review Dimensions \| Step 3 (Run Targeted Validation) \|
40
41	Each step notes where config applies with "Config override" callouts.
42
43	## Workflow
44
45	### Step 1: Identify the Delta
46
47	Use `framework:learning-harvest` Load behavior. Focus hint: "review session — focus: all categories".
48
49	Determine what code reviewing & establish scope.
50
51	- PR or commit: Use `git diff` for changed files/lines. Delta is changes, not entire codebase.
52	- Set of files: User specifies files. Delta is those files.
53	- Feature or module: User points to feature. Identify relevant files from codebase.
54
55	Classify delta:
56
57	1. Which architectural layers touched? (per loaded architecture rules) -- determines if `architecture` loads.
58	2. Is domain code included? (files in configured `domain_folder` or containing aggregates, entities, value objects) -- determines if `domain-driven-design` loads.
59	3. Security-sensitive areas touched? (auth, authz, input handling, DB queries, external API calls, file I/O, config, secrets) -- determines if `secure-coding` loads.
60	4. Test files included? -- determines if `test-quality` loads.
61
62	Config override (§4 Scope Rules): If review-standards doc defines scope rules, apply after identifying delta:
63	- Directory exclusions: Remove files matching exclusion patterns from delta before classification.
64	- Directory inclusions (always-full-scan): When delta touches file in always-full-scan dir, expand delta to include all files in that dir.
65	- Surrounding-code policy: Use configured policy (strict/default/expansive) instead of default.
66	- Dependency expansion: If enabled, also include files that directly import from changed files.
67
68	### Step 2: Load Relevant Atoms
69
70	Always load: `framework:clean-code` -- applies to all code regardless of layer/purpose.
71
72	Conditionally load based on delta classification:
73
74	\| Condition \| Load \|
75	\|-----------\|------\|
76	\| Delta touches multiple layers, adds new files, or changes file locations \| `framework:architecture` \|
77	\| Delta includes files in domain folder or modifies domain objects \| `framework:domain-driven-design` \|
78	\| Delta touches trust boundaries

People who liked this also viewed

6 picks

Type