| name | asco-review |
| description | 为 ASCO 仓库做代码审查。用于三种模式：全量 review、排除当前未提交修改的全量 review、review 当前未提交修改（包含未追踪文件）。如果用户没有明确指出模式，则默认 review 当前未提交修改。重点输出 bug、风险、行为回归和缺失测试。 |
| argument-hint | 说明 review 模式、关注范围，以及是否需要重点看 asco/core、并发、取消、生命周期或资源释放路径 |
审查 ASCO 代码
何时使用
- 用户要求 review 代码、审查改动、检查风险或找行为回归。
- 需要只审查当前未提交修改。
- 需要审查整个仓库当前工作区状态。
- 需要审查整个仓库，但排除当前未提交修改的干扰。
三种模式
1. 全量 review
- 审查当前工作区可见的整体代码状态。
- 默认包含当前工作区中已经存在的未提交修改。
- 适合用户要求“整体看看这个仓库/模块现在有什么问题”。
2. 排除当前未提交修改的全量 review
- 审查仓库的已提交内容，忽略当前工作区里的未提交修改。
- 适合用户想看基线代码质量，不希望本地脏工作树干扰判断。
- 若工作区有未提交改动，审查时必须明确忽略这些改动，而不是混在一起评估。
3. review 当前未提交修改
- 只审查当前未提交修改。
- 包含已跟踪文件中的 staged/unstaged 修改，也包含未追踪文件。
- 这是默认模式：如果用户没有明确指出模式，就按此模式执行。
目标产出
- 以发现为主的审查结论，优先报告 bug、风险、行为回归和缺失测试。
- 对每条发现给出严重性、影响范围和定位依据。
- 明确说明本次 review 使用的是哪一种模式。
- 对
asco/core、并发、取消、生命周期、资源释放路径相关改动，额外强调需要用户自行核对语义与失败路径。
输入信息
开始前先确认这些信息；若缺失且会影响审查边界，先向用户确认：
- 本次是三种模式中的哪一种。
- 如果用户没有说明模式，默认采用“review 当前未提交修改”。
- 是否有重点关注目录或文件。
- 是否要特别关注并发、取消、生命周期、资源释放、测试覆盖或文档一致性。
决策规则
1. 先确定模式
- 用户明确说“review 当前改动”“看未提交修改”“帮我看这次本地改动”时，使用模式 3。
- 用户明确说“全量 review”时，使用模式 1。
- 用户明确说“忽略当前未提交修改”“看基线代码”“不要把我本地改动算进去”时，使用模式 2。
- 用户没有明确指出模式时，默认使用模式 3。
2. review 以发现为主，不默认改代码
- review 的默认目标是找问题，不是直接修代码。
- 除非用户明确要求顺手修复，否则不要在 review 过程中直接改文件。
3. 输出顺序固定
- 先列 findings，按严重性排序。
- 再补充开放问题、假设或证据不足之处。
- 最后才给简短总结或剩余风险。
执行流程
1. 收集审查边界
根据模式决定要看的对象：
- 模式 1：读取当前工作区中的整体代码与相关文档、测试。
- 模式 2：以已提交内容为准，忽略当前未提交修改。
- 模式 3：先收集当前未提交修改与未追踪文件，再围绕这些改动读取上下文。
如果模式 3 涉及新增文件，必须把未追踪文件也纳入审查范围。
2. 建立语义上下文
在下结论前，至少补齐这些上下文：
- 被审查代码属于公开 API、普通实现，还是
asco/core 运行时语义路径。
- 关联的测试、文档、示例是否同步。
- 改动是否触及调度、取消、生命周期、并发、资源释放或 guard 跨
co_await 等高风险点。
3. 重点检查项
优先检查：
- 行为是否可能回归。
- 是否引入明显 bug、未定义行为、悬垂引用、竞态或死锁风险。
- 是否遗漏失败路径、边界条件或资源释放。
- 是否缺少必要测试或测试接入。
- 文档或注释是否与行为语义不一致。
对本仓库尤其要重点看：
- 引用是否被传入协程入口或 awaitable，并在挂起后变悬垂或读取到意外值。
- guard 是否跨越
co_await 存活。
- 新增测试文件是否同步更新
tests/CMakeLists.txt。
- 新增中文文档页面是否同步更新
docs/zh-cn/src/SUMMARY.md 与对应章节 README.md。
4. 形成 findings
每条 finding 应尽量包含：
- 严重性。
- 问题是什么。
- 为什么会出错，或为什么存在行为风险。
- 受影响的文件或路径。
- 如有必要，指出缺失的测试或验证。
如果没有发现问题，也要明确写出“未发现明确问题”，并补充剩余风险或证据不足之处。
5. 针对 asco/core 的额外要求
如果审查对象涉及 asco/core 或其他运行时语义路径，额外检查：
- 不变量是否被破坏。
- 状态迁移是否自洽。
- 失败路径是否能正确收束。
- 资源是否在正确位置释放。
- 并发与取消条件下是否存在竞态、双重释放、悬垂引用或长期持锁。
并且必须提醒用户：不要盲目相信审查结论，尤其需要自行核对语义、边界条件和失败路径。
完成标准
满足以下条件才算完成：
- 已明确说明本次使用的 review 模式。
- findings 是回答主体，而不是总结或改进建议。
- findings 按严重性排序，并优先覆盖 bug、风险、行为回归和缺失测试。
- 默认模式在用户未说明时为“review 当前未提交修改”，并包含未追踪文件。
- 若涉及
asco/core 或其他运行时语义路径，已额外提醒用户自行核对关键语义与失败路径。
常见分支
用户只说“帮我 review 一下”
- 默认按模式 3：review 当前未提交修改。
- 必须把未追踪文件一并纳入范围。
用户说“全量 review，但不要看我本地改动”
- 使用模式 2。
- 明确告诉用户本次结论基于已提交内容，而不是当前工作区修改。
用户说“看整个仓库现在有没有明显问题”
- 使用模式 1。
- 说明这会包含当前工作区可见状态中的本地修改。
用户要求 review asco/core
- 按更高风险标准审查。
- 必须更强调不变量、失败路径、资源释放和并发/取消风险。
推荐提示词
- review 当前未提交修改，包含未追踪文件。
- 全量 review 当前仓库。
- 全量 review，但排除我当前未提交的修改。
- review
asco/core/task 下这次本地改动，重点看生命周期、取消和资源释放。
