sunjunzhao
fc1c5de0a7
Add boundary routing, pre-flight step, per-step acceptance criteria, reasoned hard constraints, red lines, troubleshooting table, and a fixed report structure.
6.9 KiB
6.9 KiB
name, description
| name | description |
|---|---|
| push-and-report | 标准收尾流程：盘点 git 变更 → 英文 conventional commit → 推送远程（兼容 git submodule 多 repo 与单个 git repo）→ 通过 SPMS MCP 上报当日日报。凡用户要求「提交推送并上报日报 / push 并写日报 / 提交代码顺便写日报 / 帮我收个尾 / 下班前提交一下顺便写日报」，务必使用本 skill——即使用户只说「收尾」两个字没提「日报」。Use whenever the user wants to commit, push, and file the daily report in one go. 边界：只提交推送、不写日报时直接走 git，不用本 skill；发版/推镜像用 xgent-image-push 或 xgent-app-release；代码没改完不要用本 skill 提前收尾。 |
提交推送并上报日报
标准收尾流程，一条指令走完：预检 → 变更盘点 → 英文 commit → 推送 → SPMS 日报。
触发方式
- “提交推送并上报日报” / “push 并写日报” / “提交代码并写今日日报”
- “帮我收个尾” / “下班前提交一下”等不带术语的收尾说法
- 任何同时要求「提交推送代码」和「上报日报」的表述
第 0 步：预检（绝不可跳过）
- 确认在 git 仓库内，判断形态：
git submodule status非空即 submodule 多 repo - 探测 SPMS MCP 可用性（试调
spms_get_bootstrap）——不可用现在就知道，不要到 Step 4 才撞见；不可用照走 git 部分，日报标记为"未上报"，并提醒用户配置 SPMS MCP
→ 验收：仓库形态（单 repo / submodule 列表）与 SPMS 可用性都有明确结论，记入最终汇报。
Step 1: 盘点变更
- 主仓：
git status --short、git diff（未暂存 +git diff --cached已暂存） - submodule 形态：逐个
git -C <sub> status --short、git -C <sub> diff - 摘要一律以实际 diff 为准，不凭记忆（约束③）
- ⚠️ 全量提交（
git add -A/git add .）前若发现与本次任务无关的杂项文件（未跟踪文档、临时文件等），先向用户确认是否一并提交，不擅自排除或包含
→ 验收：变更清单逐文件有 git 输出背书；杂项文件的处置已有用户确认结论。
Step 2: 生成英文 commit message
- conventional commits 风格（
feat: .../fix: .../refactor(scope): ...），并参考该仓库git log --oneline的既有习惯 - 多 repo 共用同一条 message 时，message 要能概括全部改动
→ 验收：message 符合 conventional 格式，且与 diff 的实际内容逐条对得上（不是凭印象写的）。
Step 3: 提交并推送
按仓库形态选路径：
A. 仓库自带推送脚本（优先）
若仓库提供一键推送脚本（例如内部已处理 submodule 的 bin/push 之类），直接用它，按其用法传入 message：
./bin/push "<commit message>"
使用前先快速浏览脚本确认行为（pull 策略、add 范围、是否处理 submodule）。
B. submodule 多 repo（无脚本时手工）
- 逐个处理有变更的子模块：
子模块处于 detached HEAD 时停下来报告，不擅自建分支（约束②）。
git -C <sub> pull && git -C <sub> add -A && git -C <sub> commit -m "<msg>" && git -C <sub> push - 主仓同样四步（pull → add -A → commit → push），把子模块指针更新一并提交。
C. 单个 git repo
git pull && git add -A && git commit -m "<msg>" && git push
通用要求
- 先 pull 后 push（约束①）；push 被拒绝时 pull 后重试一次，再失败则停下报告
- 只提交推送，不做 tag、release、force-push 等额外操作（约束⑤）
→ 验收：每个 repo git status 干净，且远端指针与本地一致（git rev-parse HEAD 对比 git rev-parse @{u}）；部分失败如实汇报，不假装完成（约束⑥）。
Step 4: 上报日报（SPMS MCP）
date +%F取当天日期（约束④）。- 确定项目：
spms_get_bootstrap查 projects，按当前仓库/产品名匹配；匹配不到或有歧义时问用户，不猜。 - 调用
spms_submit_report：project：上一步确定的项目名或 idcontent：本次修改摘要，中文列表，逐条说清楚做了什么（改了什么、为什么、结果如何），不铺垫、不评价mode：默认append（同日同产品自动追加）；仅用户明确要求覆盖时用replace
- 日报由服务端按 项目→版本→产品 自动归集，无需手动指定产品。
→ 验收：spms_submit_report 返回成功；失败或未执行（MCP 不可用/用户只要 git 部分）必须在汇报中显式声明"日报未上报"。
硬约束
- ① 先 pull 后 push。为什么：减少 non-fast-forward 被拒；被拒后 pull 重试一次，再失败停下报告，不强行第三次。
- ② detached HEAD 不提交。为什么：detached 上的 commit 不属于任何分支，checkout 一走即成孤儿丢失；停下报告，分支决策是人的事。
- ③ 摘要与 message 以实际 diff 为准。为什么：凭记忆写会幻觉——把没改的写进去、把改了的漏掉；diff 是唯一事实源。
- ④ 日期现取
date +%F。为什么：会话里的时间可能是旧会话的，日报会归错天。 - ⑤ 只做 commit + push。为什么：tag/release/force-push 不可逆或超出"收尾"授权范围；用户没要求的一律不做。
- ⑥ 不假装完成。为什么：部分推送失败、日报未上报却报"完成"，比不做更有害——用户会基于假信息下班。
红线（任何情况下不违反）
- 不凭记忆写变更摘要和 commit message
- 不擅自提交与用户任务无关的杂项文件，也不擅自排除
- 不在 detached HEAD 上提交
- 日报没报成就说没报成，不静默、不伪造
- 不替用户决定
replace模式覆盖日报
排障对照表
| 症状 | 原因 | 怎么办 |
|---|---|---|
| push 被拒 non-fast-forward | 远程有新提交 | pull 后重试一次；再失败停下报告，不 force-push |
| 子模块 detached HEAD | submodule 检出的是提交指针不是分支 | 停下报告，不擅自建分支 |
spms_get_bootstrap 工具不存在/报错 |
SPMS MCP 未配置 | 走完 git 部分，汇报声明日报未上报，提醒用户配 MCP |
| 项目匹配不到或多个同名 | 仓库名与 SPMS 项目名对不上 | 摊开候选问用户，不猜 |
| 提交后才发现混入杂项文件 | Step 1 的确认闸被跳过 | 如实汇报混入内容；是否 revert 由用户定，不擅自操作 |
汇报结构（固定）
- 仓库形态：单 repo / submodule（N 个有变更，列出）
- commit：每个 repo 的 hash + message
- 推送：逐 repo 结果；被拒重试过的要注明
- 日报：项目、日期、mode（append/replace）、成功或未上报
- 被跳过/没做成的：如杂项文件未提交、某子模块未推送
- 验证做到哪一步：远端指针对比结果；没做就说没做