/skillify — Create, adapt, or update a skill

When you want to create, adapt, or update an Agent Skill (Claude Code, Codex, Cursor, and other hosts) in one of your repos (listed in ~/.config/makerskills/skillify/repos.yaml.

by coreyhaines31·MIT license·★ 855 Stars on the repo·GitHub ↗

Use now

Inside this skill

SKILL.md · the author's own words
# /skillify — Create, adapt, or update a skill

One skill, three modes. Routes automatically to the right one based on input signal.

Consolidates and replaces the prior `create-skill`, `adapt-skill`, and `update-skill` (all merged as of v0.2.0 for vocabulary-moat consiste…

## Step 0 — Detect mode

Route by signal:

| Signal | Mode |
|---|---|
| Invoked mid-conversation with substantive recent workflow discussion | **CREATE / from-chat** (default) |
| `/skillify from-video <url>` OR `/skillify` + a video URL | **CREATE / from-video** |
| `/skillify from-dump` + pasted brief/transcript/notes | **CREATE / from-dump** |
| `/skillify from-scratch <name>` OR "make a new skill called X" with no context | **CREATE / from-scratch** |

Word-for-word excerpt, not a result. Read the full SKILL.md ↓

Files of /skillify — Create, adapt, or update a skill

coreyhaines31/main1 file shown
SKILL.md
Show the full text431 lines

/skillify — Create, adapt, or update a skill

One skill, three modes. Routes automatically to the right one based on input signal.

Consolidates and replaces the prior create-skill, adapt-skill, and update-skill (all merged as of v0.2.0 for vocabulary-moat consistency with the -ify trifecta).

Step 0 — Detect mode

Route by signal:

Signal Mode
Invoked mid-conversation with substantive recent workflow discussion CREATE / from-chat (default)
/skillify from-video <url> OR /skillify + a video URL CREATE / from-video
/skillify from-dump + pasted brief/transcript/notes CREATE / from-dump
/skillify from-scratch <name> OR "make a new skill called X" with no context CREATE / from-scratch
/skillify <github-url> OR "adapt this skill" / "port this skill" / "fork this skill" + external source ADAPT
/skillify <existing-skill> <change> OR "update X skill" / "propagate this learning" UPDATE / targeted
/skillify update (mid-conversation) UPDATE / from-chat — scan recent chat for learnings
/skillify usage <skill> UPDATE / usage — review recent runs, suggest improvements

If ambiguous, ask before proceeding. Never guess between CREATE and ADAPT if there's an external URL involved.


Mode: CREATE

Build a new skill from chat / video / dump / scratch.

Step 1 — Confirm the input source
Sub-mode What
from-chat (default) Extract the skill from the workflow discussed in this conversation. Most common case.
from-video User recorded a Loom / Zoom / screen-share. Calls watch-video in visual mode → transcript + key visual moments → SKILL.md. Best for visual/UI-heavy workflows.
from-dump User pastes a brief, prior conversation transcript, exported chat, or notes.
from-scratch Fresh idea with no source material — interactive Q&A.
Step 2 — Defer to Anthropic guidance for the schema

Don't reinvent SKILL.md format rules. For frontmatter, description-writing, references/ structure, and skill best practices:

  • compound-engineering:create-agent-skill (agent) — expert guidance for creating + editing Claude Code skills
  • compound-engineering:skill-creator (skill) — deeper guide for effective skills
  • compound-engineering:heal-skill (skill) — for fixing existing skills
  • anthropics/skills — official Anthropic examples
  • agentskills.io — open Agent Skills spec

Call those directly when in doubt about format. skillify orchestrates your workflow — which repo, which conventions, which cross-references. Format expertise lives upstream.

Step 3 — Pick target repo

Load the user's sibling repo list from ${MAKERSKILLS_CONFIG:-$HOME/.config/makerskills}/skillify/repos.yaml if present. Otherwise default to makerskills (this repo). Example format:

# ~/.config/makerskills/skillify/repos.yaml
repos:
  - name: makerskills
    domain: Personal cross-cutting operator work
    path: ~/code/makerskills
  - name: marketingskills
    domain: Generic marketing tactics
    path: ~/code/marketingskills

Infer target if obvious from the skill's domain; ask if ambiguous.

Step 4 — Synthesize per sub-mode

from-chat:

  1. Read backward through this conversation. Look for a workflow repeated multiple times, a process re-explained, opinions restated, tooling/voice/output decisions.
  2. Identify the load-bearing pieces: trigger, steps, references, success shape, voice.
  3. Surface gaps that need clarification before scaffolding — ask 2–4 tight questions.
  4. Draft SKILL.md, citing chat moments inline ("Per your message about X…") so the user can verify.

from-dump:

  1. Parse the dump (Notion page, Slack thread, Loom transcript, teammate brief, exported ChatGPT conversation).
  2. Same synthesis logic as from-chat.
  3. Cite where in the dump each rule came from.

from-video:

  1. Take the URL or local path.
  2. Call watch-video <url> visual — get transcript + key visual moments + summary.
  3. Read outputs: <workdir>/transcript.txt, <workdir>/moments.md, <workdir>/summary.md.
  4. Synthesize: trigger (first 30s), steps (visual moments + matching transcript), tools used, decision points ("if X do Y" moments), success shape (last few seconds), voice cadence.
  5. Surface gaps — ambiguous moments needing clarification.
  6. Draft SKILL.md citing video moments by timestamp.
  7. Optionally save the source to second-brain as call-<slug>.md or note-<slug>.md.

Heuristic: recording >10 minutes = process probably too big for one skill. Suggest splitting before drafting.

from-scratch: Interactive Q&A:

  1. Name (kebab-case, verb-noun preferred — matches watch-video, read-book, paste)
  2. One-line purpose
  3. Trigger phrases (4–8)
  4. Initial reference files?
  5. Composes with which other skills?
Step 5 — Generate frontmatter
---
name: <kebab-case>
description: <rich, trigger-rich, ~2–4 sentences. Lead with "When you want to..." Include 4–8 trigger phrases in quotes. Differentiate from adjacent skills.>
metadata:
  version: 0.1.0
---

Description rules (load-bearing — agents route by description match):

  • Lead with the use case ("When you want to X…")
  • Include explicit trigger phrases
  • Differentiate from sibling skills
  • Mention key references the skill loads
  • Keep under ~500 characters (the Agent Skills spec hard limit is 1024; stricter hosts may reject longer ones)

For deeper description-writing guidance, consult compound-engineering:skill-creator.

Step 6 — Scaffold the directory
<target-repo>/skills/<name>/
├── SKILL.md
└── references/
    └── ...

Body follows existing skills' pattern (pm, decide, second-brain):

  • # /<name> — <one-line purpose>
  • Numbered ## Step N — <phase> sections
  • Composes-with cross-references
  • Quality notes at the end
Step 7 — Update README, commit, push

Append to target repo's README skill table:

| [`<name>`](./skills/<name>/SKILL.md) | <one-line purpose> |

Commit + push. Report new skill path, commit hash, and reminder that /plugin install or symlink may need a refresh.

Step 8 — Offer follow-ups
  • "Flesh out a specific Step now, or come back to it?"
  • "Run through compound-engineering:heal-skill for a quality pass?"
  • "Should this compose with [adjacent skill]?"

Mode: ADAPT

Port an external skill (GitHub URL, agentskills.io, local disk, or pasted SKILL.md) into your namespace.

Step 1 — Fetch the source

Accept:

  • GitHub URL to a SKILL.md or repo (https://github.com/<owner>/<repo> or full path to SKILL.md)
  • agentskills.io URL or skills.sh URL
  • Local path to an existing skill on disk (other installed plugins, e.g. ~/.claude/plugins/ in Claude Code, ~/.agents/skills/ or ~/.codex/skills/ elsewhere)
  • Pasted SKILL.md content
# GitHub repo: clone shallow
git clone --depth 1 <url> /tmp/skillify-adapt-<short-id>/
# OR fetch a single file
gh api -H "Accept: application/vnd.github.raw" repos/<owner>/<repo>/contents/SKILL.md > /tmp/adapt-source.md

Capture the commit SHA so attribution can point at a stable revision.

Step 2 — Analyze + classify

Read source SKILL.md + any references/ it ships. Classify into three buckets per references/adapt-buckets.md:

Bucket What Example
Keep verbatim Format, schema, mechanic, scripts, frameworks Question banks, ffmpeg flags, regex patterns, JSON schemas
Adapt Tool defaults, paths, voice, naming, opinions Their video tool → your watch-video, their kanban → your pm, their voice → your voice
Add Cross-references to your existing skills, composition notes, your conventions "Composes with decide," "Saves to second-brain raw/," "Uses MLX-Whisper local"

Output classification as a table for approval before writing anything. Don't silently rewrite — surface the changes.

Step 3 — License check

Read the source's LICENSE. Per references/adapt-license-check.md:

License Action
MIT / Apache-2.0 / BSD / ISC / CC0 ✅ Green — proceed
MPL-2.0 / LGPL 🟡 Yellow — adapt OK; warn about file-level reciprocity
GPL-2.0 / GPL-3.0 / AGPL ❌ Red — contagion risk. Surface before proceeding.
Proprietary / no license ❌ Red — stop. No legal basis to copy.
Unclear 🟡 Yellow — ask, default to skip if uncertain

For permissive licenses, attribution is the only requirement — handled in Step 6.

Step 4 — Pick target repo

Same table as CREATE Step 3.

Step 5 — Rewrite

Keep verbatim: copy as-is; add <!-- from <source> --> marker if helpful.

Adapt:

  • Naming: rename to verb-noun if not (matches watch-video, read-book, paste)
  • Tool swaps: their generic kanban → pm, their video tool → watch-video, their note system → second-brain, their decision framework → decide
  • Voice: apply your voice rules — direct, conviction-coded. For social-adjacent skills, apply link-placement rule.
  • Paths: their ~/outputs/ → your ~/Documents/<skill>-<...>/ convention; their config → your references/ pattern
  • Names + context: generic examples → your portfolio context where the skill needs it

Add:

  • Cross-references to existing sibling skills
  • Composition notes (which other skills this calls or feeds)
  • Your conventions (frontmatter version, references/ subdir structure, BACKLOG entry if it spawns sub-ideas)
Step 6 — Attribution file

Write references/attribution.md:

# Attribution

- **Source**: <original SKILL.md URL>
- **Repository**: <repo URL>
- **Author**: <name + handle>
- **Commit SHA**: <SHA at time of adapt>
- **License**: <license name + URL>
- **Adapted**: <YYYY-MM-DD>

## What was kept verbatim
- ...

## What was adapted
- <old> → <new>

## What was added
- ...

## License compliance
<upstream LICENSE text if MIT/BSD/Apache requires it, OR reference where in this repo it lives>

## Upgrade path
Run `git ls-remote <repo-url> HEAD`. If SHA differs from above, re-run `/skillify <same-url>` for a 3-way merge.

For MIT / Apache / BSD, LICENSE text either gets copied into this file or the source LICENSE file gets copied to the skill dir.

Step 7 — Scaffold + commit

Same as CREATE Steps 6–7. Commit message: "Adapt <name> skill from <source-name>".

Step 8 — Report + offer follow-ups
  • Commit hash + new skill path
  • Show three-bucket classification one more time so the diff is clear
  • Offer:
    • "Flesh out the adaptations? Some defaults may still need your touch."
    • "Run compound-engineering:heal-skill for a QA pass?"
    • "Set up an upstream-check reminder via loopify?"

Mode: UPDATE

Improve existing skill(s) from learnings.

Step 1 — Confirm sub-mode
Sub-mode When
from-chat (default) Scan recent conversation for learnings, identify affected skill(s)
from-dump User provides a brief, feedback, transcript, postmortem
targeted User names the skill + change directly. Skip discovery.
usage Review recent runs of the named skill, identify gaps

Default when invoked mid-conversation with substantive recent activity: from-chat.

Step 2 — Extract learning(s)

For from-chat / from-dump / usage: look for change-worthy signals (full taxonomy in references/update-change-types.md):

  • Corrections — "no, don't do that anymore"
  • Validations — "yes that worked — bake it in"
  • New patterns — user just did an undocumented workflow; encode it
  • Voice / tone updates — like the spoken-aloud rule for slide-deck
  • Tool changes — switched defaults
  • Architectural decisions — naming conventions, file layout, frontmatter
  • Gaps — something the skill should have handled but didn't

Output: a clear list of N learnings, each phrased as a single change.

For targeted: skip extraction — user already named the change.

Step 3 — Identify affected skills

For each learning, search across all SKILL.md + references/ in the current repo (and optionally all sibling repos from your repos.yaml with --cross-repo):

grep -rln "<key terms>" ~/code/makerskills/skills/ --include="*.md"

# Across all sibling repos (list yours in $MAKERSKILLS_CONFIG/skillify/repos.yaml):
config="${MAKERSKILLS_CONFIG:-$HOME/.config/makerskills}/skillify/repos.yaml"
for raw in $(yq -r '.repos[].path' "$config"); do
  repo="${raw/#\~/$HOME}"  # expand leading ~ to $HOME so grep resolves the real path
  grep -rln "<terms>" "$repo/skills/" --include="*.md" 2>/dev/null
done

Classify by confidence:

Confidence What Action
High Direct keyword match + clearly same topic Propose change
Medium Adjacent topic — rule might apply Surface for explicit approval
Low Tangential — rule could be stretched Mention but don't propose

See references/update-propagation.md for the cross-skill propagation playbook.

Step 4 — Memory-vs-skill check

For each learning: is this skill-specific or a broader principle?

Type Where it goes
Skill-specific rule Edit the SKILL.md / references file directly
Cross-cutting principle feedback_<topic>.md in the memory store (agent memory, or ${MAKERSKILLS_MEMORY:-${MAKERSKILLS_CONFIG:-$HOME/.config/makerskills}/memory}/)
Both Write the memory file AND update the skill(s) that immediately apply

Example: "links go in first comments, not body" → applies to jab-hook AND is a broader social principle → both update jab-hook AND save feedback_social_link_placement.md.

Offer the memory write explicitly: "This looks like a principle, not just a skill rule. Save to memory as feedback_<slug>.md?"

Step 5 — Propose diffs per file

For each affected file, show change as before/after or unified diff:

### `skills/<skill>/SKILL.md` — proposed change

**Before** (lines NN–NN):
> <existing text>

**After**:
> <new text>

**Why**: <one-line rationale>

**Version bump**: 0.2.0 → 0.2.1 (PATCH — clarification)

**Approve / edit / skip?**

Per-file approval. Don't batch — small changes are easy to OK; bundling forces all-or-nothing.

See references/update-versioning.md for semver rules.

Step 6 — Apply approved changes
  1. Use Edit to apply the exact change
  2. Bump metadata.version per the suggested level
  3. If the change involves a rename, follow the cross-reference update pattern (grep all files, update all references)

Batch multiple file changes within one skill into a single commit.

Step 7 — Commit + push

Group by skill. Examples:

  • One-skill update: "slide-deck: emphasize spoken-aloud voice (write for the ear, not the page)"
  • Multi-skill propagation: "jab-hook, marketingskills:social: link placement (no inline URLs)"
  • Cross-repo: one commit per repo. Don't atomic-commit across repos.
Step 8 — Report

Show:

  • Learnings extracted
  • Skill(s) updated (with version bumps)
  • Memory files written
  • Whether compound-engineering:heal-skill would be a useful QA pass
  • Anything flagged but skipped
When NOT to use UPDATE mode

Don't add ceremony to surgical edits. If the user says "add this one bullet to X.md," just Edit. UPDATE mode earns its keep when:

  1. Multiple skills are affected by one learning (cross-skill propagation)
  2. Bulk extraction from a long session
  3. Memory-vs-skill decision is unclear (need explicit triage)
  4. Version discipline matters (about to commit and want sane semver)

For one-line updates with no cross-skill implications: just Edit.


Composes with

  • watch-video — load-bearing for CREATE / from-video. Visual-mode output (transcript + key visual moments + summary) is the input for skill synthesis. Always call in visual mode for process recordings — UI state matters as much as words.
  • second-brain — optionally capture source video/dump as raw/call-<slug>.md or raw/note-<slug>.md so the source artifact lives alongside the skill it produced.
  • toolify — sibling in the -ify trifecta. Use toolify when the goal is adding an integration/MCP/API, not authoring a skill.
  • loopify — sibling in the -ify trifecta. Use loopify for agent-loop setup rather than a skill.
  • compound-engineering:create-agent-skill (agent) — call for format and best-practices expertise
  • compound-engineering:skill-creator (skill) — deeper best-practices reference
  • compound-engineering:heal-skill (skill) — QA pass after any mode

Notes on quality

  • Cite the source. Whether chat, video, dump, external URL, or user-named learning — the SKILL.md body should reference where each decision came from. Makes revising easier.
  • Don't over-engineer v0.1. Ship a minimal SKILL.md + 1–2 references files. Iterate after first use. Most generated skills are over-scoped.
  • Verb-noun naming where possible (matches watch-video, read-book, paste). Single-word noun names are fine for distinctive concepts (decide, pm, paste, skillify).
  • Always reference Anthropic's official guidance for the schema — don't invent format conventions.
  • Write for any agent host, not just Claude Code:
    • Name capabilities, not tool names ("fetch the URL", not a host tool name like Claude Code's fetch tool; "the Typefully create-draft tool", not a raw MCP tool ID).
    • Memory lives in the agent's memory or ${MAKERSKILLS_MEMORY:-${MAKERSKILLS_CONFIG:-$HOME/.config/makerskills}/memory}/, never a hardcoded Claude Code memory path.
    • Read CLAUDE.md or AGENTS.md for user-owned schema/config docs.
    • Give Linux fallbacks for macOS-only commands (clipboard, open, MLX) — e.g. wl-copy/xclip, xdg-open, faster-whisper.
    • If a skill genuinely needs a Claude Code feature, say so in the body and give the other-hosts path (see loopify).
  • Attribution is non-negotiable for ADAPT mode. Every adapted skill ships with references/attribution.md.
  • License is a hard gate. Don't proceed on GPL/proprietary without explicit approval.
  • Per-file approval in UPDATE mode. Small changes are easy to OK; bundling forces all-or-nothing.
1---
2name: skillify
3description: When you want to create, adapt, or update an Agent Skill (Claude Code, Codex, Cursor, and other hosts) in one of your repos (listed in ~/.config/makerskills/skillify/repos.yaml; defaults to makerskills). Modes — CREATE (from chat, video, dump, or scratch) turns a workflow into a new skill. ADAPT ports an external skill with keep/adapt/add classification, license check, and attribution. UPDATE improves existing skills from learnings with cross-skill propagation, memory-vs-skill triage, and semver. Checks new skills for host portability. Triggers on "/skillify," "create a skill," "make this a skill," "skill from this chat," "adapt this skill," "port this skill," "fork this skill," "update X skill," "apply this to the relevant skills," "propagate this learning," "improve [skill]," "fix [skill]." Part of the -ify trifecta (skillify / toolify / loopify).
4metadata:
5 version: 0.2.1
6---
7 
8# /skillify — Create, adapt, or update a skill
9 
10One skill, three modes. Routes automatically to the right one based on input signal.
11 
12Consolidates and replaces the prior `create-skill`, `adapt-skill`, and `update-skill` (all merged as of v0.2.0 for vocabulary-moat consistency with the `-ify` trifecta).
13 
14## Step 0 — Detect mode
15 
16Route by signal:
17 
18| Signal | Mode |
19|---|---|
20| Invoked mid-conversation with substantive recent workflow discussion | **CREATE / from-chat** (default) |
21| `/skillify from-video <url>` OR `/skillify` + a video URL | **CREATE / from-video** |
22| `/skillify from-dump` + pasted brief/transcript/notes | **CREATE / from-dump** |
23| `/skillify from-scratch <name>` OR "make a new skill called X" with no context | **CREATE / from-scratch** |
24| `/skillify <github-url>` OR "adapt this skill" / "port this skill" / "fork this skill" + external source | **ADAPT** |
25| `/skillify <existing-skill> <change>` OR "update X skill" / "propagate this learning" | **UPDATE / targeted** |
26| `/skillify update` (mid-conversation) | **UPDATE / from-chat** — scan recent chat for learnings |
27| `/skillify usage <skill>` | **UPDATE / usage** — review recent runs, suggest improvements |
28 
29If ambiguous, ask before proceeding. Never guess between CREATE and ADAPT if there's an external URL involved.
30 
31---
32 
33## Mode: CREATE
34 
35Build a new skill from chat / video / dump / scratch.
36 
37### Step 1 — Confirm the input source
38 
39| Sub-mode | What |
40|---|---|
41| **from-chat** (default) | Extract the skill from the workflow discussed in this conversation. Most common case. |
42| **from-video** | User recorded a Loom / Zoom / screen-share. Calls `watch-video` in visual mode → transcript + key visual moments → SKILL.md. Best for visual/UI-heavy workflows. |
43| **from-dump** | User pastes a brief, prior conversation transcript, exported chat, or notes. |
44| **from-scratch** | Fresh idea with no source material — interactive Q&A. |
45 
46### Step 2 — Defer to Anthropic guidance for the schema
47 
48Don't reinvent SKILL.md format rules. For frontmatter, description-writing, references/ structure, and skill best practices:
49 
50- **`compound-engineering:create-agent-skill`** (agent) — expert guidance for creating + editing Claude Code skills
51- **`compound-engineering:skill-creator`** (skill) — deeper guide for effective skills
52- **`compound-engineering:heal-skill`** (skill) — for fixing existing skills
53- **[anthropics/skills](https://github.com/anthropics/skills)** — official Anthropic examples
54- **[agentskills.io](https://agentskills.io)** — open Agent Skills spec
55 
56Call those directly when in doubt about format. `skillify` orchestrates *your* workflow — which repo, which conventions, which cross-references. Format expertise lives upstream.
57 
58### Step 3 — Pick target repo
59 
60Load the user's sibling repo list from `${MAKERSKILLS_CONFIG:-$HOME/.config/makerskills}/skillify/repos.yaml` if present. Otherwise default to `makerskills` (this repo). Example format:
61 
62```yaml
63# ~/.config/makerskills/skillify/repos.yaml
64repos:
65 - name: makerskills
66 domain: Personal cross-cutting operator work
67 path: ~/code/makerskills
68 - name: marketingskills
69 domain: Generic marketing tactics
70 path: ~/code/marketingskills
71```
72 
73Infer target if obvious from the skill's domain; ask if ambiguous.
74 
75### Step 4 — Synthesize per sub-mode
76 
77**from-chat:**
781. Read backward through this conversation. Look for a workflow repeated multiple times, a process re-explained, opinions restated, tooling/voice/output decisions.
792. Identify the load-bearing pieces: trigger, steps, references, success shape, voice.
803. Surface gaps that need clarification before scaffolding — ask 2–4 tight questions.
814. Draft SKILL.md, citing chat moments inline ("Per your message about X…") so the user can verify.
82 
83**from-dump:**
841. Parse the dump (Notion page, Slack thread, Loom transcript, teammate brief, exported ChatGPT conversation).
852. Same synthesis logic as from-chat.
863. Cite where in the dump each rule came from.
87 
88**from-video:**
891. Take the URL or local path.
902. Call `watch-video <url> visual` — get transcript + key visual moments + summary.
913. Read outputs: `<workdir>/transcript.txt`, `<workdir>/moments.md`, `<workdir>/summary.md`.
924. Synthesize: trigger (first 30s), steps (visual moments + matching transcript), tools used, decision points ("if X do Y" moments), success shape (last few seconds), voice cadence.
935. Surface gaps — ambiguous moments needing clarification.
946. Draft SKILL.md citing video moments by timestamp.
957. Optionally save the source to `second-brain` as `call-<slug>.md` or `note-<slug>.md`.
96 
97Heuristic: recording >10 minutes = process probably too big for one skill. Suggest splitting before drafting.
98 
99**from-scratch:**
100Interactive Q&A:
1011. Name (kebab-case, verb-noun preferred — matches `watch-video`, `read-book`, `paste`)
1022. One-line purpose
1033. Trigger phrases (4–8)
1044. Initial reference files?
1055. Composes with which other skills?
106 
107### Step 5 — Generate frontmatter
108 
109```yaml
110---
111name: <kebab-case>
112description: <rich, trigger-rich, ~2–4 sentences. Lead with "When you want to..." Include 4–8 trigger phrases in quotes. Differentiate from adjacent skills.>
113metadata:
114 version: 0.1.0
115---
116```
117 
118Description rules (load-bearing — agents route by description match):
119- Lead with the use case ("When you want to X…")
120- Include explicit trigger phrases
121- Differentiate from sibling skills
122- Mention key references the skill loads
123- Keep under ~500 characters (the Agent Skills spec hard limit is 1024; stricter hosts may reject longer ones)
124 
125For deeper description-writing guidance, consult `compound-engineering:skill-creator`.
126 
127### Step 6 — Scaffold the directory
128 
129```
130<target-repo>/skills/<name>/
131├── SKILL.md
132└── references/
133 └── ...
134```
135 
136Body follows existing skills' pattern (`pm`, `decide`, `second-brain`):
137- `# /<name> — <one-line purpose>`
138- Numbered `## Step N — <phase>` sections
139- Composes-with cross-references
140- Quality notes at the end
141 
142### Step 7 — Update README, commit, push
143 
144Append to target repo's README skill table:
145 
146```markdown
147| [`<name>`](./skills/<name>/SKILL.md) | <one-line purpose> |
148```
149 
150Commit + push. Report new skill path, commit hash, and reminder that `/plugin install` or symlink may need a refresh.
151 
152### Step 8 — Offer follow-ups
153 
154- *"Flesh out a specific Step now, or come back to it?"*
155- *"Run through `compound-engineering:heal-skill` for a quality pass?"*
156- *"Should this compose with [adjacent skill]?"*
157 
158---
159 
160## Mode: ADAPT
161 
162Port an external skill (GitHub URL, agentskills.io, local disk, or pasted SKILL.md) into your namespace.
163 
164### Step 1 — Fetch the source
165 
166Accept:
167- **GitHub URL** to a SKILL.md or repo (`https://github.com/<owner>/<repo>` or full path to SKILL.md)
168- **agentskills.io URL** or **skills.sh URL**
169- **Local path** to an existing skill on disk (other installed plugins, e.g. `~/.claude/plugins/` in Claude Code, `~/.agents/skills/` or `~/.codex/skills/` elsewhere)
170- **Pasted SKILL.md content**
171 
172```bash
173# GitHub repo: clone shallow
174git clone --depth 1 <url> /tmp/skillify-adapt-<short-id>/
175# OR fetch a single file
176gh api -H "Accept: application/vnd.github.raw" repos/<owner>/<repo>/contents/SKILL.md > /tmp/adapt-source.md
177```
178 
179Capture the commit SHA so attribution can point at a stable revision.
180 
181### Step 2 — Analyze + classify
182 
183Read source SKILL.md + any `references/` it ships. Classify into three buckets per `references/adapt-buckets.md`:
184 
185| Bucket | What | Example |
186|---|---|---|
187| **Keep verbatim** | Format, schema, mechanic, scripts, frameworks | Question banks, ffmpeg flags, regex patterns, JSON schemas |
188| **Adapt** | Tool defaults, paths, voice, naming, opinions | Their video tool → your `watch-video`, their kanban → your `pm`, their voice → your voice |
189| **Add** | Cross-references to your existing skills, composition notes, your conventions | "Composes with `decide`," "Saves to `second-brain raw/`," "Uses MLX-Whisper local" |
190 
191Output classification as a table for approval before writing anything. Don't silently rewrite — surface the changes.
192 
193### Step 3 — License check
194 
195Read the source's LICENSE. Per `references/adapt-license-check.md`:
196 
197| License | Action |
198|---|---|
199| MIT / Apache-2.0 / BSD / ISC / CC0 | ✅ Green — proceed |
200| MPL-2.0 / LGPL | 🟡 Yellow — adapt OK; warn about file-level reciprocity |
201| GPL-2.0 / GPL-3.0 / AGPL | ❌ Red — contagion risk. Surface before proceeding. |
202| Proprietary / no license | ❌ Red — stop. No legal basis to copy. |
203| Unclear | 🟡 Yellow — ask, default to skip if uncertain |
204 
205For permissive licenses, attribution is the only requirement — handled in Step 6.
206 
207### Step 4 — Pick target repo
208 
209Same table as CREATE Step 3.
210 
211### Step 5 — Rewrite
212 
213**Keep verbatim**: copy as-is; add `<!-- from <source> -->` marker if helpful.
214 
215**Adapt:**
216- Naming: rename to verb-noun if not (matches `watch-video`, `read-book`, `paste`)
217- Tool swaps: their generic kanban → `pm`, their video tool → `watch-video`, their note system → `second-brain`, their decision framework → `decide`
218- Voice: apply your voice rules — direct, conviction-coded. For social-adjacent skills, apply link-placement rule.
219- Paths: their `~/outputs/` → your `~/Documents/<skill>-<...>/` convention; their config → your `references/` pattern
220- Names + context: generic examples → your portfolio context where the skill needs it
221 
222**Add:**
223- Cross-references to existing sibling skills
224- Composition notes (which other skills this calls or feeds)
225- Your conventions (frontmatter version, references/ subdir structure, BACKLOG entry if it spawns sub-ideas)
226 
227### Step 6 — Attribution file
228 
229Write `references/attribution.md`:
230 
231```markdown
232# Attribution
233 
234- **Source**: <original SKILL.md URL>
235- **Repository**: <repo URL>
236- **Author**: <name + handle>
237- **Commit SHA**: <SHA at time of adapt>
238- **License**: <license name + URL>
239- **Adapted**: <YYYY-MM-DD>
240 
241## What was kept verbatim
242- ...
243 
244## What was adapted
245- <old> → <new>
246 
247## What was added
248- ...
249 
250## License compliance
251<upstream LICENSE text if MIT/BSD/Apache requires it, OR reference where in this repo it lives>
252 
253## Upgrade path
254Run `git ls-remote <repo-url> HEAD`. If SHA differs from above, re-run `/skillify <same-url>` for a 3-way merge.
255```
256 
257For MIT / Apache / BSD, LICENSE text either gets copied into this file or the source LICENSE file gets copied to the skill dir.
258 
259### Step 7 — Scaffold + commit
260 
261Same as CREATE Steps 6–7. Commit message: `"Adapt <name> skill from <source-name>"`.
262 
263### Step 8 — Report + offer follow-ups
264 
265- Commit hash + new skill path
266- Show three-bucket classification one more time so the diff is clear
267- Offer:
268 - *"Flesh out the adaptations? Some defaults may still need your touch."*
269 - *"Run `compound-engineering:heal-skill` for a QA pass?"*
270 - *"Set up an upstream-check reminder via `loopify`?"*
271 
272---
273 
274## Mode: UPDATE
275 
276Improve existing skill(s) from learnings.
277 
278### Step 1 — Confirm sub-mode
279 
280| Sub-mode | When |
281|---|---|
282| **from-chat** (default) | Scan recent conversation for learnings, identify affected skill(s) |
283| **from-dump** | User provides a brief, feedback, transcript, postmortem |
284| **targeted** | User names the skill + change directly. Skip discovery. |
285| **usage** | Review recent runs of the named skill, identify gaps |
286 
287Default when invoked mid-conversation with substantive recent activity: **from-chat**.
288 
289### Step 2 — Extract learning(s)
290 
291For from-chat / from-dump / usage: look for change-worthy signals (full taxonomy in `references/update-change-types.md`):
292 
293- **Corrections** — "no, don't do that anymore"
294- **Validations** — "yes that worked — bake it in"
295- **New patterns** — user just did an undocumented workflow; encode it
296- **Voice / tone updates** — like the spoken-aloud rule for slide-deck
297- **Tool changes** — switched defaults
298- **Architectural decisions** — naming conventions, file layout, frontmatter
299- **Gaps** — something the skill should have handled but didn't
300 
301Output: a clear list of *N learnings*, each phrased as a single change.
302 
303For **targeted**: skip extraction — user already named the change.
304 
305### Step 3 — Identify affected skills
306 
307For each learning, search across all SKILL.md + references/ in the current repo (and optionally all sibling repos from your `repos.yaml` with `--cross-repo`):
308 
309```bash
310grep -rln "<key terms>" ~/code/makerskills/skills/ --include="*.md"
311 
312# Across all sibling repos (list yours in $MAKERSKILLS_CONFIG/skillify/repos.yaml):
313config="${MAKERSKILLS_CONFIG:-$HOME/.config/makerskills}/skillify/repos.yaml"
314for raw in $(yq -r '.repos[].path' "$config"); do
315 repo="${raw/#\~/$HOME}" # expand leading ~ to $HOME so grep resolves the real path
316 grep -rln "<terms>" "$repo/skills/" --include="*.md" 2>/dev/null
317done
318```
319 
320Classify by confidence:
321 
322| Confidence | What | Action |
323|---|---|---|
324| **High** | Direct keyword match + clearly same topic | Propose change |
325| **Medium** | Adjacent topic — rule *might* apply | Surface for explicit approval |
326| **Low** | Tangential — rule could be stretched | Mention but don't propose |
327 
328See `references/update-propagation.md` for the cross-skill propagation playbook.
329 
330### Step 4 — Memory-vs-skill check
331 
332For each learning: **is this skill-specific or a broader principle?**
333 
334| Type | Where it goes |
335|---|---|
336| Skill-specific rule | Edit the SKILL.md / references file directly |
337| Cross-cutting principle | `feedback_<topic>.md` in the memory store (agent memory, or `${MAKERSKILLS_MEMORY:-${MAKERSKILLS_CONFIG:-$HOME/.config/makerskills}/memory}/`) |
338| Both | Write the memory file AND update the skill(s) that immediately apply |
339 
340Example: *"links go in first comments, not body"* → applies to `jab-hook` AND is a broader social principle → both update jab-hook AND save `feedback_social_link_placement.md`.
341 
342Offer the memory write explicitly: *"This looks like a principle, not just a skill rule. Save to memory as `feedback_<slug>.md`?"*
343 
344### Step 5 — Propose diffs per file
345 
346For each affected file, show change as before/after or unified diff:
347 
348```markdown
349### `skills/<skill>/SKILL.md` — proposed change
350 
351**Before** (lines NN–NN):
352> <existing text>
353 
354**After**:
355> <new text>
356 
357**Why**: <one-line rationale>
358 
359**Version bump**: 0.2.0 → 0.2.1 (PATCH — clarification)
360 
361**Approve / edit / skip?**
362```
363 
364Per-file approval. Don't batch — small changes are easy to OK; bundling forces all-or-nothing.
365 
366See `references/update-versioning.md` for semver rules.
367 
368### Step 6 — Apply approved changes
369 
3701. Use `Edit` to apply the exact change
3712. Bump `metadata.version` per the suggested level
3723. If the change involves a rename, follow the cross-reference update pattern (grep all files, update all references)
373 
374Batch multiple file changes within one skill into a single commit.
375 
376### Step 7 — Commit + push
377 
378Group by skill. Examples:
379 
380- One-skill update: `"slide-deck: emphasize spoken-aloud voice (write for the ear, not the page)"`
381- Multi-skill propagation: `"jab-hook, marketingskills:social: link placement (no inline URLs)"`
382- Cross-repo: one commit per repo. Don't atomic-commit across repos.
383 
384### Step 8 — Report
385 
386Show:
387- Learnings extracted
388- Skill(s) updated (with version bumps)
389- Memory files written
390- Whether `compound-engineering:heal-skill` would be a useful QA pass
391- Anything flagged but skipped
392 
393### When NOT to use UPDATE mode
394 
395Don't add ceremony to surgical edits. If the user says "add this one bullet to X.md," just Edit. UPDATE mode earns its keep when:
396 
3971. **Multiple skills are affected** by one learning (cross-skill propagation)
3982. **Bulk extraction** from a long session
3993. **Memory-vs-skill decision** is unclear (need explicit triage)
4004. **Version discipline matters** (about to commit and want sane semver)
401 
402For one-line updates with no cross-skill implications: just Edit.
403 
404---
405 
406## Composes with
407 
408- **`watch-video`** — load-bearing for CREATE / from-video. Visual-mode output (transcript + key visual moments + summary) is the input for skill synthesis. Always call in `visual` mode for process recordings — UI state matters as much as words.
409- **`second-brain`** — optionally capture source video/dump as `raw/call-<slug>.md` or `raw/note-<slug>.md` so the source artifact lives alongside the skill it produced.
410- **`toolify`** — sibling in the `-ify` trifecta. Use `toolify` when the goal is adding an integration/MCP/API, not authoring a skill.
411- **`loopify`** — sibling in the `-ify` trifecta. Use `loopify` for agent-loop setup rather than a skill.
412- **`compound-engineering:create-agent-skill`** (agent) — call for format and best-practices expertise
413- **`compound-engineering:skill-creator`** (skill) — deeper best-practices reference
414- **`compound-engineering:heal-skill`** (skill) — QA pass after any mode
415 
416## Notes on quality
417 
418- **Cite the source.** Whether chat, video, dump, external URL, or user-named learning — the SKILL.md body should reference where each decision came from. Makes revising easier.
419- **Don't over-engineer v0.1.** Ship a minimal SKILL.md + 1–2 references files. Iterate after first use. Most generated skills are over-scoped.
420- **Verb-noun naming** where possible (matches `watch-video`, `read-book`, `paste`). Single-word noun names are fine for distinctive concepts (`decide`, `pm`, `paste`, `skillify`).
421- **Always reference Anthropic's official guidance** for the schema — don't invent format conventions.
422- **Write for any agent host**, not just Claude Code:
423 - Name capabilities, not tool names ("fetch the URL", not a host tool name like Claude Code's fetch tool; "the Typefully create-draft tool", not a raw MCP tool ID).
424 - Memory lives in the agent's memory or `${MAKERSKILLS_MEMORY:-${MAKERSKILLS_CONFIG:-$HOME/.config/makerskills}/memory}/`, never a hardcoded Claude Code memory path.
425 - Read `CLAUDE.md` **or** `AGENTS.md` for user-owned schema/config docs.
426 - Give Linux fallbacks for macOS-only commands (clipboard, `open`, MLX) — e.g. `wl-copy`/`xclip`, `xdg-open`, faster-whisper.
427 - If a skill genuinely needs a Claude Code feature, say so in the body and give the other-hosts path (see loopify).
428- **Attribution is non-negotiable** for ADAPT mode. Every adapted skill ships with `references/attribution.md`.
429- **License is a hard gate.** Don't proceed on GPL/proprietary without explicit approval.
430- **Per-file approval in UPDATE mode.** Small changes are easy to OK; bundling forces all-or-nothing.
431 

Discussion

Alternatives

Browser Automation SkillWeb browser automation with AI-optimized snapshots for claude-flow agentsCoding · MITDeepevalDeepEval evaluation workflow for AI agents and LLM applications. TRIGGER when the user wants to evaluate or improve an AI agent, tool-using workflow, multi-turn chatbot, RAG pipeline, or LLM app; add evals; generate datasets or goldens; use deepeval generate; use deepeval test run; send results to Confident AI; monitor production; run online evals; inspect traces; or iterate on prompts, tools, retrieval, or agent behavior from eval failures. AI agents are the primary use case. Covers Python SDK, pytest eval suites, CLI generation, traced evals, Confident AI reporting, and agent-driven improvement loops. DO NOT TRIGGER for unrelated generic pytest, non-AI test setup, or non-DeepEval observability work unless the user asks to compare or migrate to DeepEval; for instrumenting an app with DeepEval tracing, @observe, or framework integrations (use the `deepeval-tracing` skill); or for raw OpenTelemetry / OTLP export without the deepeval package (use the `deepeval-otel` skill).Business & ops · Apache-2.0Dev browserBrowser automation with persistent named pages via the dev-browser CLI. Use when users ask to navigate websites, fill forms, take screenshots, extract web data, test web apps, log into sites, or automate browser workflows. Trigger phrases include "go to [url]", "click on", "fill out the form", "take a screenshot", "scrape", "automate", "test the website", "log into", "open the browser", or any browser interaction request.Business & ops · MITTurn into appTurn visible project context, a proven thread, skill, or workflow into a runnable Agent-Native app with simple buttons, visible agent steps, preview, and deployment handoff. Use when a user invokes `/turn-into-app` or asks to make a workflow into an app, including from Claude or ChatGPT on the web, including when the source is a spreadsheet link or upload.Business & ops · MIT