Skip to main content

easy-codex-review

当用户要求审查计划、本地改动、执行计划后的代码最终审查、拉取请求风格审查、回归风险检查或验证缺口分析时使用。

소스 정보

저장소
dualface/easy-codex
최근 소스 활동
2026년 6월 1일 12:24
감지된 SKILL.md 언어
중국어
스타
4
포크
0

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

파일 탐색기
2 개 파일

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
easy-codex-review
description
当用户要求审查计划、本地改动、执行计划后的代码最终审查、拉取请求风格审查、回归风险检查或验证缺口分析时使用。
# Easy Codex 审查 审查计划或已实现改动。代码最终审查写审查产物,不改代码。 ## 用户选择 - “选择功能”指:可点击选择可用时必须用控件;工具不可用时用文本降级,给每个选项编号,列 2-3 个互斥选项,推荐项第一,要求用户回复编号数字、完整选项名或 `其他: <自定义>`;开放答案用“其他”,并允许用户直接输入自定义内容;禁止要求用户输入关键词或技能名。 ## 强制门禁 - Easy Codex 流程内审查必须在规格/计划字段 `绝对 worktree 路径` 内进行;字段缺失、相对路径、未通过 `<主项目根>/<显示路径>` realpath 校验、或指向 main worktree 时阻塞。 - `基准` 缺失、`git rev-parse --verify <基准>^{commit}` 失败、或不是 HEAD 祖先时阻塞,回 `$easy-codex-writing-plans` 补齐。 - 独立只读 review 可在当前 worktree 进行,但禁止任何写入。 - 审查阶段禁止改源文件、测试、配置或规格。 - 计划审查只能更新被审计划的 `流程状态` 和 `对抗性审核` / `用户处理决定` 字段;不改阶段内容、范围、文件结构、验证命令或实现步骤。 - 代码最终审查必须写 `docs/reviews/YYYY-MM-DD-<slug>.md`,记录基准、HEAD、结论、接受风险和用户选择。 - 修复问题必须先经选择功能批准,再回 `$easy-codex-writing-plans`、`$easy-codex-executing-plans` 或对应流程。 ## 工作流 1. Easy Codex 流程内读取字段 `绝对 worktree 路径`、`主项目根`、`显示路径` 和 `基准`;先用 `realpath` 与 `git worktree list --porcelain` 验证后切入;独立只读 review 用当前目录。 2. 代码最终审查读取提交范围:`git log <基准>..HEAD`、`git diff --stat <基准>..HEAD`、`git diff <基准>..HEAD`;`git diff HEAD`、`git diff --cached`、`git ls-files --others --exclude-standard` 只用于检查未提交/未跟踪遗漏。 3. 若有相关 `docs/specs/` 或 `docs/plans/`,先读作审查基准。 4. 若用户要求审查计划,执行“计划审查”;只有提交范围、未提交 diff、暂存 diff、未跟踪文件都为空,才视为没有实现 diff。 5. 否则阅读提交范围 diff、附近代码、测试和运行时契约,执行“代码审查”。 6. 只报告可执行问题; findings 优先,摘要靠后。 7. 若有问题,按审查模式用选择功能请求下一步。 8. 若无问题,按审查模式写审查产物并用选择功能请求下一步。 ## 计划审查 - 对照已批准规格,检查计划是否覆盖目标、验收标准和非目标。 - 检查阶段顺序、依赖、文件路径、命令、预期失败测试、验证和回滚是否可执行。 - 计划审查优先判断计划能否执行并让规格落地;不要把计划审成完整实现设计。 - 标出范围漂移、缺失测试、含糊步骤、跨阶段冲突和高风险迁移点;只有会阻止执行、无法验收、违反门禁,或存在具体不可逆风险且无处理边界的问题才要求回到计划。 - 轻微范围漂移、可自然补齐的技术细节、测试补强建议、后续代码审查可兜底的问题,只记录为非阻塞建议。 - 未发现明确阻塞问题时,计划审查必须通过;非阻塞建议不得阻止进入实现。 - 有明确阻塞问题时提供:回到实现计划、接受风险、停止。计划审查的“接受风险”必须先写入计划的 `对抗性审核` / `用户处理决定`,并把 `计划批准记录`、`审核状态`、`下一阶段许可` 更新为允许执行;只允许进入 `$easy-codex-executing-plans`,不允许进入 `$easy-codex-ship`。 - 无明确阻塞时先把通过结论写入计划的 `对抗性审核`,并把 `计划批准记录`、`审核状态`、`下一阶段许可` 更新为允许执行,再提供:开始实现、停止。 ## 代码审查 - 对照规格和计划检查 `<基准>..HEAD` 范围内的阶段提交和最终 diff。 - 检查整体集成:跨阶段冲突、契约不一致、计划外改动、回归风险、验证缺口。 - 写 `docs/reviews/YYYY-MM-DD-<slug>.md`,包含 `基准`、`HEAD`、结论、接受风险、用户选择、验证缺口。 - 代码最终审查无论通过、有 findings、还是用户接受风险,都必须先写入或更新匹配当前 `基准` 和当前 `HEAD` 的 `docs/reviews/YYYY-MM-DD-<slug>.md`,再允许进入 `$easy-codex-ship`。 - 有问题时提供:回到执行计划、接受风险、停止。代码审查的“接受风险”允许进入 `$easy-codex-ship`。 - 无问题时提供:准备交付、停止。 ## 检查内容 - 是否满足规格和计划,是否多做或少做。 - 多阶段合并后是否破坏接口、数据契约、状态流或错误处理。 - 是否有回归、竞态、鉴权/安全、数据丢失、迁移或兼容风险。 - 测试是否覆盖用户行为和关键边界。 - 验证是否足以证明完成;失败或未跑项是否有解释。 - diff 是否包含无关改动、调试残留或计划外重构。 ## 问题格式 每条问题必须包含: - 严重级别:Critical / Important / Minor - 文件和行号 - 具体坏结果 - 当前差异为什么会导致它 - 最小修复方向 ## 输出 顺序: 1. 按严重级别排序的问题 2. 开放问题或假设 3. 验证缺口 4. 简短改动摘要 5. 下一步选择 没有发现问题时,直接说明,并列剩余风险和未验证项。
GitHub에서 보기