skill-validate

Name: skill-validate
Author: techygarg

165stars12forks

How to install skill-validate?

techygarg/lattice/skill-validate

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

Installs into the current project.

Summary

Validate any Lattice SKILL.md against all tier conventions — atoms, molecules, and refiners. Catches structural errors, broken cross-references, and convention violations before they reach the repo. If you just wrote or modified a Lattice skill file and haven't run this yet, run

Files · 1

View on GitHub

SKILL.md

1	# Skill Validator
2
3	Core responsibility: Verify that a SKILL.md is structurally correct, follows all Lattice tier conventions, and composes correctly with the rest of the framework.
4
5	Input: One or more of:
6	- A file path: `skills/atoms/clean-code/SKILL.md`
7	- A skill name: `clean-code` (resolves to the correct path automatically)
8	- A tier: `atoms` (validates all skills in that tier)
9	- No argument: validates all skills across all three tiers (count derived from `skills/` at runtime — never hardcoded)
10
11	Output: A findings report per skill:
12	```
13	## Skill Validator — {skill-name}
14	Tier: {atom \| molecule \| refiner}
15
16	### Structural PASS / FAIL — specific findings
17	### Tier conventions PASS / FAIL — specific findings
18	### Cross-references PASS / FAIL — specific findings
19	### Three-angle review PASS / WARN / FAIL per lens
20
21	Result: PASS \| FAIL (N errors, M warnings)
22	```
23
24	How to verify this skill did its job:
25	- Every finding references a specific file and section (no vague "missing content" — says exactly what is missing and where)
26	- FAIL findings have an actionable fix, not just a description of the problem
27	- The report distinguishes errors (must fix) from warnings (judgment calls)
28	- After "fix mode" is applied, re-running the validator returns PASS
29
30	## Step 1: Load conventions
31
32	Read `PROJECT.md` — Skill Conventions section. This is the source of truth. STOP: do not rely on memory.
33
34	Read `references/convention-rules.md` for the detailed per-tier checklist.
35
36	## Step 2: Run structural checks (all tiers)
37
38	For every SKILL.md being validated:
39
40	```
41	[ ] Frontmatter: name field present, lowercase-hyphenated
42	[ ] Frontmatter: description field present and non-empty
43	[ ] Frontmatter: description contains trigger phrases (what the user would type)
44	[ ] Folder name matches name field exactly
45	[ ] No inline atom content in molecules (no duplicating what framework:{atom} already provides)
46	```
47
48	## Step 3: Run tier-specific checks
49
50	Read `references/convention-rules.md` for the full per-tier checklist. Apply the relevant section based on tier (determined from file path: atoms/, molecules/, refiners/).
51
52	## Step 4: Run cross-reference checks
53
54	For every `framework:{atom-name}` reference in a molecule:
55	```bash
56	ls skills/atoms/{atom-name}/SKILL.md 2>/dev/null \|\| echo "BROKEN REF: framework:{atom-name}"
57	```
58
59	For every `paths.{key}` config key referenced in a refiner or atom:
60	- Check it appears in `docs/configuration.md` paths table
61
62	For every `.lattice/{subfolder}/` path referenced in a molecule:
63	- Check that subfolder is in the known subfolders list in `PROJECT.md`
64
65	## Step 5: Three-angle structural review
66
67	These three lenses are fixed — they match the three stakeholder types who depend on Lattice skills working correctly. This is a structural review (does the skill follow conventions?), not a behavioral review (does it work in practice?) — use `skill-review` for the latter.
68
69	Each lens asks a different question:
70
71	Product Owner lens — "Will this produce the right output for its users?"
72	- If a molecule: does the output document structure (from the SKILL.md template) give a PO a clear picture of what was produced?
73	- If an atom: are the quality checks grounded in real user need, not just technical form?
74	- If a refiner: does the produced standards document solve the configuration problem the user has?
75
76	Business Analyst / Practitioner lens — "Are the rules complete and enforceable?"
77	- Are checklists specific enough to have a clear pass/fail for each item?
78	- Are anti-patterns named with a fix, not just a symptom?
79	- Are ambiguity signals genuinely ambiguous, or are they just gaps in the rules?
80	- For molecules: are all practical scenarios handled (fresh start, existing material, interrupted session, single-item request)?
81
82	Technical Lead lens — "Does this compose correctly with the rest of the framework?"
83	- Do atom references (`framework:{name}`) resolve to real skills?
84	- Do config keys follow snake_case and match what's in configuration.md?
85	- Does the molecule write to a named `.lattice/` subfolder (never root)?
86	- For planning molecules: is the session resume check present at Step 1?
87	- For generative molecules: are there no confirmation gates?
88
89	## Step 6: Report
90
91	**STOP: a passing category gets

People who liked this also viewed

6 picks

Type

skill-validate

165stars12forks

View on GitHub

How to install skill-validate?

techygarg/lattice/skill-validate

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

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Skill Validator
2
3	Core responsibility: Verify that a SKILL.md is structurally correct, follows all Lattice tier conventions, and composes correctly with the rest of the framework.
4
5	Input: One or more of:
6	- A file path: `skills/atoms/clean-code/SKILL.md`
7	- A skill name: `clean-code` (resolves to the correct path automatically)
8	- A tier: `atoms` (validates all skills in that tier)
9	- No argument: validates all skills across all three tiers (count derived from `skills/` at runtime — never hardcoded)
10
11	Output: A findings report per skill:
12	```
13	## Skill Validator — {skill-name}
14	Tier: {atom \| molecule \| refiner}
15
16	### Structural PASS / FAIL — specific findings
17	### Tier conventions PASS / FAIL — specific findings
18	### Cross-references PASS / FAIL — specific findings
19	### Three-angle review PASS / WARN / FAIL per lens
20
21	Result: PASS \| FAIL (N errors, M warnings)
22	```
23
24	How to verify this skill did its job:
25	- Every finding references a specific file and section (no vague "missing content" — says exactly what is missing and where)
26	- FAIL findings have an actionable fix, not just a description of the problem
27	- The report distinguishes errors (must fix) from warnings (judgment calls)
28	- After "fix mode" is applied, re-running the validator returns PASS
29
30	## Step 1: Load conventions
31
32	Read `PROJECT.md` — Skill Conventions section. This is the source of truth. STOP: do not rely on memory.
33
34	Read `references/convention-rules.md` for the detailed per-tier checklist.
35
36	## Step 2: Run structural checks (all tiers)
37
38	For every SKILL.md being validated:
39
40	```
41	[ ] Frontmatter: name field present, lowercase-hyphenated
42	[ ] Frontmatter: description field present and non-empty
43	[ ] Frontmatter: description contains trigger phrases (what the user would type)
44	[ ] Folder name matches name field exactly
45	[ ] No inline atom content in molecules (no duplicating what framework:{atom} already provides)
46	```
47
48	## Step 3: Run tier-specific checks
49
50	Read `references/convention-rules.md` for the full per-tier checklist. Apply the relevant section based on tier (determined from file path: atoms/, molecules/, refiners/).
51
52	## Step 4: Run cross-reference checks
53
54	For every `framework:{atom-name}` reference in a molecule:
55	```bash
56	ls skills/atoms/{atom-name}/SKILL.md 2>/dev/null \|\| echo "BROKEN REF: framework:{atom-name}"
57	```
58
59	For every `paths.{key}` config key referenced in a refiner or atom:
60	- Check it appears in `docs/configuration.md` paths table
61
62	For every `.lattice/{subfolder}/` path referenced in a molecule:
63	- Check that subfolder is in the known subfolders list in `PROJECT.md`
64
65	## Step 5: Three-angle structural review
66
67	These three lenses are fixed — they match the three stakeholder types who depend on Lattice skills working correctly. This is a structural review (does the skill follow conventions?), not a behavioral review (does it work in practice?) — use `skill-review` for the latter.
68
69	Each lens asks a different question:
70
71	Product Owner lens — "Will this produce the right output for its users?"
72	- If a molecule: does the output document structure (from the SKILL.md template) give a PO a clear picture of what was produced?
73	- If an atom: are the quality checks grounded in real user need, not just technical form?
74	- If a refiner: does the produced standards document solve the configuration problem the user has?
75
76	Business Analyst / Practitioner lens — "Are the rules complete and enforceable?"
77	- Are checklists specific enough to have a clear pass/fail for each item?
78	- Are anti-patterns named with a fix, not just a symptom?
79	- Are ambiguity signals genuinely ambiguous, or are they just gaps in the rules?
80	- For molecules: are all practical scenarios handled (fresh start, existing material, interrupted session, single-item request)?
81
82	Technical Lead lens — "Does this compose correctly with the rest of the framework?"
83	- Do atom references (`framework:{name}`) resolve to real skills?
84	- Do config keys follow snake_case and match what's in configuration.md?
85	- Does the molecule write to a named `.lattice/` subfolder (never root)?
86	- For planning molecules: is the session resume check present at Step 1?
87	- For generative molecules: are there no confirmation gates?
88
89	## Step 6: Report
90
91	**STOP: a passing category gets

People who liked this also viewed

6 picks

Type