尧图网页设计 
Matt Pocock Skills to-spec 完全指南三步把一次 Agent 会话沉淀为可构建的规格文档【免费下载链接】skillsSkills for Real Engineers. Straight from my .agents directory.项目地址: https://gitcode.com/GitHub_Trending/skills13/skillsMatt Pocock Skills来自仓库自述的 Skills for Real Engineers是一套面向 Claude Code 等编码 Agent 的技能集其中的to-spec技能专门做一件事把你刚结束的那场 Agent 会话直接综合成一份spec规格文档specification并作为单条 issue 发布到项目的问题追踪器issue tracker上。它不问你新问题、不替你拍板新方案——它只在决定已经做完、但上下文窗口context window即将清零的那一刻把对话里幸存下来的决策写下来让下一个全新会话可以无缝接手。想装到本地可以直接git clone https://gitcode.com/GitHub_Trending/skills13/skills。第一性原则归档决策而不是产生决策先说它不做什么它不采访你。SKILL.md 正文第一行就是硬性约束Do NOT interview the user; just synthesize what you already know. 不要采访用户只综合你已经知道的东西。description 字段同样重复了这一点no interview, just synthesis of what youve already discussed。再说它做什么把你已经做过的决定用你项目自己的词汇落成一份能跨会话存活的记录。一句话点题spec 是会议纪要不是新的会议——它只记录会上定了什么不开新一轮讨论。这一点在实现层面被双重锁死SKILL.md 头部写着disable-model-invocation: true配套的 agents/openai.yaml 写着allow_implicit_invocation: false。两者合起来意味着该技能只能由你手动敲/to-spec触发Agent 永远不会自作主张地伸手去拿它——归档动作必须由决定已完成的那个人来发起。先用这张表自检什么状态该走哪条路to-spec的触发条件只有一个构建规模超过单个 Agent 会话session能承载的范围。判断现在该不该用它对照 docs/engineering/to-spec.md 给出的四行决策表你现在的状态该跑什么什么决定都还没做先跑 grill-with-docs先决策再归档已决定且工作量塞得进一个上下文窗口直接 implement跳过 spec已决定且工作要横跨多个会话/to-spec随后/to-tickets一张 wayfinder 地图刚梳理完毕/to-spec #map_issue喂地图 issue不是喂零散票注意最后一行wayfinder 地图上的决策散落在多张子票里/to-spec可以把地图 issue 当参数接收把整张地图的决策折叠成一份可构建的文档。前置条件先让它知道写到哪里去结论没有配置好追踪器这个技能会直接停下来让你去配置而不是猜一个位置。to-spec的产出物是一条 issue所以仓库必须先跑过 setup-matt-pocock-skills每个仓库只需一次配齐三样东西issue 追踪器、triage分诊标签词汇、领域文档布局。SKILL.md 原文对此的处理只有一句The issue tracker and triage label vocabulary should have been provided to you. If not, tell the user to run/setup-matt-pocock-skills.追踪器两类任选其一真实追踪器GitHub走ghCLI、GitLab走glabCLI等本地 Markdown开箱即用issue 就是.scratch/下的文件。本地追踪器的目录约定写在 issue-tracker-local.md每个特性一个目录.scratch/feature-slug/spec 固定落在.scratch/feature-slug/spec.md实现票则是issues/NN-slug.md一票一文件、从01编号triage 状态记在文件顶部的Status:行。标签词汇里与to-spec直接相关的是ready-for-agent——它是 setup 时写入的五种规范 triage 角色之一needs-triage、needs-info、ready-for-agent、ready-for-human、wontfixto-spec发布 spec 后会自动给它打上。另外整个 spec 必须使用项目 CONTEXT.md 领域词汇表里的名词并尊重你触及区域内的 ADR架构决策记录Architecture Decision Record——这两样也是 setup 时声明的领域文档布局的一部分。规格的两枚齿轮决策记录 与 测试缝这一节是全文技术密度最高的部分讲透 spec 内部的两个核心概念。齿轮一spec 是决策记录decision recordspec 之所以存在是因为上下文窗口终会结束。你在 grilling拷问式访谈阶段敲定的一切——方案的形状、反复论证过的取舍、你刻意拒绝的东西——全部集中在一场即将被清空clearing/compaction的对话里。打个比方上下文窗口像一块白板上进行的设计评审散会前白板会被擦掉spec 就是擦板之前拍下的那张照片。由此它有两道边界缺一道就走样不验证任何东西也不决定任何东西它只做综合用你项目自己的词汇domain glossary记录已经决定过什么让一个全新的会话无需你重新解释就能接手。判断标准很锋利spec 里任何一条你从未真正说过的断言都是缺陷defect不是合理推断。齿轮二seam测试缝先于正文to-spec在写下第一个字之前会先勾勒出这个特性将在哪些 seam 上被测试并停下来跟你确认。它的偏好规则写在 SKILL.md 第 2 步Existing seams should be preferred to new ones. Use the highest seam possible. … the ideal number is one. 优先用已存在的缝取能取到的最高层缝整个变更的理想缝数量是一个。tdd 技能给出了 seam 的正式定义A seam is the public boundary you test at: the interface where you observe behavior without reaching inside. seam 是你测试所在的公共边界在那里你能观察到行为而不必探进内部。用一件贴身的东西类比seam 就像外套的拉链——你验收衣服时拉拉链而不是拆开内衬检查走线。关键在于这些缝会往下游传导所以值得现在认真对待tdd 只会在预先商定的 seams 上工作原文明确要求 Test only at pre-agreed seams只测在预先商定的缝上code-review 会对照 spec 审查 diff一个没人同意过的 seam 会以 review 发现的形式暴露出来。这种绑定是间接的它经由 spec 这份文档发生作用。这就是为什么 seam 的讨论被放在 spec 阶段做而不是推迟到实现阶段——实现里临时定测试边界等于绕过协商直接制造审查问题。落地走查从探索到发布的三步按 SKILL.md 的 Process 章节执行分三步第 1 步探索仓库建立词汇。如果还没探索过代码库先了解现状。spec 通篇使用项目领域词汇表的名词并尊重触及区域内的 ADR。第 2 步勾勒测试缝并确认。按优先已有、取最高层、越少越好理想为 1三条规则草拟 seams停下来问你是否与预期一致。第 3 步按模板写 spec发布到追踪器打上ready-for-agent标签。模板骨架如下全文见 SKILL.md 的spec-template块## Problem Statement 用户视角的问题 ## Solution 用户视角的解法 ## User Stories 极详尽的编号用户故事As an actor, I want a feature, so that benefit ## Implementation Decisions 模块/接口/架构决策/API 契约——禁止具体文件路径与代码片段 ## Testing Decisions 好测试的标准 被测模块 代码库中的先例prior art ## Out of Scope 明确拒绝的东西 ## Further Notes 补充说明模板里有两条值得单独拎出的工程纪律Implementation Decisions 禁止文件路径和代码片段理由写得很直白They may end up being outdated very quickly.它们会很快过时。唯一例外prototype原型产出的、比散文更精确地编码了决策的片段状态机、reducer、schema、类型形状要裁到决策密集的部分并注明来自原型User Stories 要求extremely extensive极其详尽覆盖特性的所有方面格式固定为 As anactor, I want afeature, so thatbenefit。高频问题9 个真实疑问逐条答1. 我见过/to-prd它去哪了就是本技能v1.1 改名而来。CHANGELOG.md 里Unify the planning skills.to-prdis renamed toto-spec与Finish theto-prd→to-specrename: spec is now the only term in the shipped text两条记录完整交代了过程旧的to-plan、to-issues则并入了新的 to-tickets。新词汇组合是spec ticketsspec 是目的地及钉死它的决策tickets 是通往那里的执行步骤。中途改方向时删掉未完成的 tickets、保留 spec。2. 为什么打ready-for-agent标签我不想让 Agent 直接照它实现。这个标签含义是无需进一步 triage是输入标记不是工作指令。但如果你跑着轮询该标签的 AFK无人值守Agent这个区别对它们不可见——它们会试图一口气构建整个 spec。官方承认这是被报告最多的粗糙边缘对策是在 AFK Agent 提示词里显式排除父级 spec或在/to-tickets跑完后剥掉该标签。3. 能不能跳过 specgrilling 完直接/to-tickets通常你就该这么做。spec 只在多会话工作上挣得这一步tickets 是一次性的按一个全新上下文窗口切分用完即删/即关spec 不是它是承载 tickets 背后推理的唯一长期场所。单会话变更上它买不到东西反而多付一次可能让模型漂移drift的综合步骤——正确路径是 grilling →/implement。4. 我刚做完一张 wayfinder 地图喂什么喂主地图 issue/to-spec #map_issue不是那些零散决策票。wayfinder 产出的是决策而非交付物散落在整张地图上to-spec正是把它们折叠成可构建文档的那一步。把地图直接灌进/implement会丢掉折叠过程。5. spec 是给我看的还是给 Agent 看的主要是给 Agent 看的读起来也如此完整、密集、引用重。值得你亲自过目的只有seams和Out of Scope两块——错误决策在这两处最便宜、事后发现最贵。没有摘要模式诚实的回答是spec 让你感到意外说明 grilling 太浅而不是 spec 太长。6. tickets 开工后spec 冻结还是让 Agent 改写没有任何机制保持它同步它实际是你当时所知的快照实现教会你第一件事时就开始过时。交付后当一次性物品处理真正该活下来的产物是CONTEXT.md和 ADR——实现中学到的东西若值得留存写进那里。7. 我的工作是一次重构/模块边界调整模板合适吗不太合适这是已知局限。模板重度依赖 user stories对架构类工作是错误形状你会围绕本质上是接口与不变量的决策写出没人要的故事。改倚重 Implementation Decisions 与 Testing Decisions 两节把持久架构决策通过 grill-with-docs 落成 ADR。8. 它会去追踪器查重、或引用它尊重的 ADR 吗两个都不会。它读取并尊重触及区域的 ADR 但不链接它们起草前也不搜索追踪器里重叠的 issuespec 可能悄悄重复别人已提交的工作。区域活跃时自己先搜一遍。9./to-tickets读我的 spec 一直被截断非常大的 spec 会超出追踪器 issue 能干净回读的容量且没有本地副本兜底。修复办法是上下文卫生不要在/to-spec和/to-tickets之间执行 clearing 或 compaction同一窗口连跑spec 根本不需要被重新拉取。⚠️ 4 个常见用错场景以及正确姿势拿它当需求文档用期望 Agent 采访你、帮你收集需求。区别在于 spec 是已发生决策的事后综合不是面向未来的需求征集。它若开始抛出新一轮问题说明用错了上游——决策没做完该回去跑 grilling。往 spec 里塞文件路径和代码片段模板明文禁止因为它们很快会过时。路径与代码会随实现漂移唯一例外是编码了决策的原型片段。单会话小改动也走 spec多付一次综合步骤、多一分漂移风险什么也没买到。能塞进一个上下文窗口的工作直接/implement。让 AFK Agent 拿着 spec 一口气全建spec 是给人 后续会话的决策底座可执行的是to-tickets切出的 tracer-bullet曳光弹式垂直切片票每张票按一个全新上下文窗口定尺寸并声明自己的阻塞边blocking edges。 体系坐标它在构建链的哪个位置to-spec只在多会话分支上出现主链路是┌─ wayfinder 地图完成 ─┐ ▼ │ grill-with-docs → to-spec → to-tickets → implement → code-review 做决定 记决定 切执行票 构建 双轴校验上游grill-with-docs 负责本技能只记录、不参与的那场决策wayfinder 完成的整张地图在此并入链条下游to-tickets 把 spec 切成声明阻塞边的垂直切片票真实追踪器上用原生阻塞关系表达本地.scratch/约定下写进每张票的Blocked by行implement 基于 spec 或 tickets 构建用 tdd 在预定 seams 上开发以 code-review 收尾沿 Standards 与 Spec 两条轴审查按docs/、specs/、.scratch/顺序查找原始 spec迷路时ask-matt 是路由技能负责告诉你当前局面该走哪条路。✅ 自检清单这一次跑对了没有对任何一次/to-spec下列行为应当全部可观察它开始动笔了而不是向你抛出一轮新问题动笔前seams 摆到了你面前并得到确认提议的新缝尽可能少理想为零通篇用的是你项目名词对得上 CONTEXT.md 词汇表没有泛化的产品管理套话每条决策你都能回忆起自己做过——没有为填满某节而编造的内容Out of Scope 里有真实条目你拒绝过的东西通常是全页最有用的几行发布形态正确追踪器里是单条 issue并带ready-for-agent标签本地追踪器则是.scratch/feature-slug/spec.md一个文件之后紧接着在同一上下文窗口跑/to-tickets没有夹着 clearing/compaction。一句话收尾to-spec替你做了一件你自己也会忘的事在决定已做完、而对话即将被清空的那一秒钟把会消失的谈话变成一条躺在追踪器里、可供后续多个会话接力构建的决策记录。先/to-spec再/to-tickets——这是 Matt Pocock Skills 给所有横跨多个 Agent 会话的构建任务的标准答案。【免费下载链接】skillsSkills for Real Engineers. Straight from my .agents directory.项目地址: https://gitcode.com/GitHub_Trending/skills13/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Matt Pocock Skills to-spec 完全指南：三步把一次 Agent 会话沉淀为可构建的规格文档
Matt Pocock Skills to-spec 完全指南三步把一次 Agent 会话沉淀为可构建的规格文档【免费下载链接】skillsSkills for Real Engineers. Straight from my .agents directory.项目地址: https://gitcode.com/GitHub_Trending/skills13/skillsMatt Pocock Skills来自仓库自述的 Skills for Real Engineers是一套面向 Claude Code 等编码 Agent 的技能集其中的to-spec技能专门做一件事把你刚结束的那场 Agent 会话直接综合成一份spec规格文档specification并作为单条 issue 发布到项目的问题追踪器issue tracker上。它不问你新问题、不替你拍板新方案——它只在决定已经做完、但上下文窗口context window即将清零的那一刻把对话里幸存下来的决策写下来让下一个全新会话可以无缝接手。想装到本地可以直接git clone https://gitcode.com/GitHub_Trending/skills13/skills。第一性原则归档决策而不是产生决策先说它不做什么它不采访你。SKILL.md 正文第一行就是硬性约束Do NOT interview the user; just synthesize what you already know. 不要采访用户只综合你已经知道的东西。description 字段同样重复了这一点no interview, just synthesis of what youve already discussed。再说它做什么把你已经做过的决定用你项目自己的词汇落成一份能跨会话存活的记录。一句话点题spec 是会议纪要不是新的会议——它只记录会上定了什么不开新一轮讨论。这一点在实现层面被双重锁死SKILL.md 头部写着disable-model-invocation: true配套的 agents/openai.yaml 写着allow_implicit_invocation: false。两者合起来意味着该技能只能由你手动敲/to-spec触发Agent 永远不会自作主张地伸手去拿它——归档动作必须由决定已完成的那个人来发起。先用这张表自检什么状态该走哪条路to-spec的触发条件只有一个构建规模超过单个 Agent 会话session能承载的范围。判断现在该不该用它对照 docs/engineering/to-spec.md 给出的四行决策表你现在的状态该跑什么什么决定都还没做先跑 grill-with-docs先决策再归档已决定且工作量塞得进一个上下文窗口直接 implement跳过 spec已决定且工作要横跨多个会话/to-spec随后/to-tickets一张 wayfinder 地图刚梳理完毕/to-spec #map_issue喂地图 issue不是喂零散票注意最后一行wayfinder 地图上的决策散落在多张子票里/to-spec可以把地图 issue 当参数接收把整张地图的决策折叠成一份可构建的文档。前置条件先让它知道写到哪里去结论没有配置好追踪器这个技能会直接停下来让你去配置而不是猜一个位置。to-spec的产出物是一条 issue所以仓库必须先跑过 setup-matt-pocock-skills每个仓库只需一次配齐三样东西issue 追踪器、triage分诊标签词汇、领域文档布局。SKILL.md 原文对此的处理只有一句The issue tracker and triage label vocabulary should have been provided to you. If not, tell the user to run/setup-matt-pocock-skills.追踪器两类任选其一真实追踪器GitHub走ghCLI、GitLab走glabCLI等本地 Markdown开箱即用issue 就是.scratch/下的文件。本地追踪器的目录约定写在 issue-tracker-local.md每个特性一个目录.scratch/feature-slug/spec 固定落在.scratch/feature-slug/spec.md实现票则是issues/NN-slug.md一票一文件、从01编号triage 状态记在文件顶部的Status:行。标签词汇里与to-spec直接相关的是ready-for-agent——它是 setup 时写入的五种规范 triage 角色之一needs-triage、needs-info、ready-for-agent、ready-for-human、wontfixto-spec发布 spec 后会自动给它打上。另外整个 spec 必须使用项目 CONTEXT.md 领域词汇表里的名词并尊重你触及区域内的 ADR架构决策记录Architecture Decision Record——这两样也是 setup 时声明的领域文档布局的一部分。规格的两枚齿轮决策记录 与 测试缝这一节是全文技术密度最高的部分讲透 spec 内部的两个核心概念。齿轮一spec 是决策记录decision recordspec 之所以存在是因为上下文窗口终会结束。你在 grilling拷问式访谈阶段敲定的一切——方案的形状、反复论证过的取舍、你刻意拒绝的东西——全部集中在一场即将被清空clearing/compaction的对话里。打个比方上下文窗口像一块白板上进行的设计评审散会前白板会被擦掉spec 就是擦板之前拍下的那张照片。由此它有两道边界缺一道就走样不验证任何东西也不决定任何东西它只做综合用你项目自己的词汇domain glossary记录已经决定过什么让一个全新的会话无需你重新解释就能接手。判断标准很锋利spec 里任何一条你从未真正说过的断言都是缺陷defect不是合理推断。齿轮二seam测试缝先于正文to-spec在写下第一个字之前会先勾勒出这个特性将在哪些 seam 上被测试并停下来跟你确认。它的偏好规则写在 SKILL.md 第 2 步Existing seams should be preferred to new ones. Use the highest seam possible. … the ideal number is one. 优先用已存在的缝取能取到的最高层缝整个变更的理想缝数量是一个。tdd 技能给出了 seam 的正式定义A seam is the public boundary you test at: the interface where you observe behavior without reaching inside. seam 是你测试所在的公共边界在那里你能观察到行为而不必探进内部。用一件贴身的东西类比seam 就像外套的拉链——你验收衣服时拉拉链而不是拆开内衬检查走线。关键在于这些缝会往下游传导所以值得现在认真对待tdd 只会在预先商定的 seams 上工作原文明确要求 Test only at pre-agreed seams只测在预先商定的缝上code-review 会对照 spec 审查 diff一个没人同意过的 seam 会以 review 发现的形式暴露出来。这种绑定是间接的它经由 spec 这份文档发生作用。这就是为什么 seam 的讨论被放在 spec 阶段做而不是推迟到实现阶段——实现里临时定测试边界等于绕过协商直接制造审查问题。落地走查从探索到发布的三步按 SKILL.md 的 Process 章节执行分三步第 1 步探索仓库建立词汇。如果还没探索过代码库先了解现状。spec 通篇使用项目领域词汇表的名词并尊重触及区域内的 ADR。第 2 步勾勒测试缝并确认。按优先已有、取最高层、越少越好理想为 1三条规则草拟 seams停下来问你是否与预期一致。第 3 步按模板写 spec发布到追踪器打上ready-for-agent标签。模板骨架如下全文见 SKILL.md 的spec-template块## Problem Statement 用户视角的问题 ## Solution 用户视角的解法 ## User Stories 极详尽的编号用户故事As an actor, I want a feature, so that benefit ## Implementation Decisions 模块/接口/架构决策/API 契约——禁止具体文件路径与代码片段 ## Testing Decisions 好测试的标准 被测模块 代码库中的先例prior art ## Out of Scope 明确拒绝的东西 ## Further Notes 补充说明模板里有两条值得单独拎出的工程纪律Implementation Decisions 禁止文件路径和代码片段理由写得很直白They may end up being outdated very quickly.它们会很快过时。唯一例外prototype原型产出的、比散文更精确地编码了决策的片段状态机、reducer、schema、类型形状要裁到决策密集的部分并注明来自原型User Stories 要求extremely extensive极其详尽覆盖特性的所有方面格式固定为 As anactor, I want afeature, so thatbenefit。高频问题9 个真实疑问逐条答1. 我见过/to-prd它去哪了就是本技能v1.1 改名而来。CHANGELOG.md 里Unify the planning skills.to-prdis renamed toto-spec与Finish theto-prd→to-specrename: spec is now the only term in the shipped text两条记录完整交代了过程旧的to-plan、to-issues则并入了新的 to-tickets。新词汇组合是spec ticketsspec 是目的地及钉死它的决策tickets 是通往那里的执行步骤。中途改方向时删掉未完成的 tickets、保留 spec。2. 为什么打ready-for-agent标签我不想让 Agent 直接照它实现。这个标签含义是无需进一步 triage是输入标记不是工作指令。但如果你跑着轮询该标签的 AFK无人值守Agent这个区别对它们不可见——它们会试图一口气构建整个 spec。官方承认这是被报告最多的粗糙边缘对策是在 AFK Agent 提示词里显式排除父级 spec或在/to-tickets跑完后剥掉该标签。3. 能不能跳过 specgrilling 完直接/to-tickets通常你就该这么做。spec 只在多会话工作上挣得这一步tickets 是一次性的按一个全新上下文窗口切分用完即删/即关spec 不是它是承载 tickets 背后推理的唯一长期场所。单会话变更上它买不到东西反而多付一次可能让模型漂移drift的综合步骤——正确路径是 grilling →/implement。4. 我刚做完一张 wayfinder 地图喂什么喂主地图 issue/to-spec #map_issue不是那些零散决策票。wayfinder 产出的是决策而非交付物散落在整张地图上to-spec正是把它们折叠成可构建文档的那一步。把地图直接灌进/implement会丢掉折叠过程。5. spec 是给我看的还是给 Agent 看的主要是给 Agent 看的读起来也如此完整、密集、引用重。值得你亲自过目的只有seams和Out of Scope两块——错误决策在这两处最便宜、事后发现最贵。没有摘要模式诚实的回答是spec 让你感到意外说明 grilling 太浅而不是 spec 太长。6. tickets 开工后spec 冻结还是让 Agent 改写没有任何机制保持它同步它实际是你当时所知的快照实现教会你第一件事时就开始过时。交付后当一次性物品处理真正该活下来的产物是CONTEXT.md和 ADR——实现中学到的东西若值得留存写进那里。7. 我的工作是一次重构/模块边界调整模板合适吗不太合适这是已知局限。模板重度依赖 user stories对架构类工作是错误形状你会围绕本质上是接口与不变量的决策写出没人要的故事。改倚重 Implementation Decisions 与 Testing Decisions 两节把持久架构决策通过 grill-with-docs 落成 ADR。8. 它会去追踪器查重、或引用它尊重的 ADR 吗两个都不会。它读取并尊重触及区域的 ADR 但不链接它们起草前也不搜索追踪器里重叠的 issuespec 可能悄悄重复别人已提交的工作。区域活跃时自己先搜一遍。9./to-tickets读我的 spec 一直被截断非常大的 spec 会超出追踪器 issue 能干净回读的容量且没有本地副本兜底。修复办法是上下文卫生不要在/to-spec和/to-tickets之间执行 clearing 或 compaction同一窗口连跑spec 根本不需要被重新拉取。⚠️ 4 个常见用错场景以及正确姿势拿它当需求文档用期望 Agent 采访你、帮你收集需求。区别在于 spec 是已发生决策的事后综合不是面向未来的需求征集。它若开始抛出新一轮问题说明用错了上游——决策没做完该回去跑 grilling。往 spec 里塞文件路径和代码片段模板明文禁止因为它们很快会过时。路径与代码会随实现漂移唯一例外是编码了决策的原型片段。单会话小改动也走 spec多付一次综合步骤、多一分漂移风险什么也没买到。能塞进一个上下文窗口的工作直接/implement。让 AFK Agent 拿着 spec 一口气全建spec 是给人 后续会话的决策底座可执行的是to-tickets切出的 tracer-bullet曳光弹式垂直切片票每张票按一个全新上下文窗口定尺寸并声明自己的阻塞边blocking edges。 体系坐标它在构建链的哪个位置to-spec只在多会话分支上出现主链路是┌─ wayfinder 地图完成 ─┐ ▼ │ grill-with-docs → to-spec → to-tickets → implement → code-review 做决定 记决定 切执行票 构建 双轴校验上游grill-with-docs 负责本技能只记录、不参与的那场决策wayfinder 完成的整张地图在此并入链条下游to-tickets 把 spec 切成声明阻塞边的垂直切片票真实追踪器上用原生阻塞关系表达本地.scratch/约定下写进每张票的Blocked by行implement 基于 spec 或 tickets 构建用 tdd 在预定 seams 上开发以 code-review 收尾沿 Standards 与 Spec 两条轴审查按docs/、specs/、.scratch/顺序查找原始 spec迷路时ask-matt 是路由技能负责告诉你当前局面该走哪条路。✅ 自检清单这一次跑对了没有对任何一次/to-spec下列行为应当全部可观察它开始动笔了而不是向你抛出一轮新问题动笔前seams 摆到了你面前并得到确认提议的新缝尽可能少理想为零通篇用的是你项目名词对得上 CONTEXT.md 词汇表没有泛化的产品管理套话每条决策你都能回忆起自己做过——没有为填满某节而编造的内容Out of Scope 里有真实条目你拒绝过的东西通常是全页最有用的几行发布形态正确追踪器里是单条 issue并带ready-for-agent标签本地追踪器则是.scratch/feature-slug/spec.md一个文件之后紧接着在同一上下文窗口跑/to-tickets没有夹着 clearing/compaction。一句话收尾to-spec替你做了一件你自己也会忘的事在决定已做完、而对话即将被清空的那一秒钟把会消失的谈话变成一条躺在追踪器里、可供后续多个会话接力构建的决策记录。先/to-spec再/to-tickets——这是 Matt Pocock Skills 给所有横跨多个 Agent 会话的构建任务的标准答案。【免费下载链接】skillsSkills for Real Engineers. Straight from my .agents directory.项目地址: https://gitcode.com/GitHub_Trending/skills13/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考