fix(plugins): sync all 171 plugin SKILL.md files with fixed skills/ versions
Propagates Anti-Patterns sections, description rewrites, Required Inputs additions, and Quality Checks format fixes from skills/ to matching plugin SKILL.md copies. https://claude.ai/code/session_01MuGKn3a3Gbqoe8uM5Lmuqt
This commit is contained in:
Mohit
@@ -103,6 +103,14 @@ Flag if traffic is too low to reach significance in under 8 weeks — recommend
|
||||
- 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
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not run a test without a directional hypothesis — "let's see what happens" produces uninterpretable results
|
||||
- [ ] Do not declare a winner before reaching the pre-planned sample size — peeking at results inflates false positive rates
|
||||
- [ ] Do not test multiple independent changes in a single variant — you won't know which change caused the result
|
||||
- [ ] Do not use engagement metrics (clicks, time-on-page) as the primary metric when the goal is revenue or retention — proxy metrics mislead
|
||||
- [ ] Do not ignore guardrail metrics — a conversion lift that causes a support ticket spike is not a win
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Hypothesis is directional (predicts a specific direction and magnitude, not "let's see")
|
||||
|
||||
@@ -131,3 +131,11 @@ Ask the user for these if not provided:
|
||||
- [ ] 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
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not build a Tier 1 GTM plan for an incremental feature update — tier the launch appropriately before planning
|
||||
- [ ] Do not create activity lists without named owners and due dates — unowned tasks do not get done
|
||||
- [ ] Do not skip the rollback procedure for Tier 1 and 2 launches — every significant launch must have an abort plan
|
||||
- [ ] Do not treat marketing and engineering as separate tracks — cross-functional coordination is the whole point of a GTM plan
|
||||
- [ ] Do not set success metrics without a defined measurement window — "increase signups" is not a measurable target
|
||||
|
||||
@@ -82,6 +82,14 @@ Order by: fixes before handoff (critical) > consistency fixes (high) > polish (m
|
||||
- [ ] Audience-appropriate concerns flagged explicitly
|
||||
- [ ] Slides without issues are listed briefly, not ignored
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not flag stylistic preferences as issues — only report genuine layout problems, overflow, and consistency errors
|
||||
- [ ] Do not produce a flat list of issues — group by severity (Critical / Major / Minor) so fixes can be prioritised
|
||||
- [ ] Do not skip slides without commenting — every slide must have an explicit pass or issue status
|
||||
- [ ] Do not suggest redesigning content — the audit scope is layout, consistency, and readability, not messaging
|
||||
- [ ] Do not report the same issue type repeatedly across slides without summarising the pattern — consolidate repeated issues
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Audit this slide deck before my board meeting"
|
||||
- "Review this PowerPoint for layout issues"
|
||||
|
||||
@@ -7,6 +7,15 @@ description: "Generate a comprehensive pre-launch, launch day, and post-launch c
|
||||
|
||||
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:
|
||||
@@ -117,6 +126,14 @@ The skill generates a tiered checklist. Tier 3 launches use only the Essentials
|
||||
- [ ] 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
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: retro-analysis
|
||||
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."
|
||||
description: "Analyses sprint delivery data and produces 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
|
||||
@@ -51,3 +51,11 @@ Ask the user for these if not provided:
|
||||
- [ ] 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?)
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not assign blame to individuals in the retrospective brief — observations must describe patterns, not people
|
||||
- [ ] Do not produce Start/Stop/Continue prompts that are vague categories — each must name a specific behaviour
|
||||
- [ ] Do not recommend an experiment that cannot be completed within one sprint — small, testable experiments only
|
||||
- [ ] Do not treat carry-over tickets as a velocity problem without first identifying the root cause category
|
||||
- [ ] Do not run the same retrospective format every sprint — vary the format to prevent engagement fatigue
|
||||
|
||||
@@ -51,3 +51,11 @@ Ask the user for these if not provided:
|
||||
- [ ] 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
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not write a sprint goal as a task list — the goal must be a single outcome-focused statement that can be scored pass/fail
|
||||
- [ ] Do not leave the critical path unnamed — "the important tickets" is not a critical path
|
||||
- [ ] Do not list risks without a mitigation or owner — a risk without a response is just a worry list
|
||||
- [ ] Do not ignore carry-over items' impact on this sprint's capacity and goal
|
||||
- [ ] Do not write a Definition of Done that mixes task completion with outcome criteria — they must be observable and agreed before the sprint starts
|
||||
|
||||
@@ -15,7 +15,7 @@ Transform raw backlog items into a structured, achievable sprint with clear goal
|
||||
- **Sprint Planning Agenda** — structured 2-hour meeting agenda with timings
|
||||
- **Risk Flags** — blockers or dependencies that could derail the sprint
|
||||
|
||||
## Inputs to Request From User
|
||||
## Required Inputs
|
||||
|
||||
Ask for (if not already provided):
|
||||
- Sprint duration (1 or 2 weeks)
|
||||
@@ -95,3 +95,11 @@ Story points to commit = Historical velocity × Availability factor
|
||||
- [ ] 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
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not write sprint goals as task lists — goals must be outcome-focused and scoreable pass/fail at sprint end
|
||||
- [ ] Do not commit to 100% of available capacity — always recommend 80% to preserve slack for unplanned work
|
||||
- [ ] Do not carry stories with no acceptance criteria into the sprint — flag them as blockers before committing
|
||||
- [ ] Do not allow stories estimated at 8+ points into the sprint without splitting them first
|
||||
- [ ] Do not ignore carry-over items when calculating capacity — they consume capacity and must be accounted for before new work is pulled in
|
||||
|
||||
@@ -147,3 +147,11 @@ Error codes: [list]
|
||||
- [ ] 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")
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not include solution language in the problem statement — the problem must be described independently of the proposed solution
|
||||
- [ ] Do not omit alternatives considered — a spec that considers only one approach has not been properly evaluated
|
||||
- [ ] Do not leave open questions as "TBD" without a named owner and due date — unresolved questions are blockers
|
||||
- [ ] Do not skip security and privacy sections for any feature that touches user data
|
||||
- [ ] Do not write a non-goals section that is empty — always list at least two things that might be assumed in scope
|
||||
|
||||
@@ -209,6 +209,14 @@ Then the export contains only invoices from Jan 2026 — not all invoices
|
||||
- [ ] Out of scope is documented — not assumed
|
||||
- [ ] Stories are independent — they can be shipped individually without depending on unreleased work (except where explicitly noted)
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not write user stories from a technical perspective — every story must be from the user's point of view and state their goal
|
||||
- [ ] Do not write acceptance criteria that are untestable — every criterion must have a clear pass/fail condition
|
||||
- [ ] Do not create stories that are too large to complete in a single sprint — break epics into estimable, independently deliverable stories
|
||||
- [ ] Do not omit edge cases — unhappy paths and error states are required, not optional
|
||||
- [ ] Do not skip the Definition of Done — without it, "done" means different things to different people
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Write user stories for [feature] from this brief"
|
||||
|
||||
Reference in New Issue
Block a user