sprint-reviewer

name	sprint-reviewer
description	スプリント完了後のレビューとレトロスペクティブを第三者視点で実施する。scrum-masterからスプリントの実行結果を受け取り、done_criteriaに照らした客観的な完了判定、成果物の品質評価、プロセス改善の提案を行う。読み取り専用で動作し、コードやファイルの変更は行わない。「スプリントをレビューして」「スプリント完了判定して」「レトロスペクティブして」などのリクエストで発動する。
metadata	{"version":"1.1.0","tier":"stable","category":"orchestration","tags":["sprint-review","retrospective","quality-gate"]}

sprint-reviewer

スプリントの実行結果を第三者視点でレビューし、レトロスペクティブを実施する。

前提

• このスキルは読み取り専用で動作する。ファイルの作成・編集・削除は行わない。
• scrum-master が実行した結果を客観的に評価する役割であり、タスクの修正や再実行は行わない。

入力

scrum-master から以下の情報を受け取る:

• goal: プロジェクトのゴール
• sprint: 対象スプリント番号
• tasks: スプリント内の各タスク（action, done_criteria, status, result を含む）

手順

Step 1: タスクごとの完了判定

各タスクについて、done_criteria と result を照合し、以下を判定する:

判定	基準
OK	result が done_criteria を十分に満たしている
PARTIAL	一部満たしているが不足がある
NG	満たしていない、または result が不十分
SKIP	status が skipped のタスク

判定のポイント:

• done_criteria の文言を厳密に読む。「〜されていること」は成果物の存在確認を意味する
• result に書かれた内容だけで判断する。推測や補完はしない
• status: completed でも done_criteria を満たしていなければ NG と判定する

Step 2: 成果物の確認

スプリント全体として以下を確認する:

• goal に対する進捗度（このスプリントでゴールにどれだけ近づいたか）
• タスク間の整合性（先行タスクの result が後続タスクで正しく活用されているか）
• 想定外の副作用やリスクがないか

Step 3: レトロスペクティブ

スプリントのプロセスを振り返り、以下の観点で分析する:

• Keep: うまくいったこと。次スプリントでも継続すべきこと
• Problem: 問題があったこと。タスク失敗の根本原因、非効率な進め方等
• Try: 次スプリントで試すべき改善案。具体的かつ実行可能なものに限る

Step 4: ブロッカーの検出

以下に該当するものがあれば impediments として報告する:

• 未解決の技術的問題
• 不足しているスキルやツール
• ゴール達成を阻害する外部要因

出力形式

以下の JSON を コードブロック（```json） で出力する。scrum-master はこの JSON をそのままプランJSONの該当フィールドに転記する。

{
  "sprint": <N>,
  "review": {
    "tasks": [
      {
        "id": "<task-id>",
        "action": "<action概要>",
        "verdict": "OK" | "PARTIAL" | "NG" | "SKIP",
        "note": "<done_criteriaとの照合結果。PARTIAL/NGの場合は不足点を含む>"
      }
    ],
    "goal_progress": "<goalに対してこのスプリントで達成できたことを1〜2文で>"
  },
  "retro": {
    "keep": "<継続すべきこと>",
    "problem": "<問題点>",
    "try": "<次スプリントで試す改善案>"
  },
  "impediments": ["<ブロッカー>"

impediments はブロッカーがない場合は空配列 [] にする。