start-work

AIエージェントを活用した作業のフローを定義し、フロー通りに動かすための起点スキル。superpowers のフレームワークで実行可能なすべての作業の入り口として機能する。

いつ使うか

新しい作業を開始する時は、必ず最初にこのスキルを呼ぶこと。ここで言う「作業」とは、新規開発、機能追加、改修、リファクタリング、バグ修正、デバッグ、コードレビュー、調査、PoC、ガイドライン拡張など、superpowers のフレームワークで扱える全ての作業を指す。

責務境界

start-work が正本として持つのはオーケストレーション（フェーズ構造・次手ナビゲーション・節目の前後で行う共通処理の接続の記述・セッション終了処理）のみである。ドメイン規範の正本は所有スキルへ、所有スキルが無いものは references/ 配下へ置き、本文には発火点のポインタのみを書く。

重要な前提: 継続的ADR検出ルール

このスキルから始まる全ての作業期間中、意思決定を検出した瞬間に decision-log スキルを呼んで ADR ドラフトを作成する継続ルールが常時適用される（AGENTS.md でも宣言されている）。「スキルの途中だから後で」は禁止。検出トリガーの定義一覧とドラフトのコミットのタイミングは decision-log スキルが正である。

手順

設計案を提示するときは references/decision-delegation.md を読み、判断の分担を設計に含める。計画・実装への移行、レビュー・ADRの確定、次手判断で同じ分担を適用する。初期合意・許可の有効範囲・累積影響の判定は同ファイルを正本とし、既存の妥当性検査・操作承認は維持する。

Phase -1: 依存検出

スキル冒頭で以下を確認する:

1. superpowers プラグインの存在を確認する
2. 主要スキル（brainstorming, writing-plans, executing-plans, subagent-driven-development, systematic-debugging, requesting-code-review, receiving-code-review, verification-before-completion, finishing-a-development-branch）の利用可否を内部マッピング表に記録する
3. 不足があればユーザーに報告する:
   「superpowers の <スキル名> が見つかりません。該当フェーズではインライン簡易フローへフォールバックします。」
4. 本セッションで新規追加/改定した ai-driven-dev-principles スキルの availability は、AI 側の system-reminder（available-skills 一覧）または Skill ツール呼び出し可否で判定する（UI の /skills 表示には依存しない）。反映が確認できない場合はユーザーへ /plugin marketplace update ai-driven-dev-principles の実行を依頼する（AI からは実行不可）

Phase 0: セッション継続チェック

1. session-handoff スキルの read 操作を呼ぶ
2. 結果に応じて分岐:
   • ハンドオフなし → Phase 1 へ
   • ハンドオフあり → 内容の要約をユーザーに提示し「前回の続きから始めますか?」と確認（read が確認の記録の未記録のマイルストーンを報告した場合はあわせて提示する）
     • Yes → ハンドオフの「次セッション開始時のアクション」に従って該当ワークフローの再開ポイントへ移動し、Phase 2 から続行
     • No → Phase 1 へ

Phase 1: 状況診断（state assessment）

1. リポジトリ状態を確認する:
   • git branch --show-current
   • git status（未コミット変更の有無）
2. docs/inbox/ を確認する（ディレクトリ一覧の取得のみ。ファイル内容は読まない）:
   • README.md 以外のファイルが存在する場合、件数をユーザーに伝え、organize-inbox スキルの実行を提案する（強制はしない）
   • ユーザーが後回しを選んだ場合、handoff の「既知のブロッカー・懸念」に滞留件数を記録する
3. 会話・引き継ぎ・既存資料から今回の作業意図（目的・スコープ・成功基準）を把握し、次の作業を決めるうえで不足する情報だけユーザーに確認する。既知の事項を再質問しない。
4. ハンドオフが存在しない場合は session-handoff の create 操作を呼んで新規作成する

Phase 2: 次手のナビゲーション（ループ）

ユーザーの作業意図に応じて、以下のマッピングから推奨スキルを提示する:

作業意図	推奨スキル	フォールバック
新規開発・機能追加・改修	superpowers:brainstorming	インライン簡易ヒアリング
brainstorming 完了後・計画作成前の機能ブロック分割	feature-block-design（適用要否を内部判定）	スキップして writing-plans へ
既存仕様からの計画作成	superpowers:writing-plans（実行直前に references/plan-deviation-defaults.md〈計画逸脱判断の既定の正本〉を読んで適用）	インライン簡易plan作成
既存planの実装	superpowers:executing-plans または superpowers:subagent-driven-development（いずれも実行直前に references/plan-deviation-defaults.md〈計画逸脱判断の既定の正本〉を読んで適用）	インラインTDDサイクル
バグ修正・デバッグ	superpowers:systematic-debugging	インライン仮説立案→検証→修正
コードレビュー対応	superpowers:receiving-code-review（確定済み計画の実行中の場合は references/plan-deviation-defaults.md〈計画逸脱判断の既定の正本〉を適用）	インライン指摘整理→対応
コードレビュー依頼	superpowers:requesting-code-review	インラインPR説明作成
完了前検証	superpowers:verification-before-completion	インラインチェックリスト確認
feature ブランチの完了処理（既定ブランチへの取り込み）	superpowers:finishing-a-development-branch（実行直前に references/merge-practice.md〈マージ方式確認の正本〉を読んで適用）	インラインで慣行確認＋マージ手順を案内
ガイドライン拡張	extend-guidelines	（本プラグイン提供のスキル、フォールバック不要）
inbox の整理	organize-inbox	（本プラグイン提供のスキル、フォールバック不要）
調査・分析・PoC	アドホック	アドホック
サブプロジェクト完了直後の振り返り	retrospective	（本プラグイン提供のスキル、フォールバック不要）
計画・仕様など非コード成果物の確定前レビュー（確定点での提示・反復・実施。規則の正本は同スキル）	pre-finalization-review	（本プラグイン提供のスキル、フォールバック不要）

次手は判断の分担に照らし、委任範囲内なら理由を通知して続行し、範囲外・調査後も不明ならユーザーに確認する（正本は references/decision-delegation.md。推奨を強制せず、ユーザーの意図優先）。
確定前レビューの提示・推奨順位・反復・停止判定の正本は pre-finalization-review（提示操作）である。確定点に到達したら同スキルを提示操作で呼ぶ（実施は個別指示または判断の分担に従う）。ここで列挙する到達時点は次の 2 種に限る: spec 確定点＝brainstorming の設計が確定し feature-block-design を適用しないと判断した時点（同スキルの起動有無を問わない）、plan 確定点＝superpowers:writing-plans が完了したとき（インライン簡易 plan の確定を含む）。
選択されたスキルへ delegate する。

完了工程への接続

実装完了・対策済み課題のクローズ・作業の終了依頼では、以下に従って完了工程へ接続する。課題のクローズだけをブランチ全体の完了とは扱わない。

1. 既存経路と残作業を確認する。executing-plans / subagent-driven-development が持つ finishing-a-development-branch への必須接続を優先し、必要な検証・最終レビューを飛ばさない。これらを経ない場合も、合意範囲の残作業と検証・レビューの結果を確認する。残作業があればその作業へ戻る。ただし明示的な中断では再開せず、セッション終了処理で引き継ぐ。
2. 進行状態から続ける。完了スキルが実行中・選択待ち・実行済みなら、重ねて起動せずその状態から続ける。完成済みで未マージなら、取り込み要求が明示されていなくても完了スキルへ接続する。調査のみ、不採用・重複によるクローズ、PRのレビュー待ち、明示的な取り込み保留は、その状態と次手を引き継ぐ。非Git環境・既定ブランチへの直接変更では自己マージを行わず、該当する検証・記録へ進む。
3. 取り込みの判断と実行を委譲する。完了スキルの選択肢の意味・環境分岐・前後の検証・停止条件を維持する。表示言語・推奨順位・質問形式は適用先の上位指示に従い、表示の調整を理由に操作の選択肢を増減しない。同じ対象・方法へのユーザーの明示承認が有効な範囲では、その指示を選択として引き継ぐ。対象変更や新たなリスクで承認範囲を外れる場合は必要な判断を求める。マージ方式設定や単なる継続指示を実行承認とせず、方式確認と操作前レビューは「作業前の確認」に従う。完了スキルが無い場合はPhase 2のインライン案内を使い、不在を無確認実行の根拠にしない。
4. 到達状態に応じて次へ進む。マージ直後は retrospective へ接続し、同スキルのユーザー判断と仕上げを経て引き継ぎへ進む。実装・検証、ローカル統合、リモート反映のどこまで済んだかを報告し、未完了分は次手を示す。PR作成や作業ブランチのpushだけで統合済みと報告しない。外部への書き込みは既存の操作承認とユーザーの指示に従う。

節目の前後で行う共通処理（全スキル実行の前後で適用）

スキルへ delegate する前後で以下を実施する:

作業前の確認:

• 不可逆操作・大規模変更の可能性があれば pre-action-review スキルを呼ぶ
• サブエージェントへ作業を委譲する場合は subagent-dispatch スキルを呼び、委譲プロンプトの制約ブロック（常時適用の 4 件＋条件発火の判定行）を組み立てる
• 完了処理〈既定ブランチへの取り込み〉を行うスキル・手順の実行直前は、references/merge-practice.md（マージ方式確認の正本）を読んで適用する。本条項は冒頭の適用範囲文（「delegate する前後」）の例外として、delegate 済みスキルが内部で呼ぶ必須サブスキルの実行直前にも適用される（節目の確認の発火粒度は現行のまま変わらない）
• 計画作成（writing-plans またはインライン簡易 plan）へ進む直前、および実装系スキル（executing-plans / subagent-driven-development またはインライン TDD）へ delegate する直前は、references/plan-deviation-defaults.md（計画逸脱判断の既定の正本）を読んで適用する。適用は委譲中に発生する実装時レビュー・実装者検証の指摘受領時にも及ぶ（本条項も冒頭の適用範囲文の例外として delegate 済みスキル内部の当該時点に適用される。節目の確認の発火粒度は現行のまま変わらない。二重発火の抑止と再開時の扱いは正本の「発火点」節が正）

節目の確認:

以下の項目を1つずつ明示的に確認して記録する。確認の結果は session-handoff update が handoff の「節目ごとの確認記録」へ1行で残す（記録対象・形式・値の定義は session-handoff スキルが正）。ハンドオフ更新（項目2）の完了は worklog-record（項目3）の免除にならない。

確定点を通過したマイルストーンでは、先に確定前レビューの提示または委任に基づく通知を行い、個別回答または有効な委任による判断結果が確定してから update を呼ぶこと（review= の値は判断の根拠と結果が揃ってから確定するため）。順序が前後して update を先に済ませてしまった場合は、個別回答を得た時点または有効な委任による判断結果が確定した時点で当該行へ review= を追記する。

1. ADR候補検出: 実行中に行われた意思決定が decision-log の検出トリガー一覧に該当するか自己評価し、該当すれば decision-log スキルを呼ぶ（実行中に既に作成済みのものは除く。トリガーの定義は同スキルが正）。

   設計を確定させた ADR ドラフトをコミットする場合は、コミットの直前が spec 確定点にあたる（設計文書ファイルを作らない拡張の型）。pre-finalization-review の提示操作を呼んで提示すること。

   また、設計承認・実装完了などのチェックポイントを通過した場合、Proposed のまま据え置かれている ADR のうち決定が確定したものの Accepted 昇格、不採用が確定したものの Rejected 更新、未コミットドラフトのうち関連論点が収束したもののコミットを行う。手順は decision-log の references/status-updates.md「承認の昇格」（サイクル全体整合検査・粒度の点検を含む）「ステータス変更」と references/adr-authoring.md「コミットのタイミング」が正であり、ここには重複して書かない。

   改訂対象が Accepted 済み ADR 本文である場合は、意思決定の有無を問わず decision-log の references/status-updates.md「ステータス変更」の改訂記録規定を適用する。

2. ハンドオフ更新: マイルストーン到達と判断したら session-handoff の update 操作を呼ぶ。マイルストーンの例:

   • スキルの完了
   • plan の 1 タスク完了
   • 重要な分岐の通過

3. 作業記録の追記: マイルストーン到達時、worklog-record スキルを呼ぶ。マイルストーン契機・記録ゲートの判定・発火結果の「節目ごとの確認記録」への記載は同スキルが正である

4. 次手ナビゲーションへ復帰: Phase 2 へ戻る

セッション終了処理

ユーザーが「ここまで」「続きは別セッションで」と明示した時、または明らかなセッション終了サイン（PR作成完了、作業完了宣言など）を検出した時:

1. 合意した作業範囲の完了・中断と統合状態を確認する。未マージの場合は「完了工程への接続」の条件に従い、完成済みなら取り込み方法の案内へ、明示的な中断・保留等なら記録へ進む。統合済みの作業へ完了スキルを再起動しない（マージ実行前の方式確認は references/merge-practice.md が担う）。
   • 統合済みなら、当該サイクルの振り返りの進行状態と実施記録を確認する。未実施なら retrospective を起動し、実施中ならその続きへ戻り、実施済みなら重ねて起動しない。課題候補の修正・起票判断は同スキル内でユーザーに委ね、仕上げを経て引き継ぐ。ユーザーが明示的に延期を指示した場合は、その指示と残作業をhandoffへ記録する。
2. 未コミットの ADR ドラフトがないか確認し、関連論点が収束済みのものはコミットする。Accepted 昇格漏れ・不採用確定分の Rejected 更新漏れの確認と合わせて行い、昇格する場合は decision-log の references/status-updates.md「承認の昇格」の手順（サイクル全体整合検査を含む）に従う
3. worklog-record を呼ぶ。セッション切り替え直前の発火契機（節目かどうかを問わない）・記録ゲートの判定・発火結果の「節目ごとの確認記録」への記載は同スキルが正である
4. session-handoff の finalize 操作を呼ぶ
5. ハンドオフの「次セッション開始時のアクション」が確実に埋まっていることを確認する
6. 今回終了した範囲を報告する。セッションの終了と作業全体の完了を区別し、未統合・レビュー待ち・未送信等があれば、その状態と次手を示す。

インラインフォールバックの内容

superpowers が無い環境でも最低限動くよう、各フェーズの簡易ガイダンスを以下に記載する。

要件明確化（brainstorming 不在時）

1. 会話・引き継ぎ・既存資料から不足する情報だけを1問ずつ確認する（複数質問を1メッセージに混ぜない）。既知の事項を再質問しない。
2. 確認候補: 目的、スコープ、制約、成功基準、関係者・利用者。次の判断に必要な不足項目だけを尋ねる。
3. 2-3案を比較してアプローチを選ぶ → ADR候補
4. 設計の概要をユーザーに提示し承認を得る

計画（writing-plans 不在時）

1. タスクを箇条書きで列挙する
2. 各タスクの依存関係を明示する
3. 各タスクのファイルパスを明示する
4. 各タスクの完了基準（手動でも自動でも）を明示する

実装（executing-plans 不在時）

1. plan の 1 タスクを取り出す
2. テストを先に書く（TDDサイクル）
3. 最小限の実装でテストを通す
4. リファクタリング
5. コミット
6. 次のタスクへ

デバッグ（systematic-debugging 不在時）

1. 再現手順を確認する
2. 仮説を立てる（何が原因か）
3. 仮説を検証する（ログ追加、最小再現、二分探索）
4. 原因を修正する
5. 再現手順で再検証する

対応する原則

• 原則1（追跡可能性）: ADRゲート、handoff の自動適用
• 原則2（関心の分離）: ワークフローのオーケストレーションを独立した責務として分離
• 原則3（コンテキスト管理）: handoff によるセッション間コンテキスト引継ぎ
• 原則4（人間の関与）: 次手選択、ADR承認、handoff 確認
• 原則5（漸進的検証）: マイルストーン単位での handoff 更新