fix: sync all skill updates and new skills into plugin bundles
- Synced 97 existing skill SKILL.md files from skills/ to their plugin bundle copies - Added 7 new skills to plugin bundles: - seo-content-brief, media-pitch -> pm-gtm - tax-planning-checklist -> pm-finance - change-management-plan -> pm-hr - sales-forecasting-model -> pm-sales - workshop-facilitation-guide -> pm-operations - teaching-lesson-plan -> pm-cross Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
mohitagw15856
@@ -1,12 +1,21 @@
|
||||
---
|
||||
name: ab-test-planner
|
||||
description: Designs statistically rigorous A/B tests for product features, UI changes, onboarding flows, and pricing experiments. Use when asked to set up an experiment, run an A/B test, calculate sample size, or interpret test results. Triggers on "A/B test", "experiment", "split test", "statistical significance", "sample size".
|
||||
description: "Design statistically rigorous A/B tests for product features, UI changes, onboarding flows, and pricing experiments. Use when asked to set up an experiment, design an A/B test, calculate sample size, or interpret test results. Produces a complete test plan with hypothesis, variant definitions, sample size, duration estimate, guardrail metrics, and a results interpretation guide."
|
||||
---
|
||||
|
||||
# A/B Test Planner Skill
|
||||
|
||||
Design experiments that produce trustworthy results — not just directional signals. Every test output includes hypothesis, success metrics, sample size, duration, and a results interpretation guide.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **What is being tested** (feature, UI change, copy, pricing, onboarding step)
|
||||
- **Hypothesis** (or ask to help formulate one)
|
||||
- **Primary metric** (conversion rate, click-through, completion rate, etc.)
|
||||
- **Baseline rate** and **minimum detectable effect** (MDE)
|
||||
- **Daily eligible users** (to calculate duration)
|
||||
|
||||
## Experiment Design Checklist
|
||||
|
||||
Before running any test, confirm:
|
||||
@@ -93,3 +102,12 @@ Flag if traffic is too low to reach significance in under 8 weeks — recommend
|
||||
- If user wants to test multiple variants, explain the multiple comparisons problem and recommend a Bonferroni correction or a Bayesian approach
|
||||
- If traffic is very low (<1,000 users/day), recommend qualitative alternatives: moderated testing, 5-second tests, or user interviews
|
||||
- Never approve a test with no guardrail metrics — always protect revenue, retention, or core engagement
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Hypothesis is directional (predicts a specific direction and magnitude, not "let's see")
|
||||
- [ ] Primary metric is singular (guardrail metrics are secondary)
|
||||
- [ ] Sample size is calculated from actual MDE and baseline (not guessed)
|
||||
- [ ] Test duration accounts for weekly seasonality (minimum 2 weeks)
|
||||
- [ ] Guardrail metrics are defined (at least one to protect revenue or core engagement)
|
||||
- [ ] Rollback trigger is specified with a concrete threshold
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: go-to-market-planner
|
||||
description: Builds go-to-market (GTM) plans for product launches, feature releases, and new market entries. Use when planning a product launch, writing a GTM strategy, defining launch tiers, or coordinating cross-functional launch activities. Triggers on "go-to-market", "GTM plan", "product launch plan", "launch strategy", "release plan".
|
||||
description: "Build a go-to-market plan for any product launch, feature release, or new market entry. Use when planning a product launch, writing a GTM strategy, defining launch tiers, or coordinating cross-functional launch activities. Produces a tiered GTM plan with messaging, cross-functional activity tracker, success metrics, and launch day checklist."
|
||||
---
|
||||
|
||||
# Go-to-Market Planner Skill
|
||||
@@ -106,9 +106,28 @@ Always confirm tier with the user before proceeding.
|
||||
|
||||
---
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Product or feature name**
|
||||
- **Target launch date**
|
||||
- **Launch tier** (Tier 1 / 2 / 3 — or describe scope and the skill will classify)
|
||||
- **Target audience** (who benefits and who it's NOT for)
|
||||
- **Key message** (what's the headline outcome for the customer)
|
||||
- **PM and launch owner**
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Never plan a Tier 1 launch without at least 8 weeks of lead time
|
||||
- Always include a "Not for" section — it prevents misdirected sales and support tickets
|
||||
- Recommend a soft launch to 5–10% of users before full rollout for any Tier 1 or 2 launch
|
||||
- Post-launch retrospective should be scheduled at launch planning time — don't leave it to chance
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Launch tier is confirmed and appropriate for scope
|
||||
- [ ] "Not for" section is included to prevent misdirected sales and support
|
||||
- [ ] Every function has at least one activity with a named owner and due date
|
||||
- [ ] Success metrics include a measurement window (30/60/90 days)
|
||||
- [ ] Rollback procedure is confirmed for Tier 1 and 2 launches
|
||||
- [ ] Post-launch retrospective is scheduled
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: product-launch-checklist
|
||||
description: Generates comprehensive pre-launch, launch day, and post-launch checklists for product releases. Use when preparing for a product launch, feature release, or major update. Triggers on "launch checklist", "pre-launch", "launch day", "release checklist", "ship checklist", "go-live checklist".
|
||||
description: "Generate a comprehensive pre-launch, launch day, and post-launch checklist for any product release. Use when preparing for a product launch, feature release, or major update. Produces a role-assigned, tiered checklist covering engineering readiness, marketing and comms, support, and post-launch monitoring."
|
||||
---
|
||||
|
||||
# Product Launch Checklist Skill
|
||||
@@ -109,6 +109,14 @@ The skill generates a tiered checklist. Tier 3 launches use only the Essentials
|
||||
|
||||
---
|
||||
|
||||
## 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
|
||||
|
||||
## Guidelines
|
||||
|
||||
- The Go/No-Go decision must have a named owner — "the team" is not an owner
|
||||
|
||||
@@ -1,19 +1,20 @@
|
||||
---
|
||||
name: retro-analysis
|
||||
description: Analyse sprint delivery data and produce a structured retrospective brief
|
||||
tool_integration: Jira, Miro
|
||||
description: "Analyse sprint delivery data and produce a structured retrospective brief. Use when asked to run a retrospective, analyse sprint data, prepare a retro brief, or turn sprint metrics into discussion prompts. Produces a data-grounded retrospective brief with completion stats, pattern analysis, Start/Stop/Continue prompts, and one concrete experiment for next sprint."
|
||||
---
|
||||
|
||||
# Retrospective Analysis Skill
|
||||
|
||||
## Purpose
|
||||
Generate a data-grounded retrospective brief that separates facts from feelings, so the team spends retro time on solutions rather than debating what happened.
|
||||
|
||||
## Required Inputs
|
||||
- Sprint tickets: planned vs. completed
|
||||
- Carry-over tickets and reasons
|
||||
- Tickets reopened after closing
|
||||
- Any incidents or unplanned work
|
||||
- Sprint velocity vs. historical average
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Sprint tickets: planned vs. completed**
|
||||
- **Carry-over tickets and reasons** (if known)
|
||||
- **Tickets reopened after closing** (quality signal)
|
||||
- **Any incidents or unplanned work** (scope creep signal)
|
||||
- **Sprint velocity vs. historical average** (trend context)
|
||||
|
||||
## Process
|
||||
1. Calculate: completion rate, carry-over rate, unplanned work percentage
|
||||
@@ -21,8 +22,9 @@ Generate a data-grounded retrospective brief that separates facts from feelings,
|
||||
3. Note any process or communication breakdowns visible in the data
|
||||
4. Prepare 3 "Start / Stop / Continue" prompts based on the data — not generic, specific to this sprint
|
||||
5. Suggest 1 concrete experiment for the next sprint based on the biggest friction point
|
||||
6. **Validate** — Confirm each prompt is specific to this sprint (not a recycled generic prompt), and that the recommended experiment is concrete and measurable
|
||||
|
||||
## Output Format
|
||||
## Output Structure
|
||||
|
||||
### Sprint [Number] Retrospective Brief
|
||||
|
||||
@@ -35,9 +37,17 @@ Generate a data-grounded retrospective brief that separates facts from feelings,
|
||||
[2-3 observations grounded in the numbers above]
|
||||
|
||||
**Discussion Prompts:**
|
||||
- Start: [specific prompt]
|
||||
- Stop: [specific prompt]
|
||||
- Continue: [specific prompt]
|
||||
- Start: [specific prompt based on this sprint's data]
|
||||
- Stop: [specific prompt based on this sprint's data]
|
||||
- Continue: [specific prompt based on this sprint's data]
|
||||
|
||||
**Suggested Experiment for Next Sprint:**
|
||||
[One concrete, testable process change]
|
||||
[One concrete, testable process change — with a specific success metric]
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Each Start/Stop/Continue prompt names a specific behaviour, not a vague category
|
||||
- [ ] The recommended experiment is testable in one sprint
|
||||
- [ ] Carry-over analysis identifies the ticket type or cause, not just the count
|
||||
- [ ] Data observations don't assign blame — they describe patterns
|
||||
- [ ] Velocity trend is mentioned in context (is this a one-off or a pattern?)
|
||||
|
||||
@@ -1,19 +1,20 @@
|
||||
---
|
||||
name: sprint-brief
|
||||
description: Generate a structured sprint brief from Jira sprint data and goals
|
||||
tool_integration: Jira, Slack
|
||||
description: "Generate a structured sprint brief from sprint data and goals. Use when asked to write a sprint brief, create a sprint summary, document sprint goals and scope, or produce a team-facing sprint overview. Produces a scannable brief with sprint goal, rationale, grouped work, critical path, risks, and definition of done."
|
||||
---
|
||||
|
||||
# Sprint Brief Skill
|
||||
|
||||
## Purpose
|
||||
Produce a clear, scannable sprint brief that every team member — engineer, designer, PM — can read in under three minutes and understand exactly what we're doing and why.
|
||||
|
||||
## Required Inputs
|
||||
- Sprint name and number
|
||||
- Sprint goal (1-2 sentences)
|
||||
- Ticket list with owners
|
||||
- Known dependencies or blockers
|
||||
- Carry-over items from previous sprint
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Sprint name and number**
|
||||
- **Sprint goal** (1-2 sentences — flag if too vague)
|
||||
- **Ticket list with owners** (or a description of the work)
|
||||
- **Known dependencies or blockers**
|
||||
- **Carry-over items from previous sprint** (if any)
|
||||
|
||||
## Process
|
||||
1. Read sprint goal and check it's specific and measurable — flag if it's too vague
|
||||
@@ -21,11 +22,12 @@ Produce a clear, scannable sprint brief that every team member — engineer, des
|
||||
3. Identify the critical path — which tickets must complete for the sprint goal to be met?
|
||||
4. Flag risks: tickets with unclear acceptance criteria, missing designs, unresolved dependencies
|
||||
5. Note carry-over items and whether they affect this sprint's goal
|
||||
6. **Validate** — Confirm the sprint goal is achievable given the ticket scope and capacity. If the critical path items alone would fill the sprint, flag it as overloaded.
|
||||
|
||||
## Output Format
|
||||
## Output Structure
|
||||
|
||||
### Sprint [Number] Brief — [Dates]
|
||||
**Sprint Goal:** [1-2 sentences]
|
||||
**Sprint Goal:** [1-2 sentences — specific and measurable]
|
||||
**Why This Sprint Matters:** [Connect to quarterly OKR in 2-3 sentences]
|
||||
|
||||
**What We're Building:**
|
||||
@@ -41,3 +43,11 @@ Produce a clear, scannable sprint brief that every team member — engineer, des
|
||||
**Carry-over from Last Sprint:** [List + impact on current goal]
|
||||
|
||||
**Definition of Done:** [Specific, agreed criteria for sprint success]
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Sprint goal is specific enough to score pass/fail at the end of the sprint
|
||||
- [ ] Critical path items are named — not just "the important ones"
|
||||
- [ ] Every risk has a mitigation or owner (not just "this is a risk")
|
||||
- [ ] Carry-over items are connected to their impact on this sprint's goal
|
||||
- [ ] Definition of Done is agreed criteria, not a task list
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: sprint-planning
|
||||
description: Structures and facilitates sprint planning sessions. Use when asked to plan a sprint, organise backlog items, assign story points, create sprint goals, or prepare sprint planning meeting agendas. Triggers on phrases like "plan sprint", "sprint planning", "sprint goal", "sprint backlog".
|
||||
description: "Structure and facilitate sprint planning sessions. Use when asked to plan a sprint, organise backlog items, assign story points, create sprint goals, or prepare sprint planning agendas. Produces a sprint goal, velocity-calibrated backlog, capacity plan, risk flags, and a structured sprint planning meeting agenda."
|
||||
---
|
||||
|
||||
# Sprint Planning Skill
|
||||
@@ -87,3 +87,11 @@ Story points to commit = Historical velocity × Availability factor
|
||||
- Recommend the team commits to 80% of available capacity, not 100%
|
||||
- If no velocity data is provided, assume 20–30 points for a 5-person team as a starting point
|
||||
- Highlight any story with unclear ownership as a blocker
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Sprint goal is outcome-focused (not "implement X" — something like "users can do Y")
|
||||
- [ ] Team capacity is calculated using actual availability, not theoretical 100%
|
||||
- [ ] Every story has an acceptance criterion (flag any that don't)
|
||||
- [ ] Stories estimated at 8+ points are flagged for splitting
|
||||
- [ ] Carry-overs from last sprint are accounted for in capacity
|
||||
|
||||
@@ -1,12 +1,20 @@
|
||||
---
|
||||
name: technical-spec-template
|
||||
description: Creates structured technical specification documents that bridge product requirements and engineering implementation. Use when writing a tech spec, engineering spec, system design doc, or API specification. Triggers on "technical spec", "tech spec", "engineering spec", "system design doc", "API spec", "implementation spec".
|
||||
description: "Create structured technical specification documents that bridge product requirements and engineering implementation. Use when writing a tech spec, engineering spec, system design doc, or API specification. Produces a complete spec with problem statement, proposed solution, data model, API design, alternatives considered, security considerations, testing plan, and rollout strategy."
|
||||
---
|
||||
|
||||
# Technical Spec Template Skill
|
||||
|
||||
Write technical specifications that engineers actually read — clear problem framing, unambiguous requirements, explicit decisions, and documented trade-offs.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Feature or system description** (what needs to be specced)
|
||||
- **Related PRD or product brief** (if available)
|
||||
- **Engineering reviewers** (whose sign-off is needed)
|
||||
- **Known constraints** (technical limitations, security requirements, performance targets)
|
||||
|
||||
## When to Write a Tech Spec
|
||||
|
||||
Write a tech spec when:
|
||||
@@ -131,3 +139,11 @@ Error codes: [list]
|
||||
- Security and privacy sections are never optional for features that touch user data
|
||||
- Recommend async review: engineers read first, then a 30-minute sync to resolve questions
|
||||
- Keep the spec updated as implementation progresses — stale specs are worse than no specs
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Problem statement contains no solution language
|
||||
- [ ] Non-goals explicitly list at least 2 things that might be assumed in scope
|
||||
- [ ] At least 2 alternative approaches are documented with reasons for rejection
|
||||
- [ ] Security and privacy section is completed for any feature touching user data
|
||||
- [ ] All open questions have a named owner and due date (not "TBD")
|
||||
|
||||
Reference in New Issue
Block a user