---
name: Skill Validator
slug: skill-validator
category: Quality
description: Skill Validator checks a Lattice SKILL.md against tier conventions, cross-references, and structural rules. Use it when validating a new or edited skill file before it reaches the repo.
github: "https://github.com/techygarg/lattice/tree/main/dev-skills/skill-validate"
language: Shell
stars: 185
forks: 13
install: "npx degit https://github.com/techygarg/lattice/tree/main/dev-skills/skill-validate ~/.claude/skills/skill-validate"
installs_to: ~/.claude/skills/skill-validate
source_path: dev-skills/skill-validate/SKILL.md
collection_size: 25
category_size: 1745
collection_url: "https://dirskills.com/collections/techygarg/lattice"
added: 2026-09-06T05:20:40.857Z
last_synced: 2026-09-06T05:20:40.857Z
canonical_url: "https://dirskills.com/skills/skill-validator"
---

# Skill Validator

Skill Validator checks a Lattice SKILL.md against tier conventions, cross-references, and structural rules. Use it when validating a new or edited skill file before it reaches the repo.

**Install:**

```bash
npx degit https://github.com/techygarg/lattice/tree/main/dev-skills/skill-validate ~/.claude/skills/skill-validate
```

## README

# Skill Validator

**Core responsibility:** Verify that a SKILL.md is structurally correct, follows all Lattice tier conventions, and composes correctly with the rest of the framework.

**Input:** One or more of:
- A file path: `source/atoms/clean-code/SKILL.md`
- A skill name: `clean-code` (resolves to the correct path automatically)
- A tier: `atoms` (validates all skills in that tier)
- No argument: validates all skills across all three tiers (count derived from `source/` at runtime — never hardcoded)

**Output:** A findings report per skill:
```
## Skill Validator — {skill-name}
Tier: {atom | molecule | refiner}

### Structural          PASS / FAIL — specific findings
### Tier conventions    PASS / FAIL — specific findings
### Cross-references    PASS / FAIL — specific findings
### Three-angle review  PASS / WARN / FAIL per lens

Result: PASS | FAIL (N errors, M warnings)
```

**How to verify this skill did its job:**
- Every finding references a specific file and section (no vague "missing content" — says exactly what is missing and where)
- FAIL findings have an actionable fix, not just a description of the problem
- The report distinguishes errors (must fix) from warnings (judgment calls)
- After "fix mode" is applied, re-running the validator returns PASS

## Step 1: Load conventions

Read `PROJECT.md` — Skill Conventions section. This is the source of truth. **STOP: do not rely on memory.**

Read `references/convention-rules.md` for the detailed per-tier checklist.

## Step 2: Run structural checks (all tiers)

For every SKILL.md being validated:

```
[ ] Frontmatter: name field present, lowercase-hyphenated
[ ] Frontmatter: description field present and non-empty
[ ] Frontmatter: description contains trigger phrases (what the user would type)
[ ] Folder name matches name field exactly
[ ] No inline atom content in molecules (no duplicating what framework:{atom} already provides)
```

## Step 3: Run tier-specific checks

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/).

## Step 4: Run cross-reference checks

For every `framework:{atom-name}` reference in a molecule:
```bash
ls source/atoms/{atom-name}/SKILL.md 2>/dev/null || echo "BROKEN REF: framework:{atom-name}"
```

For every `paths.{key}` config key referenced in a refiner or atom:
- Check it appears in `docs/configuration.md` paths table

For every `.lattice/{subfolder}/` path referenced in a molecule:
- Check that subfolder is in the known subfolders list in `PROJECT.md`

## Step 5: Three-angle structural review

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.

Each lens asks a different question:

**Product Owner lens** — "Will this produce the right output for its users?"
- If a molecule: does the output document structure (from the SKILL.md template) give a PO a clear picture of what was produced?
- If an atom: are the quality checks grounded in real user need, not just technical form?
- If a refiner: does the produced standards document solve the configuration problem the user has?

**Business Analyst / Practitioner lens** — "Are the rules complete and enforceable?"
- Are checklists specific enough to have a clear pass/fail for each item?
- Are anti-patterns named with a fix, not just a symptom?
- Are ambiguity signals genuinely ambiguous, or are they just gaps in the rules?
- For molecules: are all practical scenarios handled (fresh start, existing material, interrupted session, single-item request)?

**Technical Lead lens** — "Does this compose correctly with the rest of the framework?"
- Do atom references (`framework:{name}`) resolve to real skills?
- Do config keys follow snake_case and match what's in configuration.md?
- Does the molecule write to a named `.lattice/` subfolder (never root)?
- For planning molecules: is the session resume check present at Step 1?
- For generative molecules: are there no confirmation gates?

## Step 6: Report

**STOP: a passing category gets the bare word `PASS`** — no restated commentary; findings text only on FAIL/WARN. Format findings as:

```
## Skill Validator — {skill-name}
Tier: {atom | molecule | refiner}

### Structural
PASS

### Tier conventions
FAIL — [Atom] Self-Validation Checklist missing STOP language on check 3
FAIL — [Molecule] Planning molecule Step 2 has no confirmation gate

### Cross-references
PASS

### Three-angle review
[PO]   PASS
[BA]   WARN — no guidance for interrupted session (resume behavior)
[Tech] FAIL — .lattice/myoutput/ not in known subfolders list

---
Result: FAIL (2 errors, 1 warning)
```

Distinguish errors (must fix) from warnings (should consider).

## Step 7: Fix mode (optional)

If the user says "fix it" or "apply fixes" — apply all error-level findings directly to the files. Re-run validation after fixes. **STOP: do not fix warnings without asking which ones to apply.**