Matt Pocock Skills 之 to-spec把一次 Agent 会话沉淀为可跨会话执行的规格文档【免费下载链接】skillsSkills for Real Engineers. Straight from my .agents directory.项目地址: https://gitcode.com/GitHub_Trending/skills13/skillsto-spec是 Matt Pocock Skills 工程技能套件中的一环它在你不打断思路的前提下把刚刚结束的那场 Agent 会话直接合成一份规格文档spec并作为单条 issue 发布到项目的问题追踪器上。本指南将完整拆解该技能的设计动机、执行流程、规格模板与常见陷阱结合仓库内 SKILL.md 与配套技能的源码实现帮助你在多会话构建、wayfinder 地图合并等真实场景中正确地使用它。它做什么记录决策而不是制造决策to-spec的核心行为只有一句话把你刚刚经历的对话变成一份 spec并作为单条 issue 发布到问题追踪器。关键在第二句话它不会采访你。当你伸手调用它时决定早已做完所以它的职责是从现有材料里做综合——对话线程、代码库现状、项目的 CONTEXT.md 以及 ADR架构决策记录——而不是重新开启一轮提问。spec 是已经做出的决策的记录不是做出新决策的场所。这一点在技能实现层面被反复强调。打开 skills/engineering/to-spec/SKILL.md 可以看到技能的description字段明确写着Turn the current conversation into a spec and publish it to the project issue tracker: no interview, just synthesis of what youve already discussed.正文第一行也同样是硬性约束Do NOT interview the user; just synthesize what you already know.不要采访用户只综合你已经知道的东西。而 agents/openai.yaml 中的allow_implicit_invocation: false与 SKILL.md 头部的disable-model-invocation: true共同表明该技能只能由用户显式调用Agent 永远不会自己伸手去拿它。何时使用多会话工作的唯一触发条件to-spec通过输入/to-spec触发Agent 不会主动调用它。它的全部触发场景只有一个构建规模超过单个 Agent 会话session能承载的范围必须拆成多个会话才能完成。原文档给出了一张决策表你处于什么状态应该运行什么什么都还没决定先跑grill-with-docsSKILL.md已决定且工作量能放进一个上下文窗口context window直接implement跳过 spec已决定且工作要横跨多个会话/to-spec然后to-tickets一张 wayfinder 地图已经梳理完毕/to-spec #map_issue注意最后一行wayfinder 地图完成时/to-spec接受地图 issue 的编号作为参数把散落在整张地图上的决策折叠成一份可构建的文档。前置条件追踪器与 triage 标签词汇to-spec会把 spec 发布为一条 issue因此仓库必须已经配置好问题追踪器和 triage 标签词汇——这一步由 setup-matt-pocock-skills 完成每次首次使用其他工程技能前运行一次。支持两类追踪器任选其一真实追踪器如 GitHub走ghCLI、GitLab走glabCLI或其他自述工作流本地 Markdownissue 以.scratch/下的 markdown 文件形式存在开箱即用无需任何外部服务。本地 Markdown 追踪器的约定在 issue-tracker-local.md 中有完整定义每个特性一个目录.scratch/feature-slug/spec 固定落在.scratch/feature-slug/spec.md实现 issue 则是issues/NN-slug.md一票一文件从01编号triage 状态通过文件顶部的Status:行记录。如果追踪器与标签词汇尚未配置SKILL.md 明确指示 AgentIf not, tell the user to run/setup-matt-pocock-skills——也就是说前置缺失时它不会自行猜测而是引导你先完成配置。ready-for-agent标签正是 setup-matt-pocock-skills 配置的五种规范 triage 角色之一needs-triage、needs-info、ready-for-agent、ready-for-human、wontfixto-spec发布 spec 后会自动打上它。spec 的本质一份决策记录decision recordspec 之所以存在是因为上下文窗口终会结束。你在 grilling 阶段敲定的一切——解决方案的形状、反复论证过的取舍、你刻意拒绝的东西——全部集中在一场即将被清空clearing/compaction的对话里。spec 就是这场对话的幸存者。因此它有两条边界它不验证任何东西也不决定任何东西它只是用你自己项目的词汇表记录已经决定过什么让一个全新的会话无需你重新解释就能接手工作。任何 spec 中断言的、但你从未真正说过的东西都是缺陷defect。这正是它区别于一般需求文档的地方它是对已发生决策的事后综合而不是面向未来的需求征集。Seams before prose先谈测试缝再写正文to-spec在写下第一个字之前会先勾勒出该特性将在哪些 seam测试缝上被测试并与你确认。它的偏好规则非常明确优先使用已存在的 seam而不是新建取能取到的最高层 seam理想情况下整个变更只需要一个seam。为什么缝的讨论值得认真对待因为这些确认过的 seams 会一路往下游传导tdd 只会在预先商定的 seams 上工作——其 SKILL.md 明确写道A seam is the public boundary you test at: the interface where you observe behavior without reaching inside. Tests live at seams, never against internals.seam 是你测试所在的公共边界测试永远站在 seams 上而不是内部实现上并进一步要求 Test only at pre-agreed seamscode-review 会对照 spec 审查 diff——一个没人同意的 seam 会作为 review 发现被暴露出来。这种绑定是间接的它经由 spec 这份文档发生作用。所以把 seam 讨论放在这里认真对待而不是推迟到实现阶段正是本技能的设计意图——在实现里临时决定测试边界等于绕过协商直接制造审查问题。实战流程SKILL.md 中的三步走从 skills/engineering/to-spec/SKILL.md 的 Process 章节可以看到完整的执行流程第 1 步探索仓库建立词汇。如果还没探索过代码库先了解当前状态。整个 spec 必须使用项目的领域术语表domain glossary定义见 CONTEXT.md词汇并尊重你触及区域内的任何 ADR。第 2 步勾勒测试 seams。按上文规则草拟测试缝并与用户确认是否与预期一致。如果必须新建 seam也要尽量在最高点提出。第 3 步按模板写 spec发布到追踪器打上ready-for-agent标签。模板全文如下是规格文档的骨架## Problem Statement The problem that the user is facing, from the users perspective. ## Solution The solution to the problem, from the users perspective. ## User Stories A LONG, numbered list of user stories. Each user story should be in the format of: 1. As an actor, I want a feature, so that benefit This list of user stories should be extremely extensive and cover all aspects of the feature. ## Implementation Decisions A list of implementation decisions that were made. This can include: - The modules that will be built/modified - The interfaces of those modules that will be modified - Technical clarifications from the developer - Architectural decisions - Schema changes - API contracts - Specific interactions Do NOT include specific file paths or code snippets. They may end up being outdated very quickly. Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it within the relevant decision and note briefly that it came from a prototype. Trim to the decision-rich parts, not a working demo, just the important bits. ## Testing Decisions A list of testing decisions that were made. Include: - A description of what makes a good test (only test external behavior, not implementation details) - Which modules will be tested - Prior art for the tests (i.e. similar types of tests in the codebase) ## Out of Scope A description of the things that are out of scope for this spec. ## Further Notes Any further notes about the feature.模板中值得注意的工程纪律User Stories 必须极其详尽覆盖特性的所有方面且每条采用标准格式 As anactor, I want afeature, so thatbenefit例如模板内置的示例As a mobile bank customer, I want to see balance on my accounts, so that I can make better informed decisions about my spendingImplementation Decisions 明确禁止包含具体文件路径或代码片段——理由写得很直白They may end up being outdated very quickly它们很快会过时。唯一的例外是 prototype 产出的、比散文更精确地编码了决策的片段状态机、reducer、schema、类型形状且要裁剪到决策密集的部分并注明其来源是原型Testing Decisions 要求给出先例prior art——即代码库中同类型的既有测试这让后续实现有章可循。常见问题FAQ逐条拆解原文档用一问一答的形式回答了实践中最常遇到的九个问题这里逐条保留并补充上下文1./to-prd去哪里了它就是这个技能在 v1.1 中改名而来。Spec 现在是唯一的贯穿性术语旧的to-prdslug 已经废弃。这一改名的仓库证据在 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. 为什么 spec 要打ready-for-agent标签我不想让 Agent 照着它实现。这个标签的含义是无需进一步 triage文档已经完整到 Agent 可以据此开工。它是输入标记不是工作指令。但如果你运行轮询ready-for-agent的 AFK Agent这个区别对它们不可见——它们会试图一口气构建整个 spec而不是拾取 ticket 切片。这是该技能被报告最多的粗糙边缘。在它改变之前要么在 AFK Agent 的提示词中显式排除父级 spec要么在/to-tickets跑完后剥掉该标签。3. 为什么不直接从 grilling 到/to-tickets跳过 spec通常你就应该这么做spec 只在多会话工作上才挣得它这一步。它值得付出的原因是tickets 是一次性的spec 不是。每个 ticket 按一个全新上下文窗口的容量切分用完即删或即关而 spec 作为承载它们背后推理的唯一场所长期留存。在单会话变更上这买不到任何东西反而多付了一次可能让模型漂移drift的综合步骤。此时正确路径是 grilling →/implementimplement 的技能流程基于 spec 或 tickets 实现用/tdd在预定 seams 上开发结束时用/code-review审查。4. 我刚完成一张 wayfinder 地图该喂什么进去主地图 issue/to-spec #map_issue而不是那些零散的决策 tickets。wayfinder 产出的是决策而非交付物散落在一张地图上to-spec是把它们折叠成一份可构建文档的那一步。把地图直接灌进/implement会丢掉这个折叠过程。5. spec 是给我看的还是只给 Agent 看的主要是给 Agent 看的读起来也是这样完整、密集、引用重。值得你亲自过目的只有两块——seams和out-of-scope 部分——因为这是错误决策最便宜被抓住、也最贵在后期被发现的唯二位置。从头到尾通读全文确实是人们的真实抱怨而且没有摘要模式。诚实的回答是如果 spec 让你感到意外那是 grilling 太浅了而不是 spec 太长。6. tickets 开工后spec 是保持冻结还是让 Agent 改写没有任何机制保持它同步所以实际上它是你当时所知的快照在实现教会你第一件事时就开始过时。工作交付后就把它当一次性物品。真正该活下来的产物是你的CONTEXT.md和 ADR实现中学到的东西若值得留存应写入那里而不是写进一份被编辑过的 spec。7. 我的工作是一次重构或模块边界不是功能模板合适吗不太合适这是已知局限。模板高度依赖 user stories这对架构类工作是错误形状你会围绕本质上是接口与不变量的决策写出没人要的故事。请倚重 implementation-decisions 和 testing-decisions 两个小节并让那些持久的架构决策通过grill-with-docs落成 ADR而不是硬塞进 spec。8. 它会检查追踪器里相关的既有工作或引用它尊重的 ADR 吗两个都不会。它会读取并尊重所触及区域内的 ADR但不会链接它们起草前也不会搜索追踪器里重叠的 issue所以 spec 可能悄悄重复别人已提交的工作。如果该区域很活跃请自己先搜索追踪器。9./to-tickets读不了我的 spec它一直在截断。非常大的 spec 会超出追踪器 issue 能干净回读的容量而且没有本地副本可兜底。修复办法是上下文卫生不要在/to-spec和/to-tickets之间执行 clearing 或 compaction。在同一个窗口里连着跑spec 就根本不需要被重新拉取。衡量标准什么算跑对了原文档给出了一份验收清单任何一次/to-spec都应当满足它开始动笔写而不是再向你抛出一轮新问题它在动笔前把 seams 摆到你面前并尽可能少地提议它用的是你项目的名词而不是泛化的产品管理套话其中的每个决策都是你记得自己做过决定的——没有任何内容是为了填满某个小节而编造的out-of-scope 小节里有真实内容——你拒绝过的东西通常是整页里最有用的几行。它在整条构建链中的位置to-spec是主构建链上的一步而且只在多会话分支上grill-with-docs → to-spec → to-tickets → implement → code-review上游邻居grill-with-docs 负责本技能只记录不参与的决策环节wayfinder 完成的整张地图正是在这里并入链条。下游邻居to-tickets 把 spec 切成曳光弹式tracer-bullet的垂直切片 tickets供 implement 构建——每个切片都声明自己的阻塞边blocking edges在真实追踪器上用原生阻塞关系表达在本地.scratch/约定下则写进每个票的Blocked by行。最终校验code-review 沿两条轴审查变更——Standards是否符合本仓库的编码标准与 Spec是否忠实实现发起它的 issue/spec并会按docs/、specs/、.scratch/的顺序查找原始 spec。不确定用哪个技能或流程时ask-matt 负责路由。一句话总结to-spec是决定已完成、但上下文即将清零那一刻的归档动作——它把会消失的对话变成一份在追踪器上永不消失、供后续多个会话接力构建的决策记录。对于任何横跨多个 Agent 会话的构建任务先/to-spec再/to-tickets是这套技能给出的标准答案。【免费下载链接】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/skillsto-spec是 Matt Pocock Skills 工程技能套件中的一环它在你不打断思路的前提下把刚刚结束的那场 Agent 会话直接合成一份规格文档spec并作为单条 issue 发布到项目的问题追踪器上。本指南将完整拆解该技能的设计动机、执行流程、规格模板与常见陷阱结合仓库内 SKILL.md 与配套技能的源码实现帮助你在多会话构建、wayfinder 地图合并等真实场景中正确地使用它。它做什么记录决策而不是制造决策to-spec的核心行为只有一句话把你刚刚经历的对话变成一份 spec并作为单条 issue 发布到问题追踪器。关键在第二句话它不会采访你。当你伸手调用它时决定早已做完所以它的职责是从现有材料里做综合——对话线程、代码库现状、项目的 CONTEXT.md 以及 ADR架构决策记录——而不是重新开启一轮提问。spec 是已经做出的决策的记录不是做出新决策的场所。这一点在技能实现层面被反复强调。打开 skills/engineering/to-spec/SKILL.md 可以看到技能的description字段明确写着Turn the current conversation into a spec and publish it to the project issue tracker: no interview, just synthesis of what youve already discussed.正文第一行也同样是硬性约束Do NOT interview the user; just synthesize what you already know.不要采访用户只综合你已经知道的东西。而 agents/openai.yaml 中的allow_implicit_invocation: false与 SKILL.md 头部的disable-model-invocation: true共同表明该技能只能由用户显式调用Agent 永远不会自己伸手去拿它。何时使用多会话工作的唯一触发条件to-spec通过输入/to-spec触发Agent 不会主动调用它。它的全部触发场景只有一个构建规模超过单个 Agent 会话session能承载的范围必须拆成多个会话才能完成。原文档给出了一张决策表你处于什么状态应该运行什么什么都还没决定先跑grill-with-docsSKILL.md已决定且工作量能放进一个上下文窗口context window直接implement跳过 spec已决定且工作要横跨多个会话/to-spec然后to-tickets一张 wayfinder 地图已经梳理完毕/to-spec #map_issue注意最后一行wayfinder 地图完成时/to-spec接受地图 issue 的编号作为参数把散落在整张地图上的决策折叠成一份可构建的文档。前置条件追踪器与 triage 标签词汇to-spec会把 spec 发布为一条 issue因此仓库必须已经配置好问题追踪器和 triage 标签词汇——这一步由 setup-matt-pocock-skills 完成每次首次使用其他工程技能前运行一次。支持两类追踪器任选其一真实追踪器如 GitHub走ghCLI、GitLab走glabCLI或其他自述工作流本地 Markdownissue 以.scratch/下的 markdown 文件形式存在开箱即用无需任何外部服务。本地 Markdown 追踪器的约定在 issue-tracker-local.md 中有完整定义每个特性一个目录.scratch/feature-slug/spec 固定落在.scratch/feature-slug/spec.md实现 issue 则是issues/NN-slug.md一票一文件从01编号triage 状态通过文件顶部的Status:行记录。如果追踪器与标签词汇尚未配置SKILL.md 明确指示 AgentIf not, tell the user to run/setup-matt-pocock-skills——也就是说前置缺失时它不会自行猜测而是引导你先完成配置。ready-for-agent标签正是 setup-matt-pocock-skills 配置的五种规范 triage 角色之一needs-triage、needs-info、ready-for-agent、ready-for-human、wontfixto-spec发布 spec 后会自动打上它。spec 的本质一份决策记录decision recordspec 之所以存在是因为上下文窗口终会结束。你在 grilling 阶段敲定的一切——解决方案的形状、反复论证过的取舍、你刻意拒绝的东西——全部集中在一场即将被清空clearing/compaction的对话里。spec 就是这场对话的幸存者。因此它有两条边界它不验证任何东西也不决定任何东西它只是用你自己项目的词汇表记录已经决定过什么让一个全新的会话无需你重新解释就能接手工作。任何 spec 中断言的、但你从未真正说过的东西都是缺陷defect。这正是它区别于一般需求文档的地方它是对已发生决策的事后综合而不是面向未来的需求征集。Seams before prose先谈测试缝再写正文to-spec在写下第一个字之前会先勾勒出该特性将在哪些 seam测试缝上被测试并与你确认。它的偏好规则非常明确优先使用已存在的 seam而不是新建取能取到的最高层 seam理想情况下整个变更只需要一个seam。为什么缝的讨论值得认真对待因为这些确认过的 seams 会一路往下游传导tdd 只会在预先商定的 seams 上工作——其 SKILL.md 明确写道A seam is the public boundary you test at: the interface where you observe behavior without reaching inside. Tests live at seams, never against internals.seam 是你测试所在的公共边界测试永远站在 seams 上而不是内部实现上并进一步要求 Test only at pre-agreed seamscode-review 会对照 spec 审查 diff——一个没人同意的 seam 会作为 review 发现被暴露出来。这种绑定是间接的它经由 spec 这份文档发生作用。所以把 seam 讨论放在这里认真对待而不是推迟到实现阶段正是本技能的设计意图——在实现里临时决定测试边界等于绕过协商直接制造审查问题。实战流程SKILL.md 中的三步走从 skills/engineering/to-spec/SKILL.md 的 Process 章节可以看到完整的执行流程第 1 步探索仓库建立词汇。如果还没探索过代码库先了解当前状态。整个 spec 必须使用项目的领域术语表domain glossary定义见 CONTEXT.md词汇并尊重你触及区域内的任何 ADR。第 2 步勾勒测试 seams。按上文规则草拟测试缝并与用户确认是否与预期一致。如果必须新建 seam也要尽量在最高点提出。第 3 步按模板写 spec发布到追踪器打上ready-for-agent标签。模板全文如下是规格文档的骨架## Problem Statement The problem that the user is facing, from the users perspective. ## Solution The solution to the problem, from the users perspective. ## User Stories A LONG, numbered list of user stories. Each user story should be in the format of: 1. As an actor, I want a feature, so that benefit This list of user stories should be extremely extensive and cover all aspects of the feature. ## Implementation Decisions A list of implementation decisions that were made. This can include: - The modules that will be built/modified - The interfaces of those modules that will be modified - Technical clarifications from the developer - Architectural decisions - Schema changes - API contracts - Specific interactions Do NOT include specific file paths or code snippets. They may end up being outdated very quickly. Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it within the relevant decision and note briefly that it came from a prototype. Trim to the decision-rich parts, not a working demo, just the important bits. ## Testing Decisions A list of testing decisions that were made. Include: - A description of what makes a good test (only test external behavior, not implementation details) - Which modules will be tested - Prior art for the tests (i.e. similar types of tests in the codebase) ## Out of Scope A description of the things that are out of scope for this spec. ## Further Notes Any further notes about the feature.模板中值得注意的工程纪律User Stories 必须极其详尽覆盖特性的所有方面且每条采用标准格式 As anactor, I want afeature, so thatbenefit例如模板内置的示例As a mobile bank customer, I want to see balance on my accounts, so that I can make better informed decisions about my spendingImplementation Decisions 明确禁止包含具体文件路径或代码片段——理由写得很直白They may end up being outdated very quickly它们很快会过时。唯一的例外是 prototype 产出的、比散文更精确地编码了决策的片段状态机、reducer、schema、类型形状且要裁剪到决策密集的部分并注明其来源是原型Testing Decisions 要求给出先例prior art——即代码库中同类型的既有测试这让后续实现有章可循。常见问题FAQ逐条拆解原文档用一问一答的形式回答了实践中最常遇到的九个问题这里逐条保留并补充上下文1./to-prd去哪里了它就是这个技能在 v1.1 中改名而来。Spec 现在是唯一的贯穿性术语旧的to-prdslug 已经废弃。这一改名的仓库证据在 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. 为什么 spec 要打ready-for-agent标签我不想让 Agent 照着它实现。这个标签的含义是无需进一步 triage文档已经完整到 Agent 可以据此开工。它是输入标记不是工作指令。但如果你运行轮询ready-for-agent的 AFK Agent这个区别对它们不可见——它们会试图一口气构建整个 spec而不是拾取 ticket 切片。这是该技能被报告最多的粗糙边缘。在它改变之前要么在 AFK Agent 的提示词中显式排除父级 spec要么在/to-tickets跑完后剥掉该标签。3. 为什么不直接从 grilling 到/to-tickets跳过 spec通常你就应该这么做spec 只在多会话工作上才挣得它这一步。它值得付出的原因是tickets 是一次性的spec 不是。每个 ticket 按一个全新上下文窗口的容量切分用完即删或即关而 spec 作为承载它们背后推理的唯一场所长期留存。在单会话变更上这买不到任何东西反而多付了一次可能让模型漂移drift的综合步骤。此时正确路径是 grilling →/implementimplement 的技能流程基于 spec 或 tickets 实现用/tdd在预定 seams 上开发结束时用/code-review审查。4. 我刚完成一张 wayfinder 地图该喂什么进去主地图 issue/to-spec #map_issue而不是那些零散的决策 tickets。wayfinder 产出的是决策而非交付物散落在一张地图上to-spec是把它们折叠成一份可构建文档的那一步。把地图直接灌进/implement会丢掉这个折叠过程。5. spec 是给我看的还是只给 Agent 看的主要是给 Agent 看的读起来也是这样完整、密集、引用重。值得你亲自过目的只有两块——seams和out-of-scope 部分——因为这是错误决策最便宜被抓住、也最贵在后期被发现的唯二位置。从头到尾通读全文确实是人们的真实抱怨而且没有摘要模式。诚实的回答是如果 spec 让你感到意外那是 grilling 太浅了而不是 spec 太长。6. tickets 开工后spec 是保持冻结还是让 Agent 改写没有任何机制保持它同步所以实际上它是你当时所知的快照在实现教会你第一件事时就开始过时。工作交付后就把它当一次性物品。真正该活下来的产物是你的CONTEXT.md和 ADR实现中学到的东西若值得留存应写入那里而不是写进一份被编辑过的 spec。7. 我的工作是一次重构或模块边界不是功能模板合适吗不太合适这是已知局限。模板高度依赖 user stories这对架构类工作是错误形状你会围绕本质上是接口与不变量的决策写出没人要的故事。请倚重 implementation-decisions 和 testing-decisions 两个小节并让那些持久的架构决策通过grill-with-docs落成 ADR而不是硬塞进 spec。8. 它会检查追踪器里相关的既有工作或引用它尊重的 ADR 吗两个都不会。它会读取并尊重所触及区域内的 ADR但不会链接它们起草前也不会搜索追踪器里重叠的 issue所以 spec 可能悄悄重复别人已提交的工作。如果该区域很活跃请自己先搜索追踪器。9./to-tickets读不了我的 spec它一直在截断。非常大的 spec 会超出追踪器 issue 能干净回读的容量而且没有本地副本可兜底。修复办法是上下文卫生不要在/to-spec和/to-tickets之间执行 clearing 或 compaction。在同一个窗口里连着跑spec 就根本不需要被重新拉取。衡量标准什么算跑对了原文档给出了一份验收清单任何一次/to-spec都应当满足它开始动笔写而不是再向你抛出一轮新问题它在动笔前把 seams 摆到你面前并尽可能少地提议它用的是你项目的名词而不是泛化的产品管理套话其中的每个决策都是你记得自己做过决定的——没有任何内容是为了填满某个小节而编造的out-of-scope 小节里有真实内容——你拒绝过的东西通常是整页里最有用的几行。它在整条构建链中的位置to-spec是主构建链上的一步而且只在多会话分支上grill-with-docs → to-spec → to-tickets → implement → code-review上游邻居grill-with-docs 负责本技能只记录不参与的决策环节wayfinder 完成的整张地图正是在这里并入链条。下游邻居to-tickets 把 spec 切成曳光弹式tracer-bullet的垂直切片 tickets供 implement 构建——每个切片都声明自己的阻塞边blocking edges在真实追踪器上用原生阻塞关系表达在本地.scratch/约定下则写进每个票的Blocked by行。最终校验code-review 沿两条轴审查变更——Standards是否符合本仓库的编码标准与 Spec是否忠实实现发起它的 issue/spec并会按docs/、specs/、.scratch/的顺序查找原始 spec。不确定用哪个技能或流程时ask-matt 负责路由。一句话总结to-spec是决定已完成、但上下文即将清零那一刻的归档动作——它把会消失的对话变成一份在追踪器上永不消失、供后续多个会话接力构建的决策记录。对于任何横跨多个 Agent 会话的构建任务先/to-spec再/to-tickets是这套技能给出的标准答案。【免费下载链接】skillsSkills for Real Engineers. Straight from my .agents directory.项目地址: https://gitcode.com/GitHub_Trending/skills13/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考