feat: 100 skills milestone — 7 new skills + quality improvements across all 93
New skills added: - teaching-lesson-plan: structured lesson plans for any subject/audience/setting - seo-content-brief: complete SEO briefs with intent, competitor gaps, and outline - media-pitch: story-first journalist pitches with angle development framework - change-management-plan: stakeholder analysis, comms strategy, adoption metrics - workshop-facilitation-guide: activity instructions, decision protocols, facilitator moves - sales-forecasting-model: pipeline model, scenario analysis, assumption log - tax-planning-checklist: year-end tax planning across income, pension, CGT, reliefs Quality improvements across all 93 existing skills: - Standardised description format: "Verb the thing. Use when X. Produces Y." - Added Required Inputs section to all skills missing it (prompts for missing info) - Added Quality Checks section to all skills missing it (specific, not generic) - Fixed broken multiline YAML descriptions - Removed non-standard frontmatter keys (tool_integration, metadata blocks) README updated to v6.0.0 with 100-skill count, new skill tables, and article series Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
@@ -1,13 +1,20 @@
|
||||
---
|
||||
name: launch-readiness
|
||||
description: Run a comprehensive pre-launch readiness assessment across all functions
|
||||
tool_integration: Notion, Jira, Slack
|
||||
description: "Run a comprehensive pre-launch readiness assessment across all functions. Use when asked to assess launch readiness, run a pre-launch review, create a go/no-go recommendation, or check if a product or feature is ready to ship. Produces a function-by-function readiness status, blockers list, risk register, and an explicit Go / Conditional Go / No-Go recommendation."
|
||||
---
|
||||
|
||||
# Launch Readiness Skill
|
||||
|
||||
## Purpose
|
||||
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
|
||||
@@ -15,7 +22,7 @@ Ensure nothing falls through the cracks before launch by systematically checking
|
||||
- [ ] Performance benchmarks met
|
||||
- [ ] Accessibility standards checked
|
||||
- [ ] Edge cases documented and handled
|
||||
- [ ] Rollback plan defined
|
||||
- [ ] Rollback plan defined and tested
|
||||
|
||||
### Marketing & Comms
|
||||
- [ ] Launch messaging approved
|
||||
@@ -45,11 +52,13 @@ Ensure nothing falls through the cracks before launch by systematically checking
|
||||
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 Format
|
||||
## 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):**
|
||||
@@ -63,3 +72,11 @@ Ensure nothing falls through the cracks before launch by systematically checking
|
||||
|
||||
**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)
|
||||
|
||||
Reference in New Issue
Block a user