comet-classic

Comet Classic — OpenSpec + Superpowers

Classic には、Open → Design → Build → Verify → Archive の5つのフェーズがあります。OpenSpec は仕様とアーカイブを管理します。Superpowers は、ユーザーが選択する設計手法と、計画・実行・レビューの手法を提供します。完全なワークフローでは、ブレインストーミングと設計の確認が必要です。ホットフィックス／微調整では、あらかじめ定められた手順に従います。

1. 対象とワークスペースを解決する

新しいタスクまたはホストの変更時は、Open を承認する前にホスト機能チェックを読み、実行してください。実行設定が変更された場合は、新しい戦略で必要となる機能のみを確認します。

開始または再開する前に、comet-classic/reference/classic-layout.md でアーティファクトのパスを解決し、comet-classic/reference/scripts.md の「CLI Bootstrap」に従ってください。公開されている Comet CLI と、その OpenSpec アダプターを使用します。現在のアクションに必要なセクションのみを読み、コンテキスト内にすでにある有効な手順を再利用してください。

• Classic が明示的に呼び出されておらず、既存の作業を再開する必要がある場合：comet-classic/reference/context-recovery.md の Ambient Resume を読み、comet resume-probe . --stdin --json に従ってください。自動的に開始するのは auto_resume の場合のみです。ask_user の場合は、Ambient Resume の表にある質問と選択肢を使い、reason に基づいて質問してください。out_of_scope／none の場合は開始しません。
• 新しいリクエストを開始する場合、または対象の変更が不明確な場合：comet-classic/reference/intent-frame.md の最小限の例と対象選択のルールを読んでください。アクティブな変更を一覧表示し、CometIntentFrame に記入して、comet classic intent route --stdin を実行してください。エージェントは証拠から意図のフィールドを抽出し、Runtime はルートを決定します。独自の文章による評価ルールを作らず、結果に従ってください。
• 対象の変更が明確で、Runtime が初期化済みの場合は、以下に従ってそのワークスペースを紐付けます。新しい SDK の変更では comet-state.yaml を使用します。過去の .comet.yaml ファイルはその場で読み書きし、互換性のための初期化でも従来の名前を使用します。復旧経路を選ぶ際は、状態ファイルが存在するだけで判断せず、state next が返す Runtime の所有権を使用してください。複数のアクティブな変更があり、どれも選択されていない場合は、早まって紐付けないでください。新規の変更は /comet-open または対応するプリセット Skill に渡します。これは初期化の前にワークスペースを準備します。未初期化の変更に対して workspace resolve は not-found を返します。

comet classic workspace resolve <change-name> --json
# Enter the returned projectRoot before selecting the change
comet state select <change-name> --json

同じ変更に対して comet-state.yaml と .comet.yaml の両方が存在する場合（リンク切れのシンボリックリンクを含む）は、処理を停止し、両方を保持して、その由来を確認してください。一方を黙って選択したり、どちらかを上書きしたり、自動的に名前を変更したりしないでください。

選択結果に現在の Runtime の所有権、フェーズ、リビジョン、nextAction が含まれている場合は、そのまま続行してください。情報が不足している場合、外部で状態が変更された場合、または応答の有効期限が切れている場合に限り、comet state next <change-name> --json を実行してください。

実際の状態ファイル、変更ドキュメント、参照されているアーティファクト、コード、プロジェクト設定をまとめて移行してください。チェックポイントには、別個の子ワークツリーや未コミットのコードは含まれません。実際の状態ファイルに run_checkpoint がある SDK の変更をコピーした場合、名前を指定した state select または state next により、保存されたフェーズ、Actions、承認が復元されます。外部作業を続ける前に、元のデバイスでの実行プロセスが停止していることを確認してください。結果が不明な Action は、再試行する前に状況を確認してください。チェックポイントのない古い状態ファイルについて、通常の開始時に Run 履歴の欠落が明示された場合に限り、正式なドキュメントを確認してください。明示的な復元では Open に戻り、新たな承認とチェックが必要になることを説明し、ユーザーの同意を得てから comet state restore <change-name> --confirmed を実行してください。

応答に agent.continuation.mode がすでに含まれている場合は、まず comet-classic/reference/auto-transition.md の共通ルールに従ってください。mode を使って実行、待機、質問、状況確認、または完了を行います。以下の nextAction.kind による振り分けは、mode を含まない古い応答にのみ適用されます。 data.runtimeFormatを使用してsdkとcompatを区別し、返されたフェーズ、設定、data.nextAction.kindに従ってください。返されたスキルを読み込むのは、SDKのactionの場合に限ります。decision、evidence、reconcileの場合は、新しいスキルアクションとして再実行せず、まず現在のRunの判断、証拠、または申告されたActionを解決してください。compatの変更では、元のルーティングを維持してください。新しい全面的な変更は/comet-openに送信してください。ワークスペースの準備、OpenSpecアーティファクトの作成、SDK Runの初期化が行われます。確認済みのホットフィックス／微調整の選択は、それぞれのプリセットスキルに送信してください。/opsx:newを直接呼び出さないでください。所有権の競合や不正な状態が発生した場合は、context-recovery.mdの「Entry Errors and Recovery」に従って停止してください。アーティファクトからフェーズを推測したり、別の状態レコードを作成したりしないでください。

新しい全面的な変更では、Openがアーティファクトを作成する前にワークスペースを選択する必要があります。全面ワークフローのisolationにはcurrent、branch、worktreeを指定できます。明示的な並行作業のリクエストにはWorktreeを準備し、それ以外の場合はcomet-classic/reference/workspace.mdに従ってください。ホットフィックス／微調整では、各自の初期化中にワークスペースを確認して紐付けます。再開時は、紐付けられたワークスペースを使用してください。ブランチの所有者が変わっている場合は、ユーザーが確認した選択に従って再紐付けしてください。有効な認可が不足している場合に限り、確認を求めてください。

2. 現在のフェーズを読み込む

同じタスクのコマンド結果とコンテキストは再利用してください。返された状態とagent.continuationから続行し、不足フィールドの確認、ワークスペースの変更、復旧時のコンテキスト喪失、または外部変更がある場合に限り照会してください。リスクに応じてチェックを選択してください。Verifyは、完成した実装に対する統合レビューを最後に1回実施します。

ワークスペースとフェーズを紐付けた後、またフェーズ変更時、Agentの引き継ぎ時、コンテキスト復旧時は、Task Context and Artifact Languageに従ってください。各エントリーまたは復旧時に1回、継続情報または申告されたActionのcontextRequestを使用してスナップショットを取得してください。設定されたアーティファクト言語を使用し、不足しているContext Manifestの内容のみを補完してください。実際の使用結果を報告し、タスク終了時にチェックポイントを保存してください。

メモリ学習では再利用可能なユーザー情報のみを登録してください。タスクの概要、進捗、コマンド出力、テスト結果は、Personal Memoryに保存しないでください。タスク完了前にタスクコンテキストのリファレンスで学習チェックを完了し、submitted、no-observation、not-runのいずれかを記録してください。

プロジェクトの経験と個人の好みは別々に保存します。タスク完了前に、プロジェクトで検証済みの再利用可能な経験をcomet knowledge rememberでProject Memoryに記録してください。Personal Memoryには、ユーザーの好みと安定した協業上の習慣のみを記録してください。コマンドとフィルタリング規則については、Task Context and Artifact Languageを参照してください。

ランタイムのルートまたはフェーズ	エントリーと役割
new full / open	/comet-open：範囲を明確にし、必要な成果物を作成して、ユーザーのレビューと確認を得ます
design	/comet-design：技術的なトレードオフを解決し、正式な設計を確認します
build + full	/comet-build：設定と計画を復元し、タスクと必要なレビューを完了します
hotfix / build + hotfix	/comet-hotfix：既存の局所的な不具合を修正します
tweak / build + tweak	/comet-tweak：1つの変更の範囲内で軽微な調整を行います
verify	/comet-verify：受け入れ確認を実行し、修正を再検証して、最終的な統合レビューのみを行います
archive / verify_result: pass	/comet-archive：アーカイブを確認し、この変更のファイルのみをコミットして、選択した納品方法を完了します

新しい依頼に限り、軽量なワークフローを推奨します。リスクがプリセットに合致し、ユーザーが明示的に選択している場合は、そのワークフローに直接入ります。エージェントが推奨する場合は、その理由を説明し、hotfix/tweak と full の影響を提示して、確認を待ちます。既存の full 変更を、黙って軽量なワークフローに切り替えてはいけません。公開 API、データ移行、セキュリティ、並行処理、モジュール間設計は実際のリスクに基づいて評価します。ファイル数が少なくても、必要な手順を省略してはいけません。

hotfix/tweak では、SDK は プリセットの範囲 を読み、それに従い、有効な rulings.md の承認を再利用する必要があります。Compat は、選択したプリセットの reference/compat.md に従います。ファイル数のしきい値を超えた場合に限り、スコープを見直し、新たな判断が必要な場合のみ確認します。ユーザーの選択後に、Run の継続手順または該当する Compat コマンドを使ってアップグレードします。検証の深さには verify_mode を使用し、ワークフローの判断とエスカレーションの判断は分けて扱います。

セッションの復旧、外部変更、または実際の作業と計画・タスク・レビュー・納品記録との不一致がある場合は、comet-classic/reference/context-recovery.md を読みます。現在のフェーズのエントリーにある nextAction を使って、未完了の手順を特定します。有効な設定と作業は再利用してください。未チェックのタスクが、実装されていない証拠になるわけではありません。復旧手順については、そのリファレンスに従ってください。

3. この呼び出しで許可された作業を完了する

フェーズ終了チェックに合格したら、comet-classic/reference/auto-transition.md に従います。成功結果から agent.continuation を読み取り、次の Skill のみを読み込みます。再利用可能な状態がない場合、セッション復旧にコンテキストが不足している場合、または外部状態が変化した場合に限り、再度問い合わせます。auto_transition: false が制御するのは次の Skill の呼び出しであり、Guard によってすでに進んだフェーズではありません。NEXT: manual の場合は HINT を表示し、確認の質問を追加せずに呼び出しを終了します。

判断が必要な作業は、ユーザーが明示的に回答するまで、それに依存する作業を進められません。最初の確認や承認を求める前に、comet-classic/reference/decision-point.md を読み、その選択肢、推奨理由、選択肢ごとの影響、AskUserQuestion の優先順位に従います。すでにコンテキスト内にある場合は、再利用します。自動引き継ぎや、推奨案が 1 つだけであることを理由に、次の確認を省略してはいけません。

• 変更対象、PRD の分割、またはワークスペースの分離方法について、まだ選択が必要な場合は、関連する質問をまとめて尋ね、回答を待ちます。
• Open の終了時に、名前、スコープ、成果物について最終確認を得ます。Design で提案を作成した後は、正式な設計について確認を得ます。いずれの場合も、承認や修正依頼を待つ前に、レビュー可能な結果を提示します。
• Build が計画を書き込む前に、実行／TDD／レビューの設定が不足している場合、またはユーザーが変更を求めた場合に限り、その設定について尋ねます。ユーザーが要求した plan-ready の一時停止後は、続行の明示的な指示を待ちます。
• Verify では、逸脱の受け入れ、実装と Spec の不一致の解消、自動修復の上限に達した後の進め方の選択が必要な場合に尋ねます。Archive では、アーカイブと納品方法について確認します。
• プリセットをフルワークフローにアップグレードする場合、または Build でスコープの拡大、再設計、変更の分割が必要な場合は、尋ねます。

明示的な選択を得る前に状態を書き込んだり、その選択に依存する分岐操作を実行したりしてはいけません。また、フェーズの Guard を回避してはいけません。有効な承認と設定は再利用します。既知の修復方法があるスコープ内の失敗、証拠から整合を取れる状態、その他有効な対応が 1 つしかないステップは自動的に処理し、「続行しますか？」という質問を追加しません。

Archive と納品方法は、最後の確認 1 回にまとめます。/comet-archive は、承認、実際の Git の状態、選択された納品操作の完了を確認します。検証に合格してもアーカイブが承認されたことにはなりません。また、アーカイブ用ディレクトリがあっても、コミット、プッシュ、PR が完了した証明にはなりません。

各フェーズ共通のルール

• Runtime フェーズ、Guard の結果、現在のワークスペースバインディングを使って、ワークフローの状態を判断します。ファイルや会話は状態の確認に役立ちますが、確認や検証を回避するためにフェーズを手動で変更する権限を与えるものではありません。
• proposal には目標とスコープを記録し、spec では動作と受け入れ条件を定義し、design_doc では唯一の正式な技術設計を参照し、plan では実装を説明し、tasks.md ではタスクの完了を記録します。
• 確認済みの実行、TDD、レビューの設定に従います。自律実行であっても、ワークフロー全体を対象とする設計、計画、実際の検証、独立したレビューが必要です。Build では、設定が不足している場合やユーザーが変更を求めている場合に限り、設定変更を確認します。モデル名を根拠に設定を置き換えてはいけません。
• 未コミットの変更は comet-classic/reference/dirty-worktree.md を使って帰属を判断します。現在の変更のみを扱い、無関係な作業を保護します。状態更新の拒否、パスの逸脱、依存関係の利用不可、所有者が不明確な場合は、「Entry Errors and Recovery」（comet-classic/reference/context-recovery.md）を読み、元のエラーを報告して、該当する復旧ルールに従います。
• 現在のフェーズで失敗が発生した場合は、修正する前に comet-classic/reference/debug-gate.md を読み、調査します。テストやビルドの結果を報告できるのは、実際に実行した後だけです。Runtime によって有効性が確認された場合に限り、以前の成功結果を再利用します。

状態フィールドの意味については comet-classic/reference/comet-yaml-fields.md を、成果物ディレクトリについては comet-classic/reference/file-structure.md を読んでください。ほかのリファレンスは、上記の適用条件に該当する場合にのみ読みます。