Write SKILL.md

Write a procedure, not an essay

Turn domain knowledge into ordered actions that an agent can execute, observe, and revise instead of vague declarations.

A skill should change how the agent works. “Follow release best practices” doesn’t change anything. The agent already thinks it’s following best practices.

Write actions instead.

The critical path as steps

For release readiness, the path looks like this. First the agent reads the project’s own instructions and checks the repository state. Then it finds the validation commands the project documents. It runs the ones that don’t mutate anything, keeps the results, reviews the release metadata, sorts what it found into blockers and warnings, and writes the report.

Every step has something you can observe. Either the command ran or it didn’t. Either the report has a Tests line or it doesn’t.

Give it a default path

Don’t offer six equivalent tools and ask the agent to choose. Choice costs tokens and produces inconsistent runs.

Use the repository’s own scripts first. If the project has npm run test:ci, run that, not a hand-rolled jest invocation. If no test command is documented, the skill reports the gap. It does not invent a test setup in the middle of a preflight.

Concrete but not hard-coded

There’s a tension here. “Run npm test” is concrete, but it fails on a Go project. “Run the tests” is portable, but vague.

The middle ground: “Read the project’s documented test command, then run it.” That’s specific about the action and generic about the ecosystem. The agent knows to look in package.json, Makefile, AGENTS.md, or wherever the project keeps it.

The skeleton

Here’s what goes in SKILL.md under the frontmatter:

## Workflow

1. Read repository instructions and release documentation.
2. Inspect status, branch, and recent release metadata.
3. Discover the project's documented validation commands.
4. Run non-mutating checks and preserve their results.
5. Review version, changelog, artifacts, and known blockers.
6. Write the readiness report using the bundled template.

Six steps. Each starts with a verb the agent can act on.

Test every verb

Now go through the list and ask three questions about each line. Can the agent know what to inspect? Does it know what success looks like? Does it know what to do when the step fails?

Step 4 is a good example. “Run non-mutating checks” is only actionable if step 3 told the agent which checks are non-mutating. If a project’s npm run build writes to dist/, is that mutating? You need to decide and say so.

Replace any sentence that only sounds responsible. “Be thorough” and “use good judgment” are the two I delete most often. They cost context and buy nothing.

Lesson completed