skill-forge

Name: skill-forge
Author: Rune-kit

80stars21forks

How to install skill-forge?

rune-kit/rune/skill-forge

$npx -y skills add Rune-kit/rune --skill skill-forge

Installs into the current project.

Summary

Use when creating new Rune skills, editing existing skills, or verifying skill quality before deployment. Applies TDD discipline to skill authoring — test before write, verify before ship.

Files · 1

View on GitHub

SKILL.md

1	# skill-forge
2
3	## Purpose
4
5	The skill that builds skills. Applies Test-Driven Development to skill authoring: write a pressure test first, watch agents fail without the skill, write the skill to fix those failures, then close loopholes until bulletproof. Ensures every Rune skill is battle-tested before it enters the mesh.
6
7	## Triggers
8
9	- `/rune skill-forge` — manual invocation to create or edit a skill
10	- Auto-trigger: when user says "create a skill", "new skill", "add skill to rune"
11	- Auto-trigger: when editing any `skills/*/SKILL.md` file
12
13	## Calls (outbound)
14
15	- `scout` (L3): scan existing skills for patterns and naming conventions
16	- `plan` (L2): structure complex skills with multiple phases
17	- `hallucination-guard` (L3): verify referenced skills/tools actually exist
18	- `verification` (L3): validate SKILL.md format compliance
19	- `journal` (L3): record skill creation decisions in ADR
20
21	## Called By (inbound)
22
23	- `cook` (L1): when the feature being built IS a new skill
24	- `scaffold` (L1): when scaffolded project includes custom skills
25
26	## References
27
28	- `references/claude-skill-reference.md` — Claude Code skill system: frontmatter fields, variables, shell injection, invocation control matrix, skill type patterns (task/research/knowledge/dynamic), file structure, and quality checklist. Load when creating or editing any skill.
29
30	## Workflow
31
32	### Phase 1 — DISCOVER
33
34	Before writing anything, understand the landscape:
35
36	1. Scan existing skills via `scout` — is this already covered?
37	2. Check for overlap — will this duplicate or conflict with existing skills?
38	3. Identify layer — L1 (orchestrator), L2 (workflow hub), L3 (utility)?
39	4. Identify mesh connections — what calls this? What does this call?
40
41	<HARD-GATE>
42	If a skill with >70% overlap already exists → extend it, don't create new.
43	The mesh grows stronger by deepening connections, not by adding nodes.
44	</HARD-GATE>
45
46	### Phase 2 — RED (Baseline Test)
47
48	Write the test BEFORE writing the skill.
49
50	Create a pressure scenario that exposes the problem the skill solves:
51
52	```markdown
53	## Pressure Scenario: [skill-name]
54
55	### Setup
56	[Describe the situation an agent faces]
57
58	### Pressures (combine 2-3)
59	- Time pressure: "This is urgent, just do it"
60	- Sunk cost: "I already wrote 200 lines, can't restart"
61	- Complexity: "Too many moving parts to follow process"
62	- Authority: "Senior dev says skip testing"
63	- Exhaustion: "We're 50 tool calls deep"
64
65	### Expected Failure (without skill)
66	[What the agent will probably do wrong]
67
68	### Success Criteria (with skill)
69	[What the agent should do instead]
70	```
71
72	Run the scenario with a subagent WITHOUT the skill. Document:
73	- Exact behavior — what did the agent do?
74	- Rationalizations — verbatim excuses for skipping discipline
75	- Failure point — where exactly did it go wrong?
76
77	<HARD-GATE>
78	You MUST observe at least one failure before writing the skill.
79	No failure observed = you don't understand the problem well enough to write the solution.
80	</HARD-GATE>
81
82	### Phase 3 — GREEN (Write Minimal Skill)
83
84	Write the SKILL.md addressing ONLY the failures observed in Phase 2.
85
86	Follow `docs/SKILL-TEMPLATE.md` format. Required sections:
87
88	\| Section \| Required \| Purpose \|
89	\|---\|---\|---\|
90	\| Frontmatter \| YES \| Name, description, metadata \|
91	\| Purpose \| YES \| One paragraph, ecosystem role \|
92	\| Triggers \| YES \| When to invoke \|
93	\| Calls / Called By \| YES \| Mesh connections (control flow) \|
94	\| Data Flow \| YES \| Feeds Into / Fed By / Feedback Loops (data flow) \|
95	\| Workflow \| YES \| Step-by-step execution \|
96	\| Output Format \| YES \| Structured, parseable output \|
97	\| Constraints \| YES \| 3-7 MUST/MUST NOT rules \|
98	\| Sharp Edges \| YES \| Known failure modes \|
99	\| Self-Validation \| YES \| Domain-specific QA checklist (per-skill, not centralized) \|
100	\| Done When \| YES \| Verifiable completion criteria \|
101	\| Cost Profile \| YES \| Token estimate \|
102	\| Mesh Gates \| L1/L2 only \| Progression guards \|
103
104	#### SKILL.md Anatomy — WHY vs HOW Split
105
106	A skill file answers WHY and WHEN — not HOW. Code examples, syntax references, and implementation patterns belong in separate files:
107
108	```
109	skills/[name]/
110	├── SKILL.md ← WHY: purpose, triggers, constraints, sharp edges (~150-300 lines)
111	├── references/ ← HOW: code patterns, syntax tables, API examples
112	│ ├── patterns.md ← Implementation patterns with code blocks
113	│ └── gotchas.md ← Language/framework-specific pitfalls
114	└── scripts/ ← WHAT: deterministic operations (shell, node)
115	```
116
117	Rules:
118	1. SKILL.md MUST NOT contain code blocks longer than 10 lines — move to `references/`
119	2. One excellent inline example (≤10 lines) is OK for clarity — more than that is a s

People who liked this also viewed

6 picks

Type

hyperframes-cliUse the HyperFrames CLI development loop: init, add, catalog, capture, lint, check, snapshot, compare, grade-compare, preview, play, present, beats, keyframes, single or batch render, publish, cloud, SkillsJul 2026262k37k
request-refactor-planSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026165k181k
analyze-projectRigor Analyze / Rigor Audit read-only skill for deep learning research repositories. Use when the user wants to read and understand a repository, inspect model structure and training or inference entrSkillsMay 2026161k507
explore-codeRigor Improve implementation leaf skill for auditable candidate implementation in deep learning research repositories. Use when the researcher explicitly authorizes exploratory work on an isolated braSkillsMay 2026161k507
ubiquitous-languageSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026160k181k
scaffold-exercisesSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026149k181k

skill-forge

80stars21forks

View on GitHub

How to install skill-forge?

rune-kit/rune/skill-forge

$npx -y skills add Rune-kit/rune --skill skill-forge

Installs into the current project.

Summary

Use when creating new Rune skills, editing existing skills, or verifying skill quality before deployment. Applies TDD discipline to skill authoring — test before write, verify before ship.

Files · 1

View on GitHub

SKILL.md

1	# skill-forge
2
3	## Purpose
4
5	The skill that builds skills. Applies Test-Driven Development to skill authoring: write a pressure test first, watch agents fail without the skill, write the skill to fix those failures, then close loopholes until bulletproof. Ensures every Rune skill is battle-tested before it enters the mesh.
6
7	## Triggers
8
9	- `/rune skill-forge` — manual invocation to create or edit a skill
10	- Auto-trigger: when user says "create a skill", "new skill", "add skill to rune"
11	- Auto-trigger: when editing any `skills/*/SKILL.md` file
12
13	## Calls (outbound)
14
15	- `scout` (L3): scan existing skills for patterns and naming conventions
16	- `plan` (L2): structure complex skills with multiple phases
17	- `hallucination-guard` (L3): verify referenced skills/tools actually exist
18	- `verification` (L3): validate SKILL.md format compliance
19	- `journal` (L3): record skill creation decisions in ADR
20
21	## Called By (inbound)
22
23	- `cook` (L1): when the feature being built IS a new skill
24	- `scaffold` (L1): when scaffolded project includes custom skills
25
26	## References
27
28	- `references/claude-skill-reference.md` — Claude Code skill system: frontmatter fields, variables, shell injection, invocation control matrix, skill type patterns (task/research/knowledge/dynamic), file structure, and quality checklist. Load when creating or editing any skill.
29
30	## Workflow
31
32	### Phase 1 — DISCOVER
33
34	Before writing anything, understand the landscape:
35
36	1. Scan existing skills via `scout` — is this already covered?
37	2. Check for overlap — will this duplicate or conflict with existing skills?
38	3. Identify layer — L1 (orchestrator), L2 (workflow hub), L3 (utility)?
39	4. Identify mesh connections — what calls this? What does this call?
40
41	<HARD-GATE>
42	If a skill with >70% overlap already exists → extend it, don't create new.
43	The mesh grows stronger by deepening connections, not by adding nodes.
44	</HARD-GATE>
45
46	### Phase 2 — RED (Baseline Test)
47
48	Write the test BEFORE writing the skill.
49
50	Create a pressure scenario that exposes the problem the skill solves:
51
52	```markdown
53	## Pressure Scenario: [skill-name]
54
55	### Setup
56	[Describe the situation an agent faces]
57
58	### Pressures (combine 2-3)
59	- Time pressure: "This is urgent, just do it"
60	- Sunk cost: "I already wrote 200 lines, can't restart"
61	- Complexity: "Too many moving parts to follow process"
62	- Authority: "Senior dev says skip testing"
63	- Exhaustion: "We're 50 tool calls deep"
64
65	### Expected Failure (without skill)
66	[What the agent will probably do wrong]
67
68	### Success Criteria (with skill)
69	[What the agent should do instead]
70	```
71
72	Run the scenario with a subagent WITHOUT the skill. Document:
73	- Exact behavior — what did the agent do?
74	- Rationalizations — verbatim excuses for skipping discipline
75	- Failure point — where exactly did it go wrong?
76
77	<HARD-GATE>
78	You MUST observe at least one failure before writing the skill.
79	No failure observed = you don't understand the problem well enough to write the solution.
80	</HARD-GATE>
81
82	### Phase 3 — GREEN (Write Minimal Skill)
83
84	Write the SKILL.md addressing ONLY the failures observed in Phase 2.
85
86	Follow `docs/SKILL-TEMPLATE.md` format. Required sections:
87
88	\| Section \| Required \| Purpose \|
89	\|---\|---\|---\|
90	\| Frontmatter \| YES \| Name, description, metadata \|
91	\| Purpose \| YES \| One paragraph, ecosystem role \|
92	\| Triggers \| YES \| When to invoke \|
93	\| Calls / Called By \| YES \| Mesh connections (control flow) \|
94	\| Data Flow \| YES \| Feeds Into / Fed By / Feedback Loops (data flow) \|
95	\| Workflow \| YES \| Step-by-step execution \|
96	\| Output Format \| YES \| Structured, parseable output \|
97	\| Constraints \| YES \| 3-7 MUST/MUST NOT rules \|
98	\| Sharp Edges \| YES \| Known failure modes \|
99	\| Self-Validation \| YES \| Domain-specific QA checklist (per-skill, not centralized) \|
100	\| Done When \| YES \| Verifiable completion criteria \|
101	\| Cost Profile \| YES \| Token estimate \|
102	\| Mesh Gates \| L1/L2 only \| Progression guards \|
103
104	#### SKILL.md Anatomy — WHY vs HOW Split
105
106	A skill file answers WHY and WHEN — not HOW. Code examples, syntax references, and implementation patterns belong in separate files:
107
108	```
109	skills/[name]/
110	├── SKILL.md ← WHY: purpose, triggers, constraints, sharp edges (~150-300 lines)
111	├── references/ ← HOW: code patterns, syntax tables, API examples
112	│ ├── patterns.md ← Implementation patterns with code blocks
113	│ └── gotchas.md ← Language/framework-specific pitfalls
114	└── scripts/ ← WHAT: deterministic operations (shell, node)
115	```
116
117	Rules:
118	1. SKILL.md MUST NOT contain code blocks longer than 10 lines — move to `references/`
119	2. One excellent inline example (≤10 lines) is OK for clarity — more than that is a s

People who liked this also viewed

6 picks

Type