skill-forge

Name: skill-forge
Author: techygarg

165stars12forks

How to install skill-forge?

techygarg/lattice/skill-forge

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

Installs into the current project.

Summary

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

Files · 1

View on GitHub

SKILL.md

1	# Lattice Skill Forge
2
3	Core responsibility: Create the right files with the right structure for a new Lattice skill.
4
5	Input: A description of what the skill should do and when it should trigger.
6
7	Output: One or more skill files written to the correct path:
8	- Atom → `skills/atoms/{name}/SKILL.md` + `skills/atoms/{name}/references/defaults.md`
9	- Molecule → `skills/molecules/{name}/SKILL.md`
10	- Refiner → `skills/refiners/{name}/SKILL.md` + `skills/refiners/{name}/assets/template.md`
11
12	How to verify this skill did its job:
13	- All required files exist at the correct paths
14	- Folder name matches `name:` frontmatter exactly
15	- All tier-required sections are present in correct order
16	- No placeholder content — all sections contain real, specific content
17
18	---
19
20	## Step 1: Understand intent and select tier
21
22	Ask the user: "What should this skill do, and when should it trigger? Describe it briefly."
23
24	From the description, determine the tier:
25
26	\| The skill... \| Tier \|
27	\|---\|---\|
28	\| Enforces ONE principle with a checklist and anti-pattern scan \| Atom \|
29	\| Orchestrates multiple atoms into a multi-step workflow \| Molecule \|
30	\| Runs a guided interview to produce a `.lattice/standards/.md` file \| Refiner* \|
31
32	State your read and confirm with the user. Get explicit tier agreement before proceeding.
33
34	---
35
36	## Step 2: Requirements alignment (molecules and refiners only)
37
38	Before writing a single line of SKILL.md, agree on the design.
39
40	Check `knowledge-base/` for an existing requirements doc:
41	```bash
42	ls knowledge-base/ \| grep -i {name}
43	```
44
45	If found → read it, summarise key design decisions, confirm they still reflect intent.
46
47	If not found → resolve these questions through conversation before writing:
48
49	For a molecule:
50	- Which atoms does it compose? (Read `skills/atoms/` to see what exists.)
51	- Is it generative (produces code/artifacts, linear flow) or planning/interactive (produces living documents, confirmation gates at each phase)?
52	- What does it write to `.lattice/`? Which subfolder? (Must be a named subfolder, never the root.)
53	- What is the session resume behavior — how does it handle an interrupted session?
54
55	For a refiner:
56	- Which atom does it configure? (A refiner must have an atom that reads its output.)
57	- What `paths.{snake_case_key}` config key does it add to `.lattice/config.yaml`?
58	- What sections does the interview template cover?
59	- Overlay/override — which is the default mode?
60
61	Write a one-paragraph design summary and confirm with the user.
62
63	Do NOT write SKILL.md until design is confirmed.
64
65	---
66
67	## Step 3: Read current conventions
68
69	Read `PROJECT.md` — the Skill Conventions section. Always read it fresh; never rely on memory.
70
71	Note the current skill counts (atoms/molecules/refiners) — they will need updating in PROJECT.md after creation, but that is `skill-align`'s job.
72
73	---
74
75	## Step 4: Write the skill files
76
77	### Writing an Atom
78
79	`skills/atoms/{name}/SKILL.md` — sections in this exact order:
80
81	1. YAML frontmatter — `name` (lowercase-hyphenated), `description` (include trigger phrases)
82	2. Config Resolution — always this pattern:
83	- Check `.lattice/config.yaml` for `paths.{config_key}`
84	- If found: read doc, check `mode: overlay` (merge with defaults) or `mode: override` (replace)
85	- If not found: read `./references/defaults.md`
86	3. Self-Validation Checklist — numbered items, bold label, imperative STOP language, clear pass/fail condition and fix per item
87	4. Active Anti-Pattern Scan — checkbox format (`- [ ] Name: what it looks like → fix`), minimum 5 items
88	5. Ambiguity Signals — genuine gray areas where two valid approaches exist; resolution guidance for each
89	6. Core Principle — what the atom governs, what it does NOT govern (boundary with other atoms)
90
91	`skills/atoms/{name}/references/defaults.md` — the embedded defaults:
92	- Numbered sections (§1, §2...) matching what a future refiner would produce
93	- Opinionated, specific content — not placeholders
94	- End with an attribution line
95
96	### Writing a Molecule
97
98	`skills/molecules/{name}/SKILL.md`:
99
100	1. YAML frontmatter — name, description with trigger phrases
101	2. Required Skills — list every atom as `framework:{name}` with always/conditional qualifier
102	3. Mode Detection (if the molecule has modes) — how modes are invoked, what each c

People who liked this also viewed

6 picks

Type

skill-forge

165stars12forks

View on GitHub

How to install skill-forge?

techygarg/lattice/skill-forge

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

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Lattice Skill Forge
2
3	Core responsibility: Create the right files with the right structure for a new Lattice skill.
4
5	Input: A description of what the skill should do and when it should trigger.
6
7	Output: One or more skill files written to the correct path:
8	- Atom → `skills/atoms/{name}/SKILL.md` + `skills/atoms/{name}/references/defaults.md`
9	- Molecule → `skills/molecules/{name}/SKILL.md`
10	- Refiner → `skills/refiners/{name}/SKILL.md` + `skills/refiners/{name}/assets/template.md`
11
12	How to verify this skill did its job:
13	- All required files exist at the correct paths
14	- Folder name matches `name:` frontmatter exactly
15	- All tier-required sections are present in correct order
16	- No placeholder content — all sections contain real, specific content
17
18	---
19
20	## Step 1: Understand intent and select tier
21
22	Ask the user: "What should this skill do, and when should it trigger? Describe it briefly."
23
24	From the description, determine the tier:
25
26	\| The skill... \| Tier \|
27	\|---\|---\|
28	\| Enforces ONE principle with a checklist and anti-pattern scan \| Atom \|
29	\| Orchestrates multiple atoms into a multi-step workflow \| Molecule \|
30	\| Runs a guided interview to produce a `.lattice/standards/.md` file \| Refiner* \|
31
32	State your read and confirm with the user. Get explicit tier agreement before proceeding.
33
34	---
35
36	## Step 2: Requirements alignment (molecules and refiners only)
37
38	Before writing a single line of SKILL.md, agree on the design.
39
40	Check `knowledge-base/` for an existing requirements doc:
41	```bash
42	ls knowledge-base/ \| grep -i {name}
43	```
44
45	If found → read it, summarise key design decisions, confirm they still reflect intent.
46
47	If not found → resolve these questions through conversation before writing:
48
49	For a molecule:
50	- Which atoms does it compose? (Read `skills/atoms/` to see what exists.)
51	- Is it generative (produces code/artifacts, linear flow) or planning/interactive (produces living documents, confirmation gates at each phase)?
52	- What does it write to `.lattice/`? Which subfolder? (Must be a named subfolder, never the root.)
53	- What is the session resume behavior — how does it handle an interrupted session?
54
55	For a refiner:
56	- Which atom does it configure? (A refiner must have an atom that reads its output.)
57	- What `paths.{snake_case_key}` config key does it add to `.lattice/config.yaml`?
58	- What sections does the interview template cover?
59	- Overlay/override — which is the default mode?
60
61	Write a one-paragraph design summary and confirm with the user.
62
63	Do NOT write SKILL.md until design is confirmed.
64
65	---
66
67	## Step 3: Read current conventions
68
69	Read `PROJECT.md` — the Skill Conventions section. Always read it fresh; never rely on memory.
70
71	Note the current skill counts (atoms/molecules/refiners) — they will need updating in PROJECT.md after creation, but that is `skill-align`'s job.
72
73	---
74
75	## Step 4: Write the skill files
76
77	### Writing an Atom
78
79	`skills/atoms/{name}/SKILL.md` — sections in this exact order:
80
81	1. YAML frontmatter — `name` (lowercase-hyphenated), `description` (include trigger phrases)
82	2. Config Resolution — always this pattern:
83	- Check `.lattice/config.yaml` for `paths.{config_key}`
84	- If found: read doc, check `mode: overlay` (merge with defaults) or `mode: override` (replace)
85	- If not found: read `./references/defaults.md`
86	3. Self-Validation Checklist — numbered items, bold label, imperative STOP language, clear pass/fail condition and fix per item
87	4. Active Anti-Pattern Scan — checkbox format (`- [ ] Name: what it looks like → fix`), minimum 5 items
88	5. Ambiguity Signals — genuine gray areas where two valid approaches exist; resolution guidance for each
89	6. Core Principle — what the atom governs, what it does NOT govern (boundary with other atoms)
90
91	`skills/atoms/{name}/references/defaults.md` — the embedded defaults:
92	- Numbered sections (§1, §2...) matching what a future refiner would produce
93	- Opinionated, specific content — not placeholders
94	- End with an attribution line
95
96	### Writing a Molecule
97
98	`skills/molecules/{name}/SKILL.md`:
99
100	1. YAML frontmatter — name, description with trigger phrases
101	2. Required Skills — list every atom as `framework:{name}` with always/conditional qualifier
102	3. Mode Detection (if the molecule has modes) — how modes are invoked, what each c

People who liked this also viewed

6 picks

Type