auto-push

提交并推送所有更改

注意：暂存所有更改，提交并推送到远程端。仅在确定所有更改都属于同一组时使用。

使用时机

当用户要求“提交并推送所有更改”“发布此更改”“自动推送”，或以其他方式希望一次性暂存、提交并推送当前工作树时，触发此技能。如果用户需要 PR、代码审查、发布版本或标签，则跳过。

前提条件

• 已安装 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"

如果工作树不干净，先暂存，再同步，然后恢复：

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、无法拉取，或发生 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 管理且大于 10 MB 的文件
• 构建产物：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 值都是占位符。如果某个值是真实值，记录为问题。

上面第一组中每个匹配项也都是一项问题。只要记录了至少一项问题，安全检查就算未通过。

第 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：生成提交消息

分析更改并创建符合约定格式的提交消息：

格式：

[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 因非快进错误而被拒绝，请运行一次 git pull --rebase && git push。如果变基发生冲突，或第二次推送失败，请停止并报告。
• 如果 git push 成功，请检查 git log -1 --oneline --decorate，确认新提交显示在 origin/[branch] 上。

步骤 7：报告结果

打印 Expected Output 中所示的报告。报告以状态开头，然后包含：

• 依据： 运行过的检查及其结果（安全扫描、推送退出代码、git log 验证）。
• 不确定项： 未检查的内容。本地不会运行 CI 和远程钩子。用于检查 API 密钥的占位符测试只是模式匹配，并不能证明密钥真实存在。列出用户在步骤 3 中确认的每一项发现，以及用户认定为误报的每一项发现。
• 决定： 推送成功后写“无需审批。”受阻时，说明需要用户采取什么操作。

预期输出

最终报告采用纯文本，并严格使用以下固定格式。如果用户要求其他格式，仍按相同顺序保留四个部分。

成功时：

✅ 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 中的约定格式
• git push 退出代码为 0，且 git log -1 显示新提交位于远程跟踪引用上
• 已打印最终报告，包含提交哈希、分支、文件数量、依据、不确定项和决定

评估运行结果时，还要检查读者是否能根据报告采取行动：

• 结果一目了然： 第一行说明已推送或受阻。
• 事实与假设分开： 依据仅列出实际运行过的检查；不确定项说明未检查的内容。
• 声明有据可查： 每项声明都指向命令结果（推送退出代码、git log 输出或发现对应的文件路径）。安全扫描通过并不意味着推送成功。
• 下一步明确： 决定应写“无需审批。”或说明需要用户采取的操作。

Agent 检查无法确认人类是否理解了报告。如果没有收到人类反馈，应报告人类是否理解尚未确认。

处理边缘情况和错误

有关边缘情况表、各阶段步骤完成报告格式、错误处理指南和替代工作流（选择性暂存、交互式 git add -p、PR 流程），请参阅 references/edge-cases-and-reports.md。每完成一步后，请根据该文件打印步骤完成报告。

如果希望更精细地控制提交内容，也可以改用单独的 git 命令。