如何用 skills 的主流程 /grill-with-docs → /to-spec → /to-tickets → /implement → /code-review 完成多会话构建【免费下载链接】skillsSkills for Real Engineers. Straight from my .agents directory.项目地址: https://gitcode.com/GitHub_Trending/skills13/skills当你有一个想法大到没法在单个会话里做完、必须拆成几个会话才能落地时skills 仓库给了一条固定的主流程/grill-with-docs → /to-spec → /to-tickets → /implement → /code-review。本文假设你正处在一个真实的工作目录一个 git 仓库里目标是把一个想法磨成共识、凝固成 spec、切成可独立交付的工单然后逐张工单在一个个全新会话里实现最后用双轴审查收尾。整条链路是多会话的前三个步骤要在同一个不间断的上下文窗口里完成而每个/implement都从一张全新上下文开始。准备条件先配置 tracker再守住上下文窗口to-spec和to-tickets都要往 issue tracker 里发布所以第一次跑主流程前先运行一次/setup-matt-pocock-skills。它会探索当前仓库并写出后续技能依赖的配置docs/agents/issue-tracker.md记录工单落在哪里。可选 GitHub走ghCLI、GitLab走glabCLI、本地 markdown落在.scratch/下、或其他你描述的自定义流程docs/agents/domain.mdCONTEXT.md与 ADR 的布局与读取规则docs/agents/triage-labels.md仅当安装了triage技能时才写在CLAUDE.md或AGENTS.md编辑已存在的那个里加一个## Agent skills块。两类 tracker 都能支撑主流程真实的 trackerGitHub、Linear 等或本地 markdown 文件。如果这套配置还没做to-spec/to-tickets会直接提示你先跑/setup-matt-pocock-skills。多会话能否成立关键在上下文窗口把 grilling、spec、tickets 这三步留在同一个不间断的窗口里在/to-tickets完成之前不要/clear或/compact。每个/implement随后各自从零开始。这个窗口的上限是文档里说的 smart zone在 state-of-the-art 模型上约 150k tokens如果某个会话在到/to-tickets之前逼近它就/compact到最近的阶段边界再继续不要在退化状态硬推。第 1 步 /grill-with-docs把想法磨成共识通过输入/grill-with-docs来调用它。它是 stateful 的agent 不会自己去够技能标了disable-model-invocation: true所以要你自己敲。它是在仓库里改东西、且改动能在一个会话里收敛时的入口如果压根没有工作目录改用/grill-me跑同样的访谈但不落任何文件。它会围绕你的计划或设计反复追问直到你和 agent 对这件事有同一个理解并把这套理解一路写进仓库一个被敲定的术语落地到根目录的CONTEXT.md若根目录有CONTEXT-MAP.md标记为多上下文则落到相应 context 的CONTEXT.md而且是一解决就立刻写入不是最后一次性补一个难以回退、没上下文会惊讶、且是真实权衡的决策作为 ADR 落到docs/adr/其余所有决定只留在对话里不落到文件。CONTEXT.md是刻意保持纯词汇表的不写实现细节、不写 spec、不写草稿笔记。ADR 需要三道门同时满足所以大多数决策不合格、多数会话产不出 ADR——一次只得到更清晰词汇表、零 ADR 的会话是符合设计的工作状态。判断它正常工作CONTEXT.md是在会话过程中逐条变动的而不是一口气冒出来词汇表读起来是纯词汇代码库能回答的问题被读代码回答掉、而不是问你你得到的 ADR 很少或没有。它结束时把这段同一个对话交给/to-spec而不是/clear掉。你们谈定的大部分东西都在这个上下文窗口里而/to-spec合成的正是它。第 2 步 /to-spec把对话凝固成 spec在跑 grilling 的同一个窗口里输入/to-spec。它不访谈你——它综合你已经知道的东西对话、代码库、你的CONTEXT.md与 ADR把结论发布成 tracker 上的一个 issue。spec 是一份已经做出的决定的记录不是新做决定的地方。动笔之前它先勾勒这个功能要测试的seams你观察行为的公开边界并和你确认。它优先选已经存在的 seam、取能取的最高 seam理想数量是整处改动只有一个。这些谈定的 seam 会一路向下游传递/implement在 seam 上驱动/tdd/code-review对照 spec 审 diff所以一个没人谈定的 seam 会以 review finding 的形式冒出来。spec 模板包含这些章节Problem Statement、Solution、User Stories、Implementation Decisions、Testing Decisions、Out of Scope、Further Notes。它不写具体文件路径和代码片段它们很快就会过时唯一例外是某个 prototype 产出的、比文字更能精确表达某个决定的片段状态机、reducer、schema、类型形状。发布时它会打ready-for-agent标签。务必和/to-tickets保持在同一个窗口里很大的 spec 可能超出 tracker issue 能干净返回的量而在同一个不间断窗口里跑这两步spec 就完全不用被重新拉取。第 3 步 /to-tickets把 spec 切成 tracer-bullet 工单输入/to-tickets或指定 spec issue 时输入/to-tickets #spec_issue。它把 spec 拆成一组tracer-bullet工单每张是一张穿透所有层schema、API、UI、tests的窄而完整的垂直切片落地那一刻就能单独演示并把每张工单的尺寸压进一个全新上下文窗口——因为接起工单的那个会话从没读过你的 spec。每张工单都声明它的blocking edges在它开始之前必须先完成的其他工单。没有阻塞项的工单可以立刻开始。任何工单落库之前它先拿编号列表标题、Blocked by、它交付什么来问你一轮粒度对不对、blocking edges 是不是真实的前置、有没有该合并或再拆的。没得到你批准之前什么都不会到 tracker。工单落在哪里取决于你配置的 tracker本地 markdown每张工单一个文件在.scratch/feature-slug/issues/NN-slug.md从01起按依赖顺序阻塞项在前编号。NN前缀是真实工单 ID所以/implement 03可以直接用真实 trackerGitHub、Linear 等按依赖顺序阻塞项在前每工单一个 issue若 tracker 有原生的 blocking / sub-issue 关系就用它否则把Blocked by指向阻塞的 issue。frontier是那些阻塞项全部完成的工单集合。对纯线性链就是从顶到底逐张做。第 4 步 /implement每张工单一个全新会话现在离开规划窗口。按 frontier 推进——线性链就是从顶到底。节奏是清上下文、实现一张工单、提交、再清。每张工单自包含这正是上一张工单上下文可以被丢弃的原因。输入/implement #42本地工单则/implement 03。传完整引用——issue URL 或owner/repo#2并让它先把标题复述给你确认#2是按 agent 能看到的任何编号列表解析的在全新会话里那可能是一份 todo 文件而不是你配置的 tracker。一次运行是五拍按顺序读工单或 spec定出 seams。在事先谈定的 seam 上驱动/tdd一次一个红绿切片。经常做类型检查边做边跑单个测试文件。最后整套件跑一次。跑/code-review然后提交到当前分支。它提交到你所在的那个分支——不新建分支、也不问。开始前先确认你在想要它落地的分支上。它也不关闭工单、不勾选验收标准无论是 GitHub 还是本地 markdown所以工单状态由你来更新。在依赖链上这很关键to-tickets把 frontier 定义为阻塞项全部关闭的工单如果没人去关就永远不会有任何工单在视觉上变成可领取。第 5 步 /code-review双轴审查你可以让/implement跑审查也可以自己在全新会话里跑/code-review——后者更诚实因为刚写完这段 diff 的 agent 持有塑造它的全部假设让同一会话审自己等于确认偏误。无论哪种都要给一个fixed point一个 commit SHA、分支名、tag、main、HEAD~5。你不给它会问而不是猜。它相对 merge-base 取 diffgit diff fixed-point...HEAD git log fixed-point..HEAD --oneline其中fixed-point就是你从它拉出的那个点。在派生任何子 agent 之前它先确认 ref 能解析、diff 非空git rev-parse fixed-point因为三点 diff 从 merge-base 起量、排除暂存与工作区改动所以要在一个中间提交之后审——先提交、再对着你拉出的那个点审。两个轴并行跑在各自的子 agent 里互不看到对方推理Standards代码是否遵循本仓库成文的编码标准仓库没成文时再叠加一组固定的 Fowler 代码坏味道基线Spec代码是否忠实实现了那个源 issue 或 spec。报告分## Standards和## Spec两块呈现结尾用一行给出每轴最严重的问题并拒绝跨轴挑一个赢家——因为一个改动可以过一轴而挂另一轴完全遵循约定却做错了东西Standards 过、Spec 挂恰好做了 issue 要的却破坏了项目约定则反过来。上下文卫生多会话为什么能成立整条流程能跑通靠的是你在哪里切上下文。阶段一个会话里的一块工作grilling、实现、QA与阶段之间的边界是这个上下文怎么处置这个判断唯一该出现的地方阶段中间没有判断只有继续或把剩下的拆成子 agent。边界上按顺序看五个选项第一个 yes 胜出Continue下一阶段要把这一段当一手来源逐字用或你还有 smart zone 余量。这是唯一让会话保持一手来源的选项先排除它。/clear身后一切都可丢弃最便宜的选项但判断错了是单向的清了相关上下文就丢掉了你为什么这么建的理由。/handoff有东西要搬——换 harness、换目录、交给同事、或阶段中途分叉一个旁支任务。它买的是可搬运性。Subagent任务范围紧到可以离开键盘跑。/compact以上都不满足时的默认项且它常常落在这里。不要在阶段中间 compact——那会让 agent 丢线。判断标准与已知边界按文档给的信号核对整条链路是否在正常工作grillingCONTEXT.md在会话中逐条变动词汇表是纯词汇to-spec它开始写而不是新开一轮提问先拿 seams 给你且尽量少且用你项目自己的名词to-tickets每张工单对做完能演示什么都有答案且答案是行为而非某一层列表编号回给你、每张有 Blocked by最上面那张无阻塞可立刻开始implement会话以读工单并复述要建什么开头、trace 里能看到真实的/tdd调用、类型检查和单测反复跑、跑完到达当前分支的一个提交、diff 正好是一张工单的分量code-review面对坏 ref 或空 diff 在派生子 agent 前就拒启报告是## Standards/## Spec两块、结尾给每轴最差且不挑总赢家每条 finding 都带引用规则或坏味道加 hunk或 spec 的某一行。边界与已知限制/implement不会关工单也不会勾验收标准工单状态由你更新/code-review只审已提交的 diff需要你先给 fixed point 并先提交它的两个子 agent 未被禁止再调用/code-review无人值守跑时可能派生更多 agent文档里记录的已知问题需盯住 agent 数量。to-tickets止于工件没有自动派发模式——派发是手动的看板、数无未决阻塞的工单、开对应数量的会话每张工单一个全新上下文、中间清空。真正应该比 spec 活得久的是CONTEXT.md和你的 ADRs实现过程中学到、值得留下来的东西属于那里而不是回去改那份会随实现逐渐过时的 spec。想确认当前处境该走哪条路、该在哪里 clear 或 compact可以看仓库里的路由 ask-matt 与 阶段边界各步细节见 grill-with-docs、to-spec、to-tickets、implement、code-review 各自的SKILL.md。【免费下载链接】skillsSkills for Real Engineers. Straight from my .agents directory.项目地址: https://gitcode.com/GitHub_Trending/skills13/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考