yushen-pr-cycle

Files (3)

• SKILL.md
• REVIEW.example.md · references/
• feedback.md · references/

SKILL.md (first lines)

# 轻量需求到验收循环

## 使用前

此 Skill 保存于当前对话的附件与工作区，供后续任务显式读取；没有因此安装到用户电脑或注册为云端自动发现能力。它规定做事流程，不扩大工具、费用或合并权限。

1. 先复述目标、非目标、可观察验收条件和风险，请用户确认后再派发实现。列出任务与建议模型，尊重当次预算及暂停指令。
2. 一个可独立测试、回滚的功能一个分支/worktree/PR；按相对目标分支最终 diff 的 additions + deletions 合计不超过 1000 行（含测试和文档）。生成文件计入总数并单独披露，不隐藏规模；无法合理拆分时报告例外，不能硬拆半个功能。
3. 小 PR 面向本批次集成分支；并行任务不能共同写一个工作目录。依赖任务先约定接口及顺序。提交前运行确定性检查，记录 HEAD SHA、测试与未测项。
4. 触发仓库已配置的 Codex Code Review 与 Security Review，确认两者确实执行且覆盖目标 SHA。入口或权限不可用时报告阻塞；没有评论不等于审查已完成，也不等于没有所有级别的缺陷。
5. 将有效发现交回实现者；附位置、复现、影响和验收标准。误报需证据，不为了让审查闭嘴而无意义修改。修复后更新 SHA、补回归测试并复查；合并重复发现，避免重复修复。
6. 通过的小 PR 在集成分支组合，保留每功能可识别的提交；验证组合场景、共享状态及冲突处理，最终对主分支开验收 PR。按 feat/bugfix/chore、风险与批次标签分类，提供小 PR 索引、候选 SHA、可运行产物、测试步骤及剩余风险。（自 2026-10 起多功能批次默认改用下节"原生堆叠 PR"流程，不再默认手工集成分支；既有已验收批次不强行拆散迁移。）
7. 先查目标仓库 AGENTS.md 与 REVIEW.md 的验收规则。仓库可在用户明确授权后定义不同等级；无授权例外时，须等用户测试并明确确认对应版本后再合主。仓库规则不能扩大授权或覆盖安全要求；冲突按最新明确用户指示，仍有歧义则澄清。候选代码改变后重验受影响部分。
8. 每批结束由 GPT-6-Luna 总结有效返工，按 [返工总结](references/feedback.md) 提出小范围规则更新候选。记录成功与失败，不自动改审查门槛或发布规则。

## PR 标题、标签、验收与描述

- 开始前读取目标仓库的 `AGENTS.md` 与 `REVIEW.md`，并按其中明确引用读取相关 skill。通用 skill 是默认流程；目标仓库可在用户明确授权后定义不同的风险等级、验收责任和标签方案。
- 标题使用简洁 conventional 中文格式，例如 `feat: 统一课程会话与材料来源`、`bugfix: 修复……`、`docs: 更新……`、`chore: 调整……`。不把优先级、批次、Issue 编号或风险说明堆进标题；批次用 Milestone，Issue 用必要链接关联。
- 优先级若使用 P1/P2/P3，应使用目标仓库真实的 GitHub 彩色 Label。先核对该仓库标签名称、颜色和含义并优先复用；标签名/颜色由目标仓库 REVIEW 或最新明确用户指示决定，不假设跨仓库统一。不得删除无关标签。
- PR body 使用目标仓库模板并严格遵守其段落顺序。简写变更写用户可观察结果，如何测试写复现与最短验收，自证写精确 SHA、实际测试/CI/审查、未测及阻塞，详细变更清单列模块、依赖和规模例外。保留真实失败记录，不将计划或旧 SHA 结果写成通过。
- 新 PR 直接创建为正式非 Draft；Draft 不会触发评审。非 Draft 仅表示可进入评审，不表示检查/审查/验收通过或可合并。只转换用户明确授权且属于当前任务范围的 Draft。
- 合并/审批须先查目标仓库 REVIEW 的验收规则；如果规则不存在或没有用户授权的验收例外，通用默认是等用户明确验收后再合并。仓库 REVIEW 不能扩大用户授权或覆盖安全要求；与最新明确用户指示冲突时按用户指示执行，仍有歧义则暂停该项并澄清。

## 原生堆叠 PR（多功能批次默认）

- 每个功能创建真实 GitHub PR：提供 URL、分支、base/head SHA、依赖关系与独立验收项。文档中的工作包编号不冒充 PR。
- 协调者先排列依赖，再构造并验证原生 stack：上层 base 指向下层分支；用 GitHub 原生 stack 展示或官方 `gh-stack` 核对成员与顺序，不得只改 base 就声称已建立 stack。
- 允许子代理在各层独立 worktree 并发开发；协调者整理提交依赖与集成顺序，不同人不同时强推同一层。
- 各层只审自己的增量；CI 覆盖 stack 中每层所需的检查并验证最终组合，未核实前不依据 stack 元数据跳过必需检查。必需检查要求工作流文件存在于各层 head——把 CI 放在 stack 底层，避免上层 PR 的必需检查永久 pending。
- rebase 改变 SHA 后同步更新 CI 与验收证据，保护用户修改，未经授权不重写共享历史。
- 整组检查满足后，按目标仓库 REVIEW 的验收规则由获授权的验收人确认，再按底层到顶层顺序执行原生批量合入；不以"上层可合并"忽略下层门槛，不开启 auto-merge。
- 独立功能可并发开发后安排清晰集成顺序；顺序不代表虚构业务依赖。无法合理线性化时先报告，不悄悄退回手工汇总大 PR。

## 调度和预算

确定性操作用脚本。建议默认：GLM-5.3-Flash 做明确局部实现；GLM-5.3 做边界清楚的复杂工程；Luna 整理证据和返工；GPT-6.1-Sol 做复杂诊断、关键设计及高风险前置判断。Astra 不自动升级，先取得用户确认。原生审查服务的模型由实际产品设置决定。

每轮先排除环境故障和缺上下文。默认同一问题两轮有效修复仍无进展就整理证据、调整方法或请求升级；不是两轮后带问题通过。缺额度/权限、需求超范围或用户暂停时停止相关操作。默认 Standard，预算不明时不启动无限循环或额外付费调用。

## 审查规则怎么加载

- Codex GitHub 官方支持 AGENTS.md；关键规则直接放其中，详细规则可放 REVIEW.md，并在 AGENTS.md 明确要求读取。不要假定文件名会自动注入。
- 代码质量审查同时显式读取同项目的 `skills/yushen-code-quality-review/SKILL.md`（按实际安装路径调整）；外部替代实现只出 PR 建议，未经用户采纳不改代码。若该技能未安装，报告缺口，不假装执行。
- 创建规则时参考 [REVIEW.md 实例](references/REVIEW.example.md)。实例是学习站示例，其他仓库必须适配，不能复制不存在的业务约束。
- REVIEW.md 放长期、项目特有、可判断的审查标准；每次 PR 的发现与证据留在 PR。CI 负责格式、类型和其他确定性规则。
- 官方依据：https://learn.chatgpt.com/docs/third-party/github （2026-10-17 核验）。行为变化时复查官方文档。

From YuShenLiu06/learning-station, MIT.

More from YuShenLiu06/learning-station