Agent Skills
› mohitagw15856/pm-claude-skills
› retro-analysis
retro-analysis
GitHub基于冲刺交付数据生成结构化的回顾简报。通过计算完成率、延期率等指标，识别模式并区分事实与感受，提供具体的开始/停止/继续讨论提示及可衡量的改进实验，帮助团队聚焦解决方案而非争论事实。
触发场景
运行回顾会议
分析冲刺数据
准备回顾简报
将冲刺指标转化为讨论提示
安装
npx skills add mohitagw15856/pm-claude-skills --skill retro-analysis -g -y
SKILL.md
Frontmatter
{
"name": "retro-analysis",
"homepage": "https:\/\/mohitagw15856.github.io\/pm-claude-skills\/skill\/retro-analysis.html",
"metadata": {
"openclaw": {
"emoji": "🚚"
}
},
"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
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
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
- Calculate: completion rate, carry-over rate, unplanned work percentage
- Identify patterns: which ticket types were most likely to carry over? Which caused blockers?
- Note any process or communication breakdowns visible in the data
- Prepare 3 "Start / Stop / Continue" prompts based on the data — not generic, specific to this sprint
- Suggest 1 concrete experiment for the next sprint based on the biggest friction point
- Validate — Confirm each prompt is specific to this sprint (not a recycled generic prompt), and that the recommended experiment is concrete and measurable
Output Structure
Sprint [Number] Retrospective Brief
By the Numbers:
- Planned: [n] tickets | Completed: [n] | Carry-over: [n] | Completion rate: [%]
- Unplanned work: [n] tickets ([%] of capacity)
- Velocity: [points] vs. [average] average
What the Data Suggests: [2-3 observations grounded in the numbers above]
Discussion Prompts:
- 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 — with a specific success metric]
Scoring Rubric (0–40)
Score any output of this skill before handing it over; 32+ is ship-quality.
| Dimension | 0 | 5 | 10 |
|---|---|---|---|
| Data grounding | Numbers missing or wrong; observations are opinions with no traceable source | Core rates computed correctly, but observations only restate the numbers without pattern analysis (ticket types, historical comparison) | Every observation traces to a computed figure, carry-over is broken down by type/cause, and velocity is compared against the historical trend, not just the average |
| Blamelessness | Brief names or implies individuals/disciplines as the cause ("QA missed them") | Neutral wording, but framing still points at effort or diligence rather than systemic conditions | Failure modes are reframed as process/coverage/scheduling patterns the data actually supports — a defensive reader would find nothing aimed at them |
| Prompt specificity | Start/Stop/Continue are recycled generic categories ("communicate better") | Prompts reference this sprint but stay at category level — no numbers, no named behaviour | Each prompt is welded to this sprint's data, names one specific behaviour, and is phrased to open discussion rather than dictate the answer |
| Experiment quality | No experiment, or a multi-quarter initiative dressed as one | One concrete change, but success is unmeasurable or can't be evaluated at the next retro | One process change testable within a single sprint, with explicit success metrics and a stated cost-if-wrong, checkable at the next retro |
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?)
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
版本历史
- 54fad50 当前 2026-07-19 12:31
