GITHUB · TT-A1I
matt-skills-
with-to-goal
一套面向 AI coding agent 的工程技能包，把「模糊想法」推进到「可验证交付」
github.com/tt-a1i/matt-skills-with-to-goal ↗matt-skills-
怕丢上下文，所以一直不太敢开新线程
CURRENT THREAD
这里的上下文最完整
为什么要做、讨论过哪些方案、哪些决定已经达成共识，它全都知道。
NEW THREAD
新线程怕交代不全
万一漏了一个约束，或者没带上某个关联问题，后面的实现可能就跑偏。
于是，聊方案和实施方案都留在同一个上下文里。
十几%
一次长线程压缩后
剩余空闲上下文
剩余空闲上下文
后半程，模型越来越像在背着行李跑步
01可用上下文越来越少，频繁触发压缩
02每次压缩都要等，任务节奏被打断
03上下文太长，实际执行也明显变慢
04主线程被大量代码细节占满，越来越不聚焦
把“聊清楚”和“写代码”拆给两类线程
需求 / 规划线程
负责和用户达成共识
- 用 Grill 问答把需求聊透
- 沉淀 spec、方案和关键决定
- 拆分任务，维护整体进展
- 接收各执行线程的结果
长期保留，但尽量不亲自写大量代码
Goal 执行线程
一次只负责一个切片
- 读取当前 goal 和指定文件
- 直接实施，不重新访谈
- 逐项验证完成标准
- 完成后把结果交回主线程
上下文短、任务窄，做完即可结束
前面负责想清楚，后面负责做完，最后把结果带回来
聊需求，达成共识
追问模糊点，明确什么做、什么不做
把共识沉淀成文档
避免关键决定只留在聊天记录里
拆分并同步 GitLab Issue
每个 ticket 有范围、依赖和验收标准
编译当前执行契约
选 frontier ticket，带上现状、Done 和约束
新线程实施 Goal
写代码、逐项验证，完成后把结果带回主线程
执行结果复制回需求 / 规划线程
先做一次仓库设置，再进入日常主流程
一次性准备
/setup-matt-pocock-skills
/grill-me
把模糊点问清楚
产物：明确的产品与技术决定
/to-spec
把当前共识写成 spec
产物：agent-ready 需求文档
/to-tickets
按依赖拆成可执行切片
产物：GitLab issues 与 blocking 关系
/to-goal
选当前 ticket，编译执行契约
产物：可复制、可验证的 goal
FRESH SESSION
直接执行 goal，不重新访谈
产物：实现与逐项验证结果
/handoff
把当前上下文压成可续接的交接文档
产物：关键现状、材料路径与 suggested skills
不是把整段聊天搬过去
只把执行需要的事实编进 goal
顺便按切片推荐模型档位：搜索和机械改用轻量档，日常实现用标准档，安全、迁移、并发等高风险任务再升级。
Goal
这个线程只交付哪个结果
Current state
分支、HEAD、已完成和已知缺口
Completion criteria
Agent 能逐项判断 done / not done
Constraints
不做什么、不能碰什么、是否可提交
需求线程终于能一直聚焦在任务本身
01不用装进大量写代码产生的中间上下文
02每个执行线程短一些，压缩少，启动也更直接
03任务切片后可以按风险选模型，成本更可控
04结果回到规划线程，整体进展没有丢
github.com/tt-a1i/archify ↗
把自然语言变成可分享的架构与流程图
描述系统或流程，Agent 在聊天里生成可以直接放进文档、评审和分享中的技术图
VIEWS架构、工作流、时序、数据流、生命周期
OUTPUT自包含 HTML、深浅主题、PNG / JPEG / WebP / SVG
QUALITYTyped JSON IR → Validate → Render → Check
npx skills add tt-a1i/archify -g
难问题先在 Chat 里想透
再回到 Codex 落地
新入口把深度讨论和代码执行接到了一起，但项目上下文仍然需要主动带过去
/HANDOFF把问题、已确认方案和相关材料压成 handoff 文件，上传给 Chat
PRO / 5.6用 Chat 里的 Pro 模型分析高难问题、推演方案和挑战关键假设
ADD TO TASK把讨论结论“添加到任务”，回到 Codex 继续读代码、修改和验证
Chat 不占用 Work / Codex 这组 agentic usage · 官方说明 ↗
按任务选
不要默认“最强”
模型解决“能不能先看对”，档次解决“愿意多查、多试、多复核多久”。
只想记一个默认值
Terra · Medium
明确、短、可验收
改名、格式化、已知文件小修、批量转换
LUNA
HIGH
HIGH
常规实现、跨文件
已有范式的新功能、普通 bug、日常仓库任务
TERRA
MEDIUM
MEDIUM
上下文长、约束分散
长会话、大仓库、多处定义和历史约束
TERRA
HIGH
HIGH
模糊、疑难、高风险
陌生仓库、根因不明、安全、支付、迁移
SOL
MEDIUM / HIGH
MEDIUM / HIGH
多条任务能独立推进
代码、测试、资料、风险可以分别完成
TERRA / SOL
ULTRA
ULTRA
真实编码任务里，能力只差 6 个百分点
成本却差到 2.8 倍
67% → 73%不是“便宜模型不能用”，而是要把贵模型留给返工更贵的任务
LUNA
67%Pass@1
$3.03平均单题成本
任务边界清楚、测试能兜底时，先省单价更划算。
TERRA
70%Pass@1
$4.95平均单题成本
能力和成本都居中，适合作为不用反复判断的日常默认。
SOL
73%Pass@1
$8.39平均单题成本
需求模糊或失败代价高时，多花的钱是在买更低的返工风险。
边界：DeepSWE 只有 113 题，三款置信区间重叠。它能说明成本与能力的取舍，不能证明每个仓库都严格按 67 / 70 / 73 排名。
便宜适合短任务
不代表适合超长上下文
OpenAI 官方 Long context 评测（分数越高越好）
EVAL
SOL
TERRA
LUNA
MRCR 256K–512K
91.5
89.6
41.3
MRCR 512K–1M
73.8
72.5
41.3
GraphWalks 1M
77.1
71.2
51.2
看它是“没做完”
还是“一开始就看错”
建议起步：Luna High · Terra Medium · Sol Medium
方向对，但搜索、测试或边界检查不够
模型已经理解问题，只是没有继续查到底。
同一模型：Medium → High → Max根因、需求边界或权衡从一开始就错
弱模型多想几步，可能只是沿着错误方向走更远。
保持档次：Luna → Terra → Sol代码、测试、资料和风险互不依赖
只有子任务能各自完成，多个代理才会节省墙钟时间。
使用 Ultra；强依赖任务不要开一句话：Max 是让一个代理深挖一个难题；Ultra 是让多个代理并行做几件独立的事。