Next Task

develop/tasks.json を1サイクルぶん前に進める。フィールドの定義・difficulty の意味・ evidence の書き方・アーカイブのトリガーは task-workflow スキルの WORKFLOW.md （以下「正典」）にあるのでここでは繰り返さない。このスキルは1タスク分を実行して終わる。 全件 done になるまで繰り返したい場合は /loop /next-task として使う（/loop 側が 続行/停止を判断する）。

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

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

以下で検証コマンド・整形コマンドと書いたところは、この節の値に読み替える。 値が なし なら、そのコマンドは走らせず、タスク本文の「## 完了条件」だけで受け入れを 判定して、その旨を報告に書く。節が無い場合は「なし」と決めつけない——まだ節に移して いないだけで、CLAUDE.md の別の節に「変更後は必ず〜を通す」と書いてあることが多い。 それも無いときだけ、検証コマンド無しで進める。アーカイブの置き場 （docs/history/）と予算は規約で固定（正典「ファイル配置と CLAUDE.md」）。 develop/tasks.json が無いプロジェクトなら、タスク運用を始めていない旨を報告して終了する （勝手にファイルを作らない）。

タスク本文を読み込まない

1タスクの task 本文は数KBある。1件を選ぶために全件の本文を読まない。選ぶのに要る値 （status・dependencies・difficulty・loopable・summary）は全部 status.py の TSV に 出るので、本文を読むのは選んだ1件だけにする。develop/progress.md も同じで、このスキルが するのは「完了したこと」の先頭への追記だけなので、全文を読まない（判定は status.py の progress 行が出す）。

/list-tasks と同じ方針。tasks.json が数万文字まで育つ運用なので、ここを守るかどうかで 1サイクルのコンテキスト消費が一桁変わる。

スクリプトが動かないとき

status.py / archive.py は python3 を使う。python3 が無い・エラーで落ちる環境では、 tasks.json を全文読んで代用しない。 節約の仕組みが死んでいることに気づけないまま、 毎サイクル数万文字を読む状態になるため。

止まる理由は2つあり、報告先が違う。 混同すると、直すべき場所と違うところを指してしまう:

どちらも /loop 側は「続行不要」の合図として扱う。なお TSV の末尾に出る missing_field 行は 止まる理由にはならない（フィールドが欠けたタスクを ? で出したという報告で、一覧としては 成立している）。該当があれば完了報告に添える。

手順

1. 見渡す: 一覧と判定はスクリプトが出す。develop/tasks.json を Read ツールで開いたり cat したりしない（理由は下の「タスク本文を読み込まない」）。

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

   MISSING ならタスク運用を始めていない旨を報告して終了する。EMPTY なら登録されている タスクは0件。INVALID なら tasks.json が読めない（上の「スクリプトが動かないとき」）。 TSVの読み方は /list-tasks と同じ（列は id / status / difficulty / loopable / dependencies / 着手可否 / passes / summary）。

   末尾の archive 行（tasks.json の判定）か progress 行（progress.md の判定）が YES なら、着手前にアーカイブする（正典「いつ移すか（トリガー）」）。転記は判断を 含まないので手で書き写さず、スクリプトに任せる:

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

   出力の MOVED 行に、移したタスクIDとファイルサイズの前後が出る。完了報告にそのまま載せる。

   あわせて develop/direction.md を節ごとに見る（正典「指示メモ」の2節）。節見出しが 1つも無い（この変更より前に作られた）ファイルは、全体を ## ユーザーから とみなす （後方互換）:

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

   ## ユーザーから に中身があれば未タスク化の指示が残っている。READY なタスクが あるならそちらを止めず、READY が0件のときだけ手順2でその場でタスク化する （正典「指示メモ」）。 ## エージェントのドラフト の行数は「未承認のドラフトが溜まっている」という状態であって、 /plan-tasks を急かす理由にはしない（正典「指示メモ」の承認ゲート）。それぞれの行数を 完了報告に添える（手順2・「完了報告のフォーマット」で使う）。

2. 選ぶ: まず手順1のTSVに status が doing の行が無いか見る。あれば前回セッションの 異常終了で着手途中のまま残ったタスクなので、READY を選ぶより先にそちらを扱う。 doing は自動では拾い直さない（status.py の 着手可否 列も doing には READY を 出さない）。作業ツリーに何が残っているか分からない状態でサブエージェントに委譲すると、 「本文だけで作業が完結する」という前提（正典「difficulty に応じたモデルの切り替え方」）が 崩れるため。該当タスクIDを添えて「T-xxx が doing のまま残っている。作業ツリーを 確認してから再開するか判断してほしい」と報告して終了する（他に READY があっても、 まずここで止まる。/loop 側はこれを「続行不要」の合図として扱う）。 doing の行が無ければ、TSVで 着手可否 が READY の行から1件選ぶ（status: "todo" かつ 依存が全て解決済み。tasks.json に存在しない依存＝アーカイブ済み＝完了扱いは スクリプトが織り込み済み）。READY が無ければ（全件 done、または残りが全て BLOCKED:）、 手順1で見た ## ユーザーから の中身の有無で分かれる（## エージェントの ドラフト だけに中身がある場合は「中身が無い」側で扱う。正典「指示メモ」）:

   • ## ユーザーから に中身がある → ここで止めず、その場でタスク化して続ける。 plan-tasks スキルを読み、その手順2〜8（確かめる・分解する・書く・登録する・ 指示メモを移す・コミット）をファイル入口（## ユーザーから）の分だけに対して 実行する。手順の正典は /plan-tasks なのでここには書き写さない。 /loop から 回っている最中でも触ってよいのはこの節だけで、会話入口と ## エージェントのドラフト には従来どおり触らない（正典「指示メモ」）。タスク化のコミットはまだブランチを切る前 （デフォルトブランチ）で済ませ、done のコミットとは分ける（1タスク＝1コミット。 正典「コミットメッセージ」）。済んだら手順1のTSVを取り直し、着手可否 が READY の 行から1件選んで手順3へ進み、そのまま1サイクルを終える（選び方はこの手順の上と同じで、 /loop から回っているときは loopable: "N" を選ばないところまで変わらない）。 タスク化しても READY が1件も生まれなければ（登録したものが全て loopable: "N"、 依存で全て BLOCKED: など）、登録したタスクIDと READY が無い理由を添えて報告して 終了する
   • ## ユーザーから に中身が無い → 「進められるタスクが無い」とだけ報告して終了する （## エージェントのドラフト に未承認の行があれば、件数だけ添える）

   報告して終了したときは、どちらも /loop 側はこれを「続行不要」の合図として扱う。

   選んだら、その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
   

   /loop から回されているときは loopable が "N" のタスクを選ばない （正典「loopable」。フィールドが無いタスクは "Y" 扱い）。残りが "N" だけになったら 「ユーザーの判断が必要なタスクのみが残っている」と、そのタスクIDを添えて報告して終了する （/loop 側はこれを「続行不要」の合図として扱う）。ユーザーが直接 /next-task を 呼んだときは "N" も選んでよい。その場合は着手前に、ユーザーの判断が要る点を先に確認する。

3. ブランチ: 既定は選んだタスクの feature/T-<タスクID> ブランチを切って作業する （例: T-008 を選んだら git switch -c feature/T-008。デフォルトブランチから分岐する）。 プロジェクトの CLAUDE.md「## タスク運用」節の - ブランチ: 行がこの既定と違う運用を 書いていれば、そちらに従う（正典「ファイル配置と CLAUDE.md」）。

4. doing にする: 選んだタスクの status を "todo" から "doing" に書き換える。 develop/tasks.json の対象タスク1件だけを編集し、passes・evidence など他のフィールドは 触らない。この変更はコミットしない（作業ツリー上にだけ置く。理由と、done へ変わる タイミングは正典「tasks.json のフィールド」の status の行）。

5. 実行: Agentツールで、選んだタスクの difficulty と同じモデルを指定した サブエージェントに委譲する（正典「difficulty に応じたモデルの切り替え方」）:

   • haiku / sonnet / opus のいずれでも委譲する。メインセッションが今どのモデルで 動いているかは判断材料にしない（メインと一致していても委譲する。理由は正典 「なぜ一致していても委譲するのか」）
   • tasks.json の task 本文だけで作業が完結するよう、対象ファイル・完了条件・ 検証コマンドを通すことを明記して渡す（サブエージェントはまっさらな文脈で起動する）
   • task 本文を prompt に貼り付けない。 タスクIDと、手順2で使ったのと同じ読み取り コマンドを渡してサブエージェント側に読ませる（貼ると本文がメインの出力トークンになる。 正典「difficulty に応じたモデルの切り替え方」）
   • develop/tasks.json はコミットしないことを明記して渡す。 手順4で当該タスクの status を doing に書き換えた直後の状態で委譲が始まるため、サブエージェントが git add -A のような一括ステージングを行うと doing のままコミットされてしまう （記録は手順7でメイン側が行う）
   • ユーザーへの確認が必要な判断・会話中の文脈に依存する判断は委譲しない。これは モデル選択とは別の軸の話で、登録時の見立ては loopable に入っている。着手して 初めて分かった場合は loopable を "N" に直し、委譲せずユーザーに預けて次のタスクへ進む
   • 着手後に想定より判断が重いと分かったら、difficulty を上げてから改めて進める

6. 受け入れ: 委譲した場合は完了報告をそのまま信用せず、自分で差分（git diff）を確認し、 整形コマンドがあれば実行してから検証コマンドを実行して通ることを確かめる。 検証コマンドが「なし」なら、タスク本文の完了条件を1つずつ目視で確かめ、報告に 「検証コマンド未設定」と書く。方針からズレた実装（例: コメントの動機がすり替わっている、 命名が既存規約と衝突する）があればその場で直してから次に進む。

7. 記録してコミット: develop/tasks.json の対象タスクの status を "doing" から "done" に書き換え、passes/evidence も更新する（evidence は3行以内、後から検証できる 形で。正典「良いevidenceの書き方」）。develop/progress.md の「完了したこと」に、 そのタスクの小節を1つ、節の先頭に足す（### YYYY-MM-DD 何をしたか（T-xxx） の形で、 中身は1〜2文）。既にある小節に混ぜず、上に積む——並びが「新しい順」であることに アーカイブが依存していて、下に足すとスクリプトが ERROR を返して止まる （正典「progress.md の構成」）。

   1タスク＝1コミットとし、件名の先頭にタスクIDを置く（正典「コミットメッセージ」）。 手順4の doing への書き換えはコミットしていないので、ここでの差分は todo → done の1回ぶんになる。コミットメッセージの末尾は現在のセッションの attribution 指示（Co-Authored-By 等）に従う。

8. マージ: 作業ブランチをデフォルトブランチへふつうの git merge で取り込む （git switch main && git merge feature/T-XXX）。main がブランチの分岐後に進んで いなければ fast-forward で取り込まれ（コミットは増えない）、進んでいればマージコミットが できる。どちらでもよい。成功したら作業ブランチを削除する（git branch -d feature/T-XXX）。

   コンフリクトが起きたら、黙って解消しようとせず、コンフリクトしたファイルを報告して ユーザーに預けて終了する（resolving-merge-conflicts スキルで解消できる。/loop は これを「続行不要」の合図として扱う）。作業ブランチは削除せずに残す。

   検証コマンドを通す位置: fast-forward で済んだ場合は再実行しない（手順6で通した結果の まま main の内容が作業ブランチの到達点と同一になるため）。マージコミットができた場合は、 main で検証コマンドをもう一度通す（両側の変更が初めて同居する状態になるため。正典 「ファイル配置と CLAUDE.md」の「ブランチ運用」）。これが落ちたらmain を壊れたまま 放置せず、マージ直前の HEAD へ git reset --hard して main を元に戻す（作業ブランチには 同じコミットが残っているので作業は失われない）。reset の前に git status --short を見て、 自分が作ったのではない未コミットの変更が無いことを確かめる（あれば reset せず報告だけする）。検証コマンドの出力と main を巻き戻した旨を 報告してユーザーに預けて終了する（/loop はこれを「続行不要」の合図として扱う）。作業 ブランチは削除しない。

9. push はしない: 外部への反映は明示的に頼まれたときだけ行う。このスキルはローカルのマージまでで止める。

完了報告のフォーマット

最後に必ず次を1行ずつ示す（/loop が続行判断に使う）:

• 今回 done にしたタスクID
• 検証コマンドの結果（ファイル数・テスト件数。「なし」なら、完了条件を目視で確かめたこと）
• 残りの todo 件数（0なら「全タスク完了」と明言する）。うち loopable: "N" が 何件かも添える（/loop では進まないので、ユーザーが自分で呼ぶ必要があるため）
• このサイクルで手順2の分岐に入ってタスク化したなら、登録したタスクIDと、そのコミットが done のコミットとは別であること
• 未タスク化の指示（develop/direction.md）の有無。節ごとの行数を分けて書く （## ユーザーから / ## エージェントのドラフト）。タスク化した場合は移したあとの行数