git-shortcuts

Git ショートカット

安全対策：このスキルをアシスタントが自律的に呼び出すことは、決して許可されません。このスキルはユーザーが明示的に呼び出す場合にのみ使用できます。ユーザーのメッセージに --cp、--cppr など、-- で始まる短縮形が明示的に入力された場合に限り実行してください。アシスタントが独自に判断してこのスキルを呼び出してはなりません。

各文字をアクションに割り当て、順番に実行します。

ブランチモデル

トランクベースです：ticket → main、または機能が複数のチケットにまたがる場合は ticket → epic/<name> → main です。トランクへのマージでは何もリリースされません。リリースするのは --release です。

まず、リポジトリが移行済みか確認してください。 staging ブランチが残っているリポジトリでは、旧来の一方向モデルが使われています。以下のルールは適用されません。

git ls-remote --exit-code --heads origin staging > /dev/null 2>&1 && echo LEGACY

LEGACY の場合はユーザーに伝えてから、このファイルと同じ場所にある LEGACY-STAGING.md を読み、そちらに従ってください。そのようなリポジトリで、トランクを対象にしていることをユーザーに知らせずに進めてはなりません。

ベースブランチをハードコードしてはなりません。 リポジトリに独自のヘルパーがある場合は、そちらを優先してください。

branch=$(git symbolic-ref --short HEAD)
trunk=$(node .agents/skills/verify/scripts/default-branch.mjs)

if [ -f .agents/hooks/lib/branch-name.sh ]; then
  . .agents/hooks/lib/branch-name.sh
  base=$(branch_base "$branch")
else
  base=$(git config "branch.${branch}.laicaBase" 2> /dev/null)
  case "$base" in
    epic/*) git rev-parse --verify --quiet "refs/remotes/origin/$base" > /dev/null || base=$trunk ;;
    *) base=$trunk ;;
  esac
fi

$trunk はリポジトリのデフォルトブランチです。推測せずに読み取ってください。$base は pr の対象ブランチで、トランクか、チケットの派生元であるエピックです。

ベースを誤ると差分が小さくなります。そしてレビューでは、小さな差分ほど問題なしと判断されがちです。そのため、origin 上で確認できない epic/* のベースはトランクに切り替えます。逆は決して行いません。

短縮形の対応表

文字	アクション
c	コミット — /commit スキルを呼び出します（関連ファイルをステージし、Conventional Commits 形式のコミットメッセージを書いて、コミットを作成します）
p	プッシュ — git push origin <current-branch>
pr	PR を作成 — PR 作成プロトコルに従って gh pr create を実行します（タイトルと本文を指定し、--base "$base" を設定します）
m	マージ — マージプロトコルに従って、マージ可能になるまで PR の状態を確認します。その後、Slack への概要の投稿を提案します（下記参照）

チケットブランチにはスカッシュマージが適しています。マージ後にブランチは不要になるためです。エピックはマージコミットでマージします。スカッシュすると、エピックを作成した理由でもあるチケットごとのコミットがまとめられてしまいます。また、release-please はコミットメッセージを読み取って変更履歴を作成します。

マージプロトコル

このスキルと同じ場所にある ../babysit-pr/SKILL.md を最後まで読み、マージモードでその手順に従ってください。CI の予算、マージコマンド、終了状態は、そのまま適用されます。

• チケットブランチ：スカッシュマージの --merge。
• トランクへの epic/* ブランチ：マージコミットの --merge=merge。
• babysit-pr がインストールされていない場合：停止し、npx -y github:timschoch/skilly add babysit-pr を実行するようユーザーに伝えてください。単独の gh pr merge に切り替えてはなりません。
• ループが needs-user または closed で終了した場合：m のステップは失敗です。停止して、その結果をユーザーに伝えてください。

PR 作成プロトコル

事前確認。 gh pr view --json url を実行します。このブランチですでに PR が開かれている場合は、その旨を報告して終了します。次に、origin/$base との差分を読み、ユーザーが提示した目標に合致していることを確認します。

タイトル。 Conventional Commit のタイプに続けて、何をしたかではなく、変更がなぜ重要なのかを記します。

• 悪い例：perf(server): negotiate per-message deflate on the websocket
• 良い例：perf(server): cut websocket frame size by 70% with gzipping

本文。 このスキルと同じ場所に ../pr/SKILL.md がある場合は、最後まで読み、そのテンプレートに基づいて本文を作成します。その場合、以下の2行は適用されません。存在しない場合は、まずユーザー自身の言葉で問題を書き、その後、数行で解決策を記します。実装内容の一覧にはしません。

• 悪い例：「すべての新しいスレッドの開始箇所から、暗黙のワークスペース引き継ぎを削除しました……」
• 良い例：「既存のワークツリーで新しいスレッドを開始すると、新しいワークツリーのデフォルト設定が無視されていました。」

どちらの場合も、差分が約200行を超える場合は、レビューを始める箇所を示す短い「レビュー方法」の案内を追加します。本文の末尾には、セッションで提示された帰属表示の行を記載します。

ドラフト PR は作成しません。 レビューボットは通常の PR でのみ実行されます。

ルール

• ブランチは絶対に削除しません。 gh コマンドに --delete-branch を渡してはいけません。git branch -d や git push origin --delete も実行してはいけません。ツールやコマンドによってブランチが削除される場合は、そのフラグや手順を完全に省略します。マージ時に GitHub がリモートのヘッドブランチを削除する設定（delete_branch_on_merge）になっている場合、削除するのはリポジトリの設定であり、フラグを渡す理由にはなりません。

• 略式の手順に記載された順序（左から右）で実行します。

• 手順が失敗した場合は停止して報告し、次の手順には進みません。

• c の場合は、コミットの全プロトコルに従いますが、ステージするファイルは、この会話で行った作業に限定します。会話の文脈から、今回のセッションで読み取り、編集、または作成したファイルを特定し、関連ファイルを判断します。git status を実行して未コミットの変更をすべて確認してから、この作業に属するファイルだけをステージします。今回の作業と無関係な変更ファイル（並行するエージェントセッションによるものなど）がある場合は、ステージせずに残します。対象かどうか判断に迷うファイルは除外し、その旨を記載します。git add . や git add -A は絶対に使用しません。ステージする前に、次の正確な形式で対象範囲の要約を出力します。

  In scope:
  • src/foo/bar.ts
  • src/foo/baz.ts
  
  Excluded:
  • src/other/thing.ts  (reason)
  

有効な組み合わせ

すべての入力には -- を付ける必要があります。

入力	手順
--c	コミット
--p	プッシュ
--cp	コミット → プッシュ
--pr	PR を作成
--prm	PR を作成 → マージ
--cppr	コミット → プッシュ → PR を作成
--cpprm	コミット → プッシュ → PR を作成 → マージ
--ff	現在のブランチをリモートから早送りする（下記参照）
--release	オープン中のリリース PR を出荷する（下記参照）。旧名称の --pub も同じ処理を行います
--close	現在のワークツリーを破棄する — ティアダウンして削除する（下記参照）。Superset では何もしません

その他の組み合わせ（例：--m 単独）は通常とは異なるため、続行する前にユーザーに確認してください。

マージ後の Slack サマリー

m（マージ）が成功するたびに、次の手順を実行します。

1. 作成者の Slack ユーザー ID を解決します。

   • 環境変数に SLACK_USER_ID が設定されているか確認します（echo $SLACK_USER_ID）。
   • 設定されていない場合：ユーザーに「Was ist dein Slack-Handle? (z.B. tim)」と尋ねます → mcp__slack__lookup_user_by_email または mcp__slack__users_lookupByUsername を呼び出してユーザー ID を解決します → 次に「Soll ich die ID als SLACK_USER_ID=<id> in .env speichern?」と尋ねます。はいの場合、.env にその行を追加します。

2. マージされた PR の詳細を取得します：gh pr view --json title,url,body

3. 1 行のメッセージを作成し（下記を参照）、プレビューとして表示します。

   Slack #dev: @tim: repo-name -> PostHog läuft jetzt via Reverse Proxy unter /_s — kein Adblocker-Problem mehr. Posten?

4. はいの場合：mcp__slack__post_message を使い、channel: "#dev" を指定して投稿します。Slack でクリック可能な @メンションとして表示されるよう、メンションには <@USER_ID> を使います。いいえの場合：何も言わずにスキップします。

5. 手順 3/4 に対するユーザーの応答を待ってから、停止します。 マージは完了です。--close などの後続処理を提案しないでください。マージ後に片付けるものはありません。

メッセージ形式： <@USER_ID>: <repo-name> -> <one-liner> <PR-URL>

1 行のメッセージの作成方法： ドイツ語で、現在形の 1 文にします。コミットの種類ではなく、実際に何が変わったかを最初に述べます。文の後に PR の URL を付けます（文中には埋め込みません）。箇条書きや絵文字は使いません。ただし、PR の内容が明らかにお祝いにふさわしい場合は絵文字を使ってもかまいません。

例：

• PR タイトル：feat: add reverse proxy for PostHog
• 本文：/_s を PostHog にルーティングし、広告ブロッカーを回避します
• → <@U0123ABCD>: colin -> PostHog läuft jetzt via Reverse Proxy unter /_s — kein Adblocker-Problem mehr. https://github.com/…

--ff コマンド

現在のブランチをリモートの対応ブランチにファストフォワードします：git pull --ff-only。

• アップストリームが設定されていない場合 → git fetch origin を実行し、その後、該当する参照が存在すれば git merge --ff-only origin/<branch> を実行します。origin に存在しない場合 → その旨を報告して停止します。
• ファストフォワードできない場合（ローカルとリモートでブランチが分岐している場合）→ git は自動的に中断します。分岐を報告して停止します。絶対に、強制的に処理を進めるためにマージやリベースへ切り替えないでください。
• 未コミットの変更があっても問題ありません。競合する場合に限り、git は更新を拒否します。その場合は報告して停止します。
• 他のブランチには触れず、何も公開しません。

--release コマンド

最後のリリース以降に trunk にマージされたものをすべてリリースします。以前は --pub という名前でしたが、動作は同じです。

このスキルはバージョンの計算、タグの作成、ブランチのマージを行いません。release-please は trunk に対してリリース PR を 1 つ開いた状態に保ち、マージのたびに内容を書き換えます。このコマンドはその PR を確認してマージします。マージすると、リポジトリのリリースワークフローが実行され、タグの作成、本番環境の移行、デプロイが行われます。

ブランチの制限はありません。どのブランチからでも実行できます。

事前確認 — リリースワークフローを見つけます：wf=$(grep -rl release-please .github/workflows/ 2> /dev/null | head -1)。空の場合、このリポジトリにはリリース自動化がありません。ここでは trunk へのマージがすべてだと報告して停止します。手動でタグ付けやデプロイをしてはいけません。

手順：

1. リリース PR を見つける — gh pr list --base "$trunk" --state open --label "autorelease: pending" --json number,title,url,headRefName

   • 見つからない場合は停止して、次のように報告します：「未マージのリリース PR はありません。最後のリリース以降、<trunk> にマージされていないか、release-please がまだ実行中です。Actions を確認してください。」
   • 手動で作成してはいけません。 手動で作成した PR にはバージョン更新も変更履歴もありません。

2. リリース内容を表示する — gh pr diff <number> -- CHANGELOG.md を実行し、PR タイトルから新しいバージョンを表示します。次のように確認します：「これらの変更を含むリリース <version> を公開しますか？」返答を待ちます。

3. マージ可能か確認する — gh pr view <number> --json mergeable,mergeStateStatus

   • MERGEABLE → 続行します。
   • CONFLICTING → 停止して報告します。リリース PR の競合を手動で解決してはいけません。release-please が再生成するため、代わりに trunk で原因を修正してください。
   • UNKNOWN → 最大 3 回、5 秒間隔で再確認します。それでも UNKNOWN の場合は、報告して停止します。

4. スカッシュマージする — gh pr merge <number> --squash

5. このマージで作成された実行を監視する。 新しい実行がキューに入るまでは、gh run list --limit 1 は前回のリリース実行を返すため、それを監視すると古い成功結果が報告されます。マージコミットを指定して実行を特定します：

   sha=$(gh pr view <number> --json mergeCommit --jq '.mergeCommit.oid')
   for _ in $(seq 12); do
     id=$(gh run list --workflow="$(basename "$wf")" --json databaseId,headSha \
            --jq ".[] | select(.headSha==\"$sha\") | .databaseId" | head -1)
     [ -n "$id" ] && break
     sleep 10
   done
   [ -n "$id" ] && gh run watch "$id" || echo "Kein Release-Run für $sha nach 2 min — prüf die Actions."
   

   結果を報告します。タグ作成後にデプロイのステップが失敗した場合は、修復手順として、ユーザーに次のように伝えます：Actions → リリースワークフロー → Run workflow → タグを入力。

6. Slack の概要 — m の後と同じ手順で行います（上記を参照）。1 行の概要にはバージョンを含めます。

7. デプロイの注記 — リポジトリの分析機能でデプロイを記録する場合は、リポジトリの分析規約に従って [DEPLOY] <tag> を記録するようユーザーに伝えます。

--close コマンド

現在のワークツリーを破棄します。開発サーバーを停止し、データベースブランチを解放して、ディレクトリを削除します。必要な処理はワークツリーの所有者によって異なるため、まずそれを確認してください。

1. ワークツリーではありませんか？ メインチェックアウトが現在のディレクトリの場合（git rev-parse --git-common-dir がそのディレクトリ内を指す場合）、閉じるものはありません。その旨を報告して終了します。

2. Superset が所有するワークツリー — 何もしません。 パスが ~/.superset/worktrees/ の下にあります。Superset はセッション終了時に .superset/teardown.sh を実行してワークツリーを削除するため、--close で行う作業はありません。その旨を報告して終了します。

   唯一の例外は、セッションを開いたまま、データベースブランチを今すぐ解放したい場合です。その場合は、リポジトリの teardown スクリプト（bash scripts/teardown.sh — 常に 0 を返して終了し、2 回実行しても安全です）を実行し、ディレクトリには手を付けません。

3. それ以外の場所 — メインチェックアウトから、次のコマンドを 1 つ実行します。

   cd "$(git rev-parse --path-format=absolute --git-common-dir)/.." && yarn wt:remove <worktree-path>
   

   worktree-remove.sh はすでに両方の処理を連結しています。ワークツリー内で teardown.sh を実行し、その後 git worktree remove を実行します。先に teardown.sh を別途実行しないでください。

リポジトリにこれらのスクリプトが必要です。 実行前に確認してください。git grep -q '"wt:remove"' -- package.json を実行するか、package.json がないリポジトリでは test -f scripts/worktree-remove.sh を実行します。見つからない場合は、そこで終了し、このファイルと同じ場所にある WORKTREE-SETUP.md のセットアップテンプレートをユーザーに提示してください。 git worktree remove をそのまま実行して済ませようとしないでください。teardown が省略され、実行中の開発サーバーや削除されていないデータベースブランチなど、ワークツリーに残っていたものが放置されます。

注意すべき点は 2 つあります。

• ワークツリー内ではなく、メインチェックアウトから実行してください。 このコマンドは指定されたディレクトリを削除します。そのディレクトリ内から実行すると、シェルの作業ディレクトリがなくなり、以降のコマンドがすべて失敗します。
• --close はセッションの作業を終了させます。 それ以降は何も実行できません。ワーキングツリーが削除されるためです。ほかの作業をすべて終えてから報告し、最後の操作として実行してください。

git worktree remove は、コミットされていない変更があるワークツリーの削除を拒否します。先に変更をコミットするか破棄してください。作業内容が失われる --force は使用しないでください。

ブランチには触れません。 削除するブランチはありません。GitHub はマージ時にリモートブランチを削除し（delete_branch_on_merge）、ローカルブランチはワークツリーとともに削除されます。

ユーザーに求められていない限り、--close を提案してはいけません。 これはどのワークフローの手順にも含まれません。ユーザーが入力した場合にのみ実行します。PR のマージを理由に実行する必要はありません。

ブランチが epic/* の場合 — そのデータベースブランチは共有され、ワークツリーより長く存続するため、teardown では削除されません。次のように提案してください。「Neon-Branch epic/<name> も削除しますか？（yarn neon branches delete epic/<name>）」。TTL がないため、自動的に削除されることはありません。回答を待ってください。

? 修飾子

任意の省略形の末尾に ? を追加すると、最後のアクションが実行ではなく確認に置き換わります。それより前の手順は、チェーン内で通常どおり実行されます。

? は末尾にのみ指定できます。--cp?r は無効です。

最後のアクション	? の動作
c	コミットされていない変更を表示します：git status と git diff --stat を実行し、ステージングおよびコミットされる内容を要約します。コミットはしません。
p	何もしません — コミットメッセージに記載されている内容以外に、表示する有用な情報はありません。何も表示せずにスキップします。
pr	現在のブランチで PR が開かれているか確認し（gh pr view --json state,mergeable,url）、そのステータスとマージ可能な状態かどうかを報告します。PR は作成しません。
m	マージする代わりに PR のマージ状態を報告します：gh pr view --json state,mergeable,mergeStateStatus,baseRefName に加えて、使用されるマージ方法（--squash、または trunk に epic をマージする場合は --merge）を示します。Vercel の状態を確認するためのポーリングはしないでください — マージしてもデプロイは発生しません。
ff	更新せずに、ブランチがリモートよりどれだけ遅れているか／進んでいるかを報告します：git fetch origin を実行してから、git rev-list --left-right --count <branch>...origin/<branch> を実行します。早送りが可能かどうかを伝えます。プルはしません。
release	オープン状態のリリース PR を確認します：バージョン、変更履歴の差分、mergeable の状態を調べます。マージはしません。--pub? も同じコマンドです。
close	削除される対象を報告します：ワークツリーのパス、Superset がそのワークツリーを所有しているかどうか、コミットされていない変更、およびリポジトリが wt:remove を提供しているかどうかを示します。何も削除しません。
例：

• --c? → コミットされていない変更を要約します
• --cp? → コミットしてからスキップします（p? は何もしません）
• --cppr? → コミット → プッシュ → PR のステータスを確認します（作成しません）
• --cpprm? → コミット → プッシュ → PR を作成 → マージ可能な状態かどうかを報告します（マージしません）
• --ff? → ブランチがリモートよりどれだけ遅れているかを表示します（プルしません）
• --release? → 次のリリースに含まれる内容を表示します
• --close? → クローズ時に何が終了するかを表示します