القائمة
Guide Sprint Retrospectives to identify improvements. Use when reflecting on sprints, planning process improvements, or executing improvement actions.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
MyLifeのスクラップ要約を作成する。ユーザーが「スクラップ要約」「前日分のスクラップを要約」「Clippingsをデイリーノートに追記」「~/MyLife/Clippings の記事をまとめて」などと依頼したときに使う。Asia/Tokyo基準で対象日を決め、~/MyLife/Clippings/ のYYYYMMDD始まりのファイルからタイトル・URL・本文を抽出し、~/MyLife/pages/YYYY_MM_DD.md の `## 要約` セクションを新規作成または置換する。
Collect analytics from YouTube Studio in Microsoft Edge and save them as a CSV with a fixed schema. Use when Codex is asked to open YouTube Studio, switch to a specific managed channel if needed, read the past 28 days of per-video metrics such as views, average view duration, likes, comments, saves, and impressions, and save the result as a CSV file.
Guide behavior-preserving code refactoring with a language-agnostic core, Fowler-aligned catalog references, and team-specific extension patterns. Use during the TDD REFACTOR phase, when code smells are detected, when preparing for later behavior changes, or when discussing structural improvements.
Orchestrate full implementation lifecycle with sub-agent team delegation through 6 strict phases: Tidy First -> Implement -> TDD Red -> Green -> Refactor -> Tidy After. The leader gives instructions only; sub-agents do all research and coding. Use when user explicitly invokes /implements or says "実装して", "これを実装", "implement this". NOT for quick fixes, single-file edits, or tasks that don't warrant the full 6-phase ceremony.
Boris Tane's structured 3-phase workflow for non-trivial tasks: Research → Plan → Todo → Implement. Use when starting a new feature, refactoring, bug investigation, or any task where you want to plan deeply before coding. Creates research.md, plan.md, and todo.md as shared artifacts for iterative refinement. DO NOT write code until the plan is explicitly approved. Trigger when user says "研究して", "計画を立てて", "research and plan", "plan before coding", or starts a complex task that benefits from upfront analysis.
Use when user says "wrap up", "close session", "end session", "wrap things up", "close out this task", or invokes /wrap-up — runs end-of-session checklist for shipping, memory, and self-improvement
| name | scrum-event-sprint-retrospective |
| description | Guide Sprint Retrospectives to identify improvements. Use when reflecting on sprints, planning process improvements, or executing improvement actions. |
Core philosophy: "The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness."
Quality and effectiveness covers EVERYTHING: how the team works together, processes and tools used, Definition of Done, technical practices.
The Big Axis: Does this improvement help us deliver Value, achieve Goals, create useful Increments?
NEVER skip, NEVER rush, NEVER blame Read Norman Kerth's Prime Directive at EVERY retrospective: "Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand." What's said in retro stays in retro - Unless team agrees to share Focus on system, not blame - Improve the SYSTEM, not punish individuals 5-10% of time: - Read Prime Directive - Check-in (one-word, ESVP, confidence vote) - Establish focus 30-40% of time: - What happened? How did people feel? - Techniques: Timeline, Mad/Sad/Glad, 4Ls, Sailboat, Start/Stop/Continue 20-25% of time: - WHY did things happen? Root causes, not symptoms - Techniques: 5 Whys, Fishbone, Circles and Soup 15-20% of time: - Select the most helpful changes (few, not all) - Techniques: Dot Voting, Impact/Effort Matrix 5-10% of time: - Execute `timing: immediate` actions - Record to `scrum.ts` - Evaluate the retro itself (Plus/Delta, ROTI) | Timing | When to Execute | Examples | |--------|-----------------|----------| | `immediate` | During Retro | Update CLAUDE.md, skills, DoD, templates | | `sprint` | Next Sprint subtask | Documentation, test helpers | | `product` | New PBI in backlog | Automation, CI/CD |immediate constraints: NO production code, single logical change.
<anti_patterns> SM always facilitates → Rotate facilitation Same format every time → Vary techniques No action follow-through → Review previous actions at start Blame culture → Re-read Prime Directive; focus on system Skipping retrospectives → "Not improving makes us busier" KPT every time → Surface-level; use varied techniques </anti_patterns>
<best_practices> Painful improvements aren't improvements - Work should become safer, easier Track happiness - Make it visible and important </best_practices>
<related_skills> Facilitation, safety concerns Full participation (not optional!) Honest participation, improvement ownership Outputs larger improvements as PBIs </related_skills>
The team should leave feeling heard, hopeful, and ready to improve.
