writing-great-skills
Reference for writing and editing skills well — the vocabulary and principles that make a skill predictable.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Reference for writing and editing skills well — the vocabulary and principles that make a skill predictable.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Recurring maintenance pass over automated dependency-bump PRs (Dependabot, Renovate, or similar) — rebase, relock, verify, and report what's ready to merge. Meant to be handed to a time-based loop or schedule, not run once.
Post-deploy verification loop — poll a rollout until every instance is on the new version and healthy, then run one smoke check against a real user path. Meant to be handed to a time-based loop with a timeout, not polled by hand.
Reference for designing agent loops — cycles of work that repeat until a stop condition is met. Covers the four loop shapes, writing completion criteria, carrying state and isolating work across cycles, and what running unattended still leaves on you.
Recurring check-in on a stack of dependent PRs — rebase children onto updated parents, surface CI state, flag anything waiting on a human-only gate, and report only what changed since last time. Meant to be handed to a time-based loop, not run once.
Pick the skill or flow that fits your situation. A router over the skills in this repo.
Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/PRD asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".
| name | writing-great-skills |
| description | Reference for writing and editing skills well — the vocabulary and principles that make a skill predictable. |
| disable-model-invocation | true |
A skill exists to squeeze determinism out of a stochastic system. Predictability — the agent walking the same process every run, not emitting the same output — is the root virtue; every lever below is in service of it.
Bold terms are defined in GLOSSARY.md; look them up there for the full meaning.
Two choices, each with its own cost:
disable-model-invocation, and write a model-facing description with rich trigger phrasing ("Use when the user wants…, mentions…").disable-model-invocation: true; the description turns human-facing — a one-line summary, trigger lists stripped.Choose model-invocation only when the agent must reach the skill on its own, or another skill must. If it only ever fires by hand, make it user-invoked and pay no context load.
When user-invoked skills pile up past what you can hold in your head, that accumulated cognitive load is cured by a router skill: one user-invoked skill that names the others and when to reach for each.
A model-invoked description does two jobs — state what the skill is, and list the branches that should trigger it. Every word adds context load, so a description earns even harder pruning than the body:
A skill is built from two content types — steps and reference — that blend freely: a skill can be all steps, all reference, or both. The core call is which to use and where each lands on the information hierarchy, a ladder ranked by how immediately the agent needs the material:
SKILL.md, the primary tier: what the agent does, in order. Each step closes on a completion criterion, the condition telling the agent the work is done. Make it checkable (can the agent tell done from not-done?) and, where it counts, exhaustive ("every modified model accounted for", not "produce a change list") — a vague criterion invites premature completion.SKILL.md, consulted on demand. Often a legitimately flat peer-set (every rule of a review on one rung) — a fine arrangement, not a smell. This skill is all reference.SKILL.md into a separate file, reached by a context pointer, loaded only when the pointer fires. (Runs from disclosed reference — a sibling file like GLOSSARY.md, still part of the skill — through fully external reference that lives outside the skill system and any skill can point at.)A demanding completion criterion drives thorough legwork — the digging the agent does inside the work — whether the skill has steps or not, since "every rule applied" binds flat reference just as "every step done" binds a sequence.
Push too little down and the top bloats; push too much and you bury material the agent actually needs. That tension is the whole call.
Progressive disclosure is the move down the ladder — out of SKILL.md into a linked file — so the top stays legible. Mechanics: a linked .md file in the skill folder, named for what it holds (this skill discloses its full definitions to GLOSSARY.md). Some skills are used in more than one way, and each distinct way is a branch — different runs taking different paths through the skill. Branching is the cleanest disclosure test: inline what every branch needs, and push behind a pointer what only some branches reach. A context pointer's wording, not its target, decides when and how reliably the agent reaches the material.
Where the ladder settles how far down a piece sits, co-location settles what sits beside it once there: keep a concept's definition, rules, and caveats under one heading rather than scattered, so reading one part pulls its neighbours in with it.
Granularity is how finely you divide skills, and each cut spends one of the two loads, so split only when the cut pays for itself. Two cuts:
Keep each meaning in a single source of truth: one authoritative home, so changing the behaviour is a one-place edit.
Check every line for relevance: does it still bear on what the skill does?
Then hunt no-ops sentence by sentence, not just line by line: run the no-op test on each sentence in isolation, and when one fails it, delete the whole sentence rather than shave words off it. Be aggressive — most prose that fails should go, not be reworded.
A leading word is a compact concept already living in the model's pretraining that the agent thinks with while running the skill (e.g. lesson, fog of war, tracer bullets). Repeated across the text (though not always — a strong leading word may only be needed once), it accrues a distributed definition and anchors a whole region of behaviour in the fewest tokens, by recruiting priors the model already holds.
It serves predictability twice. In the body it anchors execution: the agent reaches for the same behaviour every time the word shows up. In the description it anchors invocation: when the same word lives in your prompts, docs, and code, the agent links that shared language to the skill and fires it more reliably.
Hunt for chances to refactor skills onto leading words. A triad spelled out at three sites (duplication), a description spending a sentence to gesture at one idea — each is a passage begging to collapse into a single token. For example:
You win twice: fewer tokens, and a sharper hook for the agent to hang its thinking on. Assume every skill is carrying restatements that leading words retire — go find them.
Use these to diagnose issues the user is having with a skill.