Release readiness review
Skill tuanductran/soulmap-ai/.claude/skills/release-readiness-review
Review whether SoulMap AI is ready to ship by checking docs, changelog, tests, packaging, and user-facing claims for release consistency.From its SKILL.md
npx -y skills add tuanductran/soulmap-ai --skill release-readiness-reviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 2 stars2 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.
SKILL.md
2.7 KB, as published. Nobody here has run it
Release readiness review
Use this skill before shipping notable changes to the repository.
This skill is for launch and release hygiene, not feature ideation.
Do not use this skill for
- Day-to-day code review or module-level changes, use
ai-prompt-engineering-safety-revieworoperations-and-safety-review - Identifying long-term gaps or improvement ideas, use
research-and-gap-analysis - Writing or updating docs, use
docs-and-api-writer
Mission
Check whether the repo tells a consistent, shippable story across:
- code
- docs
- tests
- changelog
- packaging
- user-facing claims
Primary sources
Always inspect:
README.mdCHANGELOG.mddocs/engineering/DEV.mddocs/engineering/TESTER.mddocs/engineering/API.mddocs/operations/OPERATIONS.mdtemplates/launch-readiness-checklist.md(internal-only, not shipped)- relevant tests under
tests/
What to check
Docs sync
Verify that newly added modules, workflows, or constraints are reflected in docs.
Changelog accuracy
Verify that CHANGELOG.md captures meaningful added, changed, or removed behavior.
Test coverage
Check whether important changes are protected by:
- unit or regression tests
- eval cases
- build or packaging checks
Packaging readiness
Confirm that the distribution artifact still matches what the repo claims to ship.
Public claims
Check whether README and public-facing docs make claims the implementation can support.
Workflow
- Inspect the changed files.
- Compare them against docs and release notes.
- Identify gaps that would confuse a user, tester, or maintainer.
- Fix the highest-signal gaps first.
- Leave a concise release-readiness summary.
Expected output
When reviewing, structure the result as:
Findings
List shipping blockers or inconsistencies first.
Fixes
Summarize what was updated to restore readiness.
Residual Risks
Call out anything still unverified, untested, or intentionally deferred.
Writing rules
- Prefer concrete release risks over vague quality statements.
- Keep the focus on what affects shipping confidence.
- Do not turn the review into a feature roadmap.
Definition of done
The repo should be:
- documented honestly
- changelog-consistent
- test-backed where it matters
- ready to package and hand off