ln-403-task-rework

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

タスクの手戻り対応

タイプ： L3 ワーカー

「手戻り」に指定された単一タスクの修正を実施し、レビューに戻します。

目的と範囲

• タスク全体、レビュアーのコメント、親ストーリーを読み込み、求められている変更を把握します。
• フィードバックに従って修正し、KISS/YAGNI を維持して、ガイド／技術的アプローチに沿わせます。
• このタスクだけを更新します。「手戻り」→「進行中」→「レビュー待ち」。ほかのタスクには触れません。

Hex-line による高速化（利用可能な場合）： 大きなコードファイルを読む前に outline(file_path) を使用します。調査には read_file() を使用し、revision とチェックサムが必要な編集の前には read_file(edit_ready=true, verbosity="full") を使用します。編集後は edit_file(base_revision=rev) → verify(checksums) の順で実行します。修正内容を示すには changes() を使用します。

入力

手戻り中にコード／設定／スクリプト／テストファイルを扱う際は、主な手段として read_file() と edit_file() を使用します。デフォルトでは read_file() を調査目的で使用し、edit_ready=true, verbosity="full" を指定するのは、そのリビジョン／チェックサムの手順を使用する直前に限ります。hex-line が利用できない場合に限り、組み込みの Read/Edit を代替手段として使用します。

入力	必須	ソース	説明
taskId	はい	args、親ストーリー、kanban、ユーザー	手戻り対象のタスク

解決方法： タスク解決チェーン。 ステータスフィルター： 「手戻り」

タスクの保存モード

必須の読み込み： references/environment_state_contract.md、references/storage_mode_detection.md、references/tracker_provider_contract.md、references/input_resolution_pattern.md を読み込みます。

task_provider = タスク管理 → プロバイダー（linear | github | file）を特定します。このスキルでの操作はプロバイダーに依存しません。標準的な操作セットについては references/tracker_provider_contract.md を、通信方式の割り当てについては provider_*.md を参照してください。

このスキルで使用するトラッカー操作：getTask、getStory、listComments、updateStatus（「手戻り」→「進行中」→「レビュー待ち」）、addComment。プロバイダーごとの通信方式は references/provider_file.md, references/provider_github.md, references/provider_linear.md に記載されています。

必須の読み込み： references/mcp_tool_preferences.md を読み込みます。コードファイルには、利用可能な場合は必ず hex-line MCP を使用してください。hex-line が停止していない限り、標準の Read/Edit には切り替えないでください。

ワークフロー（簡潔版）

1. taskId を解決： ガイドに従ってタスク解決チェーンを実行します（ステータスフィルター：[「手戻り」]）。
2. タスクを読み込む： 設定済みのトラッカープロバイダー経由でタスクとレビューコメントを読み込み（getTask、listComments）、親ストーリーを取得します（getStory）。 2b) 目標ゲート： 必須の読み込み： references/goal_articulation_gate.md を読み込みます。この手戻りの真の目標（「フィードバックを適用する」ではなく、実際に何が壊れていたのか）を明確にします。5 Whys（references/problem_solving.md）と組み合わせ、手戻りの目標とともに根本原因を明確にします。目標ではないもの：原因ではなく症状に対処する表面的なパッチ。
3. 修正を計画： 各コメントを具体的な対応に結び付け、新たな作業範囲が追加されていないことを確認します。
4. 実装： 必須の読み込み： references/code_efficiency_criterion.md を読み込みます。タスクの計画／チェックボックスに従い、設定／ハードコードの問題に対処し、「影響を受けるコンポーネント」と「既存コードへの影響」に記載されたドキュメント／テストを更新します。引き渡し前に、効率性に関する3つのセルフチェックを確認します。
5. 品質： 型チェック／lint（またはプロジェクト相当の処理）を実行し、修正がガイド／マニュアル／ADR／調査内容を反映していることを確認します。
6. 根本原因分析： 「エージェントが誤ったコードを生成したのはなぜか？」と問いかけます。原因を「コンテキスト不足」「誤ったパターン」「受け入れ条件が不明確」「ドキュメント／テンプレートの不足」に分類します。ドキュメント／テンプレートの不足が見つかった場合は、再発を防ぐため該当ファイル（ガイド、テンプレート、CLAUDE.md）を更新します。
7. 引き渡し： 設定済みのトラッカープロバイダー経由でタスクを「レビュー待ち」に設定し（updateStatus）、kanban 上でも移動して、解決したフィードバックと根本原因の分類を参照する要約コメントを追加します。

重要なルール

• 単一タスクのみとし、一括更新はしないでください。
• Done にしないでください。To Review のみとし、Done にするかどうかはレビュアーが判断します。
• タスクに合わせて言語（EN/RU）を統一してください。
• ここで新しいテストやタスクを作成しないでください。影響がある場合に限り、既存のテストを更新してください。
• コミットしないでください。 すべての変更を未コミットのままにしてください。変更のレビューとコミットはレビュアーが行います。

実行時サマリー成果物

必ず読むこと： references/coordinator_summary_contract.md、references/worker_runtime_contract.md、references/task_worker_runtime_contract.md を読み込んでください。

共有コントラクト：

• summary_kind=task-status を出力してください。
• スタンドアロンモードでは runId と summaryArtifactPath を省略してください。
• 管理モードでは、ワーカーが検証済みのサマリーを書き込む前に、runId と正確な summaryArtifactPath の両方を渡してください。

Monitor（2.1.98 以降）： 検証コマンドに 30 秒を超える時間がかかると予想される場合は、Monitor を使用してください。代替手段：Bash(run_in_background=true)。

完了の定義

• タスクとレビューのフィードバックをすべて読み、対応内容を割り当てました。
• 修正を適用し、必要に応じてドキュメント／テストを更新しました。
• 品質チェック（型チェック／Lint、またはプロジェクトの基準）に合格しました。
• 根本原因を分類しました（コンテキスト不足 | 不適切なパターン | 不明確な受け入れ基準 | ドキュメントの不足）。不足が見つかった場合は、ドキュメント／テンプレートを更新しました。
• ステータスを To Review に設定し、カンバンを更新して、修正項目と根本原因を記載したサマリーコメントを追加しました。
• 実行時サマリー成果物を共有の task-status の保存先に書き込みました。

参照ファイル

• 環境の状態： references/environment_state_contract.md
• ストレージモードの操作： references/storage_mode_detection.md
• [必須] 問題解決の進め方： references/problem_solving.md
• カンバンの形式：docs/tasks/kanban_board.md

---

バージョン： 3.0.0 最終更新日： 2025-12-23