Release readiness

Release Readiness

Use this skill when the question is no longer "does it mostly work?" but "is it actually ready to ship or hand off?"

Goal

Increase delivery success rate by turning a nearly-finished change into a release decision with evidence.

Focus on:

1. scope clarity
2. validation completeness
3. dependency and config surprises
4. release notes and versioning
5. known risks and blockers
6. clear go / no-go judgment

Core Rules

1. Separate “works for me” from “ready to release”

Do not treat a passing local check as full release readiness.

Before release, verify:

• what exactly is being released
• what was actually validated
• what was not validated
• what assumptions still remain
• what user-facing change should be communicated

2. Define the release unit

Restate the release target clearly:

• branch
• tag
• package
• local tool
• script
• web app change
• repo handoff

If the unit is unclear, the release decision will also be unclear.

3. Check validation coverage, not just one green result

Review whether the release has enough evidence from:

• targeted tests
• nearby relevant tests
• browser/manual checks where needed
• build or packaging steps if relevant
• environment/config checks if relevant

A release can fail even when the main test path passed.

4. Surface hidden release risks

Look for release blockers such as:

• unvalidated config assumptions
• dependency drift
• missing assets or generated files
• stale docs/examples
• uncommitted or accidental local changes
• unclear upgrade or usage impact
• known bugs not called out

5. Require a concise release summary

Before release, be able to say:

• what changed
• why it changed
• how it was validated
• what still remains risky or unverified
• what users/reviewers should know

6. Prefer explicit go / no-go criteria

Do not end with a vague “probably fine.”

Conclude with one of:

• ready to release
• ready with caveats
• not ready yet

Minis-Specific Workflow

Shell checks

Use shell commands to:

• inspect git status and diff
• confirm expected files are present
• rerun final targeted validation
• inspect version files, manifests, or changelog-related files when present
• verify no temporary or debug residue remains

Browser checks

For web or HTML releases:

• verify the actual user-visible flow one more time
• confirm the intended route/page is the one being released
• check that the visible result matches the release summary

Lightweight release bias

Many Minis projects are scripts, tools, or compact web apps.

Bias toward:

• simple release notes
• simple versioning if needed
• explicit limitations instead of fake completeness
• small, honest release scope

Release Review Sequence

Use this order:

1. Restate the release unit and intended outcome.
2. Confirm the diff/scope matches that outcome.
3. Review validation coverage.
4. Check dependency/config/assets/docs surprises.
5. Identify known caveats or blockers.
6. Draft release/handoff summary.
7. Make a go / caveat / no-go decision.

Common Release Failures

Watch for:

• branch looks done but final test was never rerun
• browser-visible behavior changed but release notes do not mention it
• local env made things pass accidentally
• missing asset/config file outside the main code diff
• version/tag/release note not matching actual contents
• known limitation hidden instead of documented
• release includes scope creep the summary never mentions

Integration with Other Skills

• Use finishing-a-development-branch first to clean the branch before deciding release readiness.
• Use webapp-testing if user-visible behavior needs last-mile verification.
• Use performance-debugging if the release is functionally correct but too slow to be acceptable.
• Use agent-security-guard if the release involves secrets, production-affecting actions, uploads, or risky side effects.

Completion Checklist

Before calling the release ready, check:

• Is the release unit clearly named?
• Does the diff match the intended release scope?
• Was validation broad enough for the risk level?
• Are dependency/config surprises addressed?
• Are caveats documented honestly?
• Is there a clear release summary?
• Is there a clear go / no-go decision?

Response Template

• Release unit:
• Intended outcome:
• Validation coverage:
• Remaining caveats:
• Release summary:
• Readiness decision:
• Suggested next step:

Example Triggers

• "Is this branch actually ready to release?"
• "Do a release-readiness pass before I ship this."
• "Check whether this tool is ready for handoff."
• "Give me a go/no-go decision for this release."
• "Before tagging this version, review what could still go wrong."