---
name: kedarrio/launch-readiness
source: https://app.decimal.ai/s/kedarrio-launch-readiness@1/SKILL.md
source_sha256: 743e63af04f2
---

# 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
1. **Run the build** for the target environment (web build, or native build/prebuild for Expo) — confirm it succeeds (see Validate and Test Skill).
2. **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).
3. **Check for leftover debug artifacts**: console logs not intended for production, debug flags left enabled, test/mock data left in place.
4. **For web (Next.js/Vite)**: check routing works in production build mode, check for broken links/assets, check meta/SEO basics if relevant.
5. **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.
6. **Run final validation**: lint/typecheck/test/build per Validate and Test Skill.
7. **Run a final manual QA pass** on critical flows (see Manual QA and Regression Skill) — especially anything changed recently.
8. **Compile known risks/unresolved issues**: anything not fully tested, known limitations, follow-ups planned for after launch.
9. **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."

## Safety Checks
- Don't proceed with a release if the build fails or critical flows are broken — flag as a blocker.
- Don't disable failing checks/tests to force a "ready" status.
- Flag any change to deployment config, environment variables, or permissions as high-impact (see Risk Review Skill) before finalizing.

## Validation Checks
- Confirm production/release build succeeds.
- Confirm required environment variables are present for the target environment.
- Confirm no debug/test artifacts remain in production-bound code.
- Confirm critical flows pass manual QA.
- Confirm native app config (icons, permissions, version) is correct if applicable.

## Common Mistakes to Avoid
- Declaring "ready to launch" without running the build or tests.
- Missing environment variables required only in production.
- Leaving debug logs, test data, or feature flags in an unintended state.
- Treating a known critical bug as "minor" to avoid delaying launch.
- Forgetting platform-specific requirements (app icons, permissions, version bumps) for native releases.

## Output Rule
Do not invent a custom final response format for this skill. Follow the Global Agent Output and Reporting Skill. Only include skill-specific reporting details when necessary for understanding the completed work.