# Plan Tasks

> develop/direction.md に書かれたユーザーからの指示（と、承認を得たエージェントのドラフト）を develop/tasks.json のタスクに分解して登録し、指示メモを docs/history/direction.md へ移す。ユーザーが「指示をタスクにして」「direction.md を処理して」と言ったとき、またはセッション開始時に develop/direction.md に未対応の指示があったときに使う。

- Skill: `sinnlosses/plan-tasks` (Agent Skill)
- Install (CLI): `npx skillmds@latest add sinnlosses/plan-tasks`
- Raw SKILL.md: https://api.skillmd.com/api/skills/sinnlosses/plan-tasks/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: sinnlosses (https://skillmd.com/u/sinnlosses)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/sinnlosses/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つも無い（この変更より前に作られた）ファイルは、
   全体を `## ユーザーから` とみなす**（後方互換）:

   ```bash
   # ## ユーザーから
   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` が数十件あるプロジェクトでは本文だけで数万文字になる）:

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

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

   ```bash
   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 のフィールド」。

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

   ```bash
   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セッション遅れる」だけで、直す場所としては遅い）。
   転記は判断を含まないので**手で書き写さず**、スクリプトに任せる:

   ```bash
   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` のサイズ（前後）