如何用 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.md：CONTEXT.md与 ADR 的布局与读取规则；docs/agents/triage-labels.md：仅当安装了triage技能时才写；- 在
CLAUDE.md或AGENTS.md（编辑已存在的那个）里加一个## Agent skills块。
两类 tracker 都能支撑主流程：真实的 tracker（GitHub、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可以直接用； - 真实 tracker（GitHub、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 取 diff：
git 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 丢线。
判断标准与已知边界
按文档给的信号核对整条链路是否在正常工作：
- grilling：
CONTEXT.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），仅供参考
