Plan Tasks

develop/direction.md に溜まった指示を develop/tasks.json のタスクに変換する。 ## ユーザーから はそのまま、## エージェントのドラフト はユーザーの承認を得たものだけが対象。 フィールド定義・difficulty の基準・アーカイブ運用は task-workflow スキルの WORKFLOW.md （以下「正典」）にあるのでここでは繰り返さない。

このスキルはタスクを登録するところまでで止める。実行はしない（実行は /next-task）。 分解そのものが方針決めを含み、正典「委譲しないケース」に当たるため、 サブエージェントに委譲せず、ユーザーがいるセッションで行う。/loop がこのスキルを 直接呼ぶこともしない。

ただし例外が1つある。/next-task は READY が0件で ## ユーザーから に中身があるとき、 無人でもこの手順をファイル入口（## ユーザーから）の分だけ実行する（正典「指示メモ」）。 以下で**/loop から呼ばれているとき**と書いたところは、この経路で無人で回ってきたときを指す。 そのとき塞ぐのは会話入口と ## エージェントのドラフト の2つで、ファイル入口は進めてよい。

このプロジェクトの設定（CLAUDE.md の「## タスク運用」節）

!sed -n '/^## タスク運用/,/^## /p' CLAUDE.md 2>/dev/null | grep . || echo '（「## タスク運用」節が無い。CLAUDE.md の他の節に書かれた検証コマンドを探す。無ければ /setup-tasks で節を用意する）'

以下で検証コマンドと書いたところは、この節の値に読み替える（タスクの「## 完了条件」に 書くのはこのコマンド）。値が なし なら、完了条件は検証可能な言葉だけで書く。節が無い 場合は「なし」と決めつけず、CLAUDE.md の別の節に書かれた検証コマンドを探す。 タスクIDの接頭辞（T-）とアーカイブの置き場（docs/history/）は規約で固定 （正典「ファイル配置と CLAUDE.md」）。 develop/tasks.json が無ければ、このプロジェクトでタスク運用を始めてよいかユーザーに 確認してから /setup-tasks で用意する（progress.md・direction.md も一緒に要る）。

手順

1. 読む: develop/direction.md を節ごとに読み、次の4分岐で進め方を決める （正典「指示メモ」の2節と入口2つ。判定は保守的に倒し、迷ったら拾わない）。

   節ごとの中身は次で見る。節見出しが1つも無い（この変更より前に作られた）ファイルは、 全体を ## ユーザーから とみなす（後方互換）:

   # ## ユーザーから
   awk '/^## ユーザーから/{f=1;next} /^## /{f=0} f' develop/direction.md | grep -v '^\s*$'
   # 節見出しが無ければ代わりにこちらの結果を「## ユーザーから」として扱う
   grep -v '^#' develop/direction.md | grep -v '^\s*$'
   
   # ## エージェントのドラフト
   awk '/^## エージェントのドラフト/{f=1;next} /^## /{f=0} f' develop/direction.md | grep -v '^\s*$'
   

   • ## ユーザーから に中身がある（節見出しが無い場合は上のフォールバックが空でない） → 以下の手順（手順2〜8）をファイル入口として従来通り進める。/next-task から無人で 回ってきたときに進めてよいのもこの分岐だけ（上の「例外が1つある」）
   • ## エージェントのドラフト に中身がある。かつこのスキルが /loop から呼ばれていない → ドラフトの各項目をユーザーに見せて承認を得たものだけ、手順2以降でタスク化する （正典「指示メモ」の承認ゲート）。承認を得られなかった項目は節に残す。 /loop から呼ばれているときはこの節を一切見ない（正典「指示メモ」の /loop の封じ）
   • どちらの節も空だが、会話に明示の指示がある（正典「指示メモ」の判定表に当たるもの。 「これタスクにして」「登録していいよ」提案への「それでいいよ」など。検討中の発言・ 思いつきは含まない）→ develop/direction.md への書き起こしを経由せず、 その場で手順2以降に進んで develop/tasks.json に直接登録し、手順6で docs/history/direction.md にも通常どおり追記する。このスキルが /loop から 呼ばれているときは、この分岐を使わない（会話入口はそもそも塞ぐ。正典「指示メモ」）
   • どちらの節も空で、会話にも明示の指示が無い → 従来通り、未対応の指示は無い旨を 報告して終了する

   あわせて既存タスクを一覧で見る。重複と依存を判断するのに要るのは summary と status と dependencies で、それは全部この出力に入っている。 develop/tasks.json を Read ツールで開いたり cat したりしない （todo が数十件あるプロジェクトでは本文だけで数万文字になる）:

   python3 ${CLAUDE_SKILL_DIR}/../task-workflow/scripts/status.py develop/tasks.json
   

   一覧を見て同じことを言っていそうなタスクが見つかったときだけ、その1件の本文を読む:

   python3 -c "import json,sys; print([t for t in json.load(open('develop/tasks.json')) if t['id']==sys.argv[1]][0]['task'])" T-XXX
   

   INVALID が出たら tasks.json が読めない（データの不備）。理由をそのまま報告して 終了し、登録に進まない（壊れたファイルへの追記は中身を失う）。python3 が落ちる 環境では全文読みで代用しない（どちらも /next-task の「スクリプトが動かないとき」と同じ）。 develop/progress.md は「未解決」「注意」だけ見れば足りる。

2. 確かめる: 指示の各項目について、現物のコードとドキュメントを読んで裏を取る。 指示は前提が古かったり、既に対応済みだったりする。ここで 「すでに満たされている」「事実と違う」と分かったものは、タスクにせずその根拠を添えて ユーザーに報告する（勝手に消さない）。

3. 分解する: 1項目＝1タスクとは限らない。分割も統合もしてよい。判断の目安:

   • 方針決めが要るものは前段のタスクとして切り出し、残りを dependencies で後ろに置く （例: キャッシュ機構の設計を1件にして、個別の適用4件をその依存にした）
   • 1タスクは「1コミットで説明が付く」大きさに収める
   • 既存タスクと重なるなら、新しく作らず既存タスクの本文を更新する

4. 書く: まず summary（何をするかの一行要約）を書く。1行に収まらなければタスクが 大きすぎる合図なので、手順3に戻って分ける。基準は正典「summary」。

   loopable を "N" にしたくなったら、登録するその場でユーザーへ聞く。正典「loopable」の 表で「事前に聞けば解けるか」が「解ける」に当たる理由（複数案のどれを採るかが未定／ 会話中の文脈に依存する／元に戻せない・外部へ反映する）なら、聞いた結果を ## 決まっていること（蒸し返さない） 節に焼き込んで "Y" で登録する。「対話的な検証が 必要」だけは聞いても解けないので、"N" のまま登録してよい。

   そのうえで、タスク本文は次の節で書く。節の名前もそのまま使う。

   • ## 背景: なぜこれをやるのか。指示の言い回しではなく、コードのどこがどうなっているかを ファイル名・関数名つきで書く（サブエージェントはまっさらな文脈で起動するため）
   • ## 決まっていること（蒸し返さない）（該当する場合のみ）: 上でユーザーへ聞いて解決した 判断の結果と、承認の範囲を1行ずつ書く。検討の経緯は書かない（それは ## 背景 の担当）
   • ## 解くべき論点: 判断が要る点を列挙する。difficulty が opus のタスクには必ず入れる
   • ## やること: 手順。調べた結果によって結論が変わるものは、「調べて成り立たなければ、 やらずに理由を evidence に書いて閉じる」逃げ道を明記する
   • ## 完了条件: 検証可能な言葉で書く。「適切に」「きれいに」のような読み手によって 結論が変わる語を使わない。検証コマンドがあるプロジェクトでは、それを通すことを毎回書く
   • ## 注意: 触ってはいけないもの、ユーザー承認が要るものなど。/loop に載せてよいか どうかは本文に書かず loopable フィールドで表す（正典「loopable」）。"N" にした 理由がコードを読まないと分からない場合だけ、この節に1行添える

5. 登録する: develop/tasks.json に追記する。id は T- + 3桁の通し番号の続き （アーカイブ済みの番号も再利用しない。正典「何を移すか」）、status: "todo"、 passes: false、evidence: ""。 summary・difficulty・loopable・dependencies は登録時に必ず埋める （後から付けない）。loopable は "Y" / "N" で、判断基準は正典「loopable」 （迷ったら聞く。聞けない状況のときだけ "N"）。difficulty とは独立に決める。 フィールドの並びは正典「tasks.json のフィールド」。

   追記したらその場で正典「いつ移すか（トリガー）」の判定を行う:

   python3 ${CLAUDE_SKILL_DIR}/../task-workflow/scripts/status.py develop/tasks.json | tail -2
   

   末尾2行が archive（tasks.json の判定）と progress（progress.md の判定）。 列の並びと他の末尾行の意味は /list-tasks に書いてある。

   todo は数えないので、タスクを足しただけではこの判定に引っかからない。 該当したらここでアーカイブする。次のセッションへ持ち越さない（/next-task の手順1でも 拾われるが、それは「気づかれるのが1セッション遅れる」だけで、直す場所としては遅い）。 転記は判断を含まないので手で書き写さず、スクリプトに任せる:

   python3 ${CLAUDE_SKILL_DIR}/../task-workflow/scripts/archive.py develop/tasks.json
   

   python3 が落ちる環境では、tasks.json を手で書き換えて代用しない。その旨とエラー出力を 報告して、アーカイブだけ見送る（登録は済んでいるので作業は無駄にならない）。

6. 指示メモを移す: 入口・書き手を問わず、docs/history/direction.md の先頭に 日付見出し（## YYYY-MM-DD）付きで追記する（ファイルが無ければ見出し # 未対応の指示メモ 1行で作る）。書くのは正典「指示メモ」が言う3点だけ （ユーザーの生の言い回し・項目や発言 → タスクIDの対応表・タスクにしなかった理由）。 噛み砕いた説明は書かない（tasks.json の ## 背景 と二重になる）。

   • ## ユーザーから（ファイル入口）: develop/direction.md の該当部分を当時の 記述のまま移し、その節を見出し行だけの状態に戻す（節見出しが無いファイルは ファイル全体を見出し行だけの状態に戻す）
   • 会話入口: develop/direction.md には何も書かれていないので、該当する発言を ユーザーの生の言い回しのまま日付見出しの下に書く（develop/direction.md は触らない）
   • ## エージェントのドラフト（承認を得た項目）: 承認を得た項目だけを移し、出典を 1行添える（例: （エージェントのドラフト / 承認: 「…」））。タスク化した項目だけを 節から取り除き、未承認の項目は節に残す（develop/direction.md はその節を空にしない）

   タスク化した時点で正典は develop/tasks.json に移る。「タスクが全部 done になるまで develop/direction.md に残す」ことはしない（正典が二重になるため）。

7. コミット: 1回の実行＝1コミットとし、件名は正典「コミットメッセージ」に従う （このスキル自体は特定のタスクIDを持たないので、件名にIDは付けない）。

   develop/progress.md に登録したタスクの一覧を書かない。 正典は develop/tasks.json で、一覧は /list-tasks が出す（正典「progress.md の構成」）。 タスク化の過程で出てきた判断待ちの事項は「未解決」に、踏み外しやすい前提は「注意」に 書く。それ以外の経緯はタスク本文の ## 背景 と docs/history/direction.md が持つ。

8. push はしない: 外部への反映は明示的に頼まれたときだけ行う。

完了報告のフォーマット

最後に必ず次を示す:

• 指示の各項目・発言 → 生成したタスクID の対応表（## ユーザーから の項目、会話入口で 拾った発言、## エージェントのドラフト から承認を得た項目の全てを含める。1対1でなくて よい）。## エージェントのドラフト 由来の項目は、承認を得た発言も添える。 タスクに しなかった項目は、その理由を書く。承認を得られず節に残したドラフトがあれば、その旨も書く。 取りこぼしの検知点はここだけなので必ず出す
• 登録したタスクの件数と、それぞれの summary・difficulty・loopable・dependencies。 loopable が "N" のタスクは、聞いても解けなかった理由を1行で書く（/loop が 拾わないタスクなので、ユーザーが自分で呼ぶ必要があることをここで伝える）
• develop/direction.md のどの節を空にした（あるいは一部だけ取り除いた）か、移した先 （docs/history/direction.md の日付見出し）
• アーカイブしたなら、移したタスクIDと develop/tasks.json のサイズ（前後）