mcpField
R
recursive-spec

recursive-spec

github.com/try-works开发13659 次安装14 周前更新
代码仓库

关于 recursive-spec

recursive-spec 用于为新的 recursive-mode 运行共同编写结合代码库情况的需求文档。它引导用户明确目标并审批 `00-requirements.md`，不会提前进入规划或实现阶段。

主要功能

  1. 01引导式需求访谈
  2. 02检查代码库与代码
  3. 03定义可观察的验收标准
  4. 04审批前将草稿保存在仓库外
  5. 05规格获批后创建运行

适用场景

  1. 01实现前界定新功能范围
  2. 02编写错误修复或迁移需求
  3. 03明确边界与待解决问题

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/try-works/recursive-mode --skill recursive-spec

安装后在 Claude Code 中输入/recursive-spec确认已加载。

附带文件agents/openai.yamlreferences/patterns.md

详细介绍

recursive-spec

使用此技能，为新的递归模式运行共同编写了解代码库的 00-requirements.md。

此技能用于在开始实施之前编写需求／规格。它不能替代 /.recursive/RECURSIVE.md，也不应提前进入 Phase 2 规划或 Phase 3 实施。

主要用途

当用户想在运行开始前梳理工作时，使用 recursive-spec，尤其是遇到以下提示时：

  • create a plan
  • help me plan
  • create a spec
  • write requirements
  • spec this out
  • scope this

关键判断信号是针对新运行的计划／规格语言，而不是实施现有运行。

对话约定

检测到触发条件时：

  1. 首先询问用户是否需要帮助为递归运行创建规格。
  2. 如果用户回答肯定，询问：What do you want to do?
  3. 然后收集上下文、阅读代码库，并共同编写需求。

在用户确认需要规格帮助之前，不要直接开始编写 00-requirements.md。

批准前的草稿处理

在用户明确批准规格之前：

  • 将草稿保存在代码库工作树之外
  • 优先使用临时会话产物或临时文件
  • 不要创建 /.recursive/run/<run-id>/
  • 不要写入 00-requirements.md

如果用户拒绝草稿，请修改草稿或丢弃临时草稿产物。不要留下尚未完全获批的运行文件夹。

必须遵循的读取要求

起草需求之前，请阅读：

  1. /.recursive/STATE.md
  2. /.recursive/DECISIONS.md
  3. /.recursive/memory/MEMORY.md
  4. 仅在确实相关时阅读相关记忆分片
  5. 与请求范围最相关的代码和测试

此技能应了解代码库，而不是进行盲目问卷式提问。应利用控制平面文档了解当前事实，并通过代码库了解实际涉及的范围、耦合模块、现有测试和可能的边界。

编写流程

采用引导式访谈。若代码库文档或代码中尚无答案，每次只问一个有针对性的问题。

建议按以下顺序进行：

  1. 目标和用户期望的结果
  2. 任务类型：功能、缺陷修复、重构、迁移、调查
  3. 受影响的子系统或文件
  4. 范围内的需求（R#）
  5. 每项需求的可观察验收标准
  6. 边缘情况、失败路径和排除项
  7. 约束、固定决策和边界
  8. Phase 0 锁定前必须解决的待确认事项

优先提出草稿措辞，让用户确认或纠正，而不是让用户从头编写整份文档。

质量规则

借鉴契约优先工作流中最有效的编写方法，同时确保输出符合递归模式的原生格式：

  • 从用户意图和期望结果开始
  • 区分固定决策与待确认事项
  • 定义确定、可观察的验收标准
  • 考虑异常和失败路径，而不只考虑理想路径
  • 明确边界，以便指导后续的 AS-IS 分析和规划
  • 明确列出范围外事项

不要引入独立的 .spec DSL 或第二种工作流格式。

输出约定

最终输出应保存为：

  • /.recursive/run/<run-id>/00-requirements.md

使用代码库原生的 Phase 0 需求结构：

  • 保留 recursive-init 提供的脚手架标题，包括 Workflow version：recursive-mode-audit-v2
  • 保留必需的 ## TODO 部分，并替换占位清单项，而不是删除该标题
  • ## Requirements
  • ## Out of Scope
  • ## Constraints

在 ## Requirements 中，每项 R# 都应包含：

  • 简短标题
  • 清晰的描述
  • 可观察的验收标准项目符号

运行创建规则

不要立即创建运行文件夹。

  1. 先与用户一起起草并完善需求。
  2. 在临时的非仓库文件中保留草稿，直至获得批准。
  3. 确认用户已批准规范，且内容完整到足以继续。
  4. 使用 .recursive/scripts/recursive-init.py 或 .recursive/scripts/recursive-init.ps1 创建运行。
  5. 用已批准的需求内容替换脚手架生成的 00-requirements.md。

这样可以确保运行产物以用户批准的需求为依据，而不是基于尚未成形的笔记。

路由意识

如果规范编写过程中使用了委派评议、委派审查或任何其他外部模型协助来完善草稿，那么在选择该 CLI/模型之前，立即重新读取：

  • /.recursive/config/recursive-router.json
  • /.recursive/config/recursive-router-discovered.json

并通过 recursive-router 进行路由，而不是自行临时选择模型。

边界

  • 专注于为新运行编写 00-requirements.md。
  • 不要悄悄将此事转为第 2 阶段规划。
  • 不要仅仅因为需求已经明确就开始实施。
  • 如果仓库结构会影响范围或约束，不要跳过代码阅读。
  • 在用户批准的规范准备好写入之前，不要创建运行。
  • 不要将未经批准的草稿写入仓库需求产物。

参考资料

  • /.recursive/RECURSIVE.md
  • /.recursive/STATE.md
  • /.recursive/DECISIONS.md
  • /.recursive/memory/MEMORY.md
  • ../recursive-mode/references/artifact-template.md
  • ./references/patterns.md

评论

支持 Markdown