skill-creator

Name: skill-creator
Author: luongnv89

742stars61forks

How to install skill-creator?

luongnv89/asm/skill-creator

$npx -y skills add luongnv89/asm --skill skill-creator

Installs into the current project.

Summary

Create, improve, evaluate, benchmark skills. Use when authoring a new skill, updating an existing one, running evals, or optimizing a skill's description for triggering. Don't use for invoking skills, writing prose, or scaffolding Python projects.

Files · 1

View on GitHub

SKILL.md

1	# Skill Creator
2
3	A skill for creating new skills and iteratively improving them. The agent's context budget is the primary constraint, so this SKILL.md links out to focused reference files.
4
5	The core loop:
6
7	1. Decide what the skill should do and how it should do it
8	2. Write a draft
9	3. Run test prompts against claude-with-access-to-the-skill
10	4. Evaluate results with the user (qualitative review via `eval-viewer/generate_review.py`, plus quantitative evals)
11	5. Revise the skill based on feedback and benchmarks
12	6. Repeat until satisfied; expand the test set and try again at scale
13
14	Identify where the user is in this loop and jump in there. New skill from scratch → start at step 1. Existing draft → jump to step 3 or 4. User wants to vibe-iterate without formal evals → support that. After the skill stabilizes, optionally run the description improver to optimize triggering.
15
16	## Two entry paths
17
18	The skill supports two distinct workflows. Identify which one the user is on before you do anything else — they don't share a starting step.
19
20	- Path A — Create a new skill from scratch. The user wants to capture a workflow, codify a pattern, or build a new capability. Start at "Creating a skill" below (Capture Intent → Interview → Write SKILL.md → Test → Eval).
21	- Path B — Improve an existing skill. The user points to a skill that already exists and wants it brought up to standard, fixed, optimized, or iterated based on eval feedback. Do not start with Capture Intent — the intent is already encoded in the existing SKILL.md. Start at "Improving an existing skill" below.
22
23	If the request is ambiguous ("can you look at this skill?"), assume Path B and confirm before interviewing as if it were new. Path B also fires when `/skill-creator` is invoked on a skill directory or file.
24
25	Both paths share the mandatory rules below: Repo Sync Before Edits, Version Management, YAML Frontmatter Safety, and Frontmatter Audit on Review/Evaluation. Apply them in either path.
26
27	## Step Completion Reports
28
29	After completing each major step, output a status report in this format:
30
31	```
32	◆ [Step Name] ([step N of M] — [context])
33	··································································
34	[Check 1]: √ pass
35	[Check 2]: √ pass (note if relevant)
36	[Check 3]: × fail — [reason]
37	[Check 4]: √ pass
38	[Criteria]: √ N/M met
39	____________________________
40	Result: PASS \| FAIL \| PARTIAL
41	```
42
43	Adapt the check names to match what the step actually validates. Use `√` for pass, `×` for fail, and `—` to add brief context. The "Criteria" line summarizes how many acceptance criteria were met. The "Result" line gives the overall verdict.
44
45	Intent Capture phase checks: `Worth building`, `Goal defined`, `Triggers identified`, `Output format agreed`
46
47	Skill Writing phase checks: `SKILL.md written`, `README generated`, `Subagents designed`, `Predictability pass` (the 7 rubric items from _Make it predictable_ — √ when each is satisfied, × naming the gap), `Adversarial review` (fresh-subagent findings addressed)
48
49	Testing phase checks: `Evals created`, `Runs completed`, `Viewer launched`
50
51	Iteration phase checks: `Feedback incorporated`, `Benchmarks improved`, `Description optimized`
52
53	## Communicating with the user
54
55	Users span a wide range of technical familiarity. Match jargon to context cues — terms like "JSON" or "assertion" need evidence the user knows them; briefly define terms when in doubt.
56
57	---
58
59	## Mandatory Rule for Repo-Mutating Skills
60
61	When creating or updating any skill that changes files in a git repository (code, docs, config, commits, publishing), include this rule in that skill's SKILL.md:
62
63	- Add a "Repo Sync Before Edits (mandatory)" section near the top requiring `branch="$(git rev-parse --abbrev-ref HEAD)"; git fetch origin && git pull --rebase origin "$branch"` before modifications.
64	- If the working tree is dirty: stash, sync, then pop.
65	- If `origin` is missing or conflicts occur: stop and ask the user before continuing.
66
67	Do not ship repo-mutating skills without this pre-sync guardrail.
68
69	## Frontmatter rules (mandatory)
70
71	Read `references/frontmatter-rules.md` for the full mandatory rules:
72
73	- Version Management — set `metadata.version: 1.0.0` on creation; bump patch/minor/major on every edit.
74	- YAML Frontmatter Safety — double-quote any string value containing YAML-special characters (full list in the reference).
75	- Frontmatter Audit on Review/Evaluation — required-field check, name/dir match, allowed top-level keys, `metadata.version`, `me

People who liked this also viewed

6 picks

Type

skill-creator

742stars61forks

View on GitHub

How to install skill-creator?

luongnv89/asm/skill-creator

$npx -y skills add luongnv89/asm --skill skill-creator

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Skill Creator
2
3	A skill for creating new skills and iteratively improving them. The agent's context budget is the primary constraint, so this SKILL.md links out to focused reference files.
4
5	The core loop:
6
7	1. Decide what the skill should do and how it should do it
8	2. Write a draft
9	3. Run test prompts against claude-with-access-to-the-skill
10	4. Evaluate results with the user (qualitative review via `eval-viewer/generate_review.py`, plus quantitative evals)
11	5. Revise the skill based on feedback and benchmarks
12	6. Repeat until satisfied; expand the test set and try again at scale
13
14	Identify where the user is in this loop and jump in there. New skill from scratch → start at step 1. Existing draft → jump to step 3 or 4. User wants to vibe-iterate without formal evals → support that. After the skill stabilizes, optionally run the description improver to optimize triggering.
15
16	## Two entry paths
17
18	The skill supports two distinct workflows. Identify which one the user is on before you do anything else — they don't share a starting step.
19
20	- Path A — Create a new skill from scratch. The user wants to capture a workflow, codify a pattern, or build a new capability. Start at "Creating a skill" below (Capture Intent → Interview → Write SKILL.md → Test → Eval).
21	- Path B — Improve an existing skill. The user points to a skill that already exists and wants it brought up to standard, fixed, optimized, or iterated based on eval feedback. Do not start with Capture Intent — the intent is already encoded in the existing SKILL.md. Start at "Improving an existing skill" below.
22
23	If the request is ambiguous ("can you look at this skill?"), assume Path B and confirm before interviewing as if it were new. Path B also fires when `/skill-creator` is invoked on a skill directory or file.
24
25	Both paths share the mandatory rules below: Repo Sync Before Edits, Version Management, YAML Frontmatter Safety, and Frontmatter Audit on Review/Evaluation. Apply them in either path.
26
27	## Step Completion Reports
28
29	After completing each major step, output a status report in this format:
30
31	```
32	◆ [Step Name] ([step N of M] — [context])
33	··································································
34	[Check 1]: √ pass
35	[Check 2]: √ pass (note if relevant)
36	[Check 3]: × fail — [reason]
37	[Check 4]: √ pass
38	[Criteria]: √ N/M met
39	____________________________
40	Result: PASS \| FAIL \| PARTIAL
41	```
42
43	Adapt the check names to match what the step actually validates. Use `√` for pass, `×` for fail, and `—` to add brief context. The "Criteria" line summarizes how many acceptance criteria were met. The "Result" line gives the overall verdict.
44
45	Intent Capture phase checks: `Worth building`, `Goal defined`, `Triggers identified`, `Output format agreed`
46
47	Skill Writing phase checks: `SKILL.md written`, `README generated`, `Subagents designed`, `Predictability pass` (the 7 rubric items from _Make it predictable_ — √ when each is satisfied, × naming the gap), `Adversarial review` (fresh-subagent findings addressed)
48
49	Testing phase checks: `Evals created`, `Runs completed`, `Viewer launched`
50
51	Iteration phase checks: `Feedback incorporated`, `Benchmarks improved`, `Description optimized`
52
53	## Communicating with the user
54
55	Users span a wide range of technical familiarity. Match jargon to context cues — terms like "JSON" or "assertion" need evidence the user knows them; briefly define terms when in doubt.
56
57	---
58
59	## Mandatory Rule for Repo-Mutating Skills
60
61	When creating or updating any skill that changes files in a git repository (code, docs, config, commits, publishing), include this rule in that skill's SKILL.md:
62
63	- Add a "Repo Sync Before Edits (mandatory)" section near the top requiring `branch="$(git rev-parse --abbrev-ref HEAD)"; git fetch origin && git pull --rebase origin "$branch"` before modifications.
64	- If the working tree is dirty: stash, sync, then pop.
65	- If `origin` is missing or conflicts occur: stop and ask the user before continuing.
66
67	Do not ship repo-mutating skills without this pre-sync guardrail.
68
69	## Frontmatter rules (mandatory)
70
71	Read `references/frontmatter-rules.md` for the full mandatory rules:
72
73	- Version Management — set `metadata.version: 1.0.0` on creation; bump patch/minor/major on every edit.
74	- YAML Frontmatter Safety — double-quote any string value containing YAML-special characters (full list in the reference).
75	- Frontmatter Audit on Review/Evaluation — required-field check, name/dir match, allowed top-level keys, `metadata.version`, `me

People who liked this also viewed

6 picks

Type