Time to run the whole thing for real. Use a disposable repository or a safe copy of one you care about. Don’t use a production repository for the first run.

The full run

Start with the user request, word for word:

Review this repository for release readiness. Produce the report, but do not commit, push, publish, or deploy.

Confirm the skill activates. Then watch the trace. You should see the agent read the project’s policy, find the documented commands, run the checks, sort the results into evidence, open only the reference that matches the ecosystem, fill the template, and run the validator on the result.

If any of those steps is missing or out of order, note it. Don’t fix anything yet. Finish the run.

Break one thing

Now introduce a single failure. Remove the changelog entry for the target version, or make one test fail.

Run again. The report must change. The decision should move from GO to NO-GO or NEEDS REVIEW, and the reason must appear under Blockers.

If the decision stays GO, stop. Something in the instructions or the evidence gate is broken, and shipping the skill now means shipping a false sense of safety. Fix it, rerun both scenarios, then continue.

Hand it off

Give the skill to another person, or install it in a different agent host. Don’t explain anything out loud. Ask them to install it, run the activation matrix, complete one review, and tell you in their own words what the skill is allowed to do.

Write down every surprise. “I didn’t know where to put the folder.” “It activated when I asked about Docker.” “I thought it would push for me.” Each of those is a documentation or design bug. Portability means the procedure travels, not just the directory.

Maintain from evidence

Once the skill is in use, don’t add features. Fix what the runs show you.

a missed trigger: improve the description, then rerun the negative cases too
a repeated workflow mistake: improve the procedure or add a gotcha
the agent reinventing deterministic logic: consider a script
content that no longer changes outcomes: delete it

That last one is the hardest and the most important. Skills grow. Prune them.

The release note

Finish with a short note in the development repository:

release-readiness 1.0

Does: reviews a repository before release and writes an evidence-backed report.
Refuses: commit, push, publish, deploy, version bumps, announcements.
Requires: Git, local command execution, Node.js for the validator.
Evaluated: clean release, dirty tree with failing test, missing changelog policy.
Known limits: npm reference only; other ecosystems fall back to generic checks.
Next review: after the next three real releases.

You haven’t built a magic prompt. You’ve built a small operational system that can be inspected, tested, and improved. That’s what a skill is.

Finish and maintain the release-readiness skill