ln-401-task-executor

パス： ファイルパス（references/、../ln-*）は、このスキルディレクトリからの相対パスです。

実装タスク実行者

種別： L3 ワーカー

タスクの説明とリンクされたガイドに従い、Todo から To Review まで、1 件の実装（またはリファクタリング）タスクを実行します。

目的と範囲

• 選択されたタスクを 1 件だけ処理します。他のタスクには決して触れません。
• タスクの Technical Approach／計画／AC に従い、KISS／YAGNI とガイドのパターンを適用します。
• このタスクのトラッカー／カンバンを更新します：Todo -> In Progress -> To Review。
• 型チェック／lint を実行し、タスクの指示に応じてドキュメント／テスト／設定を更新します。
• テストタスクには使用しません（"tests" ラベルのタスクは ln-404-test-executor に渡します）。

Hex MCP による高速化（利用可能な場合）： 大きなコードファイルを読む前に、対象を絞って inspect_path(path=<relevant dir>) と outline(file_path) を使用してください。意図的に必要な場合を除き、リポジトリルート全体を対象にしたワイルドカードの一覧取得は避けてください。検索／調査では、まず grep_search(output_mode="summary") を使用し、後続の編集に正規のハンクが必要な場合に限り、output_mode="content", edit_ready=true に切り替えてください。allow_large_output=true は、明示的に必要と判断した場合の最後の手段としてのみ使用してください。調査モードでは、構造と対象範囲を絞った読み取りに read_file() を使用してください。後続の編集に revision とチェックサムが必要な場合は、edit_file() の前に read_file(edit_ready=true, verbosity="full") でファイルを再取得してください。既存コードを編集する場合は、index_project(path=project_root) を 1 回実行し、重要な編集の前に analyze_edit_region(...) を使用してください。編集後は、edit_file(base_revision=rev) -> verify(checksums) の順に実行してください。引き継ぎの前に、差分を確認するため changes() を実行してください。

入力

入力	必須	ソース	説明
taskId	はい	args、親 Story、カンバン、ユーザー	実行するタスク

解決方法： Task Resolution Chain。 ステータスフィルター： Todo

タスクの保存モード

必ず読み込む： references/environment_state_contract.md、references/storage_mode_detection.md、references/tracker_provider_contract.md、references/provider_file.md、references/input_resolution_pattern.md を読み込みます。

抽出項目：task_provider = Task Management → Provider（linear | github | file）。このスキルの操作はプロバイダーに依存しません。標準の操作セットについては references/tracker_provider_contract.md を、トランスポートとのバインディングについては provider_*.md を参照してください。

ツールのポリシー：ホストの AGENTS.md にある MCP の設定に従ってください。ホストのポリシーがない場合、または MCP の動作が不明確な場合に限り、references/mcp_tool_preferences.md と references/mcp_integration_patterns.md を読み込んでください。コードファイルには、利用可能な場合は hex-line MCP を使用し、意味的な編集リスクに関する質問には hex-graph を使用してください。

モード検出

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

Plan Mode が有効な場合：

• ステップ 1～2：タスクのコンテキストを読み込みます（読み取り専用のため、Plan Mode で実行可能です）。
• EXECUTION PLAN（作成／変更するファイル、アプローチ）を生成し、計画ファイルに書き込みます。
• ExitPlanMode を呼び出して停止します。実装は行いません。
• ステップ 3～6：承認後、実装を実行します。

Normal Mode の場合：

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

TodoWrite による進捗管理

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

ルール：

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

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

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

Step 2: Load Context
  - Fetch full task description + linked guides/manuals/ADRs

Step 2b: Goal Articulation Gate
  - Complete 4 questions from references/goal_articulation_gate.md (<=25 tokens each)

Step 2c: Implementation Blueprint
  - From task "Affected Components": extract file paths (Glob/Grep or narrow `inspect_path(path=<component dir>)` to find actual paths)
  - Read each file (or key sections) to understand current structure
  - IF modifying existing code in supported languages: `index_project(path=project_root)` once, then use path-scoped `find_symbols` / `inspect_symbol` for exact symbol identity and `analyze_edit_region` before editing non-trivial ranges
  - IF `find_symbols` returns `partial ... truncated=1` or a broad candidate set: refine to `name + file` or `workspace_qualified_name` before planning from it
  - Output:
    ## Implementation Blueprint: {taskId}
    **Files to create:** [list with brief purpose]
    **Files to modify:** [list with what changes]
    **Change order (dependencies first):**
    1. {file} — {what and why first}
    2. {file} — {depends on step 1}
    **Risks:** {shared files with parallel tasks, if any}
  - Scope: ONLY files of this task. Do not analyze other tasks.

  - **Checkpoint:** Emit PHASE_3 checkpoint with structured `blueprint` payload:
    `{ "blueprint": { "change_order": [{ "file": "...", "action": "create|modify", "reason": "..." }] } }`
    Guard blocks PHASE_4 if blueprint is missing from the checkpoint.

Step 3: Start Work
  - Set task to In Progress, update kanban

Step 4: Implement
  - 4a Pattern Reuse: IF creating new file/utility, Grep src/ for existing similar patterns
    (error handlers, validators, HTTP wrappers, config loaders). Reuse if found.
  - 4b Follow task plan/AC, apply KISS/YAGNI
  - 4c Architecture Guard: IF creating service function: (1) 3+ side-effect categories in **leaf** function → split (EXCEPT orchestrator functions that delegate sequentially — these are expected to have 3+ categories);
    (2) get_*/find_*/check_* naming → verify no hidden writes; (3) 3+ service imports in **leaf** function → flatten (orchestrator imports are expected)
    (4) **Frontend Guard (conditional):** IF affected files include `.tsx/.vue/.svelte/.html/.css` → **MANDATORY READ:** Load `references/frontend_design_guide.md`. Load project's design_guidelines.md if exists (design tokens source of truth). Verify: one composition per viewport; max 2 typefaces + 1 accent color; cards only when interaction requires; motion max 2-3 purposeful; WCAG 2.1 AA contrast (4.5:1 text, 3:1 UI elements)
  - Update docs and existing tests if impacted
  - Execute verify: methods from task AC (test/command/inspect)

Step 5: Quality
  - Run typecheck and lint (or project equivalents)
  - 5b Blueprint Completion: compare actual changes to blueprint; emit blueprint_status in PHASE_6 checkpoint

Step 6: Finish
  - Set task to To Review, update kanban
  - Add summary comment (changes, tests, docs)

ワークフロー（簡潔版）

1. taskId を解決: ガイドに従って Task Resolution Chain を実行します（ステータスフィルター：[Todo]）。
2. コンテキストを読み込む: 設定済みのトラッカープロバイダー（getTask）を使ってタスクの説明全体を取得し、リンクされたガイド／マニュアル／ADR／調査資料を読みます。必要に応じてチーム／設定を自動検出します。 2b) ゴールゲート: 必ず読むこと： references/goal_articulation_gate.md を読み込み、4 つの質問からなるゲートを完了します（各回答は 25 トークン以内）。REAL GOAL（成果物を主語にする）、DONE LOOKS LIKE、NOT THE GOAL、INVARIANTS & HIDDEN CONSTRAINTS を明示します。 2c) 実装ブループリント: タスクの「Affected Components」から、Glob/Grep または対象を絞った inspect_path(path=<component dir>) を使って実際のファイルパスを特定します。各ファイルの主要なセクションを読みます。タスクでサポート対象言語の既存コードを変更する場合は、ビルドグラフのコンテキストを一度構築し（index_project）、パスを絞った find_symbols／inspect_symbol でシンボルの正確な識別情報を確認してから、編集前に重要度の高い範囲について analyze_edit_region を実行します。シンボルの検出結果が途中で切れている場合は、計画を立てる前に name + file または workspace_qualified_name で絞り込みます。構造化された計画を出力します。作成／変更するファイル、変更順序（依存関係のあるものを先に）、リスク（並行タスクで共有されるファイル、外部呼び出し元、パブリック API の範囲）を記載します。範囲はこのタスクのみです。
3. 作業を開始: 設定済みのトラッカープロバイダー（updateStatus）を使って、このタスクを In Progress に更新し、カンバン上でも移動します（Epic／Story のインデントは維持します）。
4. 実装（検証ループを含む）: 新しいユーティリティ／ハンドラーを作成する前に、 src/ を Grep して既存のパターン（エラー処理、検証、設定へのアクセス）を確認します。見つかった場合は再利用します。再利用できない場合は、理由をコードコメントに記載します。既存の関数、クラス、ルート、ミドルウェアを編集する場合は、事前に analyze_edit_region を実行し、外部呼び出し元、類似実装、下流のフロー、パブリック API のリスクを考慮します。チェックボックス／計画に従い、シンプルに保ち、値をハードコードせず、既存のコンポーネントを再利用します。「Affected Components」に記載されたドキュメントを更新し、影響を受ける既存のテストも更新します（ここでは新しいテストは追加しません）。サービス関数を作成する前に、Architecture Guard を適用します（カスケードの深さ、インターフェースの誠実さ、フラットなオーケストレーション。フロントエンドファイルの場合は、references/frontend_design_guide.md を必ず読み、存在する場合は design_guidelines.md を読み込み、構成／タイポグラフィ／WCAG の規則を確認します）。実装後、タスクの AC に記載された verify: 方法を実行します。test → 指定されたテストを実行、command → コマンドを実行して出力を確認、inspect → ファイル／内容の存在を確認します。検証に失敗した場合は、次に進む前に修正します。
5. 品質: 型チェックと lint（またはプロジェクトで同等のもの）を実行し、「Existing Code Impact」の指示に対応できていることを確認します。ブループリントの完了状況: 実際の変更をステップ 2c のブループリントと照合します。計画した各ファイルについて完了またはスキップ（理由を記載）を示し、計画外の各ファイルについて追加（理由を記載）を示します。PHASE_6 チェックポイントを出力します：{ "blueprint_status": { "planned_count": N, "completed": [...], "skipped": [{"file":"...","justification":"..."}], "added": [{"file":"...","justification":"..."}], "completion_pct": N } }。これがない場合、ガードによって PHASE_7 に進めません。
6. 完了: 設定済みのトラッカープロバイダー（updateStatus）を使ってタスクを To Review にし、カンバンも To Review に更新します。変更内容、実行したテスト、更新したドキュメントをまとめたコメントを追加します。

提出前チェックリスト

背景： 「レビュー待ち」にする前に自己評価を行うことで、レビューのやり取りを減らし、明らかな問題を早期に発見できます。

必読： references/code_efficiency_criterion.md を読み込みます — 提出前にセルフチェックしてください。

「レビュー待ち」にする前に、以下のすべての項目を確認してください。

#	チェック項目	確認内容
0	AC の検証済み	各 AC の verify: メソッドを実行し、合格を示す証拠がある
1	アプローチの整合性	実装がストーリーの技術的アプローチに沿っている
2	クリーンなコード	デッドコードや後方互換性用の回避コードがなく、未使用のインポートが削除されている
3	設定の衛生状態	認証情報、URL、マジックナンバーがハードコードされていない
4	ドキュメントの更新	影響を受けるコンポーネントのドキュメントに変更が反映されている
5	テストの合格	変更後も既存のテストに合格する
6	パターンの再利用	新しいユーティリティを既存のコードベースと照合し、重複するパターンを導入していない
7	アーキテクチャのガード	カスケードの深さが 2 以下（リーフ関数）。読み取りを示す名前の関数内に隠れた書き込みがない。リーフ関数内に 3 つ以上のサービスチェーンがない（オーケストレーターのインポートは除く）。フロントエンドファイルは references/frontend_design_guide.md に従い、コンポジション、タイポグラフィ、WCAG を確認する
8	破壊的操作の安全性	タスクに「破壊的操作の安全性」セクションがある場合：（1）破壊的なコードを実行する前にバックアップ手順を実行または計画している、（2）コードにロールバックの仕組みがある、（3）環境ガードがある、（4）プレビュー／ドライランの証拠を添付または参照している
9	コード効率	不要な中間処理がなく、冗長なパターンが言語の慣用表現に置き換えられ、定型的なフレームワークのハンドルがない（references/code_efficiency_criterion.md に従う）
10	ブループリントの完了	ブループリントのすべての項目が完了しているか、正当な理由を添えてスキップされている。PHASE_6 チェックポイントで blueprint_status が出力されている

必読： 重大度の分類と安全要件について、references/destructive_operation_safety.md を読み込みます。

HITL ゲート： タスクの重大度が CRITICAL（上記で読み込んだ destructive_operation_safety.md に基づく）の場合：「レビュー待ち」にする前に AskUserQuestion を使用して確認します。「タスクには CRITICAL に分類される破壊的操作が含まれます：{operation}。バックアップ計画：{plan}。続行しますか？」ユーザーの確認を得るまで、「レビュー待ち」にしないでください。

いずれかのチェックに不合格の場合： 「レビュー待ち」にする前に修正してください。防止可能な問題の発見をレビュー担当者に頼らないでください。

重要なルール

• 更新は単一タスクのみとし、ステータスを一括変更しないでください。
• 編集やコメントでは、タスクの言語（EN/RU）を維持してください。
• 説明にコードスニペットを記載しないでください。コードはリポジトリに置き、トラッカーの説明には記載しません。
• 新しいテストを作成しないでください。必要な場合に限り、既存のテストを更新します。
• オーケストレーターによる Foundation-First の順序を維持し、タスクを並べ替えないでください。
• コミットしないでください。 すべての変更を未コミットのままにしてください — レビュー担当者がレビューしてコミットします。
• 既存コードに対して重要な変更を行う前に、利用可能な場合は、ファイル名だけから影響範囲を推測するのではなく、グラフによる影響分析の証拠を使用してください。

ランタイムサマリー成果物

必読： 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 秒を超える時間がかかると予想される場合は、Monitor を使用します。代替手段：Bash(run_in_background=true)。

完了の定義

• タスクを選択して「進行中」に設定し、カンバンを適宜更新した。
• ガイド／マニュアル／ADR／調査資料を読み、アプローチがタスクの技術的アプローチに沿っている。
• 計画／AC に従って実装を完了し、各 AC の verify: メソッドを実行して合格を示す証拠がある。
• ドキュメントと影響を受けるテストを更新した。
• 型チェックとリンター（またはプロジェクトの品質チェックコマンド）が合格し、コメントに証拠を記載した。
• タスクを「レビュー待ち」に設定し、カンバンを「レビュー待ち」に移動し、サマリーコメントを追加した。
• ランタイムサマリー成果物を共有タスクステータスの保存先に書き込んだ。

Reference Files

• Environment state: references/environment_state_contract.md
• Storage mode operations: references/storage_mode_detection.md
• Guides/manuals/ADRs/research: docs/guides/, docs/manuals/, docs/adrs/, docs/research/
• Kanban format: docs/tasks/kanban_board.md

---

Version: 3.0.0 Last Updated: 2025-12-23