메뉴
Agent 与 Agent 之间互相提交、修复、复测 GitHub issue 的自动巡检协议。当一个 agent 用另一个 agent 的产物（cdscli、prd-api、共享 skill 等）发现 bug、阻塞、能力缺口时，用本技能产出标准 issue / tracker / PR 收尾清单 / 复测报告，避免 agent 之间反复确认"修没修、修对没修、复测了没"。触发词："巡检"、"自动巡检"、"反馈给对方 agent"、"复测修复"、"agent 间提 issue"、"/audit"、"/auto-fix-issues"。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | auto-fix-issues |
| description | Agent 与 Agent 之间互相提交、修复、复测 GitHub issue 的自动巡检协议。当一个 agent 用另一个 agent 的产物（cdscli、prd-api、共享 skill 等）发现 bug、阻塞、能力缺口时，用本技能产出标准 issue / tracker / PR 收尾清单 / 复测报告，避免 agent 之间反复确认"修没修、修对没修、复测了没"。触发词："巡检"、"自动巡检"、"反馈给对方 agent"、"复测修复"、"agent 间提 issue"、"/audit"、"/auto-fix-issues"。 |
版本：v1.0.0 | 状态：已落地 | 触发：
/audit、/auto-fix-issues、"巡检"、"反馈给对方 agent"、"复测修复"
给 agent 用的「我用了你的产物发现 bug，怎么以最低 friction 让你修，修完我怎么复测」协议。 不是给最终用户的 UAT，不是自检代码 review，是 agent → agent 的契约。
满足任一条件即触发本技能：
不触发：
/verify/uat/handoff| 角色 | 时机 | 产出 |
|---|---|---|
| 反馈方 | 发现 bug | Issue（带复现+期望+验收）+ 视情况加入 tracker |
| 修复方 | 接到 issue | PR（含 Fixes #N 关键字）+ 收尾清单（改 label + 评论复测命令） |
| 复测方 | 修复 PR 合并后 | PASS 报告 / FAIL 报告（FAIL 必须重开 issue + 附版本号 + 复现日志） |
同一个 agent 在不同 session 可以扮演不同角色，本技能保证三者输出格式一致、能机读。
仓库级统一标签，新仓库初次使用本技能时若不存在自动创建（GitHub MCP issue_write 带 labels 会自动创建）：
| 标签 | 含义 | 谁加 |
|---|---|---|
待解决 | 已收到反馈，未开始修 / 修复中 | 反馈方提交 issue 时 |
已解决待验收 | 修复 PR 已合并，等复测确认 | 修复方合并 PR 当时立即改 |
已验收 | 复测 PASS，可以彻底关 | 复测方 PASS 后改（同时 close issue） |
硬规则：
待解决 改成 已解决待验收。Fixes #N 关键字会 close issue，但不会改 label —— 这是 session 实战的真实坑（2026-05-09 用户当场指出）。待解决 然后什么都不做 —— 必须重开 issue 或 新开 follow-up issue，附：cdscli --version / 复测包时间戳 / 完整复现命令 / 实际输出 vs 期望。## 背景
- Skill / CLI 名 + 版本号：`cdscli 0.4.0`
- 复测包时间戳（如适用）：`cds-skills-2026-05-09T09-51-51`
- 相关 PR / commit：#543 / commit `abc123`
- 我现在的目标：把 X 项目部署到 CDS
## 复现步骤
```bash
# 1. 干净副本（避免缓存影响）
rsync ...
# 2. 触发命令
python3 cdscli.py scan ./tmp --output out.yml
{ "ok": true, "modules": [/* 只有前端 */] }
services:
imp-api: # 后端应被识别
...
imp-api 服务-pl imp-api -am真实 Java monorepo 只生成前端 compose，后端根本不会部署。
待解决
## 4. Tracker Issue 模板（聚合多条相关反馈）
适用：同一 skill / 同一模块的多条 issue，用一个 tracker 给修复方看全貌。本仓库 `#552` 是模板范例。
```markdown
## 目标
[一句话说明 tracker 范围]
## 阻塞清单
| ID | 优先级 | 问题 | 状态 | 证据/链接 | 期待修复 |
|----|--------|------|------|-----------|----------|
| CDS-CLI-001 | P0 | Maven parent pom 不递归 | OPEN | #544 | 解析 modules + 递归 |
| CDS-CLI-002 | P0 | 嵌套 compose 漏识别 | FIXED | PR #556 | partial signal 已加 |
## 已复测通过
| 项 | 状态 | 证据 |
|----|------|------|
| Vite port 读取 | PASS | 三个前端端口正确 |
## 当前停滞点
[如果 tracker 上整体不能 PASS，说明卡在哪里]
## "彻底解决" 定义
[列出全部通过条件，让修复方有明确目标]
修复每个子项后，状态列从 OPEN 改为 FIXED 或 VERIFIED，并贴 PR 链接。
合并 PR 之后，按本清单执行（不允许跳步）：
- [ ] 1. 确认 PR description 含 `Fixes #N1, fixes #N2` 关键字（GitHub 自动 close issue）
- [ ] 2. 用 GitHub MCP issue_write method=update labels=["已解决待验收"] 改每个对应 issue 的 label
（Fixes 关键字不会改 label，这是踩过的坑）
- [ ] 3. 在每个对应 issue 评论里贴：
- 复测命令（具体 bash，可 copy-paste 跑）
- 验证点（应该看到的关键输出 / 状态变化）
- 失败时怎么办（重开 issue + 附 X / Y / Z）
- [ ] 4. 如果有 tracker（如 #552），更新 tracker 的状态列
- [ ] 5. 给反馈方 / 复测方 agent 一行话总结：版本号 + PR + 复测命令
硬规则：步骤 2 / 3 不做就视为 PR 没合并完。reviewer 看到没做就要求补，否则反馈方下一轮 session 会再捡到 待解决 标签的"幽灵 issue"。
## 复测 PASS — issue #544
- 拉取版本：`cdscli 0.5.0` / 包时间戳 `cds-skills-2026-05-09T11-30-00`
- 复测命令（按 issue 第 5 节验收标准逐条）：
```bash
python3 cdscli.py scan ./mdimp --output /tmp/out.yml
grep "imp-api:" /tmp/out.yml # 命中
grep "spring-boot:run -pl imp-api" /tmp/out.yml # 命中
grep "./imp-platform:/app" /tmp/out.yml # 命中
全部 PASS。请改 label 已验收 并关闭。
### FAIL 报告
```markdown
## 复测 FAIL — issue #544 第 N 次复测
- 拉取版本：`cdscli 0.5.0` / 包时间戳 `cds-skills-...`
- 期望：scan 包含 imp-api
- 实际：仍只识别 3 个前端
```bash
$ python3 cdscli.py scan ./mdimp
{...只有 imp-admin / imp-supplier / imp-scan-web...}
[反馈方的初步判断，给修复方 agent 一个起点]
待解决，链接本复测
## 7. Agent 间契约
互相不甩锅、不漏单的硬约束：
**反馈方义务**：
- 必须给可复现命令（不是"反正就是不行"）
- 必须给期望行为（明确"应该是什么"）
- 必须给可勾选的验收标准（不是模糊"能用就行"）
- 必须脱敏（不上 secret）
**修复方义务**：
- PR description 用 `Fixes #N` 关键字关 issue
- 合并后立刻改 label（参见第 5 节）
- 提供具体复测命令（不只是"已修复，请验证"）
- 已知 debt 写到 `doc/debt.{module}.md`，不是只写在 commit message
**复测方义务**：
- 必须用最新版本 / 包（带时间戳证据）
- 失败必须有具体 evidence，不是"还是不行"
- 不能因为复测失败就放弃推进；要拆出"新发现的子问题"另开 issue
任何一方不履行，对方有权 **退回重提**（issue 评论说明缺哪一项）而不是默默吞下。
## 8. 自动化（v2，MVP 不做）
未来可加：
- GitHub Actions：PR 含 `Fixes #N` 时合并后自动改 label 为 `已解决待验收`（消除手动遗漏）
- 复测 webhook：收到「复测 PASS」格式评论时自动改 `已验收` + close
- Cross-repo bridge：跨仓库（如 cds skill 和主仓库）反馈链路
MVP 阶段全靠人 / agent 手动按本 SKILL 执行。
## 9. 上下游技能
| 上游 | 关系 |
|------|------|
| `/scope-check` | 提交前看自己改了什么，不要越界 |
| `/verify` | 自检代码 |
| 用户 | 派单的人 |
| 下游 | 关系 |
|------|------|
| `/handoff` | 完成后给用户的交付报告 |
| `/uat` | 真人按表打勾 |
| `/cds-deploy` | 修复后部署到灰度环境复测 |
| `/preview` | 复测前生成预览地址 |
## 10. 真实案例（Reference）
- **#544 / #550**（Maven 多模块）：反馈方用本协议提了两个 issue（含明确复现 + 验收）→ 修复方在 PR #556 一并修 → 合并后改 label 为 `已解决待验收` → 等复测
- **#552**（部署体验 tracker）：反馈方聚合 9 个子项到一个 tracker → 修复方按子项 ID（CDS-CLI-001 ... 009）逐项推进 → tracker 状态列实时更新
- **本 session 反面案例**：合并 #556/#557/#558 后忘了改 label，用户当场指出"为什么还是 `待解决`" —— 这是促使本技能诞生的直接动机，第 5 节硬规则就是为了堵这个坑
## 11. 不在本技能范围
- 给最终用户的功能验收 → `/uat`
- 任务交付报告 → `/handoff`
- 代码越界检查 → `/scope-check`
- 多 agent 任务编排 → 用主 agent 的 Agent tool
本技能只管"agent A 提 bug → agent B 修 → agent A 复测"这一条链路。
识别每日验收、PR 验收、commit 验收、未发布分支验收、缺陷复测、视觉回归和发布前验收等场景，并为 create-visual-test-to-kb 生成测试范围、指差法步骤、预期结果、证据链、截图回读和报告结构。Use when the user asks to optimize or run visual acceptance across different scenarios, asks whether yesterday's changes, a PR, a commit range, or an unpublished branch were really accepted, or needs PR/commit results to map to screenshots and MAP knowledge base reports.
Convert PRs, commits, yesterday's changes, or release scope into a test-minded acceptance design before visual execution. Use when the user asks for daily acceptance, visual acceptance, PR/commit acceptance, proof that code changes really affected product behavior, coverage planning, fusion testing, evidence strength, or when screenshots/reports looked related but failed to prove the assigned task.
工业级功能验收/视觉测试全流水线（MAP 验收标准 v2）——模拟人类的浏览器取证 + 标准化验收报告 + 归档进 CDS 验收中心并出直达深链。职责分离：验收报告永远按项目归 CDS（平台自带、证据链内置），MAP 等系统通过知识库开放协议从 CDS 拉取展示，技能不再分流到 MAP 知识库。一个技能内含三段：标准/模板、模拟人类浏览器取证（点击导航进入、禁地址栏直达、双主题截图、ZZ 照做风画框标序号 stepClick/stepShot）、报告归档（命名结构固定，**每次归档强制输出可达地址**：CDS 直达深链 /reports，匿名对外用 /r/token）。默认报告走 **ZZ 照做风**（全大标题 + 一句话一步 + 逐步配图 `{{IMG:}}` + 文字在上图在下 + 变化处画框 + 分支顺序讲，同岗位照做必复现）。归档前有**强制准入校验**：目标/档位/Verdict/截图数/证据完整性/报告结构不达标直接拒收（入口准则，杜绝"什么都能进"）。项目无关，改 acceptance.config.json 即可跨仓库复用；无 CDS/离线退化为本地 md+截图。触发词："视觉验收"、"验收"、"视觉测试"、"验收归档"、"归档验收报告"、"create visual test"、"/视觉验收"、"/验收"。
CDS (Cloud Dev Space) core skill — hosts the canonical cdscli Python CLI, handles authentication (static AI_ACCESS_KEY / dynamic pairing / project key), manages env vars and project keys, owns CDS service self-update, defines the preview-URL slug formula, and acts as dispatcher when the user's intent is ambiguous between cold-path scanning and hot-path debugging. Activates when the user mentions CDS generically without specifying scan-or-deploy, configures CDS credentials, manages env / keys, updates the CDS service code itself, or asks about preview URL conventions. Does NOT directly perform project scanning (delegates to cds-project-scan, the cold path) or deployment debugging (delegates to cds-deploy-pipeline, the hot path). Trigger phrases include "cds 认证", "AI_ACCESS_KEY", "项目 key", "cds 自更新", "cds self-update", "预览地址公式", "配 cds 环境变量", "/cds", "/cds-auth", and the bare word "cds" when the user has not yet picked a direction.
Generates weekly project reports from git history. Collects commits, PRs, and contributor data, analyzes and categorizes changes, then produces a structured Chinese-language weekly report (overview, completed items, next-week priorities) saved to doc/report.YYYY-WXX.md. Trigger words: "生成周报", "写周报", "weekly report", "本周总结".
从 git 历史生成「今日大事早知道」开发日报，并发布到知识库（文档空间）。按「新增功能多讲 → 优化/修复次之 → 计划/遗留垫底」的固定权重分层叙事。自动 find-or-create「日报知识库」并出分享链。触发词："生成日报"、"写日报"、"今日大事"、"日报"、"daily report"、"/daily"、"今天干了啥"。