---
license: "MIT. Translation of the Hermes Agent documentation, Copyright (c) 2025 Nous Research. See https://wiki.winsmux.dev/hermes/licenses.txt"
title: "Sdlc Review — Kanban の引き継ぎをレビューし、検証済みの結果を振り分ける"
description: "Kanban の引き継ぎをレビューし、検証済みの結果を振り分ける"
upstream_path: user-guide/skills/bundled/devops/devops-sdlc-review.md
upstream_blob: 59998b091e53241e154452d5caf73d4d7ed95d58
sources:
  - https://hermes-agent.nousresearch.com/docs/user-guide/skills/bundled/devops/devops-sdlc-review
---

# Sdlc Review {#sdlc-review}

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

## skill の情報 {#skill-metadata}

| | |
|---|---|
| 提供元 | 最初から入っています |
| パス | `skills/devops/sdlc-review` |
| バージョン | `1.1.0` |
| 作者 | Jakub Wolniewicz (@frizikk) + Hermes Agent |
| ライセンス | MIT |
| 対応プラットフォーム | linux, macos, windows |
| タグ | `kanban`, `review`, `quality`, `verification` |

## 参考: SKILL.md 全文 {#reference-full-skillmd}

:::info
以下は、この skill が呼び出されたときに Hermes が読み込む定義の全文です。skill が有効な間、エージェントはこれを指示として受け取ります。
:::

# SDLC Review Skill {#sdlc-review-skill}

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

## 使いどころ {#when-to-use}

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

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

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

## 事前に必要なもの {#prerequisites}

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

## 進め方 {#how-to-run}

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

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

## 早見表 {#quick-reference}

| 判定 | 使う場面 | 終端の操作 |
|---|---|---|
| 承認 | 受け入れ条件と検証を通過している | `kanban_complete` |
| 修正依頼 | 直せる実装上の欠陥が残っている | `kanban_comment` のあと `kanban_request_changes` |
| エスカレーション | 人の判断か外部の前提条件が必要 | `kanban_block` |

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

## レビューの視点 {#review-lenses}

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

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

| ラウンド | 視点 | 適用のしかた |
|---|---|---|
| 1 | 成果物 | 実装担当の要約を読む前に、差分や成果物を予備知識なしで読みます。独立した判断をまず作り、そのうえで引き継ぎの説明と突き合わせ、食い違いをすべて調べます。 |
| 2 | 実行 | 作業内容をチェックアウトし、`terminal` から実際に動かします。ビルド、テスト、報告された挙動の再現を自分の手で行います。成果物を読み直すのではなく、引き継ぎの主張を 1 つずつ実地に確かめます。 |
| 3 以降 | 仕様 | 元のタスク本文と受け入れ条件を読み直し、それに照らして成果物を厳密に監査します。あわせて、過去の `kanban_request_changes` で挙げた項目がすべて実際に反映されたかを確認します。 |

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

### その場限りのレビュー並列実行での視点の振り分け {#lens-variation-for-ad-hoc-review-fan-outs}

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

## 手順 {#procedure}

### 1. 残っているタスク記録から状況を把握する {#1-orient-from-the-durable-task-record}

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

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

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

### 2. 求められた挙動と実際の挙動を突き合わせる {#2-compare-requested-behavior-with-delivered-behavior}

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

コードの作業の場合:

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

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

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

### 3. 判定を 1 つ選ぶ {#3-choose-one-verdict}

#### 承認 {#approve}

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

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

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

#### 修正依頼 {#request-changes}

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

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

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

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

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

#### エスカレーション {#escalate}

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

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

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

### 4. 役割の分離を保つ {#4-preserve-role-separation}

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

## つまずきやすいところ {#pitfalls}

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

## 確認 {#verification}

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

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