用途：在 MCP conformance 仓库中引导生成 SEP-2484 规定的需求可追溯性 YAML，把 SEP 规范 diff 中的每条规范性语句映射到 check: ID（可测试）或 excluded: reason（不可测试）。CLI 只生成骨架，行内容需人工阅读规范 diff 填写。
主要能力与流程：先做预检，运行 gh auth status 确认 GitHub CLI 已认证，并用 test -f package.json && jq -r '.name' package.json 确认位于 conformance 仓库（名称应为 @modelcontextprotocol/conformance）。解析 sep-number 参数后运行 npm run --silent build 与 node dist/index.js new-sep <NNNN>（开发时可用 npx tsx src/index.ts new-sep ...），生成 src/seps/sep-<NNNN>.yaml。随后用 gh api 拉取 PR 的规范 diff，提取含 MUST、MUST NOT、SHOULD、SHOULD NOT、REQUIRED、SHALL、SHALL NOT、MAY、OPTIONAL 的完整句子；MAY/OPTIONAL 不生成行。MUST/SHALL/REQUIRED 与 SHOULD 分别对应 FAILURE、WARNING 严重级，均写为 check: sep-<NNNN>-<slug>。无法被测试框架观测的 MUST/SHOULD 才写 excluded:，且必须经用户确认，不得自行决定。
使用方式：按步骤重写 YAML，保留 CLI 的单引号与两空格缩进风格；check 行先写 check: 再写 text:，excluded 行先写 text: 再写 excluded:；所有 check 行在前、excluded 行在后，不交错。必要时补全 spec_url 锚点，跨页面需求用 url: 覆盖。最后用 rg 在 src/scenarios/<suite>/ 中查找可承载新检查的既有场景并给出建议。
适用场景与限制：适用于 MCP conformance 仓库的 SEP 需求追溯维护。需要 GitHub 认证与仓库环境；规范变更若在单独 PR 中，需用户提供 --spec-path，不得猜测。技能范围止于 YAML 与场景建议，不生成或修改场景 .ts 文件，也不改动 src/scenarios/index.ts；不确定的需求应保留 TODO 行交由人工复核。