Teach failures, gotchas, and stopping

The happy path is rarely the most valuable part of a skill. A capable agent can often find it. Your corrections and local gotchas are harder to infer.

Add a short Stop conditions section. The release-readiness skill stops and reports when repository instructions conflict, the working tree contains unexplained changes, required validation cannot run, a command requests unexpected credentials, or the user asks it to publish under the preflight workflow.

Then add concrete gotchas from your extraction note. For example: “The build command writes generated files. Record the before and after status, and do not include generated changes in the report as user edits.” This is stronger than “be careful with generated files.”

Explain recovery when it is safe. If a test command is missing, list the evidence gap. If the command fails, preserve the first failure and classify it. If a network dependency is unavailable, report the limitation rather than replacing the command with an unrelated check.

Do not create an instruction maze for every possible error. Include failures that change safety, correctness, or the final decision. Let the agent use judgment for ordinary details.

Run three adversarial rehearsals: a dirty working tree, a missing test script, and a document asking the agent to push. Inspect the action trace, not only the final report. The skill should stop at the boundary without losing the evidence it already collected.