mohitagw15856
05b6d799f0
Three more learnings from alirezarezvani/claude-skills, applied: 1. SkillCheck validator (scripts/skillcheck.mjs) — validates every SKILL.md against the authoring standard (frontmatter, name/folder match, trigger + produces clauses, required headings) plus tier referential integrity. Errors fail CI; --strict fails on warnings too. New skillcheck.yml workflow and a SkillCheck status badge in the README. Current: 0 errors / 14 advisory warnings across 172 skills. 2. Cursor export platform — build-exports.mjs now generates exports/cursor/<bundle>/<skill>/<skill>.mdc rule files. The PLATFORMS registry now supports per-skill filenames (file as a function). 3. Per-agent installers — scripts/install.sh unifies install for claude/hermes/codex/openclaw/cursor (--link, --target, --dry-run, --list). Curl-able one-liners codex-install.sh, openclaw-install.sh, and cursor-install.sh clone the library and install in a single command. README documents the one-line installs and Cursor exports; CHANGELOG and the authoring standard updated. Claude-Session: https://claude.ai/code/session_016JWn5jRD5tcEFKrubjQ6Px Co-authored-by: Claude <noreply@anthropic.com>
92 lines
3.8 KiB
Plaintext
92 lines
3.8 KiB
Plaintext
---
|
|
description: "Assesses pre-launch readiness across every function and produces an explicit Go / Conditional Go / No-Go recommendation. Use when preparing for any product or feature launch, running a pre-launch review, or determining whether a release is safe to ship. Produces a function-by-function readiness status, a ranked blockers list with owners and deadlines, a risk register, and a clearly reasoned launch recommendation."
|
|
globs:
|
|
alwaysApply: false
|
|
---
|
|
|
|
# Launch Readiness Skill
|
|
|
|
Ensure nothing falls through the cracks before launch by systematically checking readiness across every function — and producing a clear, evidenced go/no-go recommendation.
|
|
|
|
## Required Inputs
|
|
|
|
Ask the user for these if not provided:
|
|
- **Launch name and target date**
|
|
- **Launch tier** (Tier 1 = major launch / Tier 2 = significant feature / Tier 3 = incremental update)
|
|
- **Completed checklist items or self-assessment** (even partial is fine — we'll surface gaps)
|
|
- **Team and role names** (to assign owners to blockers)
|
|
|
|
## Readiness Checklist by Function
|
|
|
|
### Product & Engineering
|
|
- [ ] Feature complete against launch spec
|
|
- [ ] Performance benchmarks met
|
|
- [ ] Accessibility standards checked
|
|
- [ ] Edge cases documented and handled
|
|
- [ ] Rollback plan defined and tested
|
|
|
|
### Marketing & Comms
|
|
- [ ] Launch messaging approved
|
|
- [ ] Blog post / press release drafted
|
|
- [ ] Social content prepared
|
|
- [ ] Email campaigns scheduled
|
|
- [ ] Landing page live and tested
|
|
|
|
### Support & Success
|
|
- [ ] Support team trained on new feature
|
|
- [ ] FAQ and help docs published
|
|
- [ ] Escalation path defined for launch issues
|
|
- [ ] Customer success briefed (if enterprise)
|
|
|
|
### Sales & Partnerships
|
|
- [ ] Sales enablement materials ready
|
|
- [ ] Pricing confirmed and communicated
|
|
- [ ] Partner comms sent (if applicable)
|
|
|
|
### Data & Analytics
|
|
- [ ] Tracking events implemented and verified
|
|
- [ ] Launch metrics dashboard live
|
|
- [ ] Baseline metrics captured pre-launch
|
|
|
|
## Process
|
|
1. Review provided launch brief and checklist responses
|
|
2. Flag any incomplete items as blockers (must fix) or risks (monitor)
|
|
3. Assess overall readiness and produce go/no-go recommendation with rationale
|
|
4. If no-go, specify exactly what must be completed and by when
|
|
5. **Validate** — Confirm every blocker has a named owner and resolution deadline, and that the rollback plan is tested (not just documented)
|
|
|
|
## Output Structure
|
|
|
|
### Launch Readiness Assessment: [Feature/Product Name]
|
|
**Launch Date:** [date]
|
|
**Launch Tier:** [1 / 2 / 3]
|
|
**Overall Status:** ✅ Go / ⚠️ Conditional Go / 🛑 No-Go
|
|
|
|
**Blockers (must resolve before launch):**
|
|
- [item + owner + resolution required by]
|
|
|
|
**Risks (monitor closely):**
|
|
- [item + mitigation plan]
|
|
|
|
**Ready Areas:**
|
|
- [function]: ✅ Ready
|
|
|
|
**Recommendation:**
|
|
[Clear go/no-go with rationale — 3-5 sentences]
|
|
|
|
## Quality Checks
|
|
|
|
- [ ] Every blocker has a specific owner (not "the team") and a deadline
|
|
- [ ] Rollback plan is explicitly tested, not just written
|
|
- [ ] Analytics events are verified in staging, not just implemented
|
|
- [ ] Go/No-Go decision has a named decision-maker and a cut-off time
|
|
- [ ] At least one post-launch monitoring check is scheduled (e.g., T+2hr, T+24hr)
|
|
|
|
## Anti-Patterns
|
|
|
|
- [ ] Do not mark a function as "Ready" without evidence — green status must be backed by a completed checklist item, not an assumption
|
|
- [ ] Do not issue a Conditional Go without specifying exactly what conditions must be met and by when — vague conditions are not conditions
|
|
- [ ] Do not treat the rollback plan as complete unless it has been tested in staging, not just documented
|
|
- [ ] Do not assign blockers to "the team" — every blocker must have a single named owner or it will not be resolved before launch
|
|
- [ ] Do not skip the analytics verification step — unverified tracking events mean the launch will be invisible and cannot be evaluated
|