skill-maker

Name: skill-maker
Author: AlpacaLabsLLC

260stars54forks

How to install skill-maker?

alpacalabsllc/skills-for-architects/skill-maker

$npx -y skills add AlpacaLabsLLC/skills-for-architects --skill skill-maker

Installs into the current project.

Summary

Scaffold a new Claude Code skill following this repo's conventions — copy a canonical template, apply the PATTERNS.md checklist, verify with lint. Use when the user runs /skill-maker, asks to create or package a new skill, or wants to turn a procedure into a slash command.

Files · 1

View on GitHub

SKILL.md

1	# /skill-maker — Scaffold a New Skill
2
3	You turn a described procedure into a working skill: a directory with a `SKILL.md` and a `README.md` that follows this repo's conventions. Input is the user's request; output is a card Claude can follow.
4
5	## Usage
6
7	```
8	/skill-maker a skill that turns raw site photos into a numbered photo log
9	/skill-maker package our submittal-review checklist as a slash command
10	/skill-maker <any procedure worth repeating>
11	```
12
13	## Hard rule: no interview
14
15	Derive everything — name, description, tools, steps — from the request. Do not ask setup questions. Ask exactly one question only if the skill's purpose is genuinely indecipherable from what the user wrote; otherwise make the reasonable call and note it when presenting the result.
16
17	## Anatomy of what you're producing
18
19	A skill is a procedure card. Four load-bearing parts:
20
21	\| Part \| Job \|
22	\|---\|---\|
23	\| `name` \| Kebab-case, matches the directory, becomes the slash command \|
24	\| `description` \| The trigger, not a label — how Claude knows to reach for the card unasked \|
25	\| `allowed-tools` \| The blast radius — the minimum set the steps need \|
26	\| Steps \| The procedure itself: numbered, concrete, in execution order \|
27
28	## Step 1 — Scaffold from the template
29
30	Copy `templates/example-skill/` (bundled next to this SKILL.md) and adapt every line. This skill's output is files on disk, not a proposal: create the target directory and write both `SKILL.md` and `README.md` immediately — the write permission prompt is the user's approval moment, so never present a draft and wait for a go-ahead first. If the bundled template can't be located, scaffold from the Anatomy table above.
31
32	- Name: kebab-case, derived from the request. Directory name and frontmatter `name` must match.
33	- Description: trigger-phrased — what the skill does AND when to invoke it, with phrases the user would actually say. A description that only labels never fires.
34	- allowed-tools: only what the steps actually need. Read-only skill? No Write. No shell work? No Bash.
35	- Steps: concrete and numbered, in the order the work happens. Include an output-format block when the skill produces a document or record. Nothing from the template survives verbatim except the shape.
36	- README.md: adapt alongside — what it does, usage, nothing more.
37
38	Where it goes — detect the target:
39
40	\| Condition \| Target \|
41	\|---\|---\|
42	\| cwd is the skills-for-architects repo — root `.claude-plugin/plugin.json` exists with name `architecture-studio` \| `skills/{name}/` \|
43	\| any other project \| `.claude/skills/{name}/` in the project \|
44	\| user explicitly asks for a global skill \| `$HOME/.claude/skills/{name}/` \|
45
46	## Step 2 — Apply the conventions checklist
47
48	Read `PATTERNS.md` at runtime — repo installs have it at the plugin root — and apply its rules to the scaffolded skill. Do not work from a remembered copy; the file is the authority.
49
50	Enforce these portable essentials regardless of target:
51
52	1. Description states what and when.
53	2. `README.md` exists alongside `SKILL.md`.
54	3. No `~/` paths in the SKILL.md body — they break on every machine but the author's. Use project-relative paths, or `$HOME` in the rare case a home path is the point.
55	4. `allowed-tools` is the minimum blast radius for the steps as written.
56	5. If the skill produces code, zoning, or life-safety analysis, its steps must instruct ending every report with the canonical disclaimer block followed by the marker `<!-- architecture-studio:requires-disclaimer -->` — see how `skills/occupancy-calculator/SKILL.md` does it.
57
58	## Step 3 — Verify
59
60	Inside the repo: run `scripts/lint.sh` with Bash and fix findings until green. Then remind the author: a new skill moves the catalog counts — the root README (catalog table, Skill Groups, "N skills" claims), the `/skills` menu headline, and the manifest descriptions all state counts the lint checks against the tree.
61
62	Outside the repo: run the Step 2 checklist explicitly, item by item, and say so. The house lint applies only to catalog contributions — a private skill owes it nothing.
63
64	## Finish
65
66	The job is done only when both files exist on disk — confirm their paths, then show the finished SKILL.md to the user. Tell them:
67
68	- How to invoke it: `/{name}` plus whatever the skill takes after the slash.
69	- How to iterate: edit the SKILL.md like any file — change a step, tighten the description, run it again.
70
71	Never commit anything; that's the author's call.

People who liked this also viewed

6 picks

Type

skill-maker

260stars54forks

View on GitHub

How to install skill-maker?

alpacalabsllc/skills-for-architects/skill-maker

$npx -y skills add AlpacaLabsLLC/skills-for-architects --skill skill-maker

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# /skill-maker — Scaffold a New Skill
2
3	You turn a described procedure into a working skill: a directory with a `SKILL.md` and a `README.md` that follows this repo's conventions. Input is the user's request; output is a card Claude can follow.
4
5	## Usage
6
7	```
8	/skill-maker a skill that turns raw site photos into a numbered photo log
9	/skill-maker package our submittal-review checklist as a slash command
10	/skill-maker <any procedure worth repeating>
11	```
12
13	## Hard rule: no interview
14
15	Derive everything — name, description, tools, steps — from the request. Do not ask setup questions. Ask exactly one question only if the skill's purpose is genuinely indecipherable from what the user wrote; otherwise make the reasonable call and note it when presenting the result.
16
17	## Anatomy of what you're producing
18
19	A skill is a procedure card. Four load-bearing parts:
20
21	\| Part \| Job \|
22	\|---\|---\|
23	\| `name` \| Kebab-case, matches the directory, becomes the slash command \|
24	\| `description` \| The trigger, not a label — how Claude knows to reach for the card unasked \|
25	\| `allowed-tools` \| The blast radius — the minimum set the steps need \|
26	\| Steps \| The procedure itself: numbered, concrete, in execution order \|
27
28	## Step 1 — Scaffold from the template
29
30	Copy `templates/example-skill/` (bundled next to this SKILL.md) and adapt every line. This skill's output is files on disk, not a proposal: create the target directory and write both `SKILL.md` and `README.md` immediately — the write permission prompt is the user's approval moment, so never present a draft and wait for a go-ahead first. If the bundled template can't be located, scaffold from the Anatomy table above.
31
32	- Name: kebab-case, derived from the request. Directory name and frontmatter `name` must match.
33	- Description: trigger-phrased — what the skill does AND when to invoke it, with phrases the user would actually say. A description that only labels never fires.
34	- allowed-tools: only what the steps actually need. Read-only skill? No Write. No shell work? No Bash.
35	- Steps: concrete and numbered, in the order the work happens. Include an output-format block when the skill produces a document or record. Nothing from the template survives verbatim except the shape.
36	- README.md: adapt alongside — what it does, usage, nothing more.
37
38	Where it goes — detect the target:
39
40	\| Condition \| Target \|
41	\|---\|---\|
42	\| cwd is the skills-for-architects repo — root `.claude-plugin/plugin.json` exists with name `architecture-studio` \| `skills/{name}/` \|
43	\| any other project \| `.claude/skills/{name}/` in the project \|
44	\| user explicitly asks for a global skill \| `$HOME/.claude/skills/{name}/` \|
45
46	## Step 2 — Apply the conventions checklist
47
48	Read `PATTERNS.md` at runtime — repo installs have it at the plugin root — and apply its rules to the scaffolded skill. Do not work from a remembered copy; the file is the authority.
49
50	Enforce these portable essentials regardless of target:
51
52	1. Description states what and when.
53	2. `README.md` exists alongside `SKILL.md`.
54	3. No `~/` paths in the SKILL.md body — they break on every machine but the author's. Use project-relative paths, or `$HOME` in the rare case a home path is the point.
55	4. `allowed-tools` is the minimum blast radius for the steps as written.
56	5. If the skill produces code, zoning, or life-safety analysis, its steps must instruct ending every report with the canonical disclaimer block followed by the marker `<!-- architecture-studio:requires-disclaimer -->` — see how `skills/occupancy-calculator/SKILL.md` does it.
57
58	## Step 3 — Verify
59
60	Inside the repo: run `scripts/lint.sh` with Bash and fix findings until green. Then remind the author: a new skill moves the catalog counts — the root README (catalog table, Skill Groups, "N skills" claims), the `/skills` menu headline, and the manifest descriptions all state counts the lint checks against the tree.
61
62	Outside the repo: run the Step 2 checklist explicitly, item by item, and say so. The house lint applies only to catalog contributions — a private skill owes it nothing.
63
64	## Finish
65
66	The job is done only when both files exist on disk — confirm their paths, then show the finished SKILL.md to the user. Tell them:
67
68	- How to invoke it: `/{name}` plus whatever the skill takes after the slash.
69	- How to iterate: edit the SKILL.md like any file — change a step, tighten the description, run it again.
70
71	Never commit anything; that's the author's call.

People who liked this also viewed

6 picks

Type