By name: write-task
description: >-
精緻化されたタスクやレビュー指摘を .artifacts/features//phases//task__.md へ書き込む時に使用する。
アトミックなタスク仕様をテンプレートに沿って構造化する。refiner・reviewer サブエージェントが使用する。
user-invocable: false
allowed-tools: [Read, Write, Edit, Glob]
task_<phase_num>_<task_num>.md 書き込みワークフロー
アトミックなタスク仕様を .artifacts/features/<feature>/phases/<phase>/task_<phase_num>_<task_num>.md へ
書き込む手順を定義する。refiner（精緻化タスク）と reviewer（レビュー指摘タスク）が使用する。
タスク命名規約
タスクファイルの命名と ID 規則は次のとおりとする。
- ファイル名:
.artifacts/features/<feature>/phases/<phase>/task_<phase_num>_<task_num>.md（例:phase_1/task_1_1.md、phase_2/task_2_3.md） - タスク ID: ファイル名の
task_<phase_num>_<task_num>部分をそのまま用いる （例:task_1_1、task_2_3）。state.db 上の ID もこの形式で揃える。 - 採番ルール: タスク番号
<task_num>は phase ごとに1から開始する。 別 phase であれば同じ番号を使ってよい（例:task_1_1とtask_2_1は別タスク）。 - review-fix の採番: レビューで起票する
review-fixタスクは、対象タスクと同じ phase の続番を割り当てる （例:phase_1で既存タスクがtask_1_5まであれば、次の review-fix はtask_1_6）。 - 採番は state.db で予約する（必須）: タスク番号は
operate-sqliteスキルのstate_dao.py reserve-task --feature <feature> --phase <phase>で予約する。 このコマンドは SQLite のトランザクション（BEGIN IMMEDIATE）でMAX(task_no) + 1を原子的に採番し、 予約したtask_<phase_num>_<task_num>を標準出力へ返す。返ってきた ID でファイルを作成する。Globで最大番号を読んでから採番する方式は read-then-write の競合を起こすため使わない。 - 並列起票での衝突回避: 複数のサブエージェント（refiner / reviewer）が同 phase へ並列に起票する場合でも、
各自が起票の冒頭で
reserve-taskを呼べば、state_dao.py側でロックが直列化され重複しない番号を得られる。 これにより後勝ち上書きによる起票内容の消失を防ぐ。
書き込み手順
Readで./template.mdを読み込む。- 採番が未確定の場合は、
state_dao.py reserve-task --feature <feature> --phase <phase>で タスク番号を原子的に予約し、返ってきたtask_<phase_num>_<task_num>を採用する （Globで最大番号を読む方式は使わない）。これにより state.db 上の予約とファイル名が同時に確定する。 - タスク ID に対応するファイル名（例:
task_1_1.md、task_2_3.md）で、.artifacts/features/<feature>/phases/<phase>/配下に新規作成する。 ファイル名・フロントマターid・本文見出しの ID は完全に一致させる。 - テンプレートのセクション構成を維持し、フロントマターとタスク本体を埋める。
- プレースホルダーはすべて実際の内容で置き換える。
type フィールドの使い分け
- impl: refiner が生成する通常の実装タスク。
- review-fix: reviewer がレビュー指摘から生成する修正タスク。
depends_onに対象タスクを記載する。
- タスクファイルは読み取り専用として扱う:
task_<phase_num>_<task_num>.mdは coder へのプロンプトとして扱い、 完了後も書き換えない。 - 完了状態は state.db に置く: 完了状態は
task_<phase_num>_<task_num>.mdではなくstate.dbに記録する （operate-sqliteスキル経由）。state.db 上のタスク ID もファイル名と同じtask_<phase_num>_<task_num>形式で揃える。 - 意味のある verify を指定する:
<verify>には単体テスト・型チェック・AST ベースのリンタなど 意味のある手段を指定する。grep -cのような単純なテキストマッチングは避ける （コメントにマッチし、テストを通すための改ざんを招くため）。 - 移動・リネームタスクは移動元の不在を検証する: ファイルやディレクトリの移動・リネーム・再配置を
伴うタスクでは、
<verify>に「移動先に存在すること」と「移動元が存在しないこと」の両方を必ず含める。 コピーで済ませて移動元が残る二重化を防ぐため、移動元パスの不在チェック（例:test ! -e <旧パス>）を 明示する。<done>にも移動元が消えた最終状態を記述する。 - 採番は reserve-task で原子的に行う:
state_dao.py reserve-taskで番号を予約してからファイルを作る。Globで最大番号を読む read-then-write 方式は並列起票で衝突するため使わない。