mcpField
R
retrospective

retrospective

github.com/donchitos開発28.5k470 回インストール1 週間前に更新
リポジトリ

retrospective について

retrospectiveは、計画、状態データ、コミット履歴、過去のレトロスペクティブを照合し、スプリントやマイルストーンを振り返るワークフロースキルです。根拠がない項目は推測せず未評価とし、承認後にレポートを保存できます。

主な機能

  1. 01スプリントやマイルストーンのデータ分析
  2. 02計画と実際の成果の比較
  3. 03ブロッカーと技術的負債の確認
  4. 04過去のアクションと傾向の追跡
  5. 05不足データを未評価として記録
  6. 06承認後のレポート保存

活用シーン

  1. 01完了した作業と未完了作業をまとめる
  2. 02繰り返し発生するブロッカーや問題を特定
  3. 03次回計画に向けてアクションと速度データを整理

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/donchitos/claude-code-game-studios --skill retrospective

インストール後、Claude Code で/retrospectiveを入力して読み込まれたか確認します。

詳細

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys automation,workflow,qa.level

振り返り

すべての AskUserQuestion 呼び出しは .claude/docs/automation-modes.md に従います (共同作業では常に質問し、ガイド付きでは主要事項のみ、自律モードでは記録して続行します。 automation_always_ask カテゴリーでは常に質問します)。

入力が不十分な場合 — レポートを作成する前に確認してください

このスキルが必要とする入力が存在しない場合、回答は「実行できません」です。 入力を埋めたレポートではありません。 まず確認し、確認に失敗したら中止してください。

  1. このスキルが読み取る入力(データファイル、以前のレポート、プロファイラー出力、 テスト結果、レジストリ、ソースコード)を列挙します。
  2. それぞれについて、「存在すると想定」ではなく FOUND または ABSENT を記録します。
  3. セクションに必要な入力が一つでも ABSENT の場合、そのセクションは NOT ASSESSED — NO DATA です。推定したり、隣接する成果物から推論したり、 次にテンプレートを読む人が埋めるよう必須セルを空欄のままにしたりしないでください。
  4. 必要な入力がすべて ABSENT の場合は中止し、何が不足しているか、 それを生成するスキルを明記して、全体の判定として NOT ASSESSED — NO DATA を報告します。

NOT ASSESSED の判定は成功です。 データがないときに「データは何を示していますか?」という問いに対する、 正しく有用な答えです。これによって防ぐのは、具体的には次のような失敗です。判定の選択肢に「実行できません」がないレポートでは、 誤ったクリーン判定が生じます。たとえば、アセットも基準もないプロジェクトのアセット監査が COMPLIANT を返したり、 プロファイラーデータも予算設定もないのに、パフォーマンスプロファイルが「16.67ms の予算に対して >99% の余裕」と報告したりするケースです。

証拠がないことは、存在しない証拠にはなりません。 スキャン対象のファイルがないため一致が見つからなかったスキャンは、 何も検証していません。どちらが起きたのかを明記してください。結果が緑色でも、読み手には区別できません。


フェーズ 1:引数を解析する

これがスプリントの振り返り(sprint-N)なのか、マイルストーンの振り返り(milestone-name)なのかを判断します。


フェーズ 1b:既存の振り返りを確認する

データを読み込む前に、既存の振り返りファイルを glob で検索します。

  • スプリントの振り返りの場合:production/retrospectives/retro-[sprint-slug]-*.md (別の場所として production/sprints/sprint-[N]-retrospective.md も確認します)
  • マイルストーンの振り返りの場合:production/retrospectives/retro-[milestone-name]-*.md

一致するファイルが見つかった場合は、AskUserQuestion を使用します。

  • プロンプト:「既存の振り返りが見つかりました:[filename]。どのように進めますか?」
  • 選択肢:
    • [A] 既存の内容を更新 — 読み込んで、新しいデータでセクションを追加・修正する
    • [B] 新規作成 — 新しい振り返りを生成する(古いものはアーカイブする)

[A] の場合:既存ファイルを読み込み、その内容を引き継ぎながら、新しいデータでセクションを修正します。 [B] の場合:フェーズ 2 に進み、白紙の状態から始めます。新しいファイルを書き込む前に、既存ファイル名に -archived-[date] のサフィックスを付けて変更します。この変更も書き込み操作です。フェーズ 5 で、そのファイル名を明示した質問が承認された場合にのみ実行します。

フェーズ 2:スプリントまたはマイルストーンのデータを読み込む

適切な場所からスプリントまたはマイルストーンの計画を読み込みます。

  • スプリント計画:production/sprints/
  • マイルストーン定義:production/milestones/

production/sprint-status.yaml も確認してください:存在する場合は、スプリント計画と併せて読み込みます。実際のストーリー完了状況(status: done、完了日、ブロッカー)の正式な情報源です。フェーズ 3 の完了指標には、これを主な情報源として使用してください。yaml が存在しない場合に限り、Markdown のスキャンを代替手段として使用します。yaml とスプリント計画に食い違いがあれば(例:yaml にのみ記載されているストーリー、またはその逆)、その内容を記録してください。

ファイルが存在しないか、空の場合は、次のように出力します。

"No sprint data found for [sprint/milestone]. Run /sprint-plan new to create a sprint (/sprint-status only reads one), or provide the sprint details manually."

workflow: minimal(上記で解決済み)の場合、スプリントはありません。代わりに、これまでにクローズされたストーリーを振り返ることを提案します(production/epics/*/story-*.md の Status: Complete)。

qa.level: minimal(上記で解決済み)の場合、テストは免除されます。そのため、テストなしでクローズされたストーリーは指摘事項ではありません。ただし、保持されたスクリーンショットがないままクローズされた Visual/Feel または UI ストーリーは指摘事項となります。

次に、AskUserQuestion を使用して以下の選択肢を提示します(workflow: minimal の場合のみ [C] を提示)。

  • [A] データを手動で提供する — スプリントのタスク、日付、結果を貼り付けるか説明するようユーザーに依頼します。振り返りでは、それを正しい情報源として使用します。
  • [B] 停止する — スキルを中止します。判定:BLOCKED — スプリントデータがありません。
  • [C] クローズ済みのストーリーを振り返る — Status: Complete のストーリーを、完了した作業の記録として使用します。

ユーザーが [A] を選択した場合は、データを収集し、提供された内容を使ってフェーズ 3 に進みます。 ユーザーが [B] を選択した場合は、ここで停止します。 ユーザーが [C] を選択した場合は、それらのストーリーを読み込み、フェーズ 3 に進みます。スプリントデータが必要なセクション(計画と実績、ベロシティ、持ち越し、見積もり精度)は NOT ASSESSED — NO DATA とします。

抽出する項目:計画されたタスク、見積もり工数、担当者、目標。

スプリント期間中に実際に何がいつコミットされたかを把握するため、git log を実行します。Bash ツールを使用してください(Windows では Git Bash を使用します。2>/dev/null は Bash の構文であり、PowerShell の構文ではありません)。

Bash: git log --oneline --since="4 weeks ago" 2>/dev/null || git log --oneline -20

スプリント計画から期間が判明している場合は、--since の日付をスプリント期間に合わせて調整します。


フェーズ 3:完了状況と傾向を分析する

計画と実際の成果物を比較し、完了したタスクと未完了のタスクを確認します。以下を確認してください。

  • 計画どおりに完了したタスク
  • 計画から変更して完了したタスク
  • 持ち越されたタスク(未完了)
  • スプリント中に追加されたタスク(計画外の作業)
  • 削除またはスコープ縮小されたタスク

production/sprint-status.yaml で status: blocked となっているすべてのストーリーを「発生したブロッカー」に記載し、その blocker フィールドをブロッカーとして記録します。また、「次のイテレーションのアクション項目」にも記載します。

コードベースをスキャンして、TODO/FIXME の傾向を確認します。

  • 現在の TODO/FIXME/HACK コメント数を数える
  • 以前のスプリントの数が確認できる場合は比較する(過去の振り返りを確認する)
  • 技術的負債が増加しているか減少しているかを記録する

過去の振り返りがあれば、production/retrospectives/ から読み込み、以下を確認します。

  • 過去のアクション項目に対応したか
  • 同じ問題が繰り返し発生しているか
  • ベロシティがどのように推移したか

それ以前のスプリントまたは振り返りがない場合、「ベロシティの傾向」には現在のスプリントの行だけを残し、NOT ASSESSED — NO DATA と記載します。「前回のアクション項目のフォローアップ」はその1行のみとし、以前の行を創作したり、空の表を作成したりしないでください。


フェーズ 4:振り返りを作成する

## Retrospective: [Sprint N / Milestone Name]
Period: [Start Date] -- [End Date]
Generated: [Date]

### Metrics

| Metric | Planned | Actual | Delta |
|--------|---------|--------|-------|
| Tasks | [X] | [Y] | [+/- Z] |
| Completion Rate | -- | [Z%] | -- |
| Story Points / Effort Days | [X] | [Y] | [+/- Z] |
| Bugs Found | -- | [N] | -- |
| Bugs Fixed | -- | [N] | -- |
| Unplanned Tasks Added | -- | [N] | -- |
| Commits | -- | [N] | -- |

### Velocity Trend

| Sprint | Planned | Completed | Rate |
|--------|---------|-----------|------|
| [N-2] | [X] | [Y] | [Z%] |
| [N-1] | [X] | [Y] | [Z%] |
| [N] (current) | [X] | [Y] | [Z%] |

**Trend**: [Increasing / Stable / Decreasing — or `NOT ASSESSED — NO DATA` with no earlier sprint to compare]
[One sentence explaining the trend]

### What Went Well
- [Observation backed by specific data or examples]
- [Another positive observation]
- [Recognize specific contributions or decisions that paid off]

### What Went Poorly
- [Specific issue with measurable impact -- e.g., "Feature X took 5 days
  instead of estimated 2, blocking tasks Y and Z"]
- [Another issue with impact]
- [Do not assign blame -- focus on systemic causes]

### Blockers Encountered

| Blocker | Duration | Resolution | Prevention |
|---------|----------|------------|------------|
| [What blocked progress] | [How long] | [How it was resolved] | [How to prevent recurrence] |

### Estimation Accuracy

| Task | Estimated | Actual | Variance | Likely Cause |
|------|-----------|--------|----------|--------------|
| [Most overestimated task] | [X] | [Y] | [+Z] | [Why] |
| [Most underestimated task] | [X] | [Y] | [-Z] | [Why] |

**Overall estimation accuracy**: [X%] of tasks within +/- 20% of estimate

[Analysis: Are we consistently over- or under-estimating? For which types of
tasks? What adjustment should we apply?]

### Carryover Analysis

| Task | Original Sprint | Times Carried | Reason | Action |
|------|----------------|---------------|--------|--------|
| [Task that was not completed] | [Sprint N-X] | [N] | [Why] | [Complete / Descope / Redesign] |

### Technical Debt Status
- Current TODO count: [N] (previous: [N])
- Current FIXME count: [N] (previous: [N])
- Current HACK count: [N] (previous: [N])
- Trend: [Growing / Stable / Shrinking]
- [Note any areas of concern]

### Previous Action Items Follow-Up

| Action Item (from Sprint N-1) | Status | Notes |
|-------------------------------|--------|-------|
| [Previous action] | [Done / In Progress / Not Started] | [Context] |

### Action Items for Next Iteration

| # | Action | Owner | Priority | Deadline |
|---|--------|-------|----------|----------|
| 1 | [Specific, measurable action] | [Who] | [High/Med/Low] | [When] |
| 2 | [Another action] | [Who] | [Priority] | [When] |

### Process Improvements
- [Specific change to how we work, with expected benefit]
- [Another improvement -- keep it to 2-3 actionable items, not a wish list]

### Summary
[2-3 sentence overall assessment: Was this a good sprint/milestone? What is
the single most important thing to change going forward?]

フェーズ 5:振り返りの保存

振り返りと主な調査結果(完了率、ベロシティの傾向、最も大きなブロッカー、最も重要なアクションアイテム)をユーザーに提示します。

次のように尋ねます:「これを production/retrospectives/retro-sprint-[N]-[date].md に書き込んでもよいですか?」(マイルストーンの振り返りでは production/retrospectives/retro-[milestone-name]-[date].md)

フェーズ 1b で「新しく開始」を選んだ場合、同じ質問でファイル名の変更も確認します:「…また、[old file] の名前を [old file name]-archived-[date].md に変更してもよいですか?」承認された場合は、先に名前を変更してから書き込みます。承認されなかった場合は、どちらも実行しません。

承認された場合は、必要に応じて production/retrospectives/ ディレクトリを作成してからファイルを書き込みます。判定:完了 — 振り返りを保存しました。

承認されなかった場合は、ここで終了します。判定:ブロック — ユーザーが書き込みを拒否しました。


フェーズ 6:次のステップ

上記で解決した workflow: minimal ではスプリントがないため、この質問を省略します。振り返りファイルを案内し、そのアクションアイテムがブリーフのビルド順序に反映されることを伝えます。

それ以外の場合は、AskUserQuestion を使用します。

  • プロンプト:「振り返りが完了しました。アクションアイテムとベロシティデータの準備ができています。このデータを事前に読み込んで、今すぐスプリント計画を始めますか?」
  • 選択肢:
    • [A] はい — 振り返りのアクションアイテムとベロシティの変化を事前入力して、スプリント計画を開始する
    • [B] いいえ — 準備ができたら、振り返りファイルを自分で参照する

ユーザーが [A] を選択した場合:振り返りファイルのパスと、アクションアイテムおよびベロシティの変化の概要を渡して /sprint-plan new の実行に進み、スプリントプランナーがそれらを参照できるようにします。

  • マイルストーンの振り返りだった場合は、/gate-check を実行して次のフェーズへの準備状況を正式に評価します。
ガイドライン
  • 誠実かつ具体的に記述します。曖昧な振り返り(「コミュニケーションを改善できる」など)からは、曖昧な改善策しか生まれません。データと例を使います。
  • 個人を責めるのではなく、システム上の問題に焦点を当てます。
  • アクションアイテムは 3~5 件に制限します。それ以上では焦点がぼやけます。
  • すべてのアクションアイテムに担当者と期限を設定します。
  • 以前のアクションアイテムが完了したか確認します。未対応の項目が繰り返し発生している場合は、プロセスに問題がある兆候です。
  • マイルストーンの振り返りの場合は、マイルストーンの目標が達成されたか、また全体のプロジェクトスケジュールにどのような影響があるかも評価します。

コメント