先确定完成后的结果是什么。从用户的请求、验收标准、相关文档、当前契约和真实调用方推导需要的行为、结构和文档。依据缺失或互相矛盾时，标记为证据不足，不从当前实现反推。
找出可能已经过期的部分：回应旧误解的说明、复述尝试和反复的叙述、迁移留下的临时字段和分支、保护已被删除行为的测试、新旧两套表示同时保留的情况。
逐项找现在仍然成立的理由。文字看删除后是否会改变读者的理解、判断或操作；代码、接口、配置和数据结构要检查当前调用方、契约、已有数据、外部约束。历史能解释一个东西为什么出现，但只有当前证据能决定它是否留下。
只在证明过的范围内清理。默认只审查和报告，用户明确要求修改时才动文件。公开接口、持久化数据、传输格式、迁移历史和仍在使用的兼容路径，先给出证据和拟议结果，取得授权再改。
跑针对性验证，检查有没有产生新的孤立代码、测试、配置或文档。

“如果从完成后的设计开始，还会加入它吗”这个反问只用来找候选项。答案是“不会”只说明值得调查，不等于可以删。

最终回复说明完成后的状态、仍然成立的约束、实际跑过的检查，以及因为证据或授权不足而保持原样的部分。它不会把刚清掉的过程改写成一份删除清单再交回来。

适用场景

why-here 可以由 agent 在交付前主动选择，也可以由你显式调用。它适合：

它不适合只想减少行数的重构和代码美化，不适合以找出全仓库死代码和重复抽象为目标的简化审计，也不适合只要求把文字写得自包含或核实事实。调查和方案设计还在进行时不要用它：那时的过程记录仍在起作用。

安装

所有 skill 统一从分发仓 agent-skills/skills 安装：

npx skills add https://git.im0o.top/agent-skills/skills.git

安装程序会列出全部 skill，勾选 why-here 即可。获取仓库前，可以先检查当前机器是否有访问权限：

git ls-remote https://git.im0o.top/agent-skills/skills.git HEAD

命令返回 commit hash 就表示可以继续安装。

本仓库负责开发和发布，不作为常规安装来源。需要单独取一份时，可以从本仓 Release 下载 why-here.zip，解压后把目录交给安装工具：

npx skills add ./why-here

安装工具不接受 ZIP 文件路径，只接受解压后的目录。

交付前直接说明要审查的范围：

这次改动中途换过方案。提交前用 why-here 看看还有没有只属于旧方案的内容。

迁移已经做完了。用 why-here 检查这些临时字段和兼容分支现在还有没有人用，先只报告不要改。

这份文档里有几段是在回应我早先的误解。用 why-here 判断哪些对现在的读者还有用，可以直接改。

在提供同名斜杠命令的客户端中，也可以运行：

/why-here

默认是只审查不修改。需要它直接动文件时，在请求里说清楚，例如“可以直接改”“清理掉”。

think-twice 负责把一段文字重写成读者可以独立理解和执行的最终文本，范围只有文字。why-here 同时看文字和有运行意义的产物，而且对两者用不同的修改门槛：文字按读者是否需要判断，代码、接口和数据结构必须再检查真实调用方、契约、已有数据和外部约束。

以查找死代码、重复状态和无收益抽象为目标的通用简化审计是另一件事。why-here 的判据只有一条：这个部分现在是否只因为做的过程走过某条路才存在。

why-here 不依赖其他 skill，可以单独安装使用。

skill/
└── SKILL.md   # 审查范围、五步流程、分类判据和交付要求
evals/
├── evals.json # 候选测试提示和预期结果
└── README.md  # 这些提示覆盖什么，以及还缺什么才能作为对照评估

发布包只包含 skill/ 目录中的内容，因此解压后的 why-here.zip 根目录直接包含 SKILL.md。evals/ 不随安装分发。

推送与 v* 匹配的 annotated tag（带说明文字的 tag）后，Gitea Actions 会运行 .gitea/workflows/release.yml：

发布 tag 必须是 annotated tag，而且 message 不能为空。创建和推送 tag 时使用完整的 refs/tags/<name> 路径，避免同名 branch 与 tag 混淆。