Skip to main content
ClaudeWave
Skill184 repo starsupdated 7d ago

skill-enhance

Full enhancement pipeline for an existing Lattice skill — rewrites a molecule or atom to modern-capable-model grade: restores degraded grammar, deduplicates, hardens gates and branching to one-unambiguous-action precision, verifies zero behavioral loss against a pre-capture diff, then runs the combined QA gate (skill-review, skill-tighten, skill-validate) and an independent fresh-context verifier, fixing everything found. Consumer-first: optimized for first-time open-source users on fresh repos with minimal .lattice/ setup, running capable models. Use when the user says 'enhance this skill', 'upgrade this molecule', 'modernize this skill', 'optimize this skill', 'make this skill production grade', 'full enhancement', 'polish this molecule like design-blueprint', or names a molecule/atom to overhaul. For gap-finding only use skill-review; for conventions only use skill-validate — this skill runs the whole loop end to end.

Install in Claude Code
Copy
git clone --depth 1 https://github.com/techygarg/lattice /tmp/skill-enhance && cp -r /tmp/skill-enhance/dev-skills/skill-enhance ~/.claude/skills/skill-enhance
Then start a new Claude Code session; the skill loads automatically.

SKILL.md

# Skill Enhance

**Core responsibility:** Take one existing Lattice skill from current state to modern-capable-model grade through a fixed pipeline: baseline → dependency map (background agent) → precision rewrite with guaranteed behavior preservation → combined three-skill QA → independent verification. The skill being enhanced must end up smaller-or-equal in redundancy, fully grammatical, convention-complete, and provably non-regressive. Organizing objective: **deterministic execution** — every sentence has exactly one reading, every reachable state exactly one action, every cross-file reference literally true. Acceptance test: two different capable models reading any sentence would act identically on it.

**Input:** One skill path or name (any tier). Molecules are the primary case.

**Output:** Edited files + close-out report.

**STOP: NEVER commit, push, stash, checkout, reset, or run `build-codex-plugin.sh`. Working tree only — surface install/mirror commands for the user instead.**

**How to verify this skill did its job:**
- Pre-capture git diff exists; every preserved behavior in it is confirmed present after rewrite
- QA trio re-run returns no critical gaps, CLEAN or tightened-only results, and PASS
- Independent verifier reports zero real defects
- Scenario walk leaves no branch with two possible readings

## Step 1: Scope and baseline

1. Read PROJECT.md (single source of truth for conventions) and the target SKILL.md in full.
2. Classify: tier (atom / molecule / refiner); if molecule, its type per PROJECT.md — **generative** (`code-forge`, `refactor-safely`, `bug-fix`) or **planning/interactive** (`design-blueprint`, `architecture-compass`). This governs every later rule: never transplant confirmation gates into generative molecules, never strip them from planning ones.
3. **STOP: capture the full git diff of target + likely-touched files BEFORE any edit**, written to a temp file whose path you will hand to the Step 5 verifier. This baseline is the preservation oracle for Steps 3-5. Without it, "did we drop anything?" is unanswerable.

## Step 2: Dependency map (background agent)

Spawn ONE background Explore agent — do not read serially in the main thread. It maps:

1. Every `framework:{atom}` reference: real behavior/mode names each atom actually exposes, plus line counts.
2. Sibling molecules feeding and consuming this one: exact handoff contracts — frontmatter fields, status values, `.lattice/{subfolder}` paths, section names each side greps for.
3. Where the target's phases/levels are actually defined (own body vs referenced atom).
4. Inventory of telegraphic damage: sentences missing articles/verbs ("ground decisions real project").

## Step 3: Rewrite (main thread, after map returns)

Apply in order:

1. **Grammar restoration** — every sentence complete. Telegraphic phrasing is ambiguity risk precisely at STOP/gate semantics.
2. **Deduplicate** — same rule twice in different words → keep the sharpest once. Cut trailing rationale ("this ensures…", "without this…") EXCEPT consequences load-bearing at the exact action point — flag every deliberate keep in the report.
3. **Precision pass** — hard gates get `**STOP:**` prefixes; targeted questions replace generic approval language; every conditional branch (missing doc, unreadable path, external reference, absent config, outputs created by older skill versions missing newer fields) resolves to exactly ONE action; expected-not-error paths marked as such.
4. **Scenario walk your own rewrite**: fresh start / interrupted session / partial output / minimal input / maximal input / entry-and-resume edges (including partial entry points and legacy docs without new markers). Derive the state space from upstream contracts first — enumerate every status value, mode name, and doc-presence combination the upstream defines, and give each a defined outcome here. Close every gap where two readings survive.
5. **Preservation check against the Step 1 baseline** — nothing dropped, renamed, or weakened.
6. **Contract alignment** — verify every referenced behavior name, section heading, table schema, config key, and status value against the live atom files; fix mismatches even when pre-existing. Composition must interlock literally, not approximately.
7. **Convention restoration** — always/conditional qualifiers on Required Skills, collaborative-judgment fallback wording in Ambiguity Signals, trigger phrases in description, description consistent with body.
8. If the skill repurposes a code-generation atom in another mode: give that atom a compact named mode section. Never improvise inline; never inline atom content into a molecule.

## Step 4: Combined QA gate (strict order)

Run on every touched file:

1. **skill-review** — fix criticals and warnings; list observations for the user decision.
2. **skill-tighten** — full T1-T6 sweep, apply.
3. **skill-validate** — fix error-level findings directly; report warnings without applying.

Iterate until all three return clean/pass. Re-run any skill whose inputs a later fix changed.

## Step 5: Independent verification (background agent)

Spawn ONE fresh general-purpose verifier that re-derives correctness WITHOUT trusting the diff author:

- Semantic-preservation checklist from the Step 1 baseline
- Internal-consistency scenario walk (Step 3.4 scenarios, independently)
- Contract checks against the real consumer files — grep them, cite lines
- Hedge/degraded-grammar grep across touched files
- Frontmatter YAML validity, name/folder match

Fix everything it finds. Then: behavior-affecting fixes → re-run the affected Step 4 tools; single-line narrowing fixes → self-check against the loaded T1-T6/validator patterns instead of a full re-run.

## Step 6: Close-out report

Report: files changed with before→after line counts; findings per QA tool and how each closed; deliberate keeps flagged; residual validator warnings listed untouched; and these commands surfaced for the user (not run):

```bash
./tools/i
skill-alignSkill

Audit and fix all Lattice documentation, README, docs/, PROJECT.md, GitHub issue templates, and CLAUDE.md to ensure they are fully aligned with the current skill inventory. Documentation drift is the most common source of user confusion in Lattice — a skill exists in the codebase but not in the docs, or a renamed skill leaves a stale reference in the bug report template. If you've made any change to skills/ and haven't run this, run it now. Use when the user says 'align docs', 'audit docs', 'update documentation', 'skill align', 'check docs are in sync', 'audit skill inventory', 'ensure docs are aligned', 'are the docs up to date', or 'what needs updating'. Standalone — does not call other skills.

skill-forgeSkill

Create a new Lattice skill — atom, molecule, or refiner — following all framework conventions. Writing skill files manually almost always produces convention violations: wrong section order, missing confirmation gates, defaults.md without the right structure. This skill knows all of that and guides you through it. Use whenever adding any new atom, molecule, or refiner to Lattice, or when the user says 'create a new skill', 'add an atom', 'add a molecule', 'add a refiner', 'build X for Lattice', 'new lattice skill', or 'skill forge'. Does not validate, align docs, or deploy — those are separate skills you run after.

skill-reviewSkill

Deep behavioral audit of a Lattice skill — proposes 3 review personas relevant to the skill, runs independent scenario analysis from each persona's perspective, then merges only the high-confidence, practical findings into a severity-ordered gap report with proposed fixes. Structural validation (conventions, cross-references) is skill-validate's job — this skill finds gaps that would realistically surface when someone actually uses the skill: missing scenario handling, ambiguous instructions, silent failure cases, and behavioral inconsistencies. Filters out theoretical edge cases, low-likelihood speculation, and findings owned by other skills. Use after writing or significantly changing any skill, or when the user says 'review this skill', 'deep review', 'does this skill work', 'find gaps in this skill', 'stress test this skill', 'review from different angles', or 'skill review'. Standalone — does not call other skills.

skill-validateSkill

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 it now — manual review consistently misses the same categories of errors this skill is specifically designed to catch. Use when the user says 'validate this skill', 'check this skill', 'does this follow conventions', 'review this skill file', 'check my SKILL.md', or 'skill validate'. Reports PASS/FAIL with specific file-and-section findings and actionable fixes. Standalone — does not call other skills.

architecture-compassSkill

Architectural thinking partner for an existing repository — scans the codebase, conducts a structured interview, agrees on current architectural state and recommended direction, and produces a shareable insights document. Scoped to one repository, module, or folder. Does not execute transformation — it orients. Use when the user says 'assess my codebase architecture', 'what direction should my codebase go', 'architecture compass', 'understand my architecture', 'audit architecture drift', 'architectural assessment', or 'help me understand what is wrong with my codebase'.

architecture-refinerSkill

Facilitate a structured conversation to define architecture principles for a repository. Supports multiple architecture styles: clean architecture (default), hexagonal / ports & adapters, modular monolith, or custom. Produces a formal architecture document that the corresponding atom will use. Use when setting up a new project, defining architecture standards, or when the user says 'setup architecture', 'define layers', 'architecture principles', 'help me define my architecture', 'hexagonal architecture', 'modular monolith', 'ports and adapters', or 'define my architecture style'.

architectureSkill

Enforce architectural rules when generating or modifying code, and validate proposed designs before approval (design mode). Defaults to clean architecture; supports any architecture style via the architecture-refiner. Validates layer responsibilities, dependency direction, and structural constraints using the loaded architecture rules. Use when generating code, reviewing architecture, creating new files, or when the user mentions 'architecture', 'layers', 'structure', 'dependency rules', 'hexagonal architecture', 'ports and adapters', 'modular monolith', or 'onion architecture'. Also use when reviewing generated code for structural compliance.

bug-fixSkill

Investigate, reproduce, and safely fix a bug with regression protection. Composes context, diagnosis, architecture, code quality, and testing guardrails into a reproduce-first repair workflow. Use when the user says 'fix this bug', 'debug this', 'investigate this failure', 'patch this regression', 'repair this issue', or 'why is this broken'.