openspec-apply-change

OpenSpec の変更からタスクを実装します。

ストアの選択： ユーザーがストア（このマシンに登録されている、独立した OpenSpec リポジトリ）を指定した場合、または作業対象がストア内にある場合は、openspec store list --json を実行して登録済みのストア ID を確認し、仕様や変更を読み書きするコマンド（new change、status、instructions、list、show、validate、archive、doctor、context、schemas、view）に --store <id> を渡します。選択後は、ワークフローの残りの間、--store <id> を継続して指定してください。以下に示す、これらのコマンドのストア指定がない例は、いずれも省略形です。実行する前にフラグを追加してください。たとえば、以下に示すストア指定なしの形式ではなく、openspec status --change "<name>" --json --store "<id>" を実行します。その他のコマンドでは、このフラグは使用しません。コマンドが出力するヒントには、すでにフラグが含まれています。後続のコマンドでもそのまま指定してください。ストアを指定しない場合、コマンドは最も近いローカルの openspec/ ルートを対象にします。

入力： 変更名を指定できます（例：/openspec-apply-change add-auth）。省略された場合は、会話の文脈から推測できるか確認してください。曖昧な場合や複数の候補がある場合は、利用可能な変更をユーザーに尋ねる必要があります。

手順

1. 変更を選択する

   名前が指定されている場合は、それを使用します。指定されていない場合：

   • ユーザーが変更について言及していれば、会話の文脈から推測します
   • アクティブな変更が 1 つだけなら、自動的に選択します
   • 候補が複数ある場合は、openspec list --json を実行して利用可能な変更を確認し、どれを選ぶかユーザーに尋ねます

   必ず次のように通知します："Using change: "。また、変更先を指定する方法（例：/openspec-apply-change <other>）も案内してください。

2. ステータスを確認してスキーマを把握する

   openspec status --change "<name>" --json
   

   JSON を解析し、次の内容を把握します：

   • schemaName：使用するワークフロー（例："spec-driven"）
   • planningHome、changeRoot、actionContext：計画の範囲と編集上の制約
   • タスクを含むアーティファクト（通常は spec-driven の場合は "tasks"。それ以外はステータスを確認します）

3. 適用手順を取得する

   openspec instructions apply --change "<name>" --json
   

   以下が返されます：

   • contextFiles：アーティファクト ID から具体的なファイルパスの配列への対応（スキーマによって異なり、proposal/specs/design/tasks または spec/tests/implementation/docs などがあります）
   • 進捗状況（合計、完了、残り）
   • ステータス付きのタスクリスト
   • 現在の状態に応じた動的な指示
   • 任意の context：選択したルートから現在必要な、プロジェクト指示の入力
   • 任意の operationGuidance：適用時の現在の参考ガイダンス

   状態に応じた対応：

   • state: "blocked"（アーティファクトが不足）の場合：メッセージを表示し、/openspec-continue-change の使用を提案します（インストールされていない場合は、openspec status --change "<name>" --json を実行して次のアーティファクトを確認し、openspec instructions <artifact-id> --change "<name>" --json を実行して作成方法を確認します）
   • state: "all_done" の場合：完了を伝え、アーカイブを提案します
   • それ以外の場合：実装に進みます

   context は、プロンプトレベルで必須の入力として扱ってください。内容を読み、考慮したうえで、実装時に関連するプロジェクトの事実、規約、制約を適用します。 operationGuidance は、任意で追加される助言として扱ってください。すべての項目を読み、考慮したうえで、組み込みのワークフローに適用でき、かつ矛盾しない項目に従います。

   これら 2 つのフィールドは、CLI が返す状態、不足しているアーティファクト、タスク、進捗状況、contextFiles、組み込みの instruction とは分けて扱ってください。これらのフィールドはタスク完了の根拠にはならず、組み込みの指示の代わりにもならず、ブロック状態を回避することも許可しません。context が組み込みの指示、ユーザーの明示的な選択、または CLI が管理する値と矛盾する場合は、その矛盾を報告し、優先される値を維持します。ガイダンスが適用できない場合や、これらの優先される入力と矛盾する場合は、それに従わず、理由を説明します。これらはプロンプトレベルの動作規約であり、強制可能なチェックではありません。

4. コンテキストファイルを読む apply instructions の出力にある contextFiles に記載されたすべてのファイルパスを読み取ります。 ファイルは使用中のスキーマによって異なります。

   • spec-driven：proposal、specs、design、tasks
   • その他のスキーマ：CLI 出力の contextFiles に従います

   ユーザーが別途その内容を求めない限り、context や operationGuidance をそのまま実装ファイルや計画成果物にコピーしないでください。

5. 現在の進捗を表示する

   次の内容を表示します。

   • 使用中のスキーマ
   • 進捗：「N/M tasks complete」
   • 残りのタスクの概要
   • CLI からの動的な指示

6. タスクを実装する（完了またはブロックされるまで繰り返す）

   保留中のタスクごとに、次の手順を実行します。

   • 作業中のタスクを表示します
   • 必要なコード変更を行います
   • 変更を最小限に抑え、対象を絞ります
   • tasks ファイルでタスクを完了としてマークします：- [ ] → - [x]
   • 次のタスクに進みます

   次の場合は一時停止します。

   • タスクが不明瞭な場合 → 明確化を求めます
   • 実装によって設計上の問題が明らかになった場合 → 成果物の更新を提案します
   • タスクの内容が仕様や tasks の記述を超える作業を必要とする場合、または仕様で定められた動作を実現するために、範囲を縮小したり、後回しにしたり、例外を認めたりしようとしている場合 → 追加の作業範囲を明示して確認を求めます。黙って取り込んではいけません
   • エラーやブロッカーが発生した場合 → 報告して指示を待ちます
   • ユーザーが中断した場合

7. 完了または一時停止時にステータスを表示する

   次の内容を表示します。

   • 今回のセッションで完了したタスク
   • 全体の進捗：「N/M tasks complete」
   • すべて完了している場合：アーカイブを提案します
   • 一時停止している場合：理由を説明し、指示を待ちます

実装中の出力

## Implementing: <change-name> (schema: <schema-name>)

Working on task 3/7: <task description>
[...implementation happening...]
✓ Task complete

Working on task 4/7: <task description>
[...implementation happening...]
✓ Task complete

完了時の出力

## Implementation Complete

**Change:** <change-name>
**Schema:** <schema-name>
**Progress:** 7/7 tasks complete ✓

### Completed This Session
- [x] Task 1
- [x] Task 2
...

All tasks complete! You can archive this change with `/openspec-archive-change`.

問題発生による一時停止時の出力

## Implementation Paused

**Change:** <change-name>
**Schema:** <schema-name>
**Progress:** 4/7 tasks complete

### Issue Encountered
<description of the issue>

**Options:**
1. <option 1>
2. <option 2>
3. Other approach

What would you like to do?

ガードレール

• 完了またはブロックされるまでタスクを進めます
• 開始前に必ずコンテキストファイルを読み取ります（apply instructions の出力から取得）
• タスクが曖昧な場合は、実装前に一時停止して確認を求めます
• 実装によって問題が明らかになった場合は、一時停止して成果物の更新を提案します
• コード変更は最小限に抑え、各タスクの範囲内に限定します
• 各タスクの完了後、すぐにタスクのチェックボックスを更新します
• エラー、ブロッカー、不明確な要件がある場合は一時停止し、推測で進めないでください
• タスクが仕様に記載された範囲を超える作業を必要とする場合は、追加の作業範囲を明示して一時停止します。仕様で定められた動作を黙って縮小、延期、簡略化してはいけません
• 指定された動作が完全に実装されている場合にのみ、タスクを - [x] にします。一部のみの実装や延期ではマークしません
• 特定のファイル名を想定せず、CLI 出力の contextFiles を使用します
• タスク完了の根拠として、コンテキストや操作ガイダンスを使用しないでください
• 関連するプロジェクトコンテキストを適用し、ワークフローを制御する入力との競合を報告します
• すべてのガイダンス項目を検討し、適用できない内容や競合する助言について説明します
• 実行時のコンテキストや操作ガイダンスを実装ファイルや計画成果物にコピーしないでください
• CLI が制御するブロック中／実行可能／すべて完了の状態と完了条件を維持します

流動的なワークフローとの連携

このスキルは「変更に応じたアクション」モデルに対応しています。

• いつでも呼び出せます：すべての成果物が完成する前（tasks が存在する場合）、部分的な実装の後、または他のアクションと交互に実行する場合
• 成果物を更新できます：実装によって設計上の問題が明らかになった場合は、フェーズに縛られず柔軟に作業し、成果物の更新を提案します