techygarg/skill-forge
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.
npx skills add https://github.com/techygarg/lattice --skill skill-forge
Core responsibility: Create the right files with the right structure for a new Lattice skill.
Input: A description of what the skill should do and when it should trigger.
Output: One or more skill files written to the correct path:
skills/atoms/{name}/SKILL.md + skills/atoms/{name}/references/defaults.mdskills/molecules/{name}/SKILL.mdskills/refiners/{name}/SKILL.md + skills/refiners/{name}/assets/template.mdHow to verify this skill did its job:
name: frontmatter exactlyAsk the user: *"What should this skill do, and when should it trigger? Describe it briefly."*
From the description, determine the tier:
| The skill... | Tier |
|---|---|
| Enforces ONE principle with a checklist and anti-pattern scan | Atom |
| Orchestrates multiple atoms into a multi-step workflow | Molecule |
| Runs a guided interview to produce a .lattice/standards/*.md file | Refiner |
State your read and confirm with the user. Get explicit tier agreement before proceeding.
Before writing a single line of SKILL.md, agree on the design.
Check knowledge-base/ for an existing requirements doc:
ls knowledge-base/ | grep -i {name}
If found → read it, summarise key design decisions, confirm they still reflect intent.
If not found → resolve these questions through conversation before writing:
For a molecule:
skills/atoms/ to see what exists.).lattice/? Which subfolder? (Must be a named subfolder, never the root.)For a refiner:
paths.{snake_case_key} config key does it add to .lattice/config.yaml?Write a one-paragraph design summary and confirm with the user.
Do NOT write SKILL.md until design is confirmed.
Read PROJECT.md — the Skill Conventions section. Always read it fresh; never rely on memory.
Note the current skill counts (atoms/molecules/refiners) — they will need updating in PROJECT.md after creation, but that is skill-align's job.
skills/atoms/{name}/SKILL.md — sections in this exact order:
name (lowercase-hyphenated), description (include trigger phrases).lattice/config.yaml for paths.{config_key}mode: overlay (merge with defaults) or mode: override (replace)./references/defaults.md- [ ] Name: what it looks like → fix), minimum 5 itemsskills/atoms/{name}/references/defaults.md — the embedded defaults:
skills/molecules/{name}/SKILL.md:
framework:{name} with always/conditional qualifierGenerative molecule conventions (code-forge, bug-fix, refactor-safely pattern):
framework:collaborative-judgmentPlanning/interactive molecule conventions (design-blueprint, requirement-forge pattern):
.lattice/{subfolder}/ — never to .lattice/ rootskills/refiners/{name}/SKILL.md — cover all of these:
./assets/template.md and its Interview Guidance comments)paths.{key} to .lattice/config.yaml)skills/refiners/{name}/assets/template.md:
<!-- INTERVIEW GUIDANCE: --> comments per sectionBefore finishing, verify:
name: frontmatter field (exactly, character by character)description: contains trigger phrases — what a user would actually type to invoke thisdefaults.md exists and has §-numbered sections with real contenttemplate.md exists with Interview Guidance comments in every sectionReport what was created and where. Do not run validation, sync, or deploy — those are separate steps.
Take techygarg/skill-forge from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.