asco-review

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 下这次本地改动，重点看生命周期、取消和资源释放。