关于 spec-mining
面向缺少可靠文档的系统，通过检查实际运行的代码来提取规格说明。适用于维护、迁移和入职场景，强调为观察结果标注证据，并将推断和未解问题分开记录。
主要功能
- 01从入口沿请求路径分析
- 02结合测试与迁移历史
- 03按 EARS 格式编写需求
- 04为观察结果引用代码位置
- 05独立记录不确定问题
适用场景
- 01为无文档系统整理规格
- 02为服务重建提供行为依据
- 03在迁移前梳理数据模型变化
- 04帮助新维护者理解系统
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/spec-mining确认已加载。
附带文件references/specification-template.md
详细介绍
规格挖掘
通过阅读实际运行的代码，从缺乏可用文档的系统中提取规格说明。
让输出值得信赖的关键原则是：将观察到的内容与推断出的内容分开。 读者会依据这份文档采取行动——重建服务、规划迁移、熟悉系统等。听起来信心十足的猜测比明确承认存在缺口更糟糕，因为没人会回头核实。
方法
从外向内开展：先看入口点，再看路由，然后看路由背后的服务，最后看数据层。沿着实际请求路径追踪，能让你了解系统真实的结构，而它的目录名称所暗示的结构往往并不准确。
也要阅读测试。它们记录了预期行为，以及有人在生产环境中遇到的边界情况；通常比仓库中的任何注释或 README 都更坦诚。
还要阅读迁移历史。迁移有日期且顺序明确，因此能展现架构如何演变成当前形态——哪些列是在紧迫情况下添加的、哪些数据被回填了、哪些字段被重命名后却从未删除。这个演变过程往往是关于数据模型为何如此的唯一留存记录。
每项观察都要引用其证据——src/auth/jwt.strategy.ts:42。没有位置，读者就无法核实声明；无法核实的声明会让逆向工程得到的规格说明逐渐失去价值。
编写观察到的需求 — EARS
EARS 通过强制在句子中写明触发条件和状态，让需求明确无歧义，从而避免“系统验证令牌”这句话掩盖了_何时_验证。
| 模式 | 形式 |
|---|---|
| 通用 | 系统应当[执行操作]。 |
| 事件 | 当[触发条件]时，系统应当[执行操作]。 |
| 状态 | 在[状态]期间，系统应当[执行操作]。 |
| 条件 | 在[状态]期间，当[触发条件]时，应当…… |
| 可选 | 在[功能已启用]时，应当…… |
按领域编号，以便之后引用——OBS-AUTH-001、OBS-USER-002：
OBS-AUTH-001
While credentials are valid, when POST /auth/login is called, the system
shall return a JWT access token (15m) and a refresh token (7d).
Evidence: src/auth/auth.controller.ts:31, src/auth/auth.service.ts:88
不确定之处也是交付内容
所有无法从代码中确定的内容，都应单独列为问题，而不是猜测：什么会触发状态转换，删除是否为软删除，哪个外部系统负责某个字段。本节往往是文档中最有价值的部分——它列出了维护者必须先回答的问题，之后才有人能依赖其余内容。
输出
保存到 specs/{project_name}_reverse_spec.md。结构和章节顺序：references/specification-template.md。