个人也算是深度测试了一个多月，感觉效果很符合预期，故此分享

改动点

- 任务分流

- 放弃trellis brainstorm，使用 grill-with-doc 来 review spec文档

- 放弃 trellis implement，使用 matt 的 implement

效果：兼顾速度和执行效果

配置方式

使用下述 AGENTS.md 文件内容```

全局 Agent 规则

以下是本机 Codex 的个人工作约定；上层指令和当前用户明确要求始终优先。

个人偏好

• 默认使用简体中文；代码标识符、命令和路径保持原文。
• 以当前机器、仓库、会话和真实运行表面的证据为准。
• 默认做最小充分实现，不扩张范围，不覆盖或还原用户已有改动。
• 结论先行；最终答复保留结论、关键证据、验证、剩余风险和必要下一步，省略过程复述。

执行边界

• 仅要求回答、解释、分析、诊断、review 或规划时，检查相关材料并报告结果，不修改代码或外部状态。
• 明确要求修改、实现、构建或修复时，完成范围内的本地改动和非破坏性验证，无需重复确认。
• 外部系统写入、发送或发布、破坏性操作、付费、权限变更及实质扩张范围前必须确认。
• spec promotion 只在知识稳定、可复用、已验证且用户确认后执行。

Workflow 分工

• 路由优先级：明确属于 Inline 的简单任务直接处理；其余工程任务使用 Matt 方法；已有 Trellis workflow 且任务需要跨会话状态或多项稳定决策时，由 Trellis 管理生命周期、Matt 提供工程方法。
• Inline：只读问答、代码解释、局部配置或文案、单文件或根因明确的小修，直接处理并做最小验证。
• Matt：按当前可用 skill description 路由需求拷问、PRD/issue、实现、TDD、诊断、review、架构和 research，不在全局 rules 复制完整 skill 清单。
• Trellis：对已进入 Trellis 生命周期的任务，负责任务状态、planning artifacts、spec/research、跨会话恢复和 archive；详细步骤以项目 workflow 和 Trellis skills 为准。
• 一个阶段只保留一个 workflow owner；简单工作不建 task，durable/多决策工作才进入 Trellis。
• 项目没有 .trellis/ 时不主动初始化，除非用户明确要求长期记录或初始化。

Codex 执行方式

- 默认由主会话完成探索、实现、检查和验收；仅在用户明确要求，或明确选用需要并行执行的 workflow/skill 时启用子 agent。

本机约定

• 没有直接验证证据时，不声称完成、通过、可提交或可合并。
• commit message 默认 <type>(scope): <中文动词短语>，不加句号。
• commit、push、PR 只在用户明确要求时执行，Trellis 不自动提交。