菜单
Use when auditing an existing retikz test suite, module test directory, or docs tests for stale, duplicate, implementation-coupled, migration-only, or temporary cases; classify which tests remain durable contract or regression coverage and produce evidence-backed cleanup recommendations before refactoring tests.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when changing any retikz apps/docs content, route data, i18n, demo, SourceLinks, or schema reference before loading the matching page-type skill.
Use when retikz needs multiple independent LLMs to review the same fixed code, ADR, implementation plan, test contract, commit, or working-tree snapshot before a gate or delivery decision.
Use when an Alpha ADR needs a pre-implementation capability gate, or a Beta milestone needs code-based completeness and package-boundary auditing.
Use when planning a retikz architecture direction, version roadmap, or alpha feature that may need a long-lived ADR before implementation.
Use when retikz work is primarily refactoring, reorganization, renaming cleanup, modularization, or internal simplification and should start from a reviewed implementation plan before code changes.
Use when retikz implementation, adversarial testing, and docs are complete, and an ADR or beta TODO needs changelog, contract consistency review, roadmap status updates, or final human acknowledgement.
| name | test-review |
| description | Use when auditing an existing retikz test suite, module test directory, or docs tests for stale, duplicate, implementation-coupled, migration-only, or temporary cases; classify which tests remain durable contract or regression coverage and produce evidence-backed cleanup recommendations before refactoring tests. |
审查测试本身是否仍在保护当前契约。本 skill 默认只读：输出保留、合并、转正或删除建议，不直接改测试、不提交。
| 场景 | 用哪个 skill |
|---|---|
| 审计已有测试是否过期、重复或临时 | test-review |
| 横向审实现、架构与文档一致性 | develop-review |
| 为疑似缺陷构造边界 case | cross-test |
| Alpha 实现完成后的对抗性验证 | develop-test |
| 已接受测试清理建议并实施 | develop-refactor |
不要用测试数量、行数或覆盖率百分比直接决定保留与删除。唯一标准是：该 case 是否以最小必要粒度保护仍然存在的行为契约。
git rev-parse HEAD 和 git status --short，保留并区分并发工作区改动。AGENTS.md；审 docs 时再读 apps/docs/AGENTS.md 及相关 docs skill。对每个测试文件或可独立删除的 describe 块，记录：
git log -- <file>、git blame 或关联 issue / commit 追溯它是否只是迁移或一次性验证优先从实现入口反查测试，不要只按测试文件名归类。
| 分类 | 判定 | 默认动作 |
|---|---|---|
| 契约测试 | 保护公开 API、schema、编译/渲染语义或跨包边界 | 保留 |
| 回归测试 | 对应已确认真实缺陷，且仍能解释风险 | 保留 |
| 行为集成测试 | 覆盖真实用户路径，且无法由更低层契约替代 | 保留或收敛 |
| 重复测试 | 与其它 case 保护同一规则，额外 case 不增加失效模式 | 合并到最接近真实行为的一层 |
| 历史护栏 | 仅保护已完成迁移、旧命名、旧目录或已删除实现 | 删除 |
| 实现耦合测试 | 断言私有源码、固定文案、内部调用顺序或无意义快照 | 删除或改成行为断言 |
| 临时探索测试 | 只为当次定位、验证或 canary 存在 | 验证后删除；确认缺陷才转为回归测试 |
Snapshot 不是天然无效：只有当它不能表达用户可见输出差异、没有明确失效价值，或被更小的行为断言覆盖时，才建议删除。
每条“合并”或“删除”建议必须写清：
docs 测试额外检查：
tests/_scratch/，以复用真实 Vitest 配置且默认不会进入 Git。pnpm temp:test -- --workspace <workspace-directory> --file <tests/_scratch/*.test.ts> 运行；脚本会在成功或失败后删除文件与空的 _scratch 目录。只有人工连续调试时才传 --keep。git add -f tests/_scratch/；提交前检查暂存 diff，确认没有 canary、scratch、debug、temporary 或仅服务本轮排查的测试。报告写入 ignored 路径：
notes/reports/test-review-YYYY-MM-DD-<scope>.md
# Test Review Report: <scope>
日期：
范围：
基准快照：
测试与实现读取范围：
## 结论概览
## 保留
| 测试 | 保护的当前契约 | 保留证据 |
## 合并
| 测试 | 重复证据 | 保留目标 | 最小保留断言 |
## 删除
| 测试 | 分类 | 过期或耦合证据 | 替代覆盖 / 风险承担 |
## 临时测试
| 测试 | 验证结论 | 删除或转正动作 |
## 建议实施顺序
没有某类时写“无”。报告不得 stage 或 commit。