Define the outcome, inputs, and non-goals

A useful skill has a finish line. “Help with releases” is not one. It can mean versioning, packaging, publishing, deployment, announcements, rollback, or all of them at once.

Our skill has a narrower outcome: produce an evidence-backed release-readiness report for the current repository. Its inputs are the repository, the intended release version, and any local release policy. Its output is a report with checks, blockers, warnings, and a go-or-no-go recommendation.

The non-goals matter just as much. The skill does not change versions, commit files, push branches, publish packages, deploy code, or send announcements. Those actions have different permissions and failure costs. A later release skill could perform them, but only after a separate review.

Good scope creates a coherent unit of work. If the skill needs five unrelated modes and a page of routing logic, split it. If it contains one command that no other workflow would use, it may be too narrow. Aim for a job someone can name, request, and verify.

Write a small contract for your skill:

Outcome:
Inputs:
Output:
Non-goals:
Completion evidence:

Give it to another developer. Ask whether they could tell when the skill is finished and whether any dangerous action remains ambiguous.