Release readiness
Skill Dokuganrryu/ai-agent-skills-and-subagents/skills/release-readiness
Portable AI agent skills and specialist subagents for prompt enhancement, workspace resume, source-grounded research, and release readiness.
npx -y skills add Dokuganrryu/ai-agent-skills-and-subagents --skill release-readinessAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use when preparing, auditing, or unblocking a software release, package, final gate, handoff, release notes, changelog, CI/test failure, or docs checklist needed for shipping. Also use when the user says release-ready, business-ready, final ZIP, final package, publish, ship, technician handoff, customer handoff, or release blockers.
SKILL.md
2.9 KB, as published. Nobody here has run it
Release Readiness
Use this skill to make a release or handoff trustworthy with the least ceremony.
Fit Check
Use for:
- Release blockers, final gates, package scripts, publish folders, handoff docs, changelogs, release notes, and "is this ready to ship?"
- CI/build/test failures that block release.
- Focused read-only audits of a release-critical workflow path.
Do not use for broad architecture redesign, generic code review, or product strategy. For PR review, prefer the existing review, brooks-review, or GitHub CI skills when they fit.
Workflow
- Pin the release target: repo, branch, package/output, intended user, and done-when.
- Inspect local evidence first:
git status, latest commits, release scripts, CI config, test commands, release docs/checklists, changelog/release notes, and package output paths. - Separate blockers from polish. A blocker must be able to ship a broken/wrong artifact, hide a failing test, mislead the handoff, or cause unsafe runtime behavior.
- For package or handoff risk, spawn the
release-gate-auditorcustom agent when subagents are useful. - For one specific runtime/workflow path, spawn the
workflow-slice-mappercustom agent when subagents are useful. - For CI/build/test/log failures, spawn the
failure-log-triagercustom agent when subagents are useful. - Make edits only if the user asked for fixes. Keep them surgical and tied to the release blocker.
- Verify against the release done-when with the repo's own commands first. If something cannot be verified, name the exact missing evidence.
Output
Keep the final answer tight:
Blockers: release-blocking issues only, with file/line or command evidence.Fixed: what changed, if edits were requested.Verified: commands/checks run and what they proved.Still unverified: missing external artifacts, protected builds, credentials, customer-machine rehearsal, or CI that was not accessible.Next action: the single next release decision or command.
Common Traps
- Do not call a release ready because source builds locally if the actual packaged artifact, final ZIP, installer, or handoff path is what the user ships.
- Do not rerun the same failing test loop without extracting the failure signature and changing one variable.
- Do not expand a release audit into a rewrite. If architecture risk appears, report the smallest release-safe slice and park larger cleanup.
- Do not overwrite changelogs or release notes with generic summaries. Use actual commits, changed files, fixed blockers, and verified commands.