auto-push

すべてをコミットしてプッシュする

注意：すべての変更をステージし、コミットしてリモートにプッシュします。すべての変更が同じ目的に属すると確信できる場合にのみ使用してください。

使用するタイミング

ユーザーが「すべてをコミットしてプッシュして」「これをリリースして」「自動プッシュして」など、現在の作業ツリーを一度にステージ、コミット、プッシュするよう求めた場合に、このスキルを実行します。プルリクエスト、コードレビュー、リリース、タグを希望している場合は実行しないでください。

前提条件

• git がインストールされており、現在のディレクトリが git リポジトリ内にあること。
• origin リモートが存在し、ユーザーがそこへプッシュできること。
• git config user.name と user.email が設定されており、git commit を実行できること。

編集前のリポジトリ同期（必須）

既存のリポジトリ内でファイルを作成、更新、削除する前に、現在のブランチをリモートと同期します。

branch="$(git rev-parse --abbrev-ref HEAD)"
git fetch origin
git pull --rebase origin "$branch"

作業ツリーがクリーンでない場合は、先に stash し、同期してから復元します。

git stash push -u -m "pre-sync"
branch="$(git rev-parse --abbrev-ref HEAD)"
git fetch origin && git pull --rebase origin "$branch"
git stash pop

origin がない場合、pull を利用できない場合、または rebase／stash で競合が発生した場合は、作業を中止し、続行する前にユーザーに確認してください。

手順

ステップ 1：変更を分析する

以下を並行して実行します。

• git status - 変更、追加、削除、未追跡のファイルを表示します
• git diff --stat - 変更の統計情報を表示します
• git log -1 --oneline - コミットメッセージのスタイルを確認するため、直近のコミットを表示します

ステップ 2：安全性チェックを実行する

❌ 検出した場合は所見として記録します。

• シークレット：.env*、*.key、*.pem、credentials.json、secrets.yaml、id_rsa、*.p12、*.pfx、*.cer
• API キー：実際の値（your-api-key、xxx、placeholder などのプレースホルダーではない値）が設定された *_API_KEY、*_SECRET、*_TOKEN 変数
• 大きなファイル：Git LFS を使用していない >10MB のファイル
• ビルド成果物：node_modules/、dist/、build/、__pycache__/、*.pyc、.venv/
• 一時ファイル：.DS_Store、thumbs.db、*.swp、*.tmp

API キーの検証： 変更されたファイルで、次のようなパターンを確認します。

OPENAI_API_KEY=sk-proj-xxxxx  # ❌ Real key detected!
AWS_SECRET_KEY=AKIA...         # ❌ Real key detected!
STRIPE_API_KEY=sk_live_...    # ❌ Real key detected!

# ✅ Acceptable placeholders:
API_KEY=your-api-key-here
SECRET_KEY=placeholder
TOKEN=xxx
API_KEY=<your-key>
SECRET=${YOUR_SECRET}

✅ 以下も確認します。

1. .gitignore：git status --porcelain に表示されたパスに、上記のシークレット、ビルド成果物、一時ファイルのパターンに一致するものがないこと。一致するものがあれば所見として記録し、.gitignore に追加する項目を提案します。
2. マージ競合：git diff --name-only --diff-filter=U の出力がないこと。パスが表示された場合は所見として記録します。
3. ブランチ：現在のブランチが main または master の場合は、所見として記録します。
4. API キー：変更されたファイル内のすべての *_API_KEY、*_SECRET、*_TOKEN の値がプレースホルダーであること。実際の値があれば所見として記録します。

上記の最初のリストに該当するものは、それぞれ所見として記録します。所見が 1 つ以上記録された場合、安全性チェックは不合格です。

ステップ 3：確認して実行する

1. 以下のドライランプレビューを表示します。安全性チェックが不合格の場合は、Proceeding now の行の代わりに所見を末尾に記載します。
2. すべての安全性チェックに合格した場合は、ステップ 4 に進みます。はい／いいえの質問はしないでください。
3. 安全性チェックに不合格があった場合は、所見をすべて列挙して停止します。ユーザーがブロッキング対象でない所見すべてを明示的に承認し、項目 4 によってブロッキング対象がすべて解消された後にのみ続行します。確認なしに不合格の安全性チェックを決して回避しないでください。
4. 確認してもブロッキング対象の所見は解消されません。
   • シークレット（シークレットファイルへの一致、または実際の API キー値）：ユーザーがプレースホルダー、テスト用フィクスチャ、サンプル値などの誤検出であると明言した場合にのみ続行します。実際のシークレットの場合は停止し、変更内容から削除してローテーションするよう伝えてから、/auto-push を再実行します。
   • 大きなファイル（Git LFS を使用していない >10 MB のファイル）：停止します。ステップ 2 を再実行した際に、Git LFS で追跡されている、削除されている、または .gitignore に記載されていることで、そのファイルが検出されなくなった場合にのみ続行します。

📊 Changes Summary:
- X files modified, Y added, Z deleted
- Total: +AAA insertions, -BBB deletions

🔒 Safety: ✅ No secrets | ✅ No large files | ⚠️ [warnings]
🌿 Branch: [name] → origin/[name]

Proceeding now: git add . → commit → push

ステップ 4：ファイルをステージする

ステップ 3 のブロッキング対象の所見が残っていない場合にのみ、このステップを実行します。これにより、git add . でシークレットや大きなファイルがステージされることを防ぎます。以下を順番に実行します。

git add .
git status --porcelain

ステップ 1 に記載されたすべてのパスがステージ済みであることを確認します。パスが不足している場合、または安全性チェックで対象にならなかったパスが表示された場合は、停止して報告します。

ステップ 5：コミットメッセージを作成する

変更を分析し、Conventional Commit 形式のメッセージを作成します。

形式：

[type]: Brief summary (max 72 characters)

- Key change 1
- Key change 2
- Key change 3

タイプ： feat、fix、docs、style、refactor、test、chore、perf、build、ci

例：

docs: Update concept README files with comprehensive documentation

- Add architecture diagrams and tables
- Include practical examples
- Expand best practices sections

ステップ 6：コミットしてプッシュする

git commit -m "$(cat <<'EOF'
[Generated commit message]
EOF
)"
git push
git log -1 --oneline --decorate

• git commit が失敗した場合（たとえば、事前コミットフックによる失敗）、フックの出力を表示して停止します。再試行しないでください。
• git push が non-fast-forward として拒否された場合は、git pull --rebase && git push を一度実行します。リベースで競合が発生した場合、または 2 回目のプッシュが失敗した場合は、停止して報告します。
• git push が成功した場合は、git log -1 --oneline --decorate に新しいコミットが origin/[branch] 上に表示されることを確認します。

ステップ 7：結果を報告する

Expected Output に示されているレポートを出力します。レポートはステータスから始まり、次の内容を含みます。

• 根拠： 実行したチェックとその結果（安全性スキャン、プッシュの終了コード、git log による確認）。
• 不確実性： 確認していない内容。CI とリモートフックはローカルでは実行されません。API キーのプレースホルダーテストはパターンマッチであり、確証ではありません。ステップ 3 でユーザーが確認した、または誤検出だとしたすべての検出結果を列挙します。
• 判断： プッシュが成功した場合は「承認は不要です。」とします。ブロックされた場合は、必要なユーザー操作を明記します。

期待される出力

最終レポートは、以下の固定形式のプレーンテキストです。ユーザーが別の形式を求めた場合も、4 つの部分の順序は維持します。

成功時：

✅ Successfully pushed to remote!

Commit: abc1234 feat: add login page with OAuth support
Branch: feature/auth → origin/feature/auth
Files changed: 4 (+112, -8)
Evidence: safety scan 0 findings · git push exit 0 · origin/feature/auth at abc1234
Uncertainty: CI and remote hooks not run; API-key check is pattern-based
Decision: No approval needed.

安全性チェックが失敗した場合：

❌ Push blocked — secrets detected

  .env: OPENAI_API_KEY=sk-proj-xxxxx (real key)

Evidence: safety scan 1 finding; nothing staged, committed, or pushed
Uncertainty: API-key check is pattern-based; if this value is a placeholder or test fixture, say it is a false positive to continue
Decision: Remove the key from the change and rotate it, then re-run /auto-push. A real secret cannot be confirmed to continue.

受け入れ基準

次のすべてを満たした場合、スキルの実行は成功です。

• 作業ツリーが origin と同期している（git fetch を実行済みで、リベースが競合なく完了しているか、stash と pop が競合なく完了している）
• 安全性スキャンでシークレット、実際の API キー、大きなバイナリが検出されていない。または、ユーザーがシークレットの検出結果をそれぞれ誤検出とし、ブロック対象ではないその他の検出結果をすべて明示的に確認している
• ブランチが正しい（main／master の場合は警告し、確認を得ている）
• コミットメッセージがステップ 5 の Conventional Commit 形式に従っている
• git push の終了コードが 0 で、git log -1 にリモート追跡参照上の新しいコミットが表示されている
• コミットハッシュ、ブランチ、ファイル数、根拠、不確実性、判断を含む最終レポートが出力されている

実行結果を評価する際は、読者がレポートを活用できるかどうかも確認します。

• 結果が見つけやすい： 1 行目にプッシュ済み、またはブロック済みと記載されている。
• 事実と仮定が区別されている： 根拠には実行したチェックのみを記載し、不確実性には未確認の内容を記載している。
• 主張の根拠をたどれる： 各主張がコマンドの結果（プッシュの終了コード、git log の出力、検出結果のファイルパス）を示している。安全性スキャンで問題が見つからなかったことは、プッシュの成功を意味しません。
• 次の判断が明確： 判断に「承認は不要です。」と記載されているか、ユーザーに必要な操作が明記されている。

エージェントによる確認では、人間がレポートを理解したかどうかは確認できません。人間からのフィードバックがない場合は、人間が理解したかどうかを未確認として報告します。

エッジケースとエラーへの対応

エッジケースの表、フェーズごとのステップ完了レポート形式、エラー処理のガイダンス、代替ワークフロー（選択的ステージング、対話型の git add -p、PR フロー）については、references/edge-cases-and-reports.md を参照してください。各ステップの後に、そのファイルに記載されたステップ完了レポートを出力します。

コミット対象をより細かく制御したい場合は、代わりに個別の git コマンドを使用してください。