Windsurf + Aider targets, MCP server, and demo placement (#33)
Broadens both reach (more tools) and content types (an MCP server), continuing the multi-platform story. Windsurf + Aider: - build-exports.mjs gains two platforms: exports/windsurf/*.md (workspace rules, trigger: model_decision) and exports/aider/*.md (conventions for `aider --read`). Now 5 platforms (ChatGPT, Gemini, Cursor, Windsurf, Aider). - install.sh + bin/cli.mjs install both (windsurf -> .windsurf/rules, aider -> .aider/skills with a --read hint); generated README index is excluded from copies. - One-line windsurf-install.sh / aider-install.sh wrappers for parity. MCP server (new content type): - mcp/server.mjs — zero-dependency stdio MCP server exposing list_skills, search_skills, get_skill. Published as a second bin (pm-claude-skills-mcp). Logs to stderr; reads bundled skills/ at startup. mcp/README.md documents client config. Also: README hero "See it in action" demo placement (ready to swap in a GIF; recording guide in web/docs-assets/README.md), Works-With table + exports + install docs updated, CHANGELOG Unreleased. package.json files/bin updated. Claude-Session: https://claude.ai/code/session_016JWn5jRD5tcEFKrubjQ6Px Co-authored-by: Claude <noreply@anthropic.com>
This commit is contained in:
mohitagw15856
GitHub
@@ -0,0 +1,137 @@
|
||||
# Product Launch Checklist Skill
|
||||
|
||||
Never launch without checking everything. Generate a complete, role-assigned checklist covering pre-launch readiness, launch day execution, and post-launch monitoring.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Launch name** and planned launch date
|
||||
- **Launch tier** (1 = major product launch, 2 = significant feature release, 3 = incremental update)
|
||||
- **Team members and their roles** (engineering lead, PM, marketing, support, etc.)
|
||||
- **Feature description** (what is being launched)
|
||||
- **Rollback capability** (can this be feature-flagged or reverted quickly?)
|
||||
|
||||
## How to Use This Skill
|
||||
|
||||
Provide:
|
||||
- Launch name and date
|
||||
- Launch tier (1 = major, 2 = feature, 3 = incremental)
|
||||
- Team members and their roles
|
||||
|
||||
The skill generates a tiered checklist. Tier 3 launches use only the Essentials section. Tier 2 adds Marketing & Comms. Tier 1 uses all sections.
|
||||
|
||||
---
|
||||
|
||||
## Output Format
|
||||
|
||||
### Launch Checklist — [Feature/Product Name] — Target Date: [Date]
|
||||
|
||||
**Launch Tier:** [1 / 2 / 3]
|
||||
**Launch Owner:** [PM Name]
|
||||
**Engineering Lead:** [Name]
|
||||
**Go/No-Go Decision By:** [Date and time — typically 24 hours before launch]
|
||||
|
||||
---
|
||||
|
||||
### 🔧 PRE-LAUNCH — Engineering & Product (T-2 weeks)
|
||||
- [ ] Feature flag created and tested in staging
|
||||
- [ ] All acceptance criteria signed off by PM
|
||||
- [ ] Code reviewed and merged to main
|
||||
- [ ] QA sign-off completed (regression + new feature)
|
||||
- [ ] Performance testing completed (load, latency)
|
||||
- [ ] Security review completed (if data or auth changes)
|
||||
- [ ] Rollback procedure documented and tested
|
||||
- [ ] Monitoring and alerting configured
|
||||
- [ ] Error logging in place with correct severity levels
|
||||
- [ ] Database migrations tested on staging with production data volume
|
||||
|
||||
### 📢 PRE-LAUNCH — Marketing & Comms (T-1 week)
|
||||
- [ ] Blog post written, reviewed, and scheduled
|
||||
- [ ] In-app announcement or tooltip configured
|
||||
- [ ] Email campaign drafted and QA'd
|
||||
- [ ] Social media posts drafted and scheduled
|
||||
- [ ] Landing page or feature page live in staging
|
||||
- [ ] Press outreach sent (Tier 1 only)
|
||||
- [ ] Product Hunt / community posts prepared (Tier 1 only)
|
||||
|
||||
### 🎓 PRE-LAUNCH — Sales & Support (T-1 week)
|
||||
- [ ] Sales enablement one-pager completed
|
||||
- [ ] FAQ document shared with sales and support teams
|
||||
- [ ] Help centre articles written and published
|
||||
- [ ] Support team demo / training completed
|
||||
- [ ] Customer success team briefed on top accounts
|
||||
- [ ] Pricing updated (if applicable)
|
||||
- [ ] Contracts / ToS updated (if applicable)
|
||||
|
||||
### 📊 PRE-LAUNCH — Analytics (T-1 week)
|
||||
- [ ] Analytics events firing correctly in staging
|
||||
- [ ] Dashboard configured for launch metrics
|
||||
- [ ] Baseline metrics documented
|
||||
- [ ] Success criteria documented and shared with team
|
||||
- [ ] A/B test configured (if applicable)
|
||||
|
||||
---
|
||||
|
||||
### ✅ GO / NO-GO DECISION — T-24 hours
|
||||
|
||||
| Criteria | Status | Owner |
|
||||
|---|---|---|
|
||||
| All critical bugs resolved | 🟢 / 🔴 | Eng Lead |
|
||||
| QA sign-off complete | 🟢 / 🔴 | QA |
|
||||
| Rollback tested | 🟢 / 🔴 | Eng Lead |
|
||||
| Help centre articles live | 🟢 / 🔴 | Support |
|
||||
| Monitoring active | 🟢 / 🔴 | Eng Lead |
|
||||
| PM sign-off | 🟢 / 🔴 | PM |
|
||||
|
||||
**Go / No-Go Decision:** [GO / NO-GO]
|
||||
**Decision Owner:** [PM + Eng Lead jointly]
|
||||
|
||||
---
|
||||
|
||||
### 🚀 LAUNCH DAY
|
||||
- [ ] Feature flag enabled for [X%] of users (start low — 5–10%)
|
||||
- [ ] Launch confirmed in team Slack/channel
|
||||
- [ ] Metrics dashboard open and being monitored
|
||||
- [ ] Error rate checked at T+15 min, T+1 hr, T+4 hr
|
||||
- [ ] Blog post published / email sent
|
||||
- [ ] Social posts live
|
||||
- [ ] Support team on standby for first 4 hours
|
||||
- [ ] PM available and reachable all day
|
||||
- [ ] Feature flag expanded to 50% if T+2hr checks pass
|
||||
- [ ] Feature flag expanded to 100% if T+4hr checks pass
|
||||
|
||||
---
|
||||
|
||||
### 📈 POST-LAUNCH (D+7, D+30)
|
||||
- [ ] D+7 metrics review: adoption, errors, support tickets
|
||||
- [ ] D+7 customer feedback synthesised
|
||||
- [ ] Retrospective scheduled
|
||||
- [ ] Learnings documented
|
||||
- [ ] D+30 success metrics reviewed against targets
|
||||
- [ ] Feature flag removed from codebase (clean up)
|
||||
- [ ] Follow-up features added to backlog based on feedback
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Launch tier confirmed before generating checklist (scope determines depth)
|
||||
- [ ] Go/No-Go decision has a named owner and a specific decision time
|
||||
- [ ] Rollback procedure is documented and tested (not just planned)
|
||||
- [ ] Feature flag expansion is staged (5% → 50% → 100%), not all-at-once
|
||||
- [ ] Post-launch retrospective is scheduled at launch time
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not apply a Tier 1 checklist to an incremental update — tier the launch appropriately before generating the checklist
|
||||
- [ ] Do not launch on a Friday without confirmed weekend engineering coverage
|
||||
- [ ] Do not leave the Go/No-Go decision owner as "the team" — it must be a named individual
|
||||
- [ ] Do not skip the rollback plan for Tier 1 and 2 launches — know the revert time before going live
|
||||
- [ ] Do not close the launch without scheduling the post-launch retrospective — it must be booked at launch time, not after
|
||||
|
||||
## Guidelines
|
||||
|
||||
- The Go/No-Go decision must have a named owner — "the team" is not an owner
|
||||
- Never launch on a Friday unless you have weekend engineering coverage
|
||||
- Recommend starting all launches at <10% traffic — even for simple features
|
||||
- Document rollback time: "We can revert this in X minutes" should be known before launch
|
||||
Reference in New Issue
Block a user