woostack-commit

woostack-commit

現在承認されている成果に属する変更をコミットし、呼び出し元が指定した範囲まで届けます。明示的な /woostack-commit は公開を行います。自然言語によるコミットのみの依頼、または --no-pr-update の場合は、ローカルコミットの後に停止します。Issue は任意です。コミットや PR の更新に、Issue、プロジェクト、担当者、ライフサイクル記録、帰属を示すトレーラーは必要ありません。

このスキルは Git の状態を変更し、PR の配信または保守が依頼された場合は GitHub の PR メタデータも変更します。マージ、自動マージの有効化、PR のキューへの追加、無関係なコミットの修正、無関係な作業のステージングは行いません。最近のアクティビティから作業を見つけたり、暗黙的に Issue やプロジェクトを作成したりすることもありません。

呼び出し

/woostack-commit [message]
/woostack-commit --no-pr-update [message]
/woostack-commit --issue <issue> [--issue <issue> ...] [message]

message は省略可能です。指定されたメッセージが不正確な場合は、そのまま従うのではなく修正します。

--issue には、Issue 番号、Issue の URL、または依頼文や確立されたタスクコンテキストですでに明示されている曖昧さのない Issue を指定できます。この配信が対象とする関連 Issue ごとに繰り返し指定します。これは簡略記法であり、必須の入力形式ではありません。また、作業を選択するものでもありません。紐付ける前に実際のリポジトリと Issue を特定し、対象や意図が本当に曖昧な場合は確認してください。ブランチの文言、PR の文言、タイトル、Issue キー、検索結果は判断材料であり、承認ではありません。Issue のコンテキストだけでは公開権限は与えられません。また、タスクで子 Issue が指定されているという理由だけで親 Issue を選ぶこともありません。

ワークフロー

1. 調査して準備します。 Git はワークツリー内のどのディレクトリからでも調査対象の状態を解決します。特定の場所は必要ありません。デリバリーの 準備と検証手順に従い、ブランチ、意図したベース、インデックス、差分を調査して、変更が承認済みの成果に照らしてどのようなものかを分類します。未解決の競合、detached HEAD、このワークツリー上の競合する書き込み元、保護されたプライマリブランチでの作業、または変更されたパスを実際に分類できない場合は、作業を停止します。既存のワーカー結果、引き継ぎ、計画、または検証サマリーで確認された結果を再利用する場合は、 エビデンスが引き続き有効な場合に従って適用可能性を独自に評価してから再利用し、時間のかかるチェック、機能の欠如、タイムアウト、その他未検証の要件については、 時間のかかるチェックに従って対処します。必須フックと設定済みのcommit.commandは、テスト結果を再利用したかどうかにかかわらず、空でない場合は実行します。未解決の必須コミットチェックの失敗、またはスコープ外の修正がある場合はコミットを中止します。必須チェックを省略したり、アサーションを弱めたりしてはいけません。実装の受け入れ条件が未達の場合、その状態は変わりませんが、明示的なコミットまたは公開のゲートでない限り、承認済みのドラフト作成を妨げるものではありません。未達の基準は明示してください。メタデータのみの保守または準備状況の確認では、ref の変更が不要な場合、既存のコミットを再利用し、準備、ステージング、コミット、プッシュを省略します。

2. ステージングしてコミットします。 デリバリーの 選択してコミット手順に従います。明示的なパスまたはハンクをステージングし、ユーザーの無関係なステージ済みおよび未ステージの作業には手を加えず、レビュー済みの選択内容だけをコミットします。新しいファイル、スキーマ、レシート、ハッシュ一覧、キャッシュサブシステムは要求しません。

3. 要求された場合に公開します。 --no-pr-updateを指定した場合は、ここで停止します。プッシュ、PR、スタック、Issue への書き込みは行わず、リモートの読み取りも必要ありません。既知の PR エビデンスは保持し、実際には行っていない読み取りを行ったと主張しないでください。また、リモートの状態については、不在または配信成功を主張せず、未検証として報告します。それ以外の場合は、デリバリーの 公開して読み戻す手順に従います。タスクブランチを公開し、一致するオープン PR を再利用するか、新しいドラフトを作成します。タイトル、本文、Issue 参照、要求された注記のルールを適用し、要求またはリポジトリのワークフローで必要な場合に限り、 ネイティブスタックへの所属を登録します。リライトには明示的な保守スコープが必要です。

4. 配信を検証します。 手順の読み戻しを自分の目で確認します。公開された ref が意図した head であること、PR が意図したものでベースも意図どおりであること、タイトルと本文が記述どおりに反映されていることを確認します。変更が要求されていない限り、既存の準備状況を維持します。各手順で変更されたもの、または不確かなままになったものを再確認し、その判断に必要な範囲を超えて読み取らないでください。書き込みの結果が不明な場合は、実際に何が起きたかを確認し、最初に未証明となっている手順から再開します。応答が失われたからといって、コミット、プッシュ、PR 更新、スタックリンク、コメントを繰り返してはいけません。

依頼された PR の保守と準備状況

公開済み PR のリベース／積み重ね直しを明示的に依頼された場合は、対象範囲を限定した書き換え、公開、ベースの変更、およびネイティブなメンバーシップの調整が許可されます。準備状況の確認のみを依頼された場合、新しいコミットを作成せずに対応できます。通常のコミットやコメントの修正は、無関係な PR の積み重ね直しを許可するものではありません。また、積み重ね直しのみの依頼では、準備完了への変更は許可されません。証拠に基づいて、対象の PR、意図された下から上への順序、ヘッド、ベース、影響を受けるスタックメンバーを特定し、書き込みを行う前に対象範囲と順序を伝えてください。重要な未解決の選択肢や付随的な影響についてのみ確認し、改めて承認一式を求めないでください。

元のヘッドを復元できる状態に保ち、各 PR の識別情報と意図された変更を維持し、選択されていないブランチ、メンバー、ローカルの編集には触れないでください。対象範囲を限定したリースの保護策と、サポートされているネイティブなメンバーシップ操作に従ってください。既存のメンバーシップや最上位ではない親は、拒否する理由ではなく計画が必要な事項です。書き込みを行う前に、選択されていないメンバーに及ぶスタック全体への影響を解決してください。結果が部分的または不確かな場合は再読み込みし、実際のプロバイダーまたは権限の制限を報告してください。

各 PR の完全な差分を意図されたベースと照合し、スタック全体の差分を trunk と照合して確認してください。無関係なコミットや失われた作業を含めず、先行する変更を保持してください。ヘッド、ベース、ネイティブな順序／メンバーシップ、および依頼された準備状況を読み戻し、新しいヘッドでチェックを更新してください。新規 PR はデフォルトでドラフトにします。依頼がない限り、既存の準備状況は変更しません。準備完了であっても、チェックの通過が証明されるわけではなく、承認やマージの権限が付与されるわけでもありません。保守のために保護設定、認証情報、または恒常的なポリシーを変更しないでください。

報告

コミットの件名と SHA、正規の PR URL またはローカルのみであることの明示、実際に確認できた検証結果、未解決の作業があればその内容を報告してください。ブランチ、パス、スタック、メモに関する詳細は、レビューや作業の継続に役立つ場合にのみ追加してください。独立して読み戻していないコミット、リモートへの書き込み、チェック、参照を行ったと主張しないでください。