create-skill
Skill293 starsChanged 10 days agoMITView on GitHub
Create a skill your org owns — scaffolded in this Egregore, protected from framework updates, shared with teammates via /save.
144 other projects use a version of this.
Adopted by
Most recently taken up by
- neomjs/neo-agent-skillstheir own version, first seen Nov 15, 2026
- shishtpal/SpiAgentHarnesstheir own version, first seen Nov 15, 2026
- shoodoow/kurutheir own version, first seen Nov 15, 2026
- CherryHQ/cherry-studiotheir own version, first seen Nov 15, 2026
- lancy69/skillstheir own version, first seen Nov 8, 2026
- niilohlin/skillstheir own version, first seen Nov 8, 2026
Used with
Projects with it also use review-bugbot, migrate-to-skills and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
0mlkrizzz655335vSkillreview-bugbot
缺陷导向代码审查。用 Bugbot 子代理找 bug。
Also in 5 projects that use this
32103210Skillmigrate-to-skills
Convert 'Applied intelligently' Cursor rules (.cursor/rules/*.mdc) and slash commands (.cursor/commands/*.md) to Agent Skills format (.cursor/skills/). Use when you want to migrate rules or commands to skills, convert .mdc rules to SKILL.md format, or consolidate commands into the skills directory.
Also in 8 projects that use this
32103210Skillupdate-cursor-settings
Modify Cursor/VSCode user settings in settings.json. Use when you want to change editor settings, preferences, configuration, themes, font size, tab size, format on save, auto save, keybindings, or any settings.json values.
Also in 8 projects that use this
PandelisZSkillupdate-cli-config
View and modify Cursor CLI configuration settings in ~/.cursor/cli-config.json. Use when the user wants to change CLI settings, configure permissions, switch approval mode, enable vim mode, toggle display options, configure sandbox, or manage any CLI preferences.
Also in 7 projects that use this
yawningwhaleAISkillbuild-premium-website
Build a premium, animated marketing website (React + Vite + Tailwind + GSAP) for any industry. Use when the user asks to "build a website", "make a landing page for [business]", "build a marketing site", or wants a high-end animated company website. Adapts color, copy, services, and signature animation to the industry.
Also in 6 projects that use this
yawningwhaleAISkillinstantly-campaign
Create a new Instantly cold-email campaign in the proven 5-email structure of the user's top-performing campaign (~16% reply rate). Use when the user wants to launch a new outbound campaign, write a cold email sequence, create an Instantly campaign, draft outreach for a new service or niche, or set up a sales sequence.
Also in 5 projects that use this
- +1 more from 32103210
Other versions144 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 144
- microsoft/vscode★ 195ksame name
- CherryHQ/cherry-studio★ 54ksame name
- videojs/video.js★ 40ksame name
- BuilderIO/agent-native★ 7.7ksame name
- stagewise-io/stagewise★ 6.8ksame name
- dotnet/skills★ 6.2ksame name
- xstongxue/best-skills★ 2.9ksame name
- Lilac-Labs/gini-agent★ 1.9ksame name
- Open-Curiosity/gini-agent★ 1.9ksame name
- mattmireles/gemma-tuner-multimodal★ 1.5ksame name
134 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository50 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- activitySkill
- announceSkill
- archiveSkill
- branchSkill
- checkupSkill
- commitSkill
- contributeSkill
- dark-modeSkill
- dashboardSkill
- deep-reflectSkill
- delete-userSkill
- emissarySkill
- envSkill
- handoffSkill
- harvestSkill
- ingest-corpusSkill
- ingest-notionSkill
- ingestSkill
- ingest-user-interviewSkill
- inviteSkill
- issueSkill
- meetingSkill
- meSkill
- noteSkill
- notion-connectSkill
- onboardingSkill
- prSkill
- pullSkill
- pushSkill
- questSkill
- recordsSkill
- reflectSkill
- review-prSkill
- saveSkill
- slack-connectSkill
- summonSkill
- sync-reposSkill
- telegram-connectSkill
- telemetrySkill
- testSkill
- the-spiralSkill
- tui-designSkill
- tutorialSkill
- updateSkill
- viewSkill
- visual-explainSkill
- wrapSkill
- preview-designSkill
The file
We split this skill into the rules it gives an agent
7 rules. 0 are common, 4 are distinctive, and 3 are very specific to this project.
0
Common
Most of the 134 edited versions we read keep these.
4
Distinctive
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 6
Create an org-owned skill.
- Very specific: line 18
Not this: installing someone else's published skill → find-skills · changing a framework skill's behavior → /contribute (upstream owns it)
- Distinctive: line 26
Must not collide with a framework skill: Check both the local tree and upstream when available:
- Distinctive: line 38
If the name exists locally or upstream, propose 2–3 alternatives and ask with a structured question when available and permitted in this …
- Distinctive: line 44
If the user gave only a name and no behavior, ask what the skill should do before scaffolding — a skill with an empty body helps nobody.
- Very specific: line 105
Add the name to owned_skills in egregore.json (create the array if absent).
- Distinctive: line 115
If it succeeds, replace the configuration:
“Common” is measured: kept by at least 6 in 10 of the 134 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Create an org-owned skill. Owned skills live in .claude/skills/<name>/ like
framework skills, but they belong to the org: /update never overwrites them,
and if upstream ever ships a skill with the same name, the org's version wins
and the collision is reported.
Arguments: an optional skill name and/or a description of what the skill should do.
When to invoke
User says: "create a skill", "make a skill for X", "I want a /foo command for
our team", "turn this workflow into a skill", /create-skill <name>
Not this: installing someone else's published skill → find-skills · changing
a framework skill's behavior → /contribute (upstream owns it)
Step 1: Name and scope
Derive a kebab-case name from the request. Rules:
- Lowercase letters, digits, hyphens only. No slashes, no leading dot.
- Must not collide with a framework skill. Check both the local tree and upstream when available:
NAME="<kebab-name>"
if [ -d ".claude/skills/$NAME" ]; then
echo "exists locally"
fi
git fetch upstream main --quiet 2>/dev/null || true
git ls-tree -d upstream/main ".claude/skills/$NAME" 2>/dev/null | grep -q . && echo "exists upstream"If the name exists locally or upstream, propose 2–3 alternatives and ask with a structured question when available and permitted in this session; otherwise ask in plain text instead of silently picking one. An org CAN deliberately own a name upstream also uses (their version then always wins), but that is an explicit choice — never a default.
If the user gave only a name and no behavior, ask what the skill should do before scaffolding — a skill with an empty body helps nobody.
Step 2: Scaffold
Write .claude/skills/$NAME/SKILL.md:
---
name: <name>
description: <one line — what it does and when an agent should reach for it>
---
<What this skill does, in 1–3 sentences.>
## When to invoke
<Describe the user intent that selects this skill, with example requests.>
<Route adjacent intents elsewhere when useful; free-form prose is valid.>
## Steps
1. <concrete step — commands in fenced bash blocks>
2. <...>Fill it with real content derived from the user's description — trigger
intent an agent can recognize, concrete steps, actual commands. Do not leave
placeholder-only invocation sections or require fixed routing labels. Follow
product-voice for any user-facing copy the skill emits.
Cross-runtime adapter (mandatory). Codex invokes skills as $<name> from
.codex/skills/, and Pi consumes the same tree — one adapter serves both.
Write .codex/skills/$NAME/SKILL.md:
---
name: <name>
description: '<same one line>'
canonical: .claude/skills/<name>/SKILL.md
---
<!-- org-owned skill adapter — created by /create-skill -->
# <name> (org skill)
This org-owned skill is defined once in `.claude/skills/<name>/SKILL.md`.
1. Read `.claude/skills/<name>/SKILL.md` for the full workflow.
2. Run any referenced `bin/` scripts directly from this shell.
3. Translate interactive choices to this runtime's question tooling when
available; otherwise render compact numbered choices with an `Other:`
option and wait for the user.The runtime installer only removes files it installed itself (hash-tracked), so this adapter survives Codex/Pi runtime upgrades. Without it, the skill exists for Claude Code teammates only — always write both files.
Step 3: Register ownership
Add the name to owned_skills in egregore.json (create the array if
absent). Use the chosen skill name as {name}, single-quoted in the command;
write any embedded single quote as '\'':
mkdir -p tmp
jq --arg n '{name}' '.owned_skills = ((.owned_skills // []) + [$n] | unique)' \
egregore.json > tmp/create-skill-config.jsonIf it succeeds, replace the configuration:
mv tmp/create-skill-config.json egregore.jsonThis is what makes the skill org-owned: /update runs
bin/restore-owned-skills.sh after every framework sync, which keeps every
listed skill at the org's committed version.
Step 4: Share it
Tell the user the skill is ready to try now (/<name> in Claude Code,
$<name> in Codex, /<name> in Pi), then run /save so it reaches the team —
teammates get it on /pull or their next session start. The skill directory,
the .codex/skills/ adapter, and the egregore.json change must all land in
the same PR, or the ownership guarantee ships half-finished.
Telemetry (fire-and-forget):
bash bin/telemetry.sh emit "command" '{"command":"create-skill"}' 2>/dev/null &Edge cases
| Scenario | Handling |
| Name collides with a framework skill | Propose alternatives; owning a colliding name is explicit opt-in only. |
| User wants to modify a framework skill | Route to /contribute — or, if they explicitly want an org-local fork, copy it under a NEW name, register ownership, and note the fork won't receive upstream improvements. |
Skill already in owned_skills | Editing an existing owned skill needs no re-registration — just edit and /save. |
No jq | Tell the user to add the name to owned_skills in egregore.json manually. |
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

