agentleFS
Sign inStart free
Sunnyshinnny776Sunnyshinnny776/pm-agentic-cookbook/skills/spec-capture/SKILL.md

spec-capture

Skill2 starsChanged 33 days agoApache-2.0View on GitHub

阶段性建设完成后,由用户发出信号触发,自动回看本阶段产出,提炼其中可复用、已确定的规则(UI/UX、交互、组件、集成、工作流、命名、方法论等),并沉淀到项目对应的 spec 文档或 PM Agentic Cookbook 的 skill 中。当用户说"沉淀规则、提炼规则、spec capture、阶段沉淀、把规则沉淀进 specs/kit、收口本阶段规则"时触发。

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

Create a free account to mount
Files
SKILL.md

spec-capture

PM Agentic Cookbook 的规则沉淀例程。把"实施后做规则沉淀检查"从一条被动文字规则,变成一个用户可一键触发、AI 自驱执行的动作:阶段性任务完成后,回看产出,提炼可复用规则,沉淀到最小的归属 spec 或 kit skill。

本 skill 操作化宿主 spec 加载规则中的沉淀检查(宿主契约 host.specMap 的 loading-rule 角色),并把沉淀目标从"项目 spec 文档"扩展到"PM Agentic Cookbook 的 skill / process / templates"。它不限定具体项目;以宿主契约声明的 spec 地图为参数。

支持用户点名调用和自动触发(当用户明确表示阶段完成、要沉淀/提炼/收口规则时)。

输入

  • 本阶段的产出与决策:git diff(自上次沉淀/相关提交以来)、本次会话中已确认的决定、用户的纠正。
  • 项目的 spec 地图:读取宿主契约(宿主根目录 cookbook.config.json 的 host 一节)的 specMap(各角色的 spec)、moduleDocs(模块文档)与 rulebooks(规则文件),以及本 skill 所在 cookbook(下称 <cookbook>)的 <cookbook>/process/、<cookbook>/templates/ 与各 skill;本 skill 单独安装、所在目录不在 cookbook 内时,cookbook 层的沉淀目标停下请用户指明 cookbook 位置。用到的字段未声明时停下,请用户指明——specMap 未声明就问 spec 在哪,moduleDocs 未声明就问模块需求文档在哪,rulebooks 未声明就问规则文件是哪几份——不从目录内容反推。
  • 调用方给出的范围提示(如某模块/某 PR)。

调用方给出范围时,以它为准。

核心原则

  1. 先判断必要性,不为沉淀而沉淀:触发后第一步先判断本阶段/任务是否值得、有必要沉淀为 spec 或 skill。若本阶段无可复用规则(纯一次性内容、纯 bugfix 无新约定、纯 mock、用户未接受的探索),如实说明"本阶段无需沉淀"并停止,不强行产出。
  2. 只沉淀"可复用 + 已确定":按捕获触发器筛选;一次性内容、临时 mock、孤立文案、不会复发的实现细节、用户未接受的想法——不沉淀。
  3. 提议在先,落盘在后:先输出"沉淀提议清单"交用户裁定;写入高冲突文件(UI/UX 总纲、宿主规则文件等)或重建 skill dist/ 前必须先确认。
  4. 可自评,不自我宣告通过:如实说明"沉淀了什么 / 为何无需沉淀",不替用户宣告"规则已收口/通过"。
  5. 最小归属:沉淀到最小的、已存在的归属 spec,沿用其既有风格与术语;无归属时建议新建路径并询问,不擅自创建宽泛新文档。
  6. 不自动提交:只产生工作区改动并报告;git commit/push 由用户另行授权(遵守宿主规则文件对提交的约定)。

执行流程

加载例程与路由规则:

沉淀例程(8 步)

规则归属路由图

简述:

  1. 圈定范围:确定本阶段改了什么、定了什么(diff + 已确认决策 + 用户纠正)。
  2. 必要性 gate:先判断本阶段是否值得沉淀;若无可复用规则,如实说明并停止,不进入后续步骤。
  3. 按触发器筛选:用「Capture Check」的触发器挑出可沉淀项,排除不该沉淀的。
  4. 分类路由:每条规则路由到归属(宿主 spec 的某个角色 / 模块需求文档 / skill / process / templates / 宿主规则文件)。
  5. 去重:对照既有 spec,定位最小归属;已存在则增补,不存在则建议新建并询问。
  6. 输出提议清单:规则 | 来源(本阶段何处) | 归属 | 新增/增补 | 拟写文字。
  7. 裁定后落盘:写入获批项;改动 skill 时重建其 dist/(若有);更新索引链接。
  8. 报告:沉淀了什么 / 为何某些未沉淀。

输出规范

  • 提议清单必须可追溯:每条规则点名"本阶段哪次决策/哪个 diff"产生它。
  • 落盘改动沿用归属文档既有风格与术语;新建文档前先询问。
  • 最终报告如实列出:已沉淀项、归属文件、是否重建 dist、以及"刻意未沉淀"的项与理由。
  • 严禁:把一次性内容塞进 spec;在报告中替用户下"规则已收口/通过"的结论;自动 commit/push。

停机条件

开始前：确定不了"本阶段"的范围——没有上次沉淀的标记，也无法从提交记录判断——时，请用户给出范围；无法询问时，以本次会话内的改动为范围，并在报告开头声明。

同时满足才算完成：

  1. 必要性判断有结论；判定无可沉淀时如实说明并停止，不硬造规则
  2. 提议清单每条都能追溯到本阶段的具体决策或改动
  3. 获批项已落盘；改动了带构建产物的 skill 时已重建

停下交用户：拿不准一条规则是否可复用；新规则与已有规范冲突。

不宣告"规则已收口"。

工作风格

  • 目标是让"散落在一次会话里的口头约定"变成"未来可加载、可复用的规则",而不是堆文档。
  • 拿不准是否可复用时,列为"待确认沉淀项"交用户,而不是擅自写入。
  • 与项目既有 spec 的边界保持一致:specs 记可复用规则;PRD 记模块业务;代码注释记本地技术细节。

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free