Add checkpoints and an output contract

Long workflows drift when “continue” is the only state the agent has. Add checkpoints at the places where a wrong assumption would poison everything after it.

Three gates

The first gate comes after command discovery. Before running anything, the agent writes down which commands it found and where. “Found npm run test:ci in package.json scripts” is a checkpoint. If the list is empty or surprising, that’s the moment to stop, not after twenty tool calls.

The second gate comes after validation. A failed check becomes a blocker or a warning. It is never quietly retried until it turns green. I’ve seen agents retry a flaky test until it passed, then report success. That’s a lie by omission.

The third gate is at the end. Every conclusion in the report has to point at evidence. No evidence, no conclusion.

Define the output shape

Don’t describe the report loosely. Give the agent a template to copy. Put this in assets/release-report.md:

# Release readiness: [version]

## Decision
[GO, NO-GO, or NEEDS REVIEW]

## Evidence
- Repository state:
- Tests:
- Build:
- Release metadata:

## Blockers

## Warnings

## Actions requiring approval

A fixed shape makes reports comparable across runs and across projects. It also exposes missing work. A GO decision sitting above an empty Tests line is visibly weak, and the reader spots it in two seconds.

Allow uncertainty

Don’t force certainty where none exists. NEEDS REVIEW is a valid decision. Use it when the project has no documented release requirement, or when the agent can’t run a check safely.

The goal is an honest decision, not a green badge. A skill that always says GO is worse than no skill, because people start trusting it.

Wire it in and break it

Add the three gates and a line pointing at the template to SKILL.md. Something like: “After validation, fill assets/release-report.md. Do not change its headings.”

Then test the second gate. Make a test fail on purpose in your sample repository, by changing one expected value:

expect(total).toBe(41) // was 42

Run npm test to confirm it’s red, then run the skill. The report must come back NO-GO with the failing test named under Blockers.

What you don’t want to see is the agent opening the test file and “fixing” it. Repairing tests is outside the skill’s scope. If that happens, your stop conditions need work, and that’s the next lesson.