gitx

GitX

デフォルトのアクション

引数なしで実行された場合（$gitx、gitx、または追加コマンドなしのスキル UI からの呼び出し）は、スマートコミットのワークフローを直ちに実行します。最初のアクションとして、Git のステータスと関連する差分を確認し、リポジトリを調査します。調査後、適切なコミットを作成するか、コミット対象がないことを報告します。

引数なしの呼び出しはアクションとして扱い、ヘルプの要求として扱わないでください。GitX が読み込まれたことを知らせたり、コマンドや例を列挙したり、どのコマンドを実行するか尋ねたり、追加の指示を待ったりしないでください。コマンド一覧を表示するのは、ユーザーがヘルプまたは使用可能なコマンドを明示的に求めた場合のみです。

コマンドと振り分け

自然言語での依頼を、以下のコマンドに対応させます。読み取り専用の概要を求めている場合、「変更を確認して」または「git status を表示して」は Status に振り分けます。「コミット前にテストを実行して」は Checks に振り分けます。Git ワークフローの診断には Doctor を、コミットのプレビューには Plan を使用します。関連するワークフローまたは読み込み条件に該当する場合にのみ、補足資料を読み込みます。

gitx issue は、文面から推測される意図ではなく、引数の形式に基づいて振り分けます。123 や #123 のように、課題番号のみを含む引数は、既存の課題を実装するワークフローとして扱います。それ以外の空でない引数はすべて、「fix」「update」「resolve」などの語が含まれていても、新しい GitHub issue の説明として扱います。引数がない場合は、課題の説明を尋ねます。数値以外の gitx issue の説明に書かれた問題を実装してはいけません。

gitx issue <description> は、GitHub への公開を明示的に要求します。リポジトリ内のトラッカーの規約を理由に、このコマンドをローカルファイル向けに変更してはいけません。失敗時の処理も含め、GitHub issue の作成ワークフローに従います。

gitx ship [base] の省略可能な引数は、PR の送信先ブランチであり、新しい機能ブランチの名前ではありません。たとえば、gitx ship dev は dev を送信先とします。Branch や Pull requests に直接振り分けず、Ship に振り分けます。

コマンド	アクション
gitx	スマートコミットを作成します。
gitx setup	プロジェクトの設定をプレビューし、リポジトリの .gitx.json に保存します。
gitx body	内容のあるコミット本文を付けて、スマートコミットを作成します。
gitx branch [name]	ブランチを作成して切り替えます。
gitx branch check	デフォルトブランチを作成し、チェックを実行してから、スマートコミットを作成します。
gitx pull	現在のブランチの更新を安全にプルします。
gitx push	現在のブランチを origin にプッシュします。
gitx pr [base]	指定された、設定済み、またはデフォルトのベースブランチに向けて、GitHub プルリクエストを作成します。
gitx ship [base]	必要に応じて機能ブランチを作成し、チェックを実行してコミット、プッシュした後、指定された、設定済み、またはデフォルトのベースブランチに向けて PR を作成します。
gitx issue <description>	生成したタイトルと本文を使って、GitHub issue を作成します。
gitx issue <number>	指定された番号の GitHub issue を修正します。
gitx resolve	進行中のマージまたはリベースの競合を解決します。
gitx check	関連するチェックを実行してから、スマートコミットを作成します。
gitx status	Git のステータスと変更ファイルの概要を表示します。変更は加えません。
gitx doctor [problem]	リポジトリの問題を診断し、次の手順を提案します。変更は加えません。
gitx tree	コンパクトな Git 履歴ツリーとリポジトリの概要を表示します。変更は加えません。
gitx scan	変更と履歴をスキャンし、漏えいしたシークレットや機密ファイルを確認します。変更は加えません。
gitx plan	提案するコミットのグループとメッセージをプレビューします。変更は加えません。
gitx type <type>	指定された Conventional Commit のタイプを使って、スマートコミットを作成します。
gitx scope <scope>	指定されたスコープを使って、スマートコミットを作成します。
gitx files <paths>	指定されたファイルのみを使って、スマートコミットを作成します。
gitx amend	確認を求めた後、直近のコミットを修正します。

プロジェクトの設定とセットアップ

コミット、計画、ブランチ、チェック、PR、リリースに関するデフォルトを適用する前に、現在の作業ツリーのルート（git rev-parse --show-toplevel）に .gitx.json があるか確認してください。存在する場合は、プロジェクトの設定を読み、内容を検証して、依頼されたワークフローに関連する項目のみを適用してください。存在しない場合は、既存の動作を維持してください。通常のコマンドで設定ファイルを作成したり、ファイルが存在するというだけで設定済みのチェックを実行したりしないでください。

明示されたユーザーの選択は保存済みの設定より優先され、保存済みの設定は GitX が推定するデフォルトより優先されます。必須のリポジトリ指示と実行権限は引き続き適用されます。無効な設定がある場合、関連する変更を行う前にその旨を説明してください。読み取り専用コマンドでは、関係のない調査を中断せずに設定の無効性を報告してもかまいません。

gitx setup では、参照先に従ってローカルの規約を調査し、提案する JSON の正確な内容をプレビューして、ルートの .gitx.json のみを作成または更新してください。セットアップでは、チェックの実行、ステージング、コミット、プッシュ、PR の作成、GitHub 認証は行いません。

スマートコミット

1. git status と、ステージ済みおよび未ステージの差分を確認してください。ステージ済みの変更を優先し、ステージ済みの変更がない場合は、安全な変更ファイルをすべて使用してください。gitx files <paths> の場合は、指定されたパスの範囲内でこの優先ルールを適用してください。ステージ済みの変更を選択した場合、部分的にステージされたファイルからは、ステージ済みの編集のみを対象にしてください。除外されたステージ済みの変更と、選択されていないすべての作業ツリーの編集は保持してください。

2. 変更された追跡対象ファイル、安全な未追跡ファイル、削除を含めてください。無視対象ファイルは除外し、リスクのあるファイルを含める前に警告してください。

3. 選択した変更を目的別にグループ化してください。同じファイル内の個別の編集も含めます。ファイルが複数のグループに関係する場合、または選択されていない編集から分離してステージングする必要がある場合は、同一ファイル内のコミット分割を読んでください。重複する編集や依存関係のある編集は、整合性のある中間バージョンの順序を構成できる場合を除き、同じグループにまとめてください。前提条件となる変更を先に配置してください。

4. 1 つのコミットが適切な場合は、明確な Conventional Commit を 1 つ作成してください。gitx type <type> または gitx scope <scope> では、指定された type または scope を使用してください。scope を推定する場合は、設定されていれば commitScopes を使用してください。該当するものがなければ、scope を勝手に作らず省略してください。このルールは gitx plan を含む、提案するすべてのグループに適用してください。

5. 2 つ以上のコミットが適切な場合は、論理的なグループの実数を算出して、次のように尋ねてください。

   N 個のコミットを作成しますか、それとも 1 つのコミットにしますか？

   尋ねる前に、各コミットのメッセージ案と、それに属する編集を示してください。ファイルが複数のグループに含まれる場合は、関数またはハンクを特定してください。N は実際の数に置き換えてください。N や {count} をそのまま表示してはいけません。ユーザーが複数のコミットを選択した場合に限り、複数のコミットを作成してください。それ以外の場合は 1 つのコミットを作成してください。参照先に記載されたインデックスのみのパッチを使って、承認されたグループを実行してください。選択されていない編集や後回しにする編集を含むファイル全体をステージングしてはいけません。

6. gitx body の場合は、各コミットメッセージに有用な本文を追加してください。

7. スマートコミットの一部としてプッシュしないでください。gitx push の場合、またはユーザーが明示的にプッシュを依頼した場合に限り、プッシュしてください。

コミット計画

gitx plan では、スマートコミットの選択ルールとグループ化ルールを適用し、提案するコミットグループの数、各グループのファイルと編集の概要、提案する Conventional Commit メッセージを示してください。共有ファイル、依存関係、同じグループにまとめる必要がある編集を特定してください。ファイルやインデックスを変更したり、Git オブジェクト、コミット、ブランチを作成したり、プッシュしたりしないでください。参照先の実行手順はコミットにのみ適用されます。

ブランチ

gitx branch [name] の場合：

1. 既存の変更を保持してください。ユーザーから明示的な依頼がない限り、破棄したり stash したりしないでください。
2. 有効なブランチ名が指定されている場合は、その名前をそのまま使用してください。名前が指定されていない場合は、小文字のケバブケース名を導出し、設定されている branchPrefix があれば適用してください。文字列の場合は固定のプレフィックスとして使用し、配列の場合はプロジェクト設定に従って最適なプレフィックスを選択してください。それ以外の場合は、作業内容から適切なプレフィックスを推測してください。新機能には feat/、バグ修正には fix/、緊急の本番環境修正に限り hotfix/、ドキュメントには docs/、構成の変更には refactor/、テストには test/、メンテナンスには chore/ を使用してください。プレフィックスが不明確な場合は、ユーザーに確認してください。デフォルトで hotfix/ を使用してはいけません。
3. ブランチがローカルまたは origin に存在するか確認してください。存在する場合は、そのブランチに切り替えるか、別の名前を選ぶかユーザーに確認してください。上書きしてはいけません。
4. git switch -c <branch-name> を使用して作成し、切り替えてください。
5. コマンドが gitx branch check の場合、またはユーザーから明示的な依頼があった場合を除き、コミットやプッシュをしてはいけません。

gitx branch check の場合は、上記の命名規則に従ってブランチを作成し、その後 Checks の動作と Smart commit の動作に従ってください。

Checks

gitx check の場合、checks が設定されていればその順序で使用してください。設定されていない場合は、npm test、npm run lint、pnpm test、pytest、cargo test、go test ./...、make test など、関連するチェックを検出してください。設定の参照先に記載されたコマンドの検査規則と作業ディレクトリの規則に従ってください。リポジトリの指示で必須とされているチェックは、設定リストに含まれていなくても実施してください。チェックに失敗した場合は、それでもコミットするかユーザーに確認してください。Ship では、より厳格な失敗時停止の動作が適用されます。

コミットを分割する場合は、参照先に従い、提案する各ステージ済みスナップショットを個別に対象として、依頼されたチェックを実行してください。作業ツリー全体でチェックに合格しても、中間コミットの検証にはなりません。通常のスマートコミットでは、差分と依存関係の検査が必要ですが、テストスイートの実行が暗黙に求められることはありません。どのスナップショットをテストしたか、また実行できなかったチェックがあれば報告してください。

Pull

gitx pull の場合：

1. 現在のブランチ、アップストリーム、作業ツリーを確認してください。上書きされる可能性のある未コミットの変更がある場合は pull せず、状態を説明してユーザーに進め方を確認してください。
2. origin という名前のリモートが存在することを確認してください。存在しない場合は、何も pull していないと伝えてください。別のリモートを自動的に選択してはいけません。
3. リポジトリ既存の pull/rebase 設定を使用して、現在のブランチを origin から pull してください。origin に同名のブランチがない場合は、pull するものがないと説明してください。--force を使用したり、ローカルの作業を破棄したりしてはいけません。
4. 統合によって競合が発生した場合は、pull のワークフローを停止し、Conflict resolution の動作に従ってください。

Push

gitx push の場合：

1. origin という名前のリモートが存在することを確認してください。存在しない場合は、何もプッシュしていないと伝えてください。別のリモートを自動的に選択してはいけません。
2. 現在のブランチを origin にプッシュしてください。アップストリームが設定されていない場合は、直ちに git push -u origin <branch> で設定してください。

Pull requests

gitx pr [base] の場合は、ベースの解決、公開、既存の PR の処理、作成について、Pull requests を参照してください。この参照先には、Ship と共通するタイトル、本文、準備状況の規則も記載されています。

Ship

gitx ship [base] の場合は、Ship workflow を参照してください。このコマンドでは、必要に応じたフィーチャーブランチの作成、チェックの実行、選択した変更のコミット、ソースブランチの origin へのプッシュ、およびそのプッシュを通じたオープンな PR の作成または更新が許可されます。PR のマージ、強制プッシュ、分岐した履歴の自動統合は許可されません。

ブランチの命名、スマートコミットでの選択とグループ化、チェックの検出、プロジェクト設定を再利用してください。PR を準備する際は、共通のPR 規則を参照してください。チェックの失敗時の処理や、既存の PR を返す前にプッシュする処理など、公開の手順は Ship の参照先に従ってください。

GitHub の issue

gitx issue では、上記の引数形式に基づくディスパッチを使用し、GitHub issues で選択されたワークフローを確認してください。このリファレンスでは、前提条件、実装の境界、新しい issue のテンプレートを定義しています。

コンフリクトの解決

gitx resolve、または進行中のマージやリベースでコンフリクトが発生している場合：

1. 操作の状態、履歴、コンフリクトが発生しているすべてのファイルを確認します。
2. 各コンフリクトの両側を、それぞれの元となったコミットまでたどり、各変更の意図を理解します。コミットメッセージと、ローカルで参照可能な issue や PR の情報があれば確認します。
3. 互換性がある場合は両方の意図を保持して、すべてのハンクを解決します。両立しない場合は、統合の目的に最も適した動作を選び、そのトレードオフを明確に記載します。無関係な動作を新たに作り込んだり、ユーザーから明示的に依頼されない限り操作を中止したりしないでください。
4. プロジェクトに関連するチェックを実行します。設定済みの checks がある場合は記載順に実行し、リポジトリで必須のチェックも含めます。それ以外の場合は通常、型チェック、テスト、フォーマットの順に実行します。解決によって生じた問題を修正します。
5. 解決したファイルをステージングし、操作を完了します。マージの場合はコミットし、リベースの場合は git rebase --continue を実行して、リベースが完了するまで繰り返します。強制プッシュはしないでください。

状態と履歴

gitx status では、現在のブランチ、ステージ済みファイル、ステージされていないファイル、未追跡ファイル、および変更されたファイルの簡潔な概要を表示します。リポジトリは変更しないでください。

gitx tree では、現在のブランチとアップストリーム、作業ツリーの概要、アップストリームまたは origin との ahead/behind 数、取得可能であれば現在の PR、および直近 20 件のコミットをコンパクトなグラフで表示します。fetch、pull、push、ブランチの作成、その他リポジトリを変更する操作は行わないでください。

リポジトリの診断

gitx doctor [problem] では、リポジトリの診断を確認します。ローカルのリポジトリ状態と、ユーザーから提示されたエラーを調べ、確認された障害要因とそれが実際に及ぼす影響を説明し、必要最小限の次のステップを提案します。省略可能な問題の説明は診断の対象を絞るものであり、修復の許可ではありません。問題の説明がない場合は、一般的なワークフローの障害要因を確認します。

診断は読み取り専用で行います。fetch、ファイルや Git の状態の変更、プロジェクトのチェックやフックの実行、push のテスト、認証の開始、修復の適用は行わないでください。確認できた事実、考えられる原因、入手できない情報を区別してください。ローカルのリモート追跡参照は古くなっている場合があり、Git の操作に失敗してもローカルの状態だけでは原因を特定できないことがあります。変更やコンフリクトがあるという理由だけで、doctor のリクエストを Smart commit または Conflict resolution に振り分けないでください。

シークレットスキャン

gitx scan では、読み取り専用スキャンの対象範囲、ツールの選択、露出状況の分類、秘匿化、およびレポートの形式と評価について、シークレットスキャンを確認します。

amend

gitx amend では、まず確認を求め、変更案のコミットメッセージを表示します。ユーザーが確認してから、直近のコミットを amend します。マージコミットは amend しないでください。強制プッシュはしないでください。amend したコミットがすでにプッシュされている場合は、通常の push は拒否されることを説明し、どのように進めるかユーザーに尋ねてください。

安全性とリスクのあるファイル

.env、*.pem、*.key、credentials、token、secret、api_key、*.log、dist/、build/、node_modules/ など、シークレット、認証情報、秘密鍵、ログ、またはビルド成果物の可能性があるものを含める前に、必ず警告してください。