refactor(push-and-report): pass skill-forge quality gate
Add boundary routing, pre-flight step, per-step acceptance criteria, reasoned hard constraints, red lines, troubleshooting table, and a fixed report structure.
This commit is contained in:
sunjunzhao committed
1 parent
41fe8bace2
commit
fc1c5de0a7
1 file changed
+58
-12
@@ -1,29 +1,41 @@
|
||||
---
|
||||
name: push-and-report
|
||||
description: 标准收尾流程：盘点 git 变更 → 英文 conventional commit → 推送远程（兼容 git submodule 多 repo 与单个 git repo）→ 通过 SPMS MCP 上报当日日报。当用户要求“提交推送并上报日报 / push 并写日报 / 提交代码顺便写日报”等收尾推送+日报场景时使用。
|
||||
description: 标准收尾流程：盘点 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 日报。
|
||||
标准收尾流程，一条指令走完：预检 → 变更盘点 → 英文 commit → 推送 → SPMS 日报。
|
||||
|
||||
## 触发方式
|
||||
|
||||
- “提交推送并上报日报” / “push 并写日报” / “提交代码并写今日日报”
|
||||
- “帮我收个尾” / “下班前提交一下”等不带术语的收尾说法
|
||||
- 任何同时要求「提交推送代码」和「上报日报」的表述
|
||||
|
||||
## 第 0 步：预检（绝不可跳过）
|
||||
|
||||
1. 确认在 git 仓库内，判断形态：`git submodule status` 非空即 submodule 多 repo
|
||||
2. 探测 SPMS MCP 可用性（试调 `spms_get_bootstrap`）——不可用**现在就知道**，不要到 Step 4 才撞见；不可用照走 git 部分，日报标记为"未上报"，并提醒用户配置 SPMS MCP
|
||||
|
||||
→ 验收：仓库形态（单 repo / submodule 列表）与 SPMS 可用性都有明确结论，记入最终汇报。
|
||||
|
||||
## Step 1: 盘点变更
|
||||
|
||||
- 主仓：`git status --short`、`git diff`（未暂存 + `git diff --cached` 已暂存）
|
||||
- 判断仓库形态：`git submodule status` 非空即 submodule 多 repo，逐个 `git -C <sub> status --short`、`git -C <sub> diff`
|
||||
- 摘要一律以实际 diff 为准，不凭记忆
|
||||
- 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: 提交并推送
|
||||
|
||||
按仓库形态选路径：
|
||||
@@ -44,7 +56,7 @@ description: 标准收尾流程：盘点 git 变更 → 英文 conventional comm
|
||||
```bash
|
||||
git -C <sub> pull && git -C <sub> add -A && git -C <sub> commit -m "<msg>" && git -C <sub> push
|
||||
```
|
||||
子模块处于 detached HEAD 时停下来报告，不擅自建分支。
|
||||
子模块处于 detached HEAD 时停下来报告，不擅自建分支（约束②）。
|
||||
2. 主仓同样四步（pull → add -A → commit → push），把子模块指针更新一并提交。
|
||||
|
||||
### C. 单个 git repo
|
||||
@@ -55,13 +67,14 @@ git pull && git add -A && git commit -m "<msg>" && git push
|
||||
|
||||
### 通用要求
|
||||
|
||||
- 先 pull 后 push，减少 non-fast-forward；push 被拒绝时 pull 后重试一次，再失败则停下报告
|
||||
- 每个 repo 的推送结果都要确认成功；部分失败如实汇报，不假装完成
|
||||
- 只提交推送，不做 tag、release、force-push 等额外操作
|
||||
- 先 pull 后 push（约束①）；push 被拒绝时 pull 后重试一次，再失败则停下报告
|
||||
- 只提交推送，不做 tag、release、force-push 等额外操作（约束⑤）
|
||||
|
||||
→ 验收：每个 repo `git status` 干净，且远端指针与本地一致（`git rev-parse HEAD` 对比 `git rev-parse @{u}`）；部分失败如实汇报，不假装完成（约束⑥）。
|
||||
|
||||
## Step 4: 上报日报（SPMS MCP）
|
||||
|
||||
1. `date +%F` 取当天日期（不用会话里的旧时间）。
|
||||
1. `date +%F` 取当天日期（约束④）。
|
||||
2. 确定项目：`spms_get_bootstrap` 查 projects，按当前仓库/产品名匹配；匹配不到或有歧义时问用户，不猜。
|
||||
3. 调用 `spms_submit_report`：
|
||||
- `project`：上一步确定的项目名或 id
|
||||
@@ -69,7 +82,40 @@ git pull && git add -A && git commit -m "<msg>" && git push
|
||||
- `mode`：默认 `append`（同日同产品自动追加）；仅用户明确要求覆盖时用 `replace`
|
||||
4. 日报由服务端按 项目→版本→产品 自动归集，无需手动指定产品。
|
||||
|
||||
## 约定
|
||||
→ 验收：`spms_submit_report` 返回成功；失败或未执行（MCP 不可用/用户只要 git 部分）必须在汇报中显式声明"日报未上报"。
|
||||
|
||||
- commit message 用英文；日报内容用中文
|
||||
- SPMS 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）、成功或未上报
|
||||
- 被跳过/没做成的：如杂项文件未提交、某子模块未推送
|
||||
- 验证做到哪一步：远端指针对比结果；**没做就说没做**
|
||||
Reference in new issue
Block a user