Authoring adept skills
Skill itaywol/adeptability/.adeptability/staging/.claude/skills/authoring-adept-skills
Cross-harness AI skill portability CLI. Author an agent skill once, sync it into Claude Code, Cursor, Copilot, Codex, OpenCode & 45+ AI coding agents. Safety scanner, content-hash drift detection. A package manager / dotfiles for AI coding agent skills.
npx -y skills add itaywol/adeptability --skill authoring-adept-skillsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 8 stars8 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Write a good, portable adept skill: pick the right activation, craft a triggering description, keep it scan-safe and within harness byte budgets. Apply when creating or editing a SKILL.md or running `adept skill add`.
SKILL.md
3.5 KB, as published. Nobody here has run it
Authoring a good adept skill
A skill is a directory <root>/skills/<id>/ with one SKILL.md (YAML frontmatter +
markdown body) and optional sidecars. adept renders it into every enabled harness, so
write it once, well, and harness-neutral.
Canonical SKILL.md format
---
id: pr-review # ^[a-z0-9](?:[a-z0-9-]{0,48}[a-z0-9])?$ — matches the directory name
description: Use before opening a PR. Tests, security, performance. # <= 280 chars
activation: agent # always | globs | agent | manual
globs: [] # REQUIRED when activation: globs (e.g. ["**/*.go"])
allowed-tools: [Read, Grep] # carried into Claude Code
targets: [] # empty = all enabled harnesses
tags: [review, quality]
---
# PR Review Checklist
- [ ] Tests added or updated
- [ ] No secrets in the diff
Validated against pkg/adeptschema/skill.schema.json on every load — adept sync fails
loudly on a malformed skill, so let it catch your mistakes.
Pick activation deliberately — this is the whole game
| activation | Fires when | Use for |
|---|---|---|
agent | The model decides from the description | Most skills. Procedures, checklists, how-tos. |
globs | A matching file is in context | Language/path-specific rules (**/*.go, **/*.tsx). |
always | Every request | Rare. Project-wide invariants only — costs budget on every turn. |
manual | Only when explicitly invoked | Heavy or destructive procedures you don't want auto-firing. |
The description is the trigger — write it like one
For activation: agent, the description is the only thing the model sees when deciding
whether to load the skill. Make it earn the load:
- Lead with when to apply, not what it is: "Use before opening a PR…" beats "A PR helper."
- Name concrete nouns the user will say (file types, commands, tools, error strings).
- One line, ≤ 280 chars. If you can't say when it applies in one line, the skill is too broad — split it.
Keep it portable and lean
- Harness-neutral body. Don't say "in Cursor, click…"; describe the behavior, not the UI.
- Budget-aware. Aggregator harnesses (Codex/Copilot) cap total bytes; a bloated skill
gets dropped first. Tighten prose; move long reference material into
references/sidecars. - Scan-safe. Installs run a safety scan. Avoid anything that reads like prompt injection,
exfiltrates secrets, or runs opaque remote code — it will flag (
criticalhard-blocks). - Sidecars (
scripts/,references/,assets/) ride along to harnesses that support them; keep the SKILL.md body self-sufficient for those that don't.
Loop
adept skill add my-skill --edit # scaffold + open $EDITOR
adept sync # render to every enabled harness
adept status && adept diff # confirm it landed clean
Run adept skill --help (and adept skill add --help) for the current flags and
subcommands — prefer it over memory; it never drifts. Edit canonical, adept sync, never
hand-edit rendered files. See [[using-adept]] for the
full CLI and [[adept-self-improve]] for turning a one-off lesson into a durable skill.