mcpField
C
comet-tweak

comet-tweak

github.com/rpamis開発3.2k854 回インストール今日更新
リポジトリ

comet-tweak について

Comet Preset: Tweak は、設定、ドキュメント、プロンプトの調整など、小規模な仕様駆動の変更向けのプリセットスキルです。Open、Build、Verify、Archive の各フェーズを使い、ブレインストーミングと完全な実装計画は省略します。

主な機能

  1. 01小規模変更向けプリセット
  2. 02OpenSpec に基づく要件整理
  3. 03Comet の4フェーズを再利用
  4. 04ブレインストーミングと完全計画を省略
  5. 05完全なワークフローへの移行

活用シーン

  1. 01設定の更新
  2. 02ドキュメントの変更
  3. 03プロンプトの調整
  4. 04中規模の範囲の変更実装

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/rpamis/comet --skill comet-tweak

インストール後、Claude Code で/comet-tweakを入力して読み込まれたか確認します。

同梱ファイルagents/openai.yamlreference/compat.md

詳細

Comet Preset: Tweak

開始または再開する前に、comet-classic/reference/classic-layout.mdを読んで従ってください。すべての OpenSpec CLI 呼び出しではアダプターを使用し、すべてのパスではバインドされた<classic-*>論理ルートを使用してください。

Tweak は、Comet の5フェーズワークフロー向けにプリセットの選択肢を提供します。要件定義と実装には OpenSpec を使用し、open/build/verify/archive を再利用し、Superpowers によるブレインストーミングと完全な実装計画は省略します。独立したワークフローを新たに作成するものではありません。

設定、ドキュメント、プロンプトの調整、および完全な/comet-classicの深い設計フローを使わずに仕様駆動の実装が必要となる中程度の変更(差分仕様を含む)に使用してください。差分仕様は Tweak の通常の成果物です。差分仕様が必要であることだけを理由に、上位のフローへ移行する必要はありません。

すべての適用条件を満たす必要があります:

  1. 作業が1つの OpenSpec 変更に収まること。
  2. Superpowers の設計ドキュメントと完全な実装計画を使わなくても、解決策を明確にできること。
  3. モジュール間またはレイヤー間のアーキテクチャ調整が必要ないこと。
  4. タスクの範囲を見積もれること。ファイル数やタスク数は判断材料にすぎず、自動的に上位のフローへ移行するルールではありません。「エスカレーションの判断」を参照してください。

プリセットが適さなくなる可能性がある場合: 実装中に「エスカレーションの判断」に記載された変更に遭遇した場合は、完全な/comet-classicフローを使用するかどうかをユーザーに判断してもらってください。

フェーズに初めて入るとき、新しい Agent に引き継ぐとき、またはコンテキストを復元するときは、タスクコンテキストと成果物の言語を読んで従ってください。中断なく同じフェーズで作業を続けている間は、繰り返し取得せず、現在の継続情報または要求済み Action のcontextRequestを優先してください。

個人用メモリには再利用可能なユーザー情報のみを保存してください。タスクの要約、進捗、コマンド出力、テスト結果は保存しないでください。

SDK Run path

現在の SDK フェーズに初めて入るとき、新しい Agent に引き継ぐとき、またはコンテキストを復元するときは、フェーズの開始と復旧と、そのリファレンスの現在のフェーズのセクションを読んでください。このセッションですでに利用可能で、引き続き有効な場合は再利用してください。以下のフェーズの手順に従ってください。nextAction.kindに基づく復旧ルートは、継続モードのない旧形式のレスポンスにのみ適用されます。

開始時または再開時には、現在有効な結果のagent.continuation / data.nextActionと、バインドされた変更、ワークスペース、フェーズ、Run リビジョンを再利用してください。既知のdata.runtimeFormatに基づいて処理を進めてください。comet state next <change-name> --jsonを実行するのは、状態を新規に確認するとき、外部で状態が変更された後、または必要な情報が不足している場合に限ります。sdkの場合は、このセクションを状態変更に使用してください。SDK 実行メソッドに記載された適用条件、OpenSpec の適用方法、エスカレーション、ファイル数の承認ルールが適用されます。状態と証跡はこのセクションを通じて提出してください。nextAction.kind: reconcileの場合、元の Action を調査するためにcomet state check <change-name> <phase> --recover --jsonを実行してください。結果が不明な間は、実装、チェック、アーカイブを繰り返さないでください。

  1. 新しい変更では、ワークスペースの選択に従って分離方法を選択します。comet classic workspace prepare <name> --isolation <selected-isolation> --json を実行し、projectRoot に移動します。エントリと成果物に従い、まず OpenSpec のベースディレクトリを作成してから、comet state init <name> tweak --isolation <selected-isolation> を実行します。その後、comet state select <name> を実行して Hook のルーティングを設定します。SDK 実行メソッドに従って OpenSpec の成果物を作成し、この変更に必要な差分仕様も含めます。comet guard <change-name> open --json でプレビューします。data.approvalHash を保存し、Open の成果物とスコープをユーザーに提示して、comet guard <change-name> open --apply --approval-hash <approvalHash> を実行する前に明示的な承認を得ます。成果物が変更された場合は、再度プレビューして承認を得てください。古いハッシュを再利用してはいけません。Run が Build に入ったときにのみ Open が完了します。
  2. tweak.build.execute では、同じ変更、ワークスペース、Run を維持したまま Build を直接再開します。再初期化したり、Open を繰り返したりしてはいけません。SDK ドキュメントメソッドの OpenSpec apply メソッドに従い、同じ tasks.md を完了します。重大なエスカレーションの兆候がある場合、または有効な許可がないままファイル数の上限を超えた場合は、comet state propose-escalation <change-name> --reason "<reason>" を実行します。tweak を継続する場合と full にアップグレードする場合の理由と影響を提示し、data.wait.proposalHash を保存します。明示的な選択を得た後、comet state decide-escalation <change-name> --proposal-hash <proposalHash> --choice <continue|upgrade> を実行します。継続する場合も、SDK 実行メソッドに定められたスコープ、リスク、裁定の条件を満たす必要があります。アップグレードすると、同じ Run とワークスペースで full の Design に移行します。直ちに標準のトリガーを使って comet-design を読み込みます。再開時は保留中の Wait を再利用します。
  3. タスクが完了し、引き続き tweak の範囲内である場合は、完全なビルドまたは受け入れコマンドを指定して comet guard <change-name> build --apply -- <program> [args...] を実行します。ここで新たにユーザーの判断を求める必要はありません。--apply は、実行して実際のチェックを記録する前に、現在のタスク、設定、ワークスペース、証拠を再検証します。有効な成功の場合のみ Verify に進みます。診断が必要な場合に限り、読み取り専用の comet guard <change-name> build プレビューを使用します。失敗した場合は、返された現在の状態を使用します。継続情報が返されなかった場合にのみ state next --json を読み取ります。不明な Action を再実行してはいけません。
  4. Run が Verify に入ったら、直ちに実行します: Skill ツールを使用して comet-verify スキルを読み込みます。この手順を省略することは禁止されています。該当する場合は、完全な検証で差分仕様との整合性を確認します。レガシーの state set verify_mode は呼び出してはいけません。Run が Archive に入ったら、直ちに実行します: Skill ツールを使用して comet-archive スキルを読み込みます。この手順を省略することは禁止されています。Archive と納品にも現在のユーザー承認が必要です。現在の成功結果に Run の完了が示されている場合にのみ、完了を宣言します。完了状態がない場合は state next --json を読み取ります。

各段階を進めた後は、その結果の agent.continuation / data.nextAction を使用します。状態が有効かつ完了している場合は、next、select、check を繰り返してはいけません。再度読み取るのは、コールド再開時、外部状態の変更後、または情報が不足している場合に限ります。現在の Run 内で decision、evidence、reconcile を解決し、対応するステップを実行するのは action の場合に限ります。 決定的なローカルチェックでは、SDK 実行メソッドの説明に従い、-- の前に --local を追加します。Runtime は入力全体とログを検証してから再利用します。外部チェックは引き続き実行されます。SDK Build には、安定した --session <builder-execution-ref> を関連付けます。指定した場合、full の complete-build にはすでにこれが含まれています。

Compat path

残りの元の Runtime 手順は、runtimeFormat: compat の場合に限り適用されます。Compat の操作を読み、現在のフェーズを続行してください。SDK はその参照を読み込みません。

コメント