agile-retro

振り返り

このスキルを使って、振り返りを具体的な改善アクションにつなげます。

スラッシュコマンド経由で受け取った初期コンテキスト：$ARGUMENTS

$ARGUMENTS が入力されている場合は、参照情報として使用します（例：期間、スプリント、取り組み、デリバリー）。 空の場合は、分析対象の期間またはデリバリーを尋ねます。

言語

成果物はユーザーの言語で作成します。文法と、必要な発音区別符号や文字種固有の文字を正しく使用します。ユーザーの言語が明確でない場合は、出力を生成する前に確認します。テンプレートは英語です。見出しと内容を、ユーザーの言語に合わせて翻訳してください。

プロジェクトルート

このスキルは、エージェントの現在の作業ディレクトリではなく、プロジェクトルート（作業を行うリポジトリ）からの相対パスに成果物を作成します。

• プロジェクト内から実行した場合は、このスキルに記載された相対パスを使用します。
• 別のディレクトリから実行した場合（例：隣接するリポジトリ、またはプロジェクトが別の場所にある場合）は、すべての成果物パスの先頭に<project-root>/を付けます。
• プロジェクトルートが不明確な場合は、書き込み前にハーネスの質問ツールを使ってユーザーに確認します。

質問

CLAUDE.md／AGENTS.mdに記載されたプロジェクト共通の規約（「Skill Prompting Conventions」）に従います。以下の判断が必要な場面では、ハーネスの構造化質問ツール（Claude CodeではAskUserQuestion、Codexではask_user_question、OpenCodeではquestion）を使用します。選択肢として列挙できないパス／名前／値を尋ねる場合に限り、自由形式のテキストを使用します。

判断事項	構造化する理由	推奨される選択肢
振り返りの範囲	分析の深さとテンプレートに影響するため	ストーリー単位 · スプリント単位 · エピック単位
ファシリテーションの形式	質問の内容を左右するため	Start-Stop-Continue · Mad-Sad-Glad · 4Ls · 自由形式

自由形式で尋ねる項目（構造化ツールは使用しません）：

• 参加者のメモ
• 改善アクション

一時停止なしモード：ユーザーがスキル実行中の確認を明示的に無効にしている場合は、構造化質問をすべて「未解決の質問」または同等の項目に記載し、処理を止めずに続行します。

目的

• 事実と意見を分けます
• うまくいったこと、うまくいかなかったこと、その理由を特定します
• 担当者と期限を明記した、少数の明確なアクションを作成します
• 過去の記録にとどめず、プロセス改善につなげます
• デリバリーの成果を振り返ります（計画と実績の比較）

使用する場面

• スプリントまたはデリバリーサイクルが終了したとき
• チームが、うまくいったことと変更が必要なことを振り返るとき
• 次のスプリントを開始する前（振り返りの内容をスプリント計画に反映します）
• 重要なデリバリーを完了した後（/agile-statusのクロージャーモード経由）
• デリバリー単位の振り返り（従来の/post-implで扱っていた振り返り）
• スプリント単位の振り返り（標準的なレトロスペクティブ）

使用しない場面

• スプリント途中の状況確認：代わりに/agile-status（チェックポイントモード）を使用します
• 次のスプリントの計画：代わりに/agile-sprintを使用します（ただし、振り返りの内容は計画に反映します）
• 検証を伴うデリバリーの完了：まず/agile-status（クロージャーモード）を使用し、その後で振り返りを行います
• メトリクスやデータが必要な場合：まず/agile-review（メトリクスのセクション）を実行し、その後で振り返りを行います

プロセス

1. 入力を収集する

以下を確認します：

• 対象期間の状況クロージャーレポート
• 状況チェックポイントおよび統合レポート
• スプリントレビュー（存在する場合）
• スプリントメトリクス（存在する場合）
• ユーザーまたはステークホルダーからのフィードバック

2. 事実と意見を分ける

• **事実：**何が起きたか（デリバリー、ブロッカー、逸脱、メトリクス）
• **認識：**チームや個人がプロセスについてどう感じたか

3. 分析する

• **うまくいったこと：**成果につながったプラクティス、ツール、意思決定
• **うまくいかなかったこと：**摩擦、遅延、手戻りの原因
• **理由：**症状だけでなく、根本原因

4. デリバリーの成果を振り返る

デリバリーのクロージャー後に実施する場合：

• 計画した内容と実際にデリバリーした内容
• 適切だった意思決定と、変更すべき意思決定
• 次回、何を変えるべきか
• 発生した技術的負債やリスク

5. アクションを定義する

• ふりかえりごとにアクションを2～3件に絞ります（量より重点を重視します）
• 各アクションには、次の内容を含めます。
  • 具体的な説明
  • 担当者
  • 期限
  • 改善が実現したことを確認する方法

6. 次のサイクルにつなげる

• 次のスプリント／デリバリーで、これらのアクションをどのように確認しますか？
• バックログ項目になるアクションはありますか？

保存先

• イニシアチブのふりかえりの場合：planning/<initiative>/retro.md
• スプリント／期間のふりかえりの場合：planning/retros/retro-YYYY-MM-DD.md

連携

• アクションから新しいタスクが生まれる場合：/agile-story または /agile-epic を提案します
• アクションによってプロセスが変わる場合、またはスキル／テンプレートの不足が明らかになった場合：人による確認のため、ふりかえりに記録します
• サイクルを再開する場合：/agile-sprint を提案します

参考テンプレート

このスキルの templates/retro.md をベースとして使用します。

ルール

• ふりかえりは、不満をぶつけたり議事録を作成したりする場ではありません。改善のためのツールです。
• アクションは具体的で実行可能なものにします。「コミュニケーションを改善する」のような曖昧な内容はアクションになりません。
• 各アクションには担当者が必要です。担当者のいないアクションは実行されません。
• ふりかえりごとにアクションを2～3件に絞ります。アクションが多いと、どれも実行されません。
• 同じアクションが連続するふりかえりに現れた場合、問題はより根深いものです。根本原因について話し合ってください。

ワークフローとの関係

flowchart LR
    A["/agile-status<br>(closure)"] --> B["/agile-retro"]
    B --> C[improvement actions]
    C --> D["/agile-sprint"]

このスキルはフィードバックループを完結させます。デリバリーを完了する場合は、まず /agile-status（完了モード）を使用してください。デモとスプリントの数値については、まず /agile-review を使用してください。次のサイクルは /agile-sprint から始まります。