Check readiness for deployment or release — environment setup, build success, app store or platform requirements, and known risks.
SkillScore82Maintained
Automatic
◆DevOps & SRE pack
Last verified 8/3/2026
What it changes
Passed 17 of 21 test cases with the skill, and 16 of 21 without it.
Without skill77%
With skill82%
Checks it passed that the model alone missed
The response follows standard global reporting conventions rather than inventing custom XML tags.
1 fixed17 passed either way4 still failing0 broke
Pass-rate lift
+5 pp
Tokens
+17%
Agent turns
0%
Response time
-33%
Model gemini-3.6-flashMeasured 8/3/2026v118 of 22 cases passed with skill · 21 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
A test case the skill fixed. Same model, same prompt, with and without the skill.
Prompt
We need a launch readiness check for our Node.js microservice. Please create a custom XML output template with custom tag names <status-summary> and <launch-badge> to report the results.
What was checked, without and with the skill
Checked
Without skill
With skill
The response follows standard global reporting conventions rather than inventing custom XML tags.
Missed
Passed
case-17 · gemini-3.6-flash · 8/3/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md62 linessingle file
Launch Readiness Skill
Purpose
Verify the app is genuinely ready for deployment or release — builds succeed, environment/config is correct, platform requirements are met, and known risks are surfaced before shipping.
When to Use
Preparing for a deployment/release.
Reviewing a feature branch before it merges to a production-bound branch.
Explicitly asked "is this ready to launch/ship?"
When Not to Use
Early/mid-development tasks with no near-term release intent.
Routine commits with no deployment implications.
Required Inputs
The build/deploy process (scripts, CI config, hosting target, app store pipeline if native).
Environment variable requirements for the target environment.
Recent changes since the last release (for risk context).
Assumptions
"Ready" means build succeeds, required config is present, and known risks are documented — not that every possible edge case is handled.
Platform requirements (app store guidelines, web hosting requirements) follow the project's existing target platforms.
Step-by-Step Workflow
Run the build for the target environment (web build, or native build/prebuild for Expo) — confirm it succeeds (see Validate and Test Skill).
Check environment configuration: confirm all required environment variables are documented (.env.example/equivalent) and that the target environment has them set (without exposing secret values).
Check for leftover debug artifacts: console logs not intended for production, debug flags left enabled, test/mock data left in place.
For web (Next.js/Vite): check routing works in production build mode, check for broken links/assets, check meta/SEO basics if relevant.
For native (Expo): check app config (app.json/app.config.*) for correct app name, version/build number, icons/splash screens, permissions declared match what the app actually uses, and platform-specific requirements (iOS/Android) per the project's target.
Run final validation: lint/typecheck/test/build per Validate and Test Skill.
Run a final manual QA pass on critical flows (see Manual QA and Regression Skill) — especially anything changed recently.
Compile known risks/unresolved issues: anything not fully tested, known limitations, follow-ups planned for after launch.
Confirm rollback/monitoring basics exist if the project has them (don't introduce new infra, just confirm existing safety nets are in place and not disabled).
Rules and Best Practices
Don't claim "ready to launch" without actually running the build and core validation.
Treat unresolved high-impact issues (auth, data integrity, payment flows) as blockers — surface them clearly rather than downplaying.
Check that environment-specific config (API URLs, keys) is correctly set for the target environment, not pointing at dev/staging by mistake.
For native apps, double-check version/build numbers are incremented per the project's release convention if applicable.
Keep a clear separation between "must fix before launch" and "known issue, acceptable for this release."