Shipping and launch
Use before any production deployment or release, when preparing to launch a feature, when validating release readiness, when a rollback plan is needed before shipping, or when a pre-launch gate is required before approving a deploy.From its SKILL.md
npx -y skills add aneja5/forge-skills --skill shipping-and-launchAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 3 stars3 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
4.0 KB, 867 tokens by cl100k_base, as published. Nobody here has run it
Shipping and Launch
Overview
A go/no-go gate before production. Six check domains. Any Critical finding is a hard blocker. Any Important finding must be explicitly accepted before proceeding. Rollback plan defined before deploy begins.
When to Use
- Before any production deployment
- Before tagging a release
- Before a significant feature goes live
/shipcommand invoked
When NOT to Use
- Local development or staging — this gate is for production
- Emergency hotfix in progress — run a compressed version of domains 1-3 only
Common Rationalizations
| Thought | Reality |
|---|---|
| "Tests pass, we're good to ship" | Tests don't check observability, infra config, or rollback plan |
| "We'll add monitoring after launch" | Monitoring must exist before launch to detect launch failures |
| "The rollback plan is obvious" | Obvious plans aren't written down — write it down |
| "Security review can happen next sprint" | Post-launch security reviews happen after breaches |
| "The README is good enough" | If someone can't deploy this without you, the README isn't good enough |
Red Flags
- No monitoring or alerting configured for the new surface area
- Rollback plan is "redeploy the previous version" with no specifics
- Environment variables not verified in production environment
- Database migrations not tested on a production-size data snapshot
- No CHANGELOG entry for a user-visible change
Six Check Domains
1. Code Quality
- Full test suite passes in CI
- Build clean — no lint errors, no type errors
- No TODO, FIXME, or debug logs committed
- No dead code or commented-out blocks
- Bundle size within acceptable range (if frontend)
2. Security
- All user inputs validated and sanitized
- No secrets in source code, logs, or error messages
- Authentication required before authorization before business logic
- Security headers configured (CSP, HSTS, X-Frame-Options if applicable)
- Dependency audit clean (
npm audit/pip audit/ equivalent)
3. Performance
- No N+1 queries introduced
- Database queries have appropriate indexes
- No synchronous blocking in async request paths
- Core Web Vitals within targets (if frontend)
- Load tested at expected peak volume (if significant new surface)
4. Observability
- Structured logging for all new error paths
- Metrics / traces in place for new endpoints or background jobs
- Alerts configured for error rate, latency, and resource usage
- Dashboards updated to include new surface area
5. Infrastructure
- Environment variables set in production environment (not just local)
- Database migrations tested — rollback migration available
- Rollback plan written and validated:
- What triggers a rollback?
- Who can execute it?
- What are the steps?
- What's the estimated time?
- Feature flags in place if a staged rollout is needed
6. Documentation
- README updated if install steps, config, or public interface changed
- CHANGELOG entry added (user-visible changes)
- ADR written if any architectural decision was made during this release
- API docs updated if external API changed
- On-call runbook updated for new failure modes
Go / No-Go Decision
After running all six domains:
GO — all Criticals clear, all Importants explicitly accepted with owner assigned.
NO-GO — any Critical finding unresolved.
State the decision explicitly: "GO — shipping T001-T005. Rollback plan: [specifics]."
Verification
- All six domains checked
- Each finding categorized (Critical / Important / OK)
- All Critical findings resolved before proceeding
- Rollback plan written with specific steps and trigger criteria
- Go/no-go decision stated explicitly
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 3 of the 12 instructions most ship operate skills give in 867 tokens
Counted across 779 of the 1,178 authors here whose files we hold, read 2026-08-07
- Document a rollback plan before deploymenthere, and in 41 of 779, across 22 files
- Update the changeloghere, and in 21 of 779, across 19 files
- Run the test suitein 20 of 779
- Create an annotated git tagin 20 of 779
- Clean up feature flags after full rolloutin 18 of 779, across 10 files
- Verify deployment health after launchin 18 of 779, across 10 files
- Test both feature flag statesin 17 of 779, across 9 files
- Verify the working tree is cleanin 17 of 779
- Make database migrations backward-compatiblein 16 of 779, across 8 files
- Set up error monitoring before launchhere, and in 15 of 779, across 7 files
- Monitor metrics at each rollout stagein 14 of 779, across 5 files
- Create a GitHub releasein 14 of 779
Said here and by no other author read
- resolve all critical findings before proceeding
- test database migrations on production data snapshot
- update on-call runbook for new failure modes
- categorize every finding as critical important or ok
- state the go decision explicitly with rollback specifics
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.