implementing

実装

承認済みの技術計画を実装し、各ステップで検証しながらフェーズごとに実行します。各フェーズは desplega:phase-running を介してバックグラウンドのサブエージェントとして実行され、メインセッションはオーケストレーターとして機能します。

作業上の合意事項

ユーザー向けの質問はすべて AskUserQuestion を通じて行ってください。規約については desplega:ask-user を参照してください。通常の箇条書きでチャット上から質問してはいけません。

読み取り、調査、検証の作業はすべてサブエージェントを通じて行ってください。ツールの生出力をメインセッションに表示しないでください。デフォルトで run_in_background: true を指定します。

以下の自律性モードによって、確認を求める頻度が決まります。質問には常に AskUserQuestion を使用してください。

重要な変更がフェーズで行われた場合は、デフォルトでファイルレビューを実施します。インラインのフィードバックを得るために /file-review:file-review <path> を実行してください（Autopilot の場合のみ省略します）。

使用するタイミング

このスキルは、次の場合に有効になります。

• ユーザーが /implement-plan コマンドを実行した場合
• 別のスキルが **REQUIRED SUB-SKILL:** Use desplega:implementing を参照している場合
• ユーザーが既存の計画の実行または実装を依頼した場合

自律性モード

自律性モードに応じて動作を調整してください。

モード	動作
Autopilot	すべてのフェーズを実行し、手動検証またはブロッカーがある場合のみ一時停止します
Critical（デフォルト）	フェーズ間で一時停止して承認を求め、不一致が見つかった場合は質問します
Verbose	こまめに確認し、大きな変更を行う前に確認を求めます

自律性モードは呼び出し元のコマンドから渡されます。指定がない場合は、デフォルトの Critical を使用します。

初期設定の質問

ユーザーの設定を確認した後、AskUserQuestion を使用して、実装に関する詳細を確認します。

1. ブランチ／ワークツリーの設定

まず、現在のブランチを確認します：git branch --show-current

次に、wts プラグインが利用可能か確認します（利用可能なスキルに wts:wts があるかを調べます）。

wts プラグインがインストールされている場合は、以下の選択肢を使って AskUserQuestion で質問します。

質問	選択肢
「現在のブランチは <current-branch> です。どこで実装しますか？」	1. 現在のブランチで続行する、2. 新しいブランチを作成する、3. wts ワークツリーを作成する

wts プラグインがインストールされていない場合は、以下の選択肢を使って AskUserQuestion で質問します。

質問	選択肢
「現在のブランチは <current-branch> です。どこで実装しますか？」	1. 現在のブランチで続行する、2. 新しいブランチを作成する

2. コミット方法

以下の選択肢を使って AskUserQuestion で質問します。

質問	選択肢
「実装中のコミットをどのように扱いますか？」	1. 各フェーズの完了後にコミットする（複雑な計画におすすめ）、2. 最後にコミットする（すべての変更を1つのコミットにまとめる）、3. 状況に応じて判断する

「各フェーズの完了後にコミットする」が選択された場合：

• 各フェーズの検証完了後、[Phase N] <phase name> というメッセージでコミットを作成します
• コミットメッセージには計画のフェーズ説明を使用します

3. コードレビューモード

以下の選択肢を使って AskUserQuestion で質問します。

質問	選択肢
「各フェーズの後に自動コードレビューを実行しますか？」	1. フェーズごとに2つの観点から自動レビューする（おすすめ）、2. 最後にのみ実施する（完了前に1回だけレビュー）、3. オフ — 自分でレビューする

Autopilot ではこの質問を省略し、フェーズごとの自動レビューをデフォルトにします。

これらの設定を保存し、実装全体を通して適用してください。

以前の学習内容の確認

任意のサブスキル： ~/.agentic-learnings.json が存在する場合は、作業を始める前に /learning recall <current topic> を実行して、関連する以前の学習内容を確認します。

はじめに

プランのパスが指定された場合：

1. プランを最後まで読みます
2. 既存のチェックマーク（- [x]）を確認します
3. フロントマターのstatusフィールドを編集し、プランのステータスをstatus: in-progressに設定します。これにより、どのプランがアクティブかを進捗追跡フックに知らせます。
4. ファイルを最後まで読みます。limit/offsetパラメーターは決して使用しないでください
5. 各要素がどのように連携するかを深く考えます
6. 進捗を追跡するためのToDoリストを作成します
7. 実施内容を理解したら、実装を開始します

プランのパスが指定されていない場合は、パスを尋ねてください。

実装の考え方

プランは慎重に設計されていますが、実際の状況は複雑な場合があります。以下を行ってください：

• 見つかった状況に合わせて調整しながら、プランの意図に従います
• 次に進む前に、各フェーズを完全に実装します
• より広いコードベースの文脈に照らして、実装内容が妥当かを検証します
• セクションを完了したら、プランのチェックボックスを更新します

プランと実際の状況が完全には一致しない場合は、その理由を考え、明確に伝えてください。

不一致への対応

不一致が発生し、自律モードがAutopilotではない場合：

• STOPして、プランに従えない理由を深く考えます
• AskUserQuestionを使って問題を提示し、指示を仰ぎます：

質問	選択肢
「フェーズ[N]で問題が発生しました。予定されていた内容：[プランの記載内容]、実際の状況：[実際の状況]。重要な理由：[説明]。どのように進めますか？」	1. 実際の状況に合わせてプランを調整する、2. 当初のプランどおりに進める、3. 停止して相談する

Autopilotモードでは、最善の判断を行い、決定事項をコメントに記録します。

検証方法

各フェーズは、バックグラウンドのサブエージェントがdesplega:phase-runningを実行して進めます：

1. メインセッションでフェーズの概要を読みます（コンテキストの使用は最小限に抑えます）
2. プランのパスとフェーズ番号を指定して、desplega:phase-runningエージェントをバックグラウンドで起動します：
   • run_in_background: trueを指定してAgentツールを使用します
   • プランのパスとフェーズ番号をコンテキストとして渡します
3. エージェントの完了を待ちます。完了すると通知されます
4. エージェントのレポートを確認します。ステータス（completed/blocked/failed）、変更されたファイル、検証結果を確認します
5. QA Docのステータスを確認します。フェーズエージェントがQA Doc: <path>を報告した場合、リンク先のQAドキュメントには実行が必要なシナリオがあります。desplega:qaをQAドキュメントのパスに対して実行します（QA: n/aの場合は通常どおり進めます）。注：フェーズのSuccess Criteriaに含まれる自動QA項目はフェーズエージェントがすでに処理しています。ここで別途実行を調整する必要があるのは、リンク先のQAドキュメントのみです。
6. フェーズごとのコードレビューを実施します（レビューがOffでない場合）。フェーズの差分に対してdesplega:code-reviewingを実行します。StandardsとSpecの観点で、desplega:delegate-workに従って振り分けたサブエージェントをバックグラウンドで並列実行します。仕様の参照元はフェーズ本文とSuccess Criteriaです。重大な指摘がある場合、フェーズを完了できません。コミット前に修正して再検証してください。「Only at the end」が選択されている場合は、実装完了前に差分全体を一度レビューします。
7. 手動検証をユーザーと行います。フェーズの手動検証項目を提示します
8. ユーザーの確認後、次のフェーズに進みます

実装スキルはオーケストレーターです。フェーズを調整し、人間による確認ポイントを処理し、フェーズをまたぐ判断を管理しますが、実際の実装作業はphase-runnerサブエージェントに委任します。

実行役の振り分け：desplega:delegate-workスキルが利用可能な場合は、phase-runningサブエージェントを既定とせず、振り分け表に基づいて各フェーズの実行役を選択します。フェーズによってはCodexのバリアントや特定のClaudeモデルのティアに振り分けられることがあります。変更されるのは実行役の選択のみです。ここに記載されているその他の内容（自律モード、確認ポイント、プランの記録、検証、コミット戦略）は変わりません。

人間による検証のための一時停止（Autopilot以外、または複数フェーズを実行する場合）

Phase [N] Complete - Ready for Manual Verification

Automated verification passed:
- [List automated checks that passed]

Please perform the manual verification steps listed in the plan:
- [List manual verification items from the plan]

Let me know when manual testing is complete so I can proceed to Phase [N+1].

複数のフェーズを連続して実行するよう指示された場合は、最後のフェーズまで一時停止を省略します。

ユーザーの確認を得るまでは、手動テスト項目にチェックを付けないでください。

行き詰まった場合

想定どおりに動作しない場合：

1. 関連するコードをすべて読み、理解したことを確認します
2. 計画の作成後にコードベースが進化していないか検討します
3. 不一致を明確に示し、指示を求めます（Autopilot の場合を除く）
4. 的を絞ったデバッグでは、サブタスクの使用を必要最小限にします

作業の再開

計画にすでにチェックマークが付いている項目がある場合：

• 完了した作業は完了済みとして扱います
• 最初の未チェック項目から再開します
• 以前の作業に問題がありそうな場合にのみ、確認します

学びの記録

任意のサブスキル： このワークフロー中に重要な知見、パターン、注意点、判断が得られた場合は、desplega:learning を使って /learning capture 経由で記録することを検討します。今後のセッションでほかの人に役立つ学びに焦点を当てます。

実装の完了

すべてのフェーズが完了し、検証されたら：

1. 計画のフロントマターにある status フィールドを completed に設定します。
2. 自動検証のチェックボックスが更新されていることを確認します。
3. ユーザーが完了を確認するまで、手動検証のチェックボックスは未チェックのままにします。
4. 実装後の監査を提案します：「実装後の監査として /verify-plan を実行し、その後、最終的な品質チェックとして /review を実行しますか？」
5. 作業を GitHub PR として公開する場合：レビューコメントが届いたら、desplega:tackle-gh-comments で対応します（スレッドを取得し、各指摘を検証して修正、返信、解決した後、最後にプッシュします）。

忘れないでください。目的はチェックボックスを埋めることではなく、解決策を実装することです。最終目標を念頭に置いてください。

レビューとの連携

ファイルレビューはデフォルトで有効です（Autopilot の場合を除く）。

• 各フェーズで重要なコード変更を行った後、インラインの人間によるコメントを得るために /file-review:file-review <changed-file-path> を実行します
• 次のフェーズに進む前に、file-review:process-review スキルを使ってフィードバックに対応します