ZDEV-XXR/make-videos-with-Remotion

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 を使用しているプロジェクトを想定しています。何か書き込みを行う最初のステップ（new change、archive、sync specs、またはアーティファクトファイルの作成）の前に、プロジェクトにルートがあることを確認します。openspec list --json を実行し（ストアが選択されている場合は --store <id> を付ける。ストアがルートになるため）、root を読み取ります。root オブジェクトがあればプロジェクトはセットアップ済みです。"root": null はセットアップされていないことを意味します。つまり、ここに openspec/ ディレクトリはなく、openspec new change などの書き込みは副作用としてそれを作成することになります。また、このコマンドは非ゼロで終了しますが、これは CLI の壊れではなくその回答です。リトライしたり回避したりせずに、JSON を読み取ってください。

"root": null に関する注意点が 1 つあります。status のエラーメッセージが Declared in または Invalid store declaration in で始まり、このプロジェクトの openspec/config.yaml（または config.yml）を指定している場合、プロジェクトは OpenSpec を使用していますが、宣言されたストアをこのマシンで解決できません（ストアが登録されていないか、store: 行が不正な形式です）。これを未初期化として扱ったり、以下の分岐をスキップしたりしないでください。書き込み前に停止し、そのエラーの message と fix をユーザーに表示してください。

それ以外のルートがない場合、このワークフローにどのように到達したかによって次の動作が異なります。

• 自動選択: ユーザーが OpenSpec やこのスキル、またはそのスラッシュコマンドを指定せずに、あなた自身がこのワークフローを選択した場合。OpenSpec の使用をやめ、OpenSpec がインストールされていない場合と同様にリクエストに通常通り回答してください。セットアップを求めたり、OpenSpec のセットアップについて言及したりしないでください。
• 明示的な OpenSpec リクエスト: ユーザーが OpenSpec またはこのスキルを指定したか、そのスラッシュコマンドを実行した場合。書き込み前に停止し、次の選択肢を提示してください: このプロジェクトをセットアップする（openspec init）、既存のストアをターゲットにする（--store <id>）、またはこのリクエストでは OpenSpec を使用せずに続行する。ユーザーの応答を待ちます。

どちらの分岐でも、ルートを副作用として作成しないでください。ユーザーが明示的に要求するまで openspec init を実行したり、openspec/ ファイルを手動で作成したり、コマンドに作成させたりしないでください。

入力: オプションで変更名を指定できます（例: /openspec-apply-change add-auth）。省略された場合、会話の文脈から推測できるか確認します。あいまいな場合や曖昧な場合は、利用可能な変更を確認するためにプロンプトを表示しなければなりません。

手順

1. 変更を選択する

   名前が指定されている場合はそれを使用します。それ以外の場合:

   • ユーザーが変更について言及していれば、会話の文脈から推測します
   • アクティブな変更が1つだけ存在する場合は自動選択します
   • あいまいな場合は、openspec list --json を実行して利用可能な変更を取得し、ユーザーに選択を求めます

   常に「使用する変更: 」と、オーバーライド方法（例: /openspec-apply-change <other>）をアナウンスします。

2. ステータスを確認してスキーマを理解する

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

   JSON を解析して以下を理解します:

   • schemaName: 使用されているワークフロー（例: "spec-driven"）
   • planningHome、changeRoot、actionContext: 計画範囲と編集制約
   • どのアーティファクトにタスクが含まれているか（通常、spec-driven では "tasks"、その他は status で確認）

3. 適用指示を取得する

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

   これにより以下が返されます:

   • contextFiles: アーティファクト ID -> 具体的なファイルパスの配列（スキーマによって異なる - proposal/specs/design/tasks または spec/tests/implementation/docs）
   • 進捗状況（合計、完了、残り）
   • ステータス、ソースパス、ソース行を含むタスクリスト
   • 現在の状態に基づく動的指示
   • オプションの context: 選択されたルートからの現在の必須プロジェクト指示入力
   • オプションの operationGuidance: 現在の適用に関するアドバイザリーガイダンス
   • missingArtifacts（存在する場合）: 出力がない必要なアーティファクト ID

   状態の処理:

   • state: "blocked" の場合: メッセージを表示し、実装を一時停止します。
     • missingArtifacts が空でない場合: 不足しているアーティファクトの完了を提案します。openspec status --change "<name>" --json を実行し、次の ready 状態のアーティファクト（skipped や blocked ではない）を選択し、openspec instructions "<artifact-id>" --change "<name>" --json を使用してそのルールとテンプレートを取得します。両方のコマンドで選択した --store <id> を維持します。
     • それ以外の場合、CLI の指示に従って、既存の計画アーティファクトからスキーマで設定された追跡ファイルを作成または修復します。ブロック中に他のアーティファクトが準備できていると想定したり、実装を開始したりしないでください。
   • state: "all_done" の場合: 追跡されているすべてのタスクが完了したことを報告し、アーカイブ前に適切なレビューまたは検証を提案します
   • それ以外の場合: 実装に進みます

   context を必須のプロンプトレベルの入力として扱います。それを読み、考慮し、実装中に関連するプロジェクトの事実、慣行、制約を適用します。 operationGuidance をオプションの追加的なアドバイスとして扱います。すべてのエントリを読み、考慮し、適用可能で組み込みワークフローと互換性のあるエントリに従います。

   これらの両方のフィールドは、CLI から返された状態、不足しているアーティファクト、タスク、進捗状況、contextFiles、組み込みの instruction とは別に保ちます。これらはタスク完了の証拠ではなく、組み込みの指示を置き換えるものではなく、ブロックされた状態をバイパスすることを許可するものでもありません。context が組み込みの指示、明示的なユーザーの選択、または CLI が制御する値と競合する場合は、競合を報告し、制御する値を保持します。guidance が適用できない場合、またはそれらの制御入力と競合する場合は、それに従わず、理由を説明します。これらはプロンプトレベルの動作契約であり、強制可能なチェックではありません。

4. コンテキストファイルを読む

   適用指示の出力で contextFiles の下にリストされているすべてのファイルパスを読みます。 ファイルは使用されているスキーマによって異なります:

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

   context や operationGuidance を実装ファイルや計画アーティファクトにそのままコピーしないでください。ユーザーが別途その内容を要求した場合を除きます。

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

   以下を表示します:

   • 使用中のスキーマ
   • 進捗状況: "N/M タスク完了"
   • 残りのタスク概要
   • CLI からの動的指示

6. タスクを実装する（完了またはブロックされるまでループ）

   各保留タスクについて:

   • どのタスクに取り組んでいるかを表示します
   • 必要なコード変更を行います
   • 変更は最小限で集中的に保ちます
   • 編集前に、返された sourcePath と line のチェックボックスがタスクの説明とまだ一致していることを確認します。一致しない場合は、適用指示を再実行し、更新された場所を使用します
   • 返された sourcePath と line でタスクを完了としてマークします: - [ ] → - [x]
   • 適用指示を再実行し、そのタスクが完了し、進捗が変わったことを確認します
   • 次のタスクに進みます

   一時停止する条件:

   • タスクが不明瞭 → 明確化を求める
   • 実装によって設計上の問題が明らかになった → アーティファクトの更新を提案する
   • タスクが仕様やタスクの説明を超えた作業を必要とする、または指定された動作を省略、縮小、延期、例外を受け入れて適合させようとしている → 追加されたスコープを明らかにして尋ねる。黙って吸収しない
   • エラーまたはブロッカーが発生した → 報告し、ガイダンスを待つ
   • ユーザーが中断した

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

   表示:

   • このセッションで完了したタスク
   • 全体の進捗状況: "N/M タスク完了"
   • すべて完了した場合: 追跡されているタスクが完了したことを報告し、アーカイブ前に適切なレビューまたは検証を提案する
   • 一時停止した場合: 理由を説明し、ガイダンスを待つ

実装中の出力

## 実装中: <change-name> (スキーマ: <schema-name>)

タスク 3/7 に取り組み中: <task description>
[...実装中...]
✓ タスク完了

タスク 4/7 に取り組み中: <task description>
[...実装中...]
✓ タスク完了

完了時の出力

## 実装完了

**変更:** <change-name>
**スキーマ:** <schema-name>
**進捗:** 7/7 タスク完了 ✓

### このセッションで完了
- [x] タスク 1
- [x] タスク 2
...

追跡されているすべてのタスクが完了しました。アーカイブ前に、変更を適切にレビューまたは検証してください。
`/openspec-archive-change` でこの変更をアーカイブできます。

一時停止時の出力（問題発生）

## 実装一時停止

**変更:** <change-name>
**スキーマ:** <schema-name>
**進捗:** 4/7 タスク完了

### 発生した問題
<問題の説明>

**オプション:**
1. <オプション 1>
2. <オプション 2>
3. その他のアプローチ

どうしますか？

ガードレール

• 完了またはブロックされるまでタスクを進め続ける
• 開始前に常にコンテキストファイルを読む（適用指示の出力から）
• タスクがあいまいな場合は、一時停止して実装前に尋ねる
• 実装によって問題が明らかになった場合は、一時停止してアーティファクトの更新を提案する
• コード変更は各タスクに最小限かつスコープ内に保つ
• 各タスク完了後すぐにタスクのチェックボックスを更新する
• エラー、ブロッカー、不明確な要件が発生した場合は一時停止する。推測しない
• タスクが仕様で説明されている以上の作業を必要とする場合、追加されたスコープを明らかにして一時停止する。指定された動作を黙って省略、延期、または簡略化しない
• タスクは、指定された動作が完全に実装された場合にのみ - [x] とマークする。部分的な完了や延期ではマークしない
• CLI 出力の contextFiles を使用し、特定のファイル名を前提としない
• 各タスクの sourcePath と line を使用して、正確なチェックボックスを更新する
• コンテキストや操作ガイダンスをタスク完了の証明として使用しない
• 関連するプロジェクトコンテキストを適用し、制御するワークフロー入力との競合を報告する
• すべてのガイダンスエントリを考慮し、適用できないアドバイスや競合するアドバイスを説明する
• ランタイムコンテキストや操作ガイダンスを実装ファイルや計画アーティファクトにコピーしない
• CLI が制御する blocked/ready/all_done の動作と完了基準を保持する

流動的ワークフロー統合

このスキルは「変更に対するアクション」モデルをサポートします:

• いつでも呼び出し可能: すべてのアーティファクトが完了する前（タスクが存在する場合）、部分的な実装後、他のアクションとインターリーブして使用可能
• アーティファクトの更新を許可: 実装によって設計上の問題が明らかになった場合、アーティファクトの更新を提案する。フェーズにロックされておらず、流動的に作業する