ln-402-task-reviewer

パス： ファイルパス（references/、../ln-*）は、このスキルディレクトリを基準とします。

タイプ： L3 ワーカー
カテゴリー： 4XX 実行

タスクレビュー担当

すべてのタスク実行後に必須です。 「レビュー待ち」のタスクを1件レビューし、即時修正を行うか、明確な手戻り指示を添えて、「完了」または「手戻り」を決定します。

このスキルは任意ではありません。 実行されたタスクはすべて、例外なく、まとめて処理したり省略したりせず、直ちにレビューする必要があります。

目的と範囲

• タスクIDを解決し（入力解決チェーンに従います）、設定済みのトラッカープロバイダー（getTask、getStory）を使用して、タスク全体と親ストーリーをそれぞれ読み込みます。
• アーキテクチャ、正確性、設定の適切さ、ドキュメント、テストを確認します。
• テストタスクの場合、プランナーテンプレートに従って、リスクベースの制限と優先度（≤15）を検証します。
• このタスクのみを更新します。承認して「完了」にするか、ベストプラクティスに基づく明示的な理由と修正案を添えて「手戻り」にします。

入力

入力	必須	ソース	説明
taskId	はい	args、親ストーリー、カンバン、ユーザー	レビュー対象のタスク

解決方法： タスク解決チェーン。
ステータスフィルター： レビュー待ち

フェーズ 0：ツール設定

必ず読み込むこと： references/environment_state_contract.md、references/storage_mode_detection.md、references/input_resolution_pattern.md

task_provider = タスク管理 -> プロバイダー（linear | github | file）を抽出します。操作はプロバイダーに依存しない形で行います。トラッカーへの入出力を行う場合にのみ、選択したプロバイダーのトランスポートリファレンスを読み込みます。

タスクの保存モード

このスキルで使用するトラッカー操作：getTask、getStory、updateStatus（完了 | 手戻り）、addComment、createTask（[BUG] の副作用タスク用）。

モードの検出

起動時に動作モードを検出します。

プランモードが有効な場合：

• ステップ 1～3：タスクを解決し、コンテキストを読み込みます（読み取り専用のため、プランモードで実行できます）
• レビュープラン（ファイル、チェック項目）を作成し、プランファイルに書き込みます
• ExitPlanMode を呼び出して終了します。レビューは実行しないでください。
• ステップ 4～9：承認後、レビュー全体を実行します

通常モード：

• ステップ 1～9：停止せずに標準ワークフローを実行します

プランモードのサポート

条件付きで読み込みます：プランモードが有効な場合に限り、references/plan_mode_pattern.md のワークフロー A を読み込みます。
ツールポリシー：ホストの AGENTS.md にある MCP の設定に従います。ホストポリシーがない場合、または MCP の動作が不明確な場合に限り、references/mcp_tool_preferences.md と references/mcp_integration_patterns.md を読み込みます。

重要：プランモードでは、プランファイルはレビュープラン（確認する内容）です。レビュー結果や判定をプランファイルに書き込んではいけません。

レビュープランの形式：

REVIEW PLAN for Task {ID}: {Title}

| Field | Value |
|-------|-------|
| Task | {ID}: {Title} |
| Status | {To Review} |
| Type | {impl/test/refactor} |
| Story | {Parent ID}: {Parent Title} |

Files to review:
- {file1} (deliverable)
- {file2} (affected component)

| # | Check | Will Verify |
|---|-------|-------------|
| 1 | Approach | Technical Approach alignment |
| 2 | Clean Code | No dead code, no backward compat shims |
| 3 | Config | No hardcoded creds/URLs |
| 4 | Errors | try/catch on external calls |
| 5 | Logging | ERROR/INFO/DEBUG levels |
| 6 | Comments | WHY not WHAT, docstrings |
| 7 | Naming | Project conventions |
| 8 | Docs | API/env/README updates |
| 9 | Tests | Updated/risk-based limits |
| 10 | AC | 4 criteria validation |
| 11 | Side-effects | Pre-existing bugs in touched files |
| 12 | Destructive ops | Safety guards from destructive_operation_safety.md (loaded in step 4) |
| 13 | Algorithm correctness | Loop invariants, collection keys, unbounded ops, shared state leaks |
| 14 | Event channels | Channel name consistency in diff |
| 15 | CI Checks | lint/typecheck pass per ci_tool_detection.md |

Expected output: Verdict (`Done | To Rework`) + Issues + Fix actions

TodoWrite による進捗管理

どのモードでも、このスキルではすべてのステップを追跡する詳細なTodoチェックリストを作成する必要があります。

ルール：

1. ステップ 1 の前に、直ちにTodoを作成します
2. ワークフローの各ステップを個別のTodo項目にします。複数のチェックを含むステップにはサブ項目を設けます
3. ステップを開始する前に in_progress、完了後に completed に設定します

Todoテンプレート（約11項目）：

Step 1: Resolve taskId
  - Resolve via args / Story context / kanban / AskUserQuestion (To Review filter)

Step 2: Load Task
  - Load task by ID, detect type

Step 3: Read Context
  - Load full task + parent Story + affected components

Step 3b: Goal Articulation Gate
  - State what specific quality question this review must answer (<=25 tokens each)

Step 4: Review Checks
  - Verify approach alignment with Story Technical Approach
  - Check clean code: no dead code, no backward compat shims
  - Cross-file DRY: Grep src/ for new function/class names (count mode). 3+ similar → CONCERN
  - Check config hygiene, error handling, logging
  - Check comments, naming, docs updates
  - Verify tests updated/run (risk-based limits for test tasks)

Step 5: AC Validation
  - Validate implementation against 4 AC criteria

Step 6: Side-Effect Bug Detection
  - Scan for bugs outside task scope, create [BUG] tasks

Step 7: Decision
  - Apply minor fixes or set To Rework with guidance

Step 8: Mechanical Verification
  - Run lint/typecheck per ci_tool_detection.md (only if verdict=Done)

Step 9: Update & Commit
  - Set task status, update kanban, post review comment
  - If Done: leave branch changes uncommitted for downstream branch ownership rules

ワークフロー（簡潔版）

意味的な差分、クローングループ、参照、レビューの影響範囲が重要な場合は、まず hex-graph を使用します。利用可能な場合、ローカルのコード、設定、スクリプト、テストを読み込む際は、まず hex-line を使用します。MCP が利用できない、未対応、またはインデックス化されていない場合は、組み込みの Read/Grep/Glob/Bash を使って続行し、ブロックせずにフォールバックしたことをレビューに記録します。

1. taskId を解決： ガイドに従って Task Resolution Chain を実行します（ステータスフィルター：[To Review]）。

2. タスクを読み込む： タスク全体と親 Story をそれぞれ独立して読み込みます。タイプを判定します（ラベルが "tests" → テストタスク、それ以外 → 実装／リファクタリング）。

3. コンテキストを読む： タスク全体と親 Story を確認し、影響を受けるコンポーネント／ドキュメントを読み込み、利用可能であれば差分を確認します。 Hex MCP による高速化： グラフがインデックス済みの場合、セマンティックなリスクの概要には analyze_changes(path=project_root, base_ref="HEAD~1") を優先します。構造的変更の AST レベルの差分レビューには changes(path="src/", compare_against="HEAD~1") を使用します。 3b) ゴールゲート： レビュー前に、次の点を明示します：（1）REAL GOAL：このレビューで答えるべき品質上の問いは何か。（2）DONE：品質が十分であることを示す証拠は何か。（3）NOT THE GOAL：表面的な追認レビューとはどのようなものか。（4）INVARIANTS：どのような自明ではない制約があるか。このゲートが曖昧、または意見が分かれる場合に限り、references/goal_articulation_gate.md を読み込みます。

4. レビュー項目：

   仕様優先ゲート： AC を簡易チェックします。タスクの AC と実装を照合します。AC が明らかに未達成（BLOCKER レベル）の場合は、直ちに To Rework とし、残りの品質チェックを省略します。AC の完全な検証は Step 5 で実施します。 必読： references/clean_code_checklist.md、references/destructive_operation_safety.md を読み込みます。

   • ゴールの検証（回復パラドックス）： 実行者が REAL GOAL を明示している場合（タスクのコメントまたは実装から確認可能）、それが Story の目標成果物と一致することを検証します。実行者が副次的な対象（例：「ユーザーデータのエクスポートを可能にする」ではなく「エンドポイントを実装する」）をゴールとしている場合は、CONCERN を追加します：GOAL-MISFRAME: executor goal targets secondary subject, may miss hidden constraints.
   • ブループリントの完了状況（参考）： 実行時データが利用可能な場合（このタスクの .hex-skills/runtime-artifacts/runs/）、実行者のチェックポイントから PHASE_3 のブループリントと PHASE_6 の blueprint_status を読み込みます。次の場合は CONCERN として報告します：スキップした項目に正当な理由がない状態で completion_pct < 100、または正当な理由なく追加ファイルが計画数の 50% を超える場合。実行時データが利用できない場合は、実行者のサマリーにある metadata.blueprint_status を確認します。BLOCKER にはしません。
   • アプローチ：差分が Story の Technical Approach に沿っていることを確認します。異なる場合は、コードコメントに根拠が記載されていることを確認します。
   • クリーンコード： チェックリストに従い、4 つのカテゴリすべてを確認します。置き換えられた実装が完全に削除されていること。リファクタリングで API が変わった場合、呼び出し元が更新され、古いシグネチャが削除されていること。
   • ファイル横断の DRY： タスクで新規作成された関数／クラス／ハンドラーごとに、src/ を Grep し、類似する名前／パターンを（件数モードで）検索します。類似ロジックが 3 ファイル以上に存在する場合は、次の CONCERN を追加します：MNT-DRY-CROSS: {pattern} appears in {count} files — consider extracting to shared module. これにより、タスク単位のレビューでは見落とされる Story をまたいだ重複を検出します。
   • ファイル横断の DRY を優先（hex-graph）： hex-graph がインデックス済みの場合は、audit_workspace(path=scan_path, verbosity="minimal", limit=5, clone_member_limit=3) を使用して、返された clones を確認します。上限を引き上げるのは、限定プレビューでは不十分な場合に限ります。いずれかのメンバーがタスクで変更されたファイルに該当するグループを抽出します。一致ごとに CONCERN として MNT-DRY-CROSS を報告します。hex-graph が利用できない場合は、上記の Grep による名前検索に切り替えます。
   • ハードコードされた認証情報／URL／マジックナンバーがないこと。設定は環境変数／設定ファイルで管理されていること。
   • 破壊的操作のガード：上で読み込んだ destructive_operation_safety.md のコードレベルのガード表を使用します。重大度が CRITICAL／HIGH の場合は BLOCKER：SEC-DESTR-{ID}。MEDIUM の場合は CONCERN：SEC-DESTR-{ID}。
   • エラー処理：すべての外部呼び出し（API、DB、ファイル I/O）が try/catch または同等の仕組みでラップされていること。例外を握りつぶしていないこと。レイヤー構造が守られ、既存のコンポーネントが再利用されていること。
   • 副作用の範囲：副作用のカテゴリが 3 つ以上ある 末端のサービス関数は、CONCERN とします：ARCH-AI-SEB。例外：オーケストレーター／コーディネーター関数（3 つ以上のサービスをインポートし、順次処理を委譲するもの）には複数の副作用カテゴリが想定されるため、報告しません。
   • インターフェースの正直さ：読み取りを示す名前の関数（get_/find_/check_）に書き込みの副作用がある場合は、CONCERN とします：ARCH-AI-AH
   • ログ：エラーは ERROR、認証／支払いイベントは INFO、デバッグデータは DEBUG で記録します。ログに機密データを含めないこと。
   • コメント：WHAT ではなく WHY を説明していること。コメントアウトされたコードがないこと。公開メソッドに docstring があること。
   • 命名：プロジェクトの既存規約に従っていること（類似するファイルを 3 つ以上確認）。ドメイン用語以外の略語を使わないこと。単一文字の変数を使わないこと（ループを除く）。
   • エンティティの漏洩：ORM エンティティを API エンドポイントから直接返してはいけません。DTO／レスポンスモデルを使用します。（認証／支払いの場合は BLOCKER、それ以外は CONCERN）
   • メソッドシグネチャ：公開メソッドにブール値フラグのパラメーターを使用しないこと（enum／オプションオブジェクトを使用）。DTO を使わずにパラメーターを 5 個より多くしないこと。（NIT）
   • アルゴリズムの正確性（ループ、コレクション、境界値）： ループ内の break／continue／return は、最初の一致だけでなく、すべての一致項目を処理しますか？dict／set の内包表記は重複キーを適切に処理していますか（最後の値で上書きされ、データを失う可能性はありませんか）？ユーザー制御のデータに対して、LIMIT のない list(query.all()) や上限のないループはありませんか？リクエスト間で漏洩する可変の共有状態（接続プールの GUC、セッションのグローバル変数など）はありませんか？（データ損失／破損の場合は BLOCKER、それ以外は CONCERN）
   • イベントチャネルの整合性（タスク単位）： タスクの差分がイベント関連コード（NOTIFY／LISTEN／emit／subscribe／publish／on）に触れる場合は、次を確認します：（1）発行側と購読側のチャネル名文字列が一致すること。（2）チャネル名が新しい文字列リテラルの場合、対応するリスナー／発行側があるか src/ を Grep で検索します。不一致の場合は CONCERN：ARCH-EVENT-MISMATCH: publisher '{pub_name}' has no matching subscriber。対応する発行側がない場合は CONCERN：ARCH-EVENT-ORPHAN: subscriber '{sub_name}' has no matching publisher。
   • シンプルさの基準（タスク単位）： MNT-KISS-SCOPE と MNT-YAGNI-SCOPE をインラインで確認します。これらの参考用 CONCERN のいずれかを報告する場合に限り、references/simplicity_criterion.md を読み込みます。
   • コード効率（タスク単位）： 差分内の主要な関数を 2～3 個抜き取り、不必要な中間処理、イディオムがあるのに冗長な書き方をしている箇所、またはフレームワークの標準機能で処理できる定型コードを確認します。該当する場合は CONCERN として報告します：MNT-EFF-SCOPE: {pattern} in {file}。プロジェクトのコンテキストが不明確な場合に限り、references/code_efficiency_criterion.md を読み込みます。
   • フロントエンドのレビュー（条件付き）： レビュー対象のファイルに .tsx/.vue/.svelte/.html/.css が含まれる場合は、references/frontend_design_guide.md を読み込み、アクセシビリティ、コンポジション、タイポグラフィ、コピー、モーション、デザインシステムへの準拠を確認します。
   • ドキュメント：公開 API が変更された場合は API ドキュメントが更新されていること。新しい環境変数が追加された場合は .env.example が更新されていること。新しい概念が追加された場合は README／アーキテクチャドキュメントが更新されていること。
   • テストの更新／実行：実装／リファクタリングの場合は、影響を受けるテストが適切に調整されていること。テストタスクの場合は、プランナーテンプレートに従い、リスクベースの上限と優先度（≤15）を確認します。

5. AC の検証（実装タスクでは必須）： 必読： references/ac_validation_checklist.md を読み込みます。次の 4 つの基準に照らして実装を検証します。

   • AC の網羅性： すべての AC シナリオ（正常系＋エラー＋エッジケース）がカバーされていること。
   • AC の具体性： 正確な要件（HTTP コード 200／401／403、時間 <200ms、正確なメッセージ）が満たされていること。
   • タスクの依存関係： タスク N がタスク 1～N-1 のみを使用していること（N+1、N+2 への先行依存がないこと）。
   • データベースの作成： タスクが Story の範囲にあるテーブルのみを作成していること（一括でのスキーマ作成を行わないこと）。 いずれかの基準に不合格の場合は、チェックリストの具体的なガイダンスを添えて To Rework とします。

6. 副作用によるバグの検出（必須）： 影響を受けるコードをレビューする際、現在のタスクとは無関係なバグ／問題も積極的に探します。

   • 変更対象ファイルに既存するバグ
   • 隣接コードにある不適切なパターン
   • 関連コンポーネントのセキュリティ問題
   • サポート対象外の API、古い依存関係
   • 呼び出し元／呼び出し先関数におけるエラー処理の不足 副作用のあるバグが見つかった場合：
   • 同じストーリーに新しいタスクを作成します。
     • 設定済みのトラッカープロバイダーの createTask 操作を使用します。parentId = Story.id、ラベル ["bug", "discovered-in-review"]、ステータス Backlog、重要度に基づく優先度を渡します。
   • タイトル：[BUG] {Short description}
   • 説明：場所、問題、修正案
   • ラベル：bug、discovered-in-review
   • 優先度：重要度に基づいて設定します（セキュリティ → 1 Urgent、ロジック → 2 High、スタイル → 4 Low）
   • 先送りしないでください — タスクをただちに作成します。レビュー担当者が実行者の見落としを見つけたものです。

7. 判定（現在のタスクのみ）：

   • 軽微な指摘のみの場合：軽微な修正を適用し、Done に設定します。
   • 問題が残っている場合：理由（ベストプラクティスの参照先）と修正方法を説明するコメントを付けて、To Rework に設定します。
   • 副作用のあるバグは、現在のタスクを Done にする妨げにはなりません（別タスクとして扱います）。
   • Done の場合： ブランチの変更はコミットせず、レビューコメントと概要アーティファクトを添えて、承認済みのタスク状態を引き継ぎます。

8. 機械的検証（Done の場合）： 必須の読み込み： references/ci_tool_detection.md を読み込みます。 verdict == Done の場合：

   • ci_tool_detection.md の検出階層に従って、lint/typecheck のコマンドを特定します。
   • 特定したチェックを実行します（ガイドに従いタイムアウトを設定：リンターは 2 分、型チェックは 5 分）。 必須の読み込み： references/output_normalization.md を読み込みます。
   • FAIL がある場合 → §1 normalize → §2 deduplicate → §4 truncate to 50 lines に従って出力を正規化し、正規化済みの出力を添えて verdict を To Rework に変更します。
   • ツールが検出されない場合 → 情報メッセージを表示してスキップします。

9. 更新： 設定済みのトラッカープロバイダーでタスクのステータスを設定します（updateStatus）。カンバンを更新します：Done の場合 → タスクをカンバンから削除します（Done セクションでは個別のタスクではなくストーリーのみを管理します）。To Rework の場合 → タスクを To Rework セクションに移動します。指摘事項と対応を記載したレビューコメントを追加します。副作用のあるバグを作成した場合は、コメント内でその旨に触れます。

レビュー品質スコア

背景： レビュー結果を定量化することで、後続の判断を監査可能にし、レビューの一貫性を追跡できます。

計算式： Quality Score = 100 - (20 × BLOCKER_count) - (10 × CONCERN_count) - (3 × NIT_count)

手順 3〜5 の各指摘を分類します：

カテゴリ	重み	例
BLOCKER	-20	AC 未達、セキュリティ上の問題、エラーハンドリングの欠如、誤ったアプローチ
CONCERN	-10	最適でないパターン、ドキュメントの不足、テストの不足
NIT	-3	命名、スタイル、軽微なクリーンアップ

判定との対応：

スコア	判定	対応
90-100	Done	承認し、軽微な指摘への修正をその場で適用
70-89	Done (with notes)	承認し、今後対応する懸念事項を記録
<70	To Rework	指摘ごとの修正ガイダンスを添えて差し戻し

注： 副作用のあるバグ（手順 5）は現在のタスクの品質スコアに影響しません — 別個の [BUG] タスクになります。

重要なルール

• 一度に扱うタスクは 1 件です。副作用のあるバグは別個の [BUG] タスクとし、スコープを拡大しません。
• 品質ゲート：Done にする前に、スコープ内の問題をすべて解決するか、明確な修正ガイダンスを添えて差し戻します。
• テストタスクの違反（上限／優先度 ≤15）→ To Rework。
• 編集やコメントでは、タスクの言語（EN/RU）を維持します。
• 機械的チェック（lint/typecheck）は判定が Done の場合にのみ実行します。To Rework の場合はスキップします。

実行時の概要アーティファクト

必須の読み込み： references/coordinator_summary_contract.md、references/worker_runtime_contract.md、references/task_worker_runtime_contract.md を読み込みます。

共有コントラクト：

• summary_kind=task-status を出力します。
• スタンドアロンモードでは runId と summaryArtifactPath を省略します。
• 管理モードでは、ワーカーが検証済みのレビュー結果を書き込む前に、runId と正確な summaryArtifactPath の両方を渡します。

モニター（2.1.98+）： 30 秒を超えると予想される lint/typecheck コマンドには Monitor を使用します。代替手段：Bash(run_in_background=true)。

完了の定義

• ステップ1～9が完了している：タスクを解決し、コンテキストを読み込み、レビューのチェックに合格し、ACを検証し、副作用によるバグを作成し、機械的な検証に合格し、判断を適用している。
• 完了の場合：レビューで承認された後、タスクをカンバンから削除している。再作業の場合：修正の指針を添えてタスクを移動している。
• レビューコメントを投稿している（指摘事項と、該当する場合は[BUG]リスト）。
• 実行時の概要アーティファクトを共有タスクステータスの場所に書き込んでいる。

参照ファイル

• 環境状態： references/environment_state_contract.md
• ストレージモードの操作： references/storage_mode_detection.md
• [必須] 問題解決のアプローチ： references/problem_solving.md
• AC検証ルール： references/ac_validation_rules.md
• AC検証チェックリスト：references/ac_validation_checklist.md（4つの基準：完全性、具体性、依存関係、DB作成）
• クリーンコードチェックリスト： references/clean_code_checklist.md
• CIツールの検出： references/ci_tool_detection.md
• 出力の正規化： references/output_normalization.md
• カンバン形式：docs/tasks/kanban_board.md

---

バージョン： 5.2.0 最終更新日： 2026-03-24