| name | task |
| description | 実装タスクのスキルオーケストレーター。プロダクションコードの変更を伴うタスク（新規実装・修正・リファクタ・バグ修正のほか、「cloneして直してPRを出して」等のオペレーション依頼で差分にコード変更が含まれる場合を含む）の開始時に常に使用し、チェックポイント（着手前・実装開始・エラー遭遇・コミット前・PR前・区切り）ごとに該当スキルを理想順序で発火させながらタスク完遂まで進行を管理する。/task やりたいこと でも起動でき、引数なしはスキルカタログ表示。境界: コード変更を伴わない純粋な調査・質問応答・文書のみの編集では使わない。個別スキルの手順・完了基準には介入しない。 |
Task Orchestrator
プロダクションコード変更を伴うタスクの開始時に発火し、チェックポイントごとに「そのターンで生成・変更する成果物」に紐づくスキルを発火させながら完遂まで進行を管理する。スキルの発火漏れ（依頼文に対応語がないスキルの見落とし）を構造的に防ぐのが目的。
既存設定との関係
- Phase 0-5（@context/workflow-rules.md）: 複雑タスクではPhase 0-5が骨格。本スキルは「各Phase・各チェックポイントでどのスキルを発火するか」の管理のみ担う
- スキル発動ルール（AGENTS.md）: 「発火判定は依頼の文言ではなく成果物で行う」の実行機構が本スキル。各チェックポイントで成果物を確認して該当スキルを列挙する
- 個別スキルの手順が優先: 発火した各スキルのワークフロー・完了基準はそのスキルに従う。本スキルは順序の管理のみ行い、各スキルの手順に介入しない
ワークフロー（実装タスク）
Step 1: チェーンの計画（着手前）
- 成果物の確定: どのファイルを何行変えるかを見積もり、複雑タスク判定（AGENTS.md「作業フロー」の4条件）を行う
- チェーンの構築: 下のチェックポイント表を骨格に、成果物に紐づくスキルを割り当てる（表にない成果物はStep 3のカタログ生成で候補を探す）
- 提示: チェーンをユーザーに数行で1度提示する（承認待ちはせず、明らかな解釈違いを訂正できる機会として）。該当スキルが無いステップは通常のツールで実施する旨を明記
- 登録: 複雑タスクではチェーンをタスク管理機構（Claude Code: TaskCreate、Codex: plan）に登録し、05_log.mdに記録する
Step 2: チェックポイント駆動の実行
計画順に進め、各チェックポイント到達時に成果物を再確認して該当スキルを発火する:
| チェックポイント | 発火判定と代表スキル |
|---|
| 着手前 | 複雑タスク→Phase 0 + /findmem。要件が抽象→/design-feature。複数PR規模→/plan-feature-prs・/large-task。コード編集あり→worktree判定（AGENTS.md「worktree 運用ルール」） |
| 計画書の作成完了時（実装着手前） | 計画の外部レビュー（必須。@context/agent-cli-guide.md を Read してから実行し、Action Required = 0 まで回す） |
| 実装開始時 | /writing-code（プロダクションコード変更で常に。除外はスキル側の適用外条件に従う） |
| バグ・エラー・テスト失敗に遭遇 | /systematic-debugging（修正案を出す前に） |
| 実装完了・コミット前 | PJ品質チェック（lint/format/typecheck/test）→ /self-review |
| コミット | /commit（直接 git commit しない） |
| PR作成 | /create-draft-pr（直接 gh pr create しない） |
| レビュー実施・レビュー指摘対応 | 外部レビュー→@context/agent-cli-guide.md（減算パス含む）、PR全体→/pr-review、特定コメント→/pr-comment |
| Phase完了・承認待ち・compaction接近 | /handoff |
- 完了基準: 計画したチェーンの全ステップが「実行済み」または「スキップ（理由を05_log.mdに記録）」になっている
Step 3: カタログの動的生成（/task 引数なし、またはチェーン構築で表以外の候補が必要な時）
スキル一覧をハードコードせず、実行時にfrontmatterから取得する（スキルの追加・変更に自動追従させるため。真実源は各スキルのdescription）。frontmatter先頭ブロックのみを対象にする（単純なgrepは本文コードフェンス内のdescription:例を誤って拾い、description: |の複数行形式を取りこぼすため）:
for dir in ~/.claude/skills ./.claude/skills; do
[ -d "$dir" ] || continue
for f in "$dir"/*/SKILL.md; do
echo "== $(basename "$(dirname "$f")")"
awk '/^---$/{c++; next} c>=2{exit} c==1' "$f" \
| awk '/^description:/{d=1} d && /^[a-zA-Z_-]+:/ && !/^description:/{exit} d{print}'
done
done
加えて、システムプロンプトのAvailable skills（ビルトイン: code-review/verify/simplify等）も候補に含める。
カタログモード（/task 引数なし）: スキルを用途カテゴリ別（要件・設計 / 実装・大規模タスク / レビュー・品質 / コミット・PR / 指示ファイル管理 / その他）に整理し、各スキル1行（名前+いつ使うか）で表示して終了する。完了基準: user-level・project-level・ビルトインの3ソースの全スキルがいずれかのカテゴリに載っている。
Gotchas
- チェーンの深さはタスク規模に合わせる: 単純タスクでは
/writing-code → /self-review → /commit の最小連鎖でよい。チェーンを組むこと自体が目的ではない（本スキルの発火は全実装タスクだが、発火するスキル数は成果物次第）
- compaction耐性: 本スキル本文は圧縮で失われ得るため、チェーンの状態は必ずタスク管理機構/05_log.md側に持たせる（compaction後はそちらから復元する）
- カタログの鮮度: チェックポイント表は骨格の代表例であり、真実源は各スキルのdescription。表のスキルが存在しない環境ではStep 3のカタログ生成で代替を探す。本ファイルに個別スキルの一覧表を追記しない（陳腐化するため）
