kkestell/xauto

xplan、xreview plan、xwork、xreview work を子セッション(または子セッションが利用不可の場合はサブエージェント)でオーケストレーションし、フィンドを解決し、すべてのタスク所有コードと .agents レコードをローカルにコミットして完了します。ユーザーが xauto を呼び出すか、この自律ワークフローを明示的に要求した場合のみ使用します。kauto を呼び出したり、変更をプッシュしたりしないでください。

xauto とは?

これは、Claude Code や Cursor などの AI エージェント環境において、コード生成とレビューの完全な自律ワークフロー(xワークフロー)をオーケストレーションするスキルです。親セッションがコーディネーターとなり、`references/workflow.md` で定義された共有契約に従って、子セッションまたはサブエージェントに計画立案(xplan)、計画レビュー(xreview plan)、実装(xwork)、実装レビュー(xreview work)を順次委譲します。主な価値は、人間の介入を最小限に抑えながら、独立したレビュアーによる検証を組み込んだ堅牢な開発サイクルを実現することにあります。このスキルは、子セッションの優先利用、親による一元管理(タスクID、アーティファクトパス、成果物の統合)、発見(フィンド)の段階的な解決、およびすべての変更を Git にローカルコミットしプッシュしないというルールを強制します。各ワーカーのセッション情報(コーディネーターID、ネイティブ会話ID)を親がログに保存し、ワークフロー全体のトレーサビリティを確保します。このスキルは Git が必須であり、必要ツールが利用できない場合や、ループする欠陥に対処できない場合は自律的に停止し、ユーザーに報告します。

対応~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/kkestell/xskills/tree/HEAD/skills/xauto

Installed? Explore more 生産性&コラボレーション skills: steipete/gemini, steipete/gh-issues, steipete/skill-creator · View all 6 →

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

xワークフロー全体をオーケストレーションする

現在のセッションは親コーディネーターです。ディスパッチ前に references/workflow.md を読んでください。必要に応じて他の3つのスキルも読んでください。それらのステージセマンティクスと共有契約はすべてのワーカーに適用されます。リクエスト内の名前のタイポが原因で無関係な kauto ワークフローを実行しないでください。

準備と割り当て

  1. 要求された成果、制約、スコープを確立します。Git ルート、現在のブランチ/HEAD、該当する指示、ダーティ/インデックス状態を見つけます。Git は必須です。静かに初期化するのではなく停止してください。1つのクリーンで排他的なタスクチェックアウトを選択します。無関係な作業は保存します。可能な場合は分離し、そうでない場合は必要な処置をユーザーに尋ねてください。別のブランチで作業する場合、ユーザーの元のブランチにコミットすることを約束しないでください。
  2. タスクIDと標準アーティファクトパスを割り当てます。プランナーは複数の有界ユニットと共有設計を提案することがあります。親は中央で追加のIDを割り当て、リクエスト全体のカバレッジを維持します。
  3. 利用可能な委譲ツールを発見します。子セッションを優先して使用し、利用できない場合のみサブエージェントを使用します。ホストの委譲/ライフサイクルルールに従ってください。ツール名を推測したり、親で別のメッセージを使って新しいコンテキストを偽装しないでください。どちらのメカニズムも存在しない場合は、停止して独立したオーケストレーションワークフローが利用できないことを説明し、すべてのロールをインラインで静かに実行しないでください。
  4. ユーザーまたは該当する指示が選択しない限り、モデル/ハーネス/エフォートを継承します。作成者のプライベートな推論を含むフォークではなく、新しいレビューアコンテキストを使用します。レビューアはリクエスト、コード、アーティファクト、以前の公開されたフィンドを見ることができますが、レビューされた計画/実装を書いたワーカーではありません。
  5. 共有契約を使用して、親セッションのプロビナンスをキャプチャします。各ワーカーのハンドオフで、そのコーディネーターIDとネイティブ会話IDを要求します。これらは一時的なワーカー名だけでなく、クリーンアップ前にワークログに保存します。

明示的なステージブリーフをディスパッチする

各ワーカーは、目的、関連するユーザー制約、スキルと呼び出し、タスクID、正確なチェックアウトと開始HEAD、入出力パス、許可された編集、コミット権限、チェック要件と既存の検証証拠、期待されるハンドオフ(セッションプロビナンスを含む)、および停止条件を取得します。結果がどこで使用されるかを含めてください。ワーカーが独立して検証することを想定した仮定ではなく、計画またはリクエストを提供します。

ステージは共有チェックアウト内で順次実行されます。デフォルトでは一度に1つのライターとします。ファイルとその依存関係が真に独立しており、統合/レビューの所有権が明示されている場合にのみ、別々のユニットを並行して実行します。各子の実際のディレクトリ/HEADを確認し、共有契約で説明されているように、次のステージの前に分離されたワーカーのハンドオフコミットを統合します。転送されていない結果を決して削除しないでください。

計画 → 計画のレビュー

  • 生産コード編集権限のない xplan <request> でプランナーを開始します。プランナーは難しい質問を調査し、エンジニアリング上の決定を確定し、準備完了の計画、小さなタスクのブリーフ、または具体的なブロッカーを返します。
  • 返されたアーティファクトとカバレッジを検査します。計画/共有設計レコードを plan としてコミットし、各実行計画を xreview plan .agents/plans/ID.md を使用して独立したワーカーに送信します。そのレビューラウンドを plan-review としてコミットします。
  • フィンドがある場合は、具体的な修正割り当てをプランナーに返します。修正された計画をコミットします。親は修正内容をフィンドと関連証拠に対してチェックし、それらの処分と最終的な計画/ガイダンスブロブを記録し、重大な欠陥が残っていない場合に進みます。これは親の実行決定であり、レビューアが目に見えない修正を承認したという主張ではありません。すべての修正を別の完全な計画レビューに送信しないでください。追加の独立した評価が必要なのは、以前のレビューと修正チェックでは解決できない特定の重大な質問がある場合のみです。その質問を指定し、必要な評価のみを要求してください。表現、メタデータ、および日常的な修正は、レビューの再開を正当化しません。共有設計の編集は、影響を受けるユニットのチェックを必要としますが、それぞれの別のレビューを自動的に委託するものではありません。
  • 本当に小さな作業の場合は、プランナーの有界ブリーフを xwork に保持し、個別の計画/レビューアーティファクトをスキップします。後のワークログがその理由を記録します。大きな未解決の割り当てをブリーフと呼んで正規化をバイパスしないでください。
  • 分割されたリクエストは、最初のユニット後に完了しません。ユニットの依存関係を共有設計で追跡し、要求されたすべてのユニットを順番に実行し、依存関係が変更された場合は共有インターフェース/中間状態を再チェックします。

作業 → 実装のレビュー

  • xwork .agents/plans/ID.md または明示的な小さなタスクのブリーフを使用して実装者をディスパッチします。承認されたレビュー/計画とリンクされたガイダンスブロブを提供します。タスク所有のコードとログコミットのみを許可します。xwork は固定された Code ベースを記録し、検証済みコードをコミットし、その後、既知の Code ヘッドを使用してログを個別にコミットします。
  • Git と記録されたテスト出力に対してハンドオフをチェックします。子の「完了」メッセージは、正しいツリー、完了したチェック、またはコミットされたファイルの証拠ではありません。統合マッピングを解決し、最終ログでタスクチェックアウトハッシュを使用します。
  • xreview work .agents/work/ID.md を使用して独立したレビューアを開始します。リクエスト、計画/ブリーフ、完全な Code ベース..Code ヘッド範囲、ワークログ、および関連するリポジトリ指示を提供します。レビューアはコードとテストを読み、ログだけではなく、実装を修正せずにレビューを書きます。そのレビューを work-review としてコミットします。
  • 記録された Code ヘッドに対して検査可能なチェック結果を渡します。レビューアにその証拠を最初に検査/再利用し、新しいチェックを選択する前に残っている不確実性を特定するよう依頼します。同じ変更されていないコードに対して、焦点を絞った繰り返し、フルパッケージ実行、およびリポジトリスイートを日常的に要求しないでください。明示的な新規実行要件は引き続き適用されます。
  • 実行者に実行可能なフィンドを送信します。実行者は元のベースを保持したまま、修正と追加のログエントリをコミットします。完全な更新された変更を独立したレビューアに返します。以前のフィンドには解決の証拠が必要であり、新しい空のチェックリストではありません。すべてのレビューラウンドを保持します。レビューアは作成者から独立している限り再利用できます。どのロールも自分が書いたコードを承認してはいけません。
  • 実装によって無効な設計が明らかになった場合は、続行する前に決定をプランナーと親に戻します。影響を受ける依存ユニットに同じ修正チェックを適用します。追加の独立した評価が必要なのは、特定の重大な不確実性がある場合のみであり、単に計画ブロブが変更されたためではありません。 xwork が静かにスコープを拡大したり、難しい選択をコーディングまで先延ばしにしたりしないでください。

フィンドを解決し、正直に完了する

日常的な確認なしに進めますが、意図、スコープ、権限、または重要なトレードオフが真にユーザーを必要とする場合は質問します。必要なツール/チェックが利用できない場合や、意見の分かれる決定がある場合は停止します。通常の修復が進捗している間は継続します。ラウンドが同じ失敗したアプローチを繰り返したり、ユーザーの決定が必要になったり、明示的な予算を超えたりした場合は、無限のレビューループを発生させるのではなく、停止して未解決の証拠を報告します。サイクルを完了するために欠陥を受け入れてはいけません。

成功する前に、親は以下を検証します:

  1. 要求されたすべての実行ユニットが実装され、必要なチェックが実際に合格し、その最終コードが独立した承認済みの作業レビューを持っていること。
  2. ユニットのレビュー済み Code ヘッド以降のすべてのコード/テスト/設定変更が、統合タスクチェックアウト上の後のユニットの承認済みレビュー範囲でカバーされているか、または検証と作業レビューに戻されること。既知のワークフローレコードのみの変更はコードの再レビューを必要としません。パス名を一致させるだけでなく、すべてのコミット/差分を説明すること。統合競合修正や以前の契約違反は、新たなチェック/レビューを必要とします。後の承認されたユニットが自動的にそれらを免除するわけではありません。
  3. ワークログには、承認された計画/ブリーフ、固定ベース、最終レビュー済みヘッド、実際のコミット、親/ワーカーのネイティブ会話ID(または明示的な利用不可の理由)、実行/再利用された検証証拠、およびレビューパスが含まれていること。それらを complete に設定し、残りのタスク所有レコードを complete としてコミットします。
  4. すべてのタスク所有の変更と新しいレコードが、報告されたブランチにコミットされていること。Git で確認し、無関係な作業を保存し、プッシュしたり、別のブランチに自動的にマージしたりしないでください。元のコード HEAD は最終 HEAD と等しい必要はありません。後のコミットにはレコードや他の独立して承認されたユニットが含まれている可能性があるためです。
  5. 各子のセッションプロビナンスを保存し、ブランチ/ワークツリーを削除するセッションを終了する前に、すべての結果を統合/保存すること。到達可能なコミット結果を残し、ホストのクリーンアップルールに従うこと。失敗したサイクルは、部分的なコミットとブロッカーを報告し、成功として報告しないこと。

簡潔な結果、タスクID、アーティファクトパス、ブランチと最終コミットID、チェック、レビュー評決、および残りの制限事項を返します。親がこの検証と最終レポートを所有します。ワーカーの要約を単に連結しないでください。

関連スキル