Sdlc Review

Kanban の引き継ぎをレビューし、検証済みの結果を振り分けます。

skill の情報

参考: SKILL.md 全文

SDLC Review Skill

Kanban の実装作業からレビュー用のレーンへ引き渡された成果物を、独立した立場で検証し、承認・修正依頼・エスカレーションのいずれかに振り分けます。この skill が見るのは成果物とその根拠であって、実装担当の作業を肩代わりするものではありません。

使いどころ

次の条件がすべて当てはまるときに使います。

• ディスパッチャが review レーンから受け取ったタスクのためにあなたを起動した。
• 実装担当が review_requested の引き継ぎを提出した。
• そのタスクを完了扱いにする前に、独立した判定が必要である。

後工程としてレビュー用のカードを別に立てた場合には使いません。そうしたカードは、レビュー寄りの仕様を持った通常の実装作業であり、それ自体のライフサイクルで完了します。

事前に必要なもの

• 現在のタスクと実行の識別子を持つ Kanban ワーカーの文脈。
• Kanban のネイティブツール kanban_show、kanban_comment、kanban_complete、kanban_request_changes、kanban_block。
• 成果物がコードの場合は、read_file、search_files、terminal によるワークスペースへのアクセス。
• タスク本来の仕様、受け入れ条件、引き継ぎの要約、過去の実行履歴が kanban_show から参照できること。

進め方

この skill はレビュー用ディスパッチャが自動で読み込みます。ファイルを見たり判定を決めたりする前に、まず kanban_show から始めてください。

1. タスクの仕様と、最新の review_requested 引き継ぎを読みます。
2. 成果物そのものを確認し、必要な検証を実行します。
3. 承認・修正依頼・エスカレーションのうち、ちょうど 1 つを選びます。
4. Kanban の終端遷移に、具体的な根拠を記録します。

早見表

修正依頼の遷移は、そのタスクを元の実装担当へ戻します。実装担当がレビュアーを指定せずに再びレビューを依頼した場合、保存されたレビュアーの来歴によって、再レビューは同じレビュアーのプロファイルへ振り分けられます。

レビューの視点

同じ見方を繰り返すのではなく、ラウンドごとに作業の見方を変えてください。相関しない視点は、それぞれ違う種類の欠陥を捕まえます。成果物を予備知識なしで読めば、実装担当の説明では見えなくなっていた設計や正しさの問題が出てきます。実際に動かせば、再現しない主張が出てきます。仕様との突き合わせを厳しく行えば、静かに広がったスコープのずれが出てきます。3 回目に 1 回目と同じ視点を使っても、たいていは 1 回目に見つけたものを見つけ直すだけです。

現在が何ラウンド目かは、タスクの記録がすでに持っている履歴から判断します。ワーカーの文脈にある「Prior attempts on this task」の節で changes_requested の項目を数えてください（kanban_show でも過去の実行として見えます）。現在のレビューのラウンドは、その数に 1 を足したものです。したがって 1 回目は changes_requested がゼロ、2 回目は 1 つ、以降も同様です。

手順の節にある基本の役目は、どのラウンドでも変わらず適用されます。視点が決めるのは、どの確認を主軸に置き、どこに重みを置くかです。

その場限りのレビュー並列実行での視点の振り分け

同じ考え方は、Kanban のレビューレーンの外でも成り立ちます。delegate_task で複数のレビュアーを並列に起動するときは、全員に同じ指示を渡すのではなく、それぞれ違う視点を渡してください。差分だけを見る指示、文脈をすべて渡す指示、チェックアウトして動かす指示、といった具合です。同じ指示は似通った判定と重複した指摘を生みますが、視点を変えれば同じレビューの手間でより多くの欠陥を覆えます。

手順

1. 残っているタスク記録から状況を把握する

kanban_show を呼び、次を確認します。

• 元のタスク本文と受け入れ条件。
• 最新の実装の要約と、構造化された付随情報。
• 変更されたファイル、コミットの識別子、テストの根拠。
• 過去の実行でのコメントと決定。
• 過去のレビューでの指摘。

引き継ぎは検証すべき主張として扱い、作業が正しいことの証明としては扱わないでください。

2. 求められた挙動と実際の挙動を突き合わせる

受け入れ条件を 1 つずつ、具体的な実装や出力の根拠に対応づけます。抜け、意味が変わった箇所、関係のない範囲の変更を書き出したうえで、さらに深く調べるかどうかを決めます。

コードの作業の場合:

1. read_file と search_files で、変更されたパスとその呼び出し元を確認します。
2. terminal で差分を確認し、プロジェクトにすでにある絞り込んだテスト、lint、型チェック、ビルドのコマンドを実行します。
3. 可能であれば、報告された失敗の経路と、少なくとも 1 つの通常の経路を実際に動かします。
4. その変更に関係するエラー処理、境界値、並行処理の境界、データの保全、セキュリティの境界、プラットフォームをまたいだ挙動を確認します。
5. テストがソースの文字列や定数をそのまま写し取っているだけでなく、挙動を検証していることを確かめます。

コード以外の作業の場合:

1. 要約だけでなく、成果物の全体を確認します。
2. 正しさ、抜けの有無、体裁、出所を確認します。
3. 参照されている URL や外部の事実が判定に影響する場合は、適切なネイティブツールで裏を取ります。

3. 判定を 1 つ選ぶ

承認

受け入れ条件が満たされ、根拠が十分なときにだけ承認します。次を呼びます。

kanban_complete(
    summary="Reviewed and approved. <what was verified>",
    metadata={"review_outcome": "approved", "reviewer_checks": [...]}
)

通過した確認の内容と、受け入れを妨げない範囲の但し書きがあればそれを書き添えます。

修正依頼

具体的で直せる欠陥にはこれを使います。まず対応できる形で指摘を記録します。

kanban_comment(
    task_id="<current-task-id>",
    body="Changes requested:\n1. <file or artifact + defect>\n2. <required correction>",
)

そのうえで、同じタスクを実装担当へ戻します。

kanban_request_changes(
    reason="<concise summary of the required corrections>"
)

欠陥がどこにあるか、どう再現するか、なぜタスクの要求に反するか、最低限どうなれば解決かを書きます。この遷移では、ブロッカーの再発回数の集計は使いません。

エスカレーション

エスカレーションは、レビュアーと実装担当だけでは解決できず、人の判断か外部の前提条件が要る場合にだけ使います。

kanban_block(
    reason="escalation: <decision or prerequisite required>"
)

止まっている判断と、先へ進むために最低限必要な情報を説明します。

4. 役割の分離を保つ

レビュアーとして動いている間は、実装に手を入れないでください。修正を依頼し、次の候補は実装担当に作ってもらいます。そのうえで、次のレビューで独立に検証します。

つまずきやすいところ

• 形だけの承認: 引き継ぎの要約が通っていることは、独立した根拠にはなりません。
• レビュアーによる実装: 成果物を自分で直すと、誰が持ち主かが曖昧になり、再レビューの境界も弱くなります。
• 曖昧な指摘: 「もう少し」では、実装担当が再現して直せる目標になりません。
• 好みだけでの差し戻し: 挙動もリポジトリの基準も満たしているなら、好みのレベルの細かい指摘で修正依頼を出さないでください。
• 過去のラウンドの読み飛ばし: 再レビューでは、依頼した修正が入ったことと、それまで通っていた挙動が保たれていることの両方を確認します。
• 通常の手戻りにブロッカーを使う: 直せる欠陥は kanban_request_changes に入れ、kanban_block は本当に外部要因や人の判断が要る場合のために取っておきます。
• 根拠のない完了: 承認の要約には、実際に確認した検査や成果物を必ず名指しで書きます。

確認

判定を出す前に、次を確かめてください。

• [ ] 現在のタスクと実行について kanban_show を読んだ。
• [ ] 受け入れ条件をすべて根拠に対応づけた。
• [ ] 成果物そのものを確認した。
• [ ] 関係する絞り込んだ検査を実行した。実行できなかった場合は、その理由を明示して記録した。
• [ ] 再レビューでは、過去に依頼した修正を再度テストした。
• [ ] 無関係な機能の後退やスコープの変化を検討した。
• [ ] 判定は終端の操作をちょうど 1 つだけ使っている。
• [ ] 要約に、具体的で秘密を含まない根拠が書かれている。
• [ ] レビュアーが実装ファイルを編集していない。