task

/task

サーフェスルーティング

開始する前に、作業に適したツールを選んでください。

作業	ツール	理由
アーキテクチャの計画	Claude Code /plan	Opus、1M コンテキスト
機能の実装	Claude Code	フック、サブエージェント、ワークツリー
単一ファイルの簡単な修正	VS Code Claude ext	小規模な作業に向いており、より高速
DevOps／ターミナル	Codex CLI	ターミナル作業に強い
バックグラウンドでのリファクタリング	Codex Cloud	実行を任せて PR を作成
コードレビュー	GitHub Actions	非同期で、セッションコストがかからない
テストの作成	subagent: test-writer (CC) / inline (Codex)	分離されたコンテキスト
ドキュメント作成	subagent: doc-writer (CC) / inline (Codex)	低コストで、作業に集中できる
調査	Claude.ai Projects	永続的なプロジェクト、ウェブ検索

ツール間の注意事項

このスキルでは Claude Code の機能を使用します。Codex／Cursor での代替方法は次のとおりです。

Claude Code	Codex / Cursor
TaskCreate / TaskUpdate	.branch-context.md に Markdown チェックリストを作成
EnterWorktree	すべての操作で絶対パスと git -C を使用
/orient、/brainstorming など	.agents/skills/<name>/SKILL.md を読み、手動で実行
サブエージェントのディスパッチ（implementer、test-writer）	メインセッションで順番に実行
Agent Teams	未対応 — 順番に作業
/review、/plan-review	.agents/skills/review/SKILL.md を読み、手動で実行

引数

呼び出し	動作
/task <description>	新しいタスクを開始
/task #<issue>	GitHub issue から開始
/task	新しいタスクを開始 — 何に取り組むかを確認

Copilot モード

Copilot モード（operating-mode.md）では、ワークフローはパイプラインではなくメニューです。

• 実行可能なステップを提示します。人間から依頼された作業を実行し、順序を強制しないでください。
• ワークツリーを最初に使う方針は緩和され、プライマリワークツリーへの書き込みが許可されます。
• 以下の不変条件は、operating-mode.md で明示的に上書きされている場合を除き、引き続き適用されます。
• 人間から「ワークフローに従って」と指示された場合は、各移行時に承認を求めながら、ステップごとに実行してください。

不変条件

これらのルールはエージェントが解釈するガイダンスであり、機械的に強制されるものではありません。明記されている場合を除き、タスクの種類や範囲にかかわらず省略できません。記載がないことは許可を意味しません。省略可能と明示されていないステップは、すべて必須です。

REQUIRE task_list.all_steps_populated BEFORE step_1
REQUIRE worktree BEFORE code
REQUIRE orient.complete BEFORE plan
REQUIRE tests BEFORE implementation  # TDD: RED → GREEN → REFACTOR
REQUIRE review(plan).pass BEFORE build UNLESS scope == one_sentence OR task_type IN [fix, hotfix]
REQUIRE validate.pass BEFORE review(build)
REQUIRE review(build).pass BEFORE archive
REQUIRE task_list.no_pending_steps BEFORE ship
REQUIRE branch.base IS CURRENT(origin/main) UNLESS stacking
REQUIRE plan.commit BEFORE review(plan)
REQUIRE batch.commit BEFORE batch.next

WHEN ci.down:
  USE local_merge AT step_8
WHEN files_touched MATCH [AGENTS.md, config.toml, sync.sh, skills]:
  REQUIRE codex_specialist IN review_panel

ステップ

ステップ 3〜5 の間に、重要な決定を .branch-context.md に記録してください。振り返りや中断のタイミングだけに記録するのではありません。

ステップ 0 — 初期設定

検出されたパスのすべてのステップを含むタスクリストを作成してください。例外なく、各ステップをタスクとして登録します。タスクリストは実施を徹底するための仕組みです。保留中のタスクが、必須作業の未完了を示します。

• Claude Code：各ステップにつき 1 つずつ TaskCreate でタスクを作成します。最初にすべてのステップを登録し、orient でパスが検出された後に調整します。開始前に in_progress、完了後に completed に設定します。
• Codex/Cursor：すべてのステップを含む Markdown チェックリストを .branch-context.md に追加します。

ステップ 1 — 状況確認

引数を指定して /orient を呼び出します（Codex：.agents/skills/orient/SKILL.md を読みます）。次の情報が出力されます。

• task_type：feat / fix / chore / docs / test / refactor
• scope：差分全体を 1 文で説明できますか？はい → 短縮パス（ステップ 3〜4 を省略）。いいえ → 通常パス。注：説明が短いことと変更が小さいことは同じではありません。「すべての依存関係を更新する」は短い説明に見えても、数十個のファイルに影響する場合があります。

orient の完了後、検出されたパスに応じて、残りのステップをタスクリストに登録します。

• ホットフィックス（fix/*、hotfix/*）：範囲にかかわらず、必ずステップ 3〜4 を省略します。計画と計画レビューは行わず、ステップ 5 に直接進みます。
• 1 文で説明できる範囲（すべてのタスク種別）：ステップ 3〜4 を省略します。
• それ以外：通常パス（ステップ 0〜9）に進みます。

Step 2 — 分離

Step 1 のブランチ名を指定して /isolate を実行します（Codex：.agents/skills/isolate/SKILL.md を読みます）。鮮度の確保（origin main のフェッチ）、origin/main からのワークツリー作成、ディレクトリの選択、gitignore の安全性確認、依存関係のインストール、ベースラインテストの検証を行います。すでにワークツリー内にいる場合は、新しいワークツリーを作成せず、ブランチを最新の状態にします。

パスの扱い： Claude Code の Bash 呼び出し間では cd の状態は維持されません。ワークツリーの作成後は、すべてのファイル操作で絶対パスを使用し、git コマンドには git -C <absolute-path> を使用してください。cd の状態が引き継がれることを前提にしてはいけません。

Step 3 — 計画

ホットフィックス（fix/*、hotfix/*）： スキップし、Step 5 に進みます。アーキテクトエージェントも計画ファイルも不要です。代わりに、コミットメッセージに診断を1段落で記載します。ログには「Step 3 — Plan: SKIPPED (hotfix fast path).」と記録します。

1文で説明できるスコープ： スキップし、Step 5 に進みます。ログには「Step 3 — Plan: SKIPPED (one-sentence scope).」と記録します。

全スコープ：

3a. ブレインストーミング。 タスクの説明を添えて /brainstorming を実行します。1ラウンドでアイデアを洗練し、制約を確認して、2〜3通りのアプローチを検討します。

3b. 計画を作成。 ai-workspace/plans/TEMPLATE.md のテンプレートを使い、ai-workspace/plans/<name>.md に計画を作成します。以下を含め、テンプレートのすべての項目を埋めます。

• ブランチ、作成日、ステータス
• 脅威モデル（助言的または敵対的）
• スコープの上限
• タスクの説明とスコープ
• チェックボックス付きの手順（作成・変更するファイルとテスト戦略を含む）
• 信頼度の枠組み（敵対的な脅威モデルでは推奨）

ここでは計画をレビューしないでください。レビューは Step 4 で行います。

Step 4 — 計画のレビュー

計画なし（ホットフィックスまたは1文で説明できるスコープ）： スキップし、Step 5 に進みます。

計画あり：

計画ファイルを対象に /review を実行します（Codex：.agents/skills/review/SKILL.md を読み、手動で手順に従います）。

• 計画レビューのパネルを自動構成します。
  • 常に含める：technical-editor
  • コードアーキテクチャの場合：architect-reviewer を追加
  • AGENTS.md / config.toml / sync.sh / skills の場合：codex-specialist を追加
  • 認証 / 認証情報 / 権限の場合：security-auditor を追加
  • UI / コンポーネント / CSS の場合：ui-designer を追加
• 判定基準：P2（P0〜P2 を修正し、P3 以上は記録）
• 上限：3ラウンド

承認されたら Step 5 に進みます。 3ラウンド後にエスカレーションされた場合は停止し、未解決の指摘事項を人間に提示します。

Step 5 — 実装

/build を実行します（Codex：.agents/skills/build/SKILL.md を読みます）。計画の解析、バッチ順次／タスク並列でのサブエージェントのディスパッチ、TDD、バッチ間のリグレッションチェック、validate の必須ゲートを処理します。ホットフィックスまたは1文で説明できるスコープの場合は、TDD で直接実装します。/build が validate の合格を報告するまで、Step 6 を開始できません。

ホットフィックスの手順（task_type が fix または hotfix の場合に適用）：

• 不具合だけを修正しなければなりません。それ以外は変更しないでください（最小変更の原則）。
• ホットフィックス中にリファクタリングしてはいけません。クリーンアップは別のブランチで行ってください。
• まず失敗する具体的なケースをテストし（RED）、その後に修正します（GREEN）。
• 根本原因をコミットメッセージの本文に記載しなければなりません。
• 明示的な承認なしにエージェントプロファイルを変更してはいけません。

Step 6 — 実装のレビュー

変更したファイル（git diff main...HEAD）を対象に /review を実行します（Codex：.agents/skills/review/SKILL.md を読み、手動で手順に従います）。

• コードレビュー用パネルを自動構成します（Step 4 の計画レビュー用パネルとは異なります）。
  • 常に含める：code-reviewer
  • コードアーキテクチャの場合：architect-reviewer を追加
  • AGENTS.md / config.toml / sync.sh / skills の場合：codex-specialist を追加
  • 認証 / 認証情報 / 権限の場合：security-auditor を追加
  • UI / コンポーネント / CSS の場合：design-reviewer を追加
• 判定基準：P2
• 上限：3ラウンド

承認されたら Step 7 に進みます。 エスカレーションされた場合は停止し、未解決の指摘事項を人間に提示します。

Step 7 — アーカイブ

計画あり：

/archive を実行します（Codex：計画ファイルの Outcomes & Learnings を記入し、.done.md に名前を変更します）。計画ファイルの Outcomes & Learnings を記入し、.done.md に名前を変更します。

計画なし（ホットフィックス／1文で説明できるスコープ）：

根本原因または変更理由がコミットメッセージの本文に記載されていることを確認します。アーカイブする計画ファイルはありません。

ステップ 8 — 出荷

/ship を呼び出します（Codex の場合：.agents/skills/ship/SKILL.md を読みます）。検証、選択肢の提示（PR + 自動マージ、ローカルマージ、保持、破棄）、CI の稼働状況に応じた振り分け、ローカルパスでのシャロークローンマージ、ワークツリーのクリーンアップを処理します。CI のステータスは会話のコンテキストから判断します。ユーザーが CI は停止中だと伝えた場合、/ship はローカルマージのパスを使用します。

変更したファイルに AGENTS.md、config.toml、sync.sh、またはスキルが含まれる場合、レビュー担当に codex-specialist を含める必要があります（ステップ 6 で適用済み）。

ステップ 9 — 振り返り

/reflect を呼び出します（Codex の場合：.agents/skills/reflect/SKILL.md を読みます）。以下を処理します。

• セッションで得た学びを .branch-context.md から読み取る
• main 上の MEMORY.md に書き込む
• 必要に応じてフォローアップの issue を作成する
• ブランチの生成物をクリーンアップする

完了の定義

• 依存関係をインストールする（pnpm install）
• すべてのテストに合格する（pnpm test:all）
• 型チェックに合格する（pnpm typecheck）
• Biome のチェックに合格する（pnpm lint）
• フォーマッターのチェックに合格する（pnpm format:check）
• コードレビューを受ける（PR：別のエージェント、ローカルマージ：/review パネル）
• 計画ファイルの Outcomes & Learnings を記入する
• レビュアー向けの背景情報を含めて PR／コミットの説明を記述する
• ブランチを primary にマージする（PR または /local-merge を使用）
• /reflect で重要な学びをまとめ、primary にプッシュする

中断

どのステップでも /bail を呼び出すと、適切に中断できます。学びを .branch-context.md に記録し、issue を更新し、開いている場合は PR をクローズし、ワークツリーをクリーンアップします。Bail はステップ 9（振り返り）の代わりとなり、学びを自動的に記録します。未完了のタスクリスト項目があれば、クリーンアップしてください。