cm-prdlisted

# cm-prd — 需求文档 → 开发规格生成 执行前读取 `../../runtime/project-context.md` 与 `../../runtime/review.md`。Codex 入口为 `$cm-prd`；Claude Code 跨平台入口为 `/cm-prd`，macOS/Linux 另有历史别名 `/cm:prd`。 支持两种模式：新建需求和需求变更。 ## 输入参数 `用户本轮输入` 格式： - **新建模式**：`$cm-prd {项目文件夹路径}` - **变更模式**：`$cm-prd --change {N}.{feature-name} 变更内容描述` 用户提供一个项目文件夹路径，文件夹结构约定： ```text {项目文件夹}/ ├── docs/ ← 需求文档（必须存在，PRD 从这里读取） ├── 1.xxx/ ← 已有的 specs（如有） ├── 2.xxx/ ← 本次生成的 specs └── ... ``` ## 模式判断 如果 `用户本轮输入` 以 `--change` 开头 → **读取 `references/change-mode.md`** 执行变更模式（C1–C8） 否则 → 进入新建模式 --- ## 新建模式 ### Step 1: 解析输入，读取需求文档 从 `用户本轮输入` 提取项目文件夹路径，记为 `SPECS_DIR`。 读取 `{SPECS_DIR}/docs/` 下的所有文件作为需求源： - 支持 `.md`、`.txt`、`.pdf`、`.html` 等文档格式 - **HTML 交互原型（可点击 PRD）→ 执行交互遍历协议，禁止只做静态截图**。可交互原型是一份可执行的需求文档，必须用无头浏览器（Playwright / Chrome DevTools）**主动遍历**： 1. **枚举**每个页面的全部可交互元素（按钮/链接/tab/表单/开关/列表项…） 2. **逐个操作**并记录三元组：`元素 → 动作 → 结果`（跳转到哪/弹了什么/状态怎么变/无响应） 3. 产出**功能点清单**：每个有响应的交互 → 对应一条 [F-xxx]；**点了没反应的 → 列为"原型死区"进开放问题**（问用户：是原型没做完，还是本就不需要？不许静默丢弃） 4. **覆盖率自检**：可交互元素总数 = 功能需求数 + 死区数，对不上不得进入 Step 6 5. 遍历过程中逐状态截图（Step 8.5 的候选基准）；三元组记录直接生成**交互流 AC 与 E2E 走查清单** 原型首先是需求，其次才是视觉候选。注意原型通病：只画理想态——异常态/空态/边界值靠 Step 5.5 歧义五问补齐 - 如果 docs/ 下有多个文件，全部读取并综合分析 - 如果 docs/ 不存在或为空，报错提示用户先在 docs/ 下放入需求文档 ### Step 2: 获取项目名称 - 从当前目录的 `package.json` name 字段、`Cargo.toml`、`go.mod` 等提取项目名 - 如无法提取，使用当前目录名 - 转为 kebab-case，记为 `PROJECT_NAME` ### Step 3: 探测项目架构类型 **代码项目根的确定（防在错误目录生成脏规格）**：`用户本轮输入` 中显式给了代码项目路径（如 `代码在~/code/app`）→