jpskill.com
📦 その他 コミュニティ

commit-and-push

変更をコミットし、GPG署名付きでリモートリポジトリにプッシュ、必要に応じてPRを作成し、Geminiのレビューを待ってフィードバックに対応するところまでを、一連の流れとして実行するSkill。

📜 元の英語説明(参考)

Commit staged changes and push to the remote using conventional commits with GPG signing. Use when you need to commit and push work, create a PR if missing, and wait for Gemini review before addressing feedback.

🇯🇵 日本人クリエイター向け解説

一言でいうと

変更をコミットし、GPG署名付きでリモートリポジトリにプッシュ、必要に応じてPRを作成し、Geminiのレビューを待ってフィードバックに対応するところまでを、一連の流れとして実行するSkill。

※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o commit-and-push.zip https://jpskill.com/download/8079.zip && unzip -o commit-and-push.zip && rm commit-and-push.zip
🪟 Windows (PowerShell)
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/8079.zip -OutFile "$d\commit-and-push.zip"; Expand-Archive "$d\commit-and-push.zip" -DestinationPath $d -Force; ri "$d\commit-and-push.zip"

完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。

💾 手動でダウンロードしたい(コマンドが難しい人向け)
  1. 1. 下の青いボタンを押して commit-and-push.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → commit-and-push フォルダができる
  3. 3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
  4. 4. Claude Code を再起動

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

  1. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。

詳しい使い方ガイドを見る →
最終更新
2026-05-18
取得日時
2026-05-18
同梱ファイル
1

📖 Skill本文(日本語訳)

※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

コミットとプッシュ

ステージングされた変更をコミットし、ブランチをプッシュし、必要に応じてPRを作成し、初期のGeminiレビューを処理します。

セットアップ

すべての gh コマンドのリポジトリを決定します。

REPO=$(./scripts/agents/tooling/agentTool.ts getRepo)

常に -R "$REPO"gh コマンドに渡してください。

実行中に以下の状態フラグを追跡します。

  • gemini_quota_exhausted: ブール値、初期値は false。Geminiが毎日のクォータメッセージを返した場合に true に設定します。
  • used_fallback_agent_review: ブール値、初期値は false。フォールバックのクロスエージェントレビューを1回実行した後に true に設定します。
  • deferred_items: {thread_id, path, line, body, html_url} の配列、初期値は空。レビューのフィードバックがその場で修正されず、後回しにされた場合に $address-gemini-feedback によって設定されます。この状態を $enter-merge-queue に渡して、issueを作成します。

ワークフロー

  1. ブランチの確認:

    • main ブランチにいる場合は、変更内容に合わせた名前の新しいブランチを作成します。
    • 作成/切り替え後、VS Codeのタイトルを更新します。
    ./scripts/agents/tooling/agentTool.ts setVscodeTitle
  2. 変更内容の分析:

    • git statusgit diff --staged を実行して、コミットされる内容を確認します。
    • ツールがアクションを報告するにもかかわらず、git status が予期しない変更を示さない場合は、生成されたファイルについて質問せずに続行します。
  3. コミットの形式:

    • CLAUDE.md のコミットガイドラインに従ってください(conventional commits、5秒のタイムアウトでGPG署名、co-author行なし、フッターなし)。
    • ヘッダーは ≤ 50文字 でなければなりません(commitlint header-max-length によって強制されます)。ヘッダーは最初の行全体です: type(scope): description。遵守を確実にするために、コミット前に文字数を数えてください。長すぎる場合は、スコープまたは説明を短くします。
      • スコープを削除する: feat: add redis and garage reset scripts
      • 省略する: feat(scripts): add reset scripts (詳細は本文に記述)
      • より広い動詞を使用する: feat(scripts): add stack reset tooling
    • ここでバージョンを上げないでください。
  4. プッシュ:

    • コミット後、現在のブランチをリモートにプッシュします。
    • プリプッシュフックはフルビルドとテストを実行します。長いタイムアウトを設定し、タイムアウトが失敗を意味すると想定しないでください。
  5. プッシュが完了したことの確認:

    • PRの作成またはGeminiのフォローアップに進む前に、プッシュが実際に完了したことを確認してください。
    BRANCH=$(git branch --show-current)
    git fetch origin "$BRANCH"
    [ "$(git rev-parse HEAD)" = "$(git rev-parse origin/$BRANCH)" ] || echo "NOT PUSHED"
    • 検証が成功するまで、ステップ6または7に進まないでください。 Xがリモートに表示されていないときに、Geminiに「コミットXで修正済み」と返信すると、混乱が生じます。
  6. PRのオープン:

    • PRが存在しない場合は、gh pr create で作成します。
    • 自動クローズキーワード(ClosesFixesResolves)を含めないでください。
    • ClaudeスタイルのPR本文形式を使用し、評価されたエージェントIDを含めます。
    • PR本文のシェル補完のバグを避けてください。常にシングルクォートのheredocで本文コンテンツを作成し、--body-file 経由で渡してください(または、バッククォート/$/[] が存在しない場合にのみ --body "$(cat ...)" を使用してください)。

    エージェントIDを計算します。

    AGENT_ID=$(basename "$(git rev-parse --show-toplevel)")

    PR本文のテンプレート(実際の箇条書きを記入し、セクションの順序を維持してください)。この安全なパターンを推奨します。

    PR_BODY_FILE=$(mktemp)
    cat <<'EOF' > "$PR_BODY_FILE"
    ## Summary
    - <動詞主導の具体的な変更>
    - <必要に応じて2番目の具体的な変更>
    
    ## Testing
    - <実行されたコマンドまたは "実行されなかった (理由)">
    
    ## Issue
    - #<issue-number>
    
    Agent: __AGENT_ID__
    EOF
    sed -i'' -e "s/__AGENT_ID__/${AGENT_ID}/g" "$PR_BODY_FILE"
    gh pr create ... --body-file "$PR_BODY_FILE"
    rm -f "$PR_BODY_FILE"

    関連するissueがない場合は、## Issue セクションを以下に置き換えます。

    ## Related
    - <リンクまたは簡単な参照>
    • PRの作成後、以下を実行します。
      • ./scripts/agents/tooling/agentTool.ts setVscodeTitle
      • ./scripts/agents/tooling/agentTool.ts tagPrWithTuxedoInstance
  7. Geminiを待機:

    • Gemini Code Assistがレビューするまで60秒待ちます。
  8. クォータ超過の確認:

    • Geminiのクォータ超過は、最初の待機中またはその後のフォローアップのやり取り中に発生する可能性があります。
    • すべてのGeminiの応答画面でクォータメッセージを確認してください。
    ./scripts/agents/tooling/agentTool.ts checkGeminiQuota --number "$PR_NUMBER"

    JSONレスポンスの quota_exhausted: true をクォータ超過として扱います。

    • 見つかった場合:

      • gemini_quota_exhausted=true を設定します。
      • used_fallback_agent_review=false の場合は、フォールバックのクロスエージェントレビュー(Codex)を1回実行します。
      # 同等のスキル呼び出し: /cross-agent-review codex
      ./scripts/agents/tooling/agentTool.ts solicitCodexReview
      • used_fallback_agent_review=true を設定します。
      • 今回の実行では、これ以上のGeminiのフォローアップをスキップします。
      • /enter-merge-queue に進むか、スキルを終了します。
  9. フィードバックへの対応:

    • gemini_quota_exhausted=false の場合は、未解決のコメントに対して $address-gemini-feedback を実行します。
    • Geminiに返信する際は、必ず @gemini-code-assist をタグ付けして、通知が届くようにしてください。
    • ./scripts/agents/tooling/agentTool.ts replyToGemini --number <pr> --comment-id <id> --commit <sha> でGeminiに返信します(gh pr review ではありません)。
    • カスタムの修正以外の応答には、replyToComment のみを使用してください。
    • Geminiとのやり取りのたびにステップ8を再実行します。クォータが後で表示された場合は、すぐにフォールバックに切り替えます。
    • $address-gemini-feedback は、フィードバックがその場で修正されず、後回しにされた場合に deferred_items を設定する可能性があります。
  10. ダウンストリームスキルへの状態の報告:

    • PR番号とURL
    • Geminiのクォータが超過したかどうか
    • 収集された deferred_items

    deferred_items が空でない場合は、$enter-merge-queue がマージ後に deferred-fix ラベル付きの追跡issueを作成することを言及してください。

トークン効率 (重要)

必須: すべてのgit commitおよびpushコマンドは、標準出力を /dev/null にリダイレクトする必要があります。これに失敗すると、フックの出力で数千のトークンが無駄になります。

# 正しい - 常にこれらの形式を使用してください
git commit -S -m "message" >/dev/nul

(原文はここで切り詰められています)
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

Commit and Push

Commit staged changes, push the branch, create a PR if needed, and handle initial Gemini review.

Setup

Determine the repository for all gh commands:

REPO=$(./scripts/agents/tooling/agentTool.ts getRepo)

Always pass -R "$REPO" to gh commands.

Track these state flags during execution:

  • gemini_quota_exhausted: Boolean, starts false. Set to true when Gemini returns its daily quota message.
  • used_fallback_agent_review: Boolean, starts false. Set to true after running one fallback cross-agent review.
  • deferred_items: Array of {thread_id, path, line, body, html_url}, starts empty. Populated by $address-gemini-feedback when review feedback is deferred rather than fixed on-the-fly. Pass this state to $enter-merge-queue for issue creation.

Workflow

  1. Check branch:

    • If on main, create a new branch named for the change.
    • After creating/switching, update the VS Code title:
    ./scripts/agents/tooling/agentTool.ts setVscodeTitle
  2. Analyze changes:

    • Run git status and git diff --staged to confirm what will be committed.
    • If tooling reports actions but git status shows no unexpected changes, proceed without asking about generated files.
  3. Commit format:

    • Follow CLAUDE.md commit guidelines (conventional commits, GPG signed with 5s timeout, no co-author lines, no footers).
    • Header must be ≤ 50 characters (enforced by commitlint header-max-length). The header is the entire first line: type(scope): description. To ensure adherence, count characters before committing. If too long, shorten the scope or description:
      • Drop the scope: feat: add redis and garage reset scripts
      • Abbreviate: feat(scripts): add reset scripts (put details in body)
      • Use a broader verb: feat(scripts): add stack reset tooling
    • Do not bump versions here.
  4. Push:

    • Push the current branch to the remote after the commit.
    • The pre-push hook runs full builds and tests; set a long timeout and do not assume timeouts mean failure.
  5. Verify push completed:

    • Before proceeding to PR creation or Gemini follow-up, verify the push actually completed:
    BRANCH=$(git branch --show-current)
    git fetch origin "$BRANCH"
    [ "$(git rev-parse HEAD)" = "$(git rev-parse origin/$BRANCH)" ] || echo "NOT PUSHED"
    • Do NOT proceed to step 6 or 7 until verification passes. Replying to Gemini with "Fixed in commit X" when X is not visible on remote creates confusion.
  6. Open PR:

    • If no PR exists, create one with gh pr create.
    • Do not include auto-close keywords (Closes, Fixes, Resolves).
    • Use the Claude-style PR body format and include the evaluated agent id.
    • Avoid shell interpolation bugs in PR bodies: always build body content with a single-quoted heredoc and pass it via --body-file (or --body "$(cat ...)" only when no backticks/$/[] are present).

    Compute the agent id:

    AGENT_ID=$(basename "$(git rev-parse --show-toplevel)")

    PR body template (fill in real bullets, keep section order). Prefer this safe pattern:

    PR_BODY_FILE=$(mktemp)
    cat <<'EOF' > "$PR_BODY_FILE"
    ## Summary
    - <verb-led, concrete change>
    - <second concrete change if needed>
    
    ## Testing
    - <command run or "not run (reason)">
    
    ## Issue
    - #<issue-number>
    
    Agent: __AGENT_ID__
    EOF
    sed -i'' -e "s/__AGENT_ID__/${AGENT_ID}/g" "$PR_BODY_FILE"
    gh pr create ... --body-file "$PR_BODY_FILE"
    rm -f "$PR_BODY_FILE"

    If there is no associated issue, replace the ## Issue section with:

    ## Related
    - <link or short reference>
    • After creating the PR, run:
      • ./scripts/agents/tooling/agentTool.ts setVscodeTitle
      • ./scripts/agents/tooling/agentTool.ts tagPrWithTuxedoInstance
  7. Wait for Gemini:

    • Wait 60 seconds for Gemini Code Assist to review.
  8. Check for quota exhaustion:

    • Gemini quota exhaustion can happen during the initial wait OR later follow-up interactions.
    • Check all Gemini response surfaces for the quota message:
    ./scripts/agents/tooling/agentTool.ts checkGeminiQuota --number "$PR_NUMBER"

    Treat quota_exhausted: true in the JSON response as quota exhaustion.

    • If found:

      • Set gemini_quota_exhausted=true.
      • If used_fallback_agent_review=false, run one fallback cross-agent review (Codex):
      # Equivalent skill invocation: /cross-agent-review codex
      ./scripts/agents/tooling/agentTool.ts solicitCodexReview
      • Set used_fallback_agent_review=true.
      • Skip further Gemini follow-ups for this run.
      • Proceed to /enter-merge-queue or end the skill.
  9. Address feedback:

    • If gemini_quota_exhausted=false, run $address-gemini-feedback for unresolved comments.
    • When replying to Gemini, always tag @gemini-code-assist to ensure it receives a notification.
    • Reply to Gemini with ./scripts/agents/tooling/agentTool.ts replyToGemini --number <pr> --comment-id <id> --commit <sha> (not gh pr review).
    • Use replyToComment only for custom non-fix responses.
    • Re-run step 8 after each Gemini interaction. If quota appears later, switch to fallback immediately.
    • $address-gemini-feedback may populate deferred_items if any feedback is deferred rather than fixed on-the-fly.
  10. Report state for downstream skills:

    • PR number and URL
    • Whether Gemini quota was exhausted
    • Any deferred_items that were collected

    If deferred_items is non-empty, mention that $enter-merge-queue will create a tracking issue with the deferred-fix label after merge.

Token Efficiency (CRITICAL)

MANDATORY: ALL git commit and push commands MUST redirect stdout to /dev/null. Failure to do this wastes thousands of tokens on hook output.

# CORRECT - always use these forms
git commit -S -m "message" >/dev/null
git push >/dev/null

# WRONG - NEVER run without stdout suppression
git commit -m "message"  # Burns 1000+ tokens on pre-commit output
git push                 # Burns 5000+ tokens on pre-push output

Why this is non-negotiable:

  • Husky pre-commit hooks output lint results, type-check results
  • Husky pre-push hooks run full test suites and builds
  • A single unsuppressed git push can add 5,000+ lines to context
  • Errors go to stderr, which >/dev/null preserves