Appearance
grill-me + Trellis 使用体验分享查看幻灯片：grill-me + Trellis 使用体验分享
先贴两个地址：
这段时间我把 grill-me 和 Trellis 放一起试了几次。我的用法很简单：开工前先让 grill-me 把需求问清楚，开工后再交给 Trellis 承接任务、上下文、检查和规范沉淀。
grill-me 是一个需求拷问 skill。它不会急着给方案，而是围绕目标、边界、验收和风险继续追问。Trellis 是一套 agent 工作流，会在项目里生成 .trellis/，并按不同平台生成 skills、commands、hooks 这些入口。
我现在最直接的体感是：grill-me 让我开工前少猜一点；Trellis 让我开工后少丢一点上下文。
以前直接开干的问题
我以前经常这样发需求：
text
帮我做一个 xxx，顺便优化一下体验。这句话人能懂，但 agent 会补很多假设。它会猜“优化体验”具体指什么，也会猜哪些文件能动、哪些旧行为要保留。任务小的时候影响不大，稍微跨几个文件，就可能写了半天才发现方向偏了。
长任务还有一个麻烦：上下文容易散。需求、取舍、踩坑点都混在聊天里，下次继续时又要重新解释。
grill-me：先把一句话需求问明白
grill-me 最适合放在开工前。它像是在帮我审题：这个需求到底要什么，边界在哪里，什么算做完，哪里最容易返工。
我现在提示词会写得很短：
text
用 grill-me 帮我问清楚这个需求：
<一句话需求>
最后整理成 Trellis task。
先问最关键的问题，每次一个。如果有硬约束，我会补一行：
text
限制：<时间 / 不能改的东西 / 兼容性>它问出来的问题不一定都复杂，但经常正好卡在我没想清楚的地方。
Trellis：我看重的不是命令，而是上下文
Trellis 不只是给一堆命令。它更像把 agent 做事需要的上下文拆到几个固定位置：
| 位置 | 我怎么理解 |
|---|---|
.trellis/tasks/ | 一次任务的工作区，放 PRD、研究、状态和上下文 |
.trellis/spec/ | 给 agent 看的项目规范和踩坑经验 |
.trellis/workflow.md | 开发流程、状态提示、skill 路由 |
| hooks / skills / commands | 不同平台里的触发入口 |
我最近比较喜欢的一点是：Trellis 把很多动作拆成了 skills 和 workflow 里的阶段。比如开始前读规范、继续当前任务、检查质量、把经验写回 spec。你当然仍然要知道自己在做什么，但不需要每轮都手动贴一大段“请先读规范、再看任务状态、最后记得检查”。
hooks：少记一点命令
Trellis 的 How It Works 里讲到，支持 hooks 的平台上，会话启动和每条用户消息都可以注入当前上下文。比如 SessionStart 会加载项目状态，UserPromptSubmit 可以把当前任务状态包装成 <workflow-state>...</workflow-state> 注入当前轮。
要说准确一点：这不是所有平台都完全一样。Codex 里还会涉及 AGENTS.md、features.hooks = true，以及新版本里 /hooks 的审批。没有 hook 的平台，也会走 skills、commands 或 prelude 这类入口。
但对使用者来说，这个方向很舒服：我不用每次都提醒“先看当前任务”“现在是什么阶段”“该读哪些 spec”。这些上下文会尽量从 .trellis/ 和 workflow 里带出来。
workflow：默认流程不是写死的
Trellis 的 .trellis/workflow.md 承担了很多事：Phase、skill routing、每轮的 workflow-state 提示、task.py 命令参考，都在这个文件里。
这就很适合团队慢慢调。比如你觉得规划阶段太重，可以压缩；你想加一个 blocked 状态，可以在 workflow-state 里写；你想让某类任务先走一个测试计划 skill，也可以改 routing 表。
hooks 也可以定制。比如团队可以在开工前自动提醒某些规范，或者在特定阶段补充检查提示。它不是装上以后就只能按官方流程走，更像给你一套默认流程，再让你把它改成自己团队的节奏。
spec：最值得长期用的地方
我最喜欢的是 .trellis/spec/。它不是产品需求文档，更像 agent 的项目记忆。
适合放这些东西：
- 目录边界和模块分工。
- 代码、测试、文档的本地约定。
- 发布路径和构建检查。
- 上次踩过、下次不想再解释的坑。
官方还有 Spec Template Marketplace 的设计：团队可以把可复用的工程规范做成模板，初始化项目时拉一套 .trellis/spec/ 起点。这个点我还没深入用，但思路很适合多仓库团队。
我现在的日常流程
text
一句话想法
-> grill-me 问到能执行
-> 整理成 Trellis task / PRD
-> Trellis 通过 hooks / skills 带出当前状态
-> before-dev 读相关 spec
-> agent 实现
-> check 收尾
-> 有价值的经验写回 .trellis/spec/不是什么任务都要这样走。三分钟能改完的小问题，直接让 agent 做就行。这套组合更适合需求还没完全定型、任务要跨文件、或者你希望后面还能继续的场景。
快速试一下
bash
# grill-me
npx skills add https://github.com/mattpocock/skills --skill grill-me
# Trellis beta
npm install -g @mindfoldhq/trellis@beta
cd your-project
trellis init -u your-name --codex我建议先拿一个中等大小的任务试，不要太小，也不要一上来就是大重构。先让 grill-me 问到你自己觉得“这个需求可以做了”，再让 Trellis 承接后面的任务。
最后补充：如果要接 OpenSpec
这块我还没完整实践过，所以只说我的理解。
| 工具 | 更适合负责 |
|---|---|
| OpenSpec | 团队评审 intent / spec，决定需求要不要做、能力应该长什么样 |
| Trellis | agent 执行层，处理任务状态、上下文、检查和规范沉淀 |
如果要串起来，我会这样放：
text
grill-me 问清楚
-> OpenSpec 做团队评审
-> Trellis 执行任务
-> .trellis/spec/ 沉淀执行经验这里要特别注意一个名字问题：Trellis 的 .trellis/spec/ 和 OpenSpec 的 openspec/specs/ 不是同一种 spec。前者偏项目规范、代码约定和 agent 执行经验；后者偏系统能力、需求意图和 requirement scenarios。Trellis 的 .trellis/tasks/<task>/ 反而更像 OpenSpec 的 openspec/changes/<change>/ 这一层。
但这次我主要实践的是 grill-me + Trellis，OpenSpec 先放在最后当补充。
最后
grill-me 让我在开工前多想几分钟。Trellis 让我在开工后少丢一点上下文。做完以后，.trellis/spec/ 还能把这次学到的东西留给下一次。
这就是我觉得它比较顺的地方。