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:
mohitagw15856
2026-04-20 20:52:31 +01:00
parent 34b0f780e6
commit f3b9d008fe
70 changed files with 2173 additions and 599 deletions
+23 -13
View File
@@ -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?)