comet-any

Comet Any

ユーザーの目標に合った実際のスキルを調査し、アプリケーションのドキュメント、ワークフロー、ビジネス実装を作成します。計画と進捗を保持するには、comet creator を使用します。各段階の後、現在のアクションを読み取り、完了するか、ユーザーの判断が必要になるか、外部機能が障害となるまで続行します。

エージェントは、エントリースキル、ビジネスルール、実行ポート、バリデーターを作成します。SDK はドキュメントを保持し、実行プロトコルと共通の保護ルールを追加して、Runtime を組み立てます。ビジネスルールは業務上の制約を記述し、Runtime と Guard はアクション、承認、書き込み権限を制御します。インストールには正式な SDK 配布を使用します。

開始または再開

1. 作成名がわかっている場合は、comet creator status <name> --project <project> --json を実行し、続いて comet creator next <name> --project <project> --json を実行します。元の名前と Run を保持し、中断後は元の Action を確認して、完了済みの作業を繰り返さないでください。
2. 新規作成の場合は、comet creator guide --project <project> --json を読みます。ユーザーの説明から目標とインストール先を特定し、調査では判断できず、結果を左右する選択肢についてのみ質問してください。comet creator start <name> --project <project> --goal <user-goal> --install-target <relative-directory> --host codex|claude-code --json で開始します。
3. 最初の申告またはアクション送信の前に、作成アクションと復旧を読みます。返された Action、attempt、inputHash、現在のホストセッション識別子を使用してください。現在のアクションに必要な機能がない場合は、障害となっている要因を報告し、現在の作業を保持します。

分析と計画

analyze の間、ホストが調査と作成を行います。委任が必要な場合は、元の目標、現在のアクション、範囲、固定された依存関係を引き継いでください。

1. comet creator candidates --project <project> --json で候補を見つけ、各候補の SKILL.md、スクリプト、必要なリソースを読みます。実際の入力、出力、認可、ホスト機能、完了条件、失敗、復旧を調査してください。名前から機能を推測したり、サードパーティのオリジナルを変更したりしないでください。

2. 計画に必要なスキルごとに、次の手順を実行します。

   直ちに実行： Skill ツールを使用して、 スキルを読み込みます。この手順を省略することは禁止されています。

   スキルの読み込み後、実際の内容を使用してアダプター契約とコンテンツハッシュを完成させます。独自に承認または公開するスキルは、それらの機能と副作用を宣言する必要があります。

3. ユーザーが必要とする開始地点を選択します。Native には手順、ガイダンス、レビューを追加します。Classic は許可された位置で全体、ホットフィックス、微調整のいずれかとして構成します。または、スタンドアロンワークフローの順序、分岐、合流、子ワークフロー、範囲を限定した修復を宣言します。Runtime にユーザーとのやり取り、共通理解の確認、実装手順を含めてください。

4. 完全なエントリースキルを作成します。フロントマターの name はアプリケーション ID と一致させ、description には適用条件を記載します。本体では、入力、依存スキルの呼び出し、やり取りと承認、成果物、受け入れ条件、失敗、復旧について説明します。ビジネスルールで、実際の業務上の動作を制約します。必要に応じて詳細をリファレンスに記載し、いつ読むべきかを明記します。

5. リファレンスの documents 構造に従って、ワークフローとビジネスポートとともにドキュメントを返します。各実行段階について manifest.artifactContracts を宣言し、実際のファイル参照、内容要件、必要なビジネスバリデーターを記載するか、ファイルが不要な場合は noArtifactsReason を指定します。必須成果物がある段階ごとに、肯定的な artifactTests ケースを用意してください。ビジネスバリデーターには、汎用ファイルチェックを通過する否定的なケースも必要です。作成前に不明な要件を明確にしてください。構造については作成アクションと復旧を参照してください。分析段階で不足しているドキュメント、実装、バリデーター、依存関係、機能を補完します。計画がすでに存在する場合は、修正して再確認してください。

確認、検証、デリバリー

1. next が計画の確認段階に達したら、ドキュメント全体、コンテンツハッシュ、実際の手順、Skill のバインディング、成果物、チェック項目、失敗時の経路、機能上の制限を提示します。コンパイル後の Eval は任意であることを説明します。
2. ユーザーが現在の計画を明示的に承認した後、現在の confirm-plan に対するユーザーの決定を送信します。ハッシュは計画を識別するだけであり、ハッシュがあっても承認が得られたことにはなりません。拒否されても現在の作業は保持されます。計画を変更する場合は revise を使用し、影響を受ける確認と検証を繰り返します。
3. next の呼び出しを続け、コンパイル、アプリケーションの読み込み、必須成果物の検証を行います。分離されたディレクトリでは、SDK が正常ケースの完了をチェックし、不足ファイル、空ファイル、変更されたコンテンツのケースを自動的に作成して、拒否された結果によって元の Action が保持されることを検証します。実際のビジネスバリデーターは、負のケースを拒否する必要があります。これらのローカルチェックはインストール前に合格する必要があります。モデル Eval を省略しても、これらのチェックは省略されません。失敗した場合は現在の作業を保持し、計画または成果物を修正して、元の Action を再開します。
4. confirm-eval では、Agent、モデル、ケース数、対話ターン数、合計タイムアウトを提示し、評価、スキップ、修正のいずれかをユーザーが選択できるようにします。評価後は next を呼び出して実行し、レポートを保存します。再試行では元のケースを再利用し、修正ではそれらを優先します。評価が失敗または未完了の場合は review-eval で停止します。レポートと未対応の経路を提示し、再試行、修正、明示的なスキップのいずれかをユーザーが選択できるようにします。スキップした場合も、実際のステータスを保持します。
5. インストール前に、エクスポートディレクトリ、プラットフォームエントリー、固定された依存関係、Runtime、Rule/Hook の設定、競合、Eval のステータスを提示します。プレビューではインストール先に書き込みません。install-target のエクスポートディレクトリは、.comet/creator/exports/<application-name> など、プラットフォームエントリーとは別にします。ユーザーが現在のプレビューを明示的に承認した後、confirm-install を送信します。Creator がアプリケーションをエクスポートし、正式にインストールします。プレビュー失敗後やインストール中断後は、リファレンスに記載された復旧手順に従います。対象、依存関係、ファイル、設定、評価レポートを変更した場合は、改めて確認が必要です。
6. パッケージとエントリーの場所、実際のチェック、Eval レポート、未実行項目、制限を報告します。Skill の実際の読み込み、Rule の設定、Hook の実行、SDK Run、ビジネスアサーションを個別に報告します。設定をインストールしただけでは、Hook が有効化されたことの証明にはなりません。

復旧時の境界

• 元の Run ID、現在の Action/Wait、入力ハッシュを引き続き使用し、古いリクエストを再利用しないでください。
• 不確かな実行について、元の実験、プロセス、または成果物と照合してください。照合できない場合は、現在の作業を保持して処理を停止し、むやみに再試行しないでください。
• 認証情報は実行環境からのみ注入し、計画、ソース、生成パッケージ、Runs、レポートには決して含めないでください。