/tag/Trellis

既没有continue也没有finsh work 把我整不会了 这是bug吗 2 个帖子 - 2 位参与者 阅读完整话题

最近刚刚使用trellis工作流来进行开发,我在用claude搭配trellis的时候有一次用/context命令发现上下文快满了,然后我compact压缩了一下,然后再执行任务时发现token消耗的数量格外的高,全部都未命中缓存导致的. 很残酷的数据,3号是没有压缩的,4号是进行压缩的.这给了我血的教训.希望各位和我一样刚刚使用这种trellis的工作流的佬,不要乱清上下文.这种工作流是强依赖上下文的 3 个帖子 - 2 位参与者 阅读完整话题

原始版本也是从某位佬的评论获取到的，然后找ds4修修补补，做做加减法，目前用的挺舒畅，遵循指令强的模型，基本都会按照流程走，token消耗也挺好的，pi有一说一，确实用起来非常之香。 ## Global Agent Rules **These rules are MANDATORY. Violation invalidates output.** ### System env Windows 11, MSYS2 bash(run in Terminal), node v24.11.1, npm v11.14.1, go v1.26.2 ### Language Keep replies concise, always use Chinese. ### Working Style Senior engineer mode: conclusion → short context → stop. State assumptions openly. No feature creep. Only refactor to fix root cause. Launch-ready = passes targeted tests. ### Coding Standards Complexity ≤6, nesting ≤2. Early returns, guard clauses, no else after return. No implicit state changes. Reuse ≥2 for new abstraction. APIs ≤3 params, explicit returns. Comments = why, not what. - **Concurrency readiness**: Non-obviously safe functions must be documented with their concurrency semantics (e.g., `// safe for concurrent calls` or `// caller must hold lock`). ### Debug Policy Root cause fix only, no symptom patches. Explicit errors: no silent catch/default/??/panic; return errors. Structural: dedup, single source, redesign shared state, encode invariants. Verify with failing test. ### Performance & Concurrency Assume concurrent calls. Guard shared state. No unbounded blocking. Bound goroutines/queues. Avoid per-op allocations in hot paths. Document concurrency semantics. ### Skill & Plugin Invocation (Conditional Gate) **Before writing any code, you MUST output a decision line:** `// DECISION: skill_needed=<true/false> reason=<short reason>` **Then follow these rules:** - If `SKILL.md` exists **and** its instructions cover the current task (e.g., build, test, deploy): `skill_needed = true` → you MUST invoke `skill` as specified. Do NOT write code that bypasses it. - If `SKILL.md` does not exist, is incomplete, or its content is irrelevant to the current request: `skill_needed = false` → skip invocation. Do NOT invent a call. - For plugins: only call `plugin.install(<name>)` if the task **explicitly requires** a capability that only that plugin provides (e.g., language-specific formatter, linter). Otherwise, no call. **If uncertain whether SKILL.md applies:** default to `skill_needed = false` and note uncertainty in reason. **Violation:** calling skill/plugin when not needed, or failing to call when needed → invalid output. ### Execution Rules **Before any action, classify task complexity:** - **Trivial** (single line/function fix, obvious syntax/typo/copy-paste error): respond directly with fix. No sub-agent, no extra tool, no Trellis command. - **Simple** (affects ≤3 files, no new architecture): state fix then minimal changes. Sub-agent forbidden. - **Complex** (requires research, multi-file coordination, design decision): then follow multi-step: state goal + first action. Then: Read first. Minimal changes only (dead code, duplicates, branches). Follow `SKILL.md` if exists and complete; else note gap. ### Sub-agent Restriction **Never spawn sub-agents for trivial or simple fixes. Direct response only.** If you cannot solve directly, state what you need rather than delegating. ### Validation Targeted test first (red→green) → type/lint/build must pass → minimal smoke. Run runtime if possible; if not, state blocker explicitly. Static checks ≠ runtime verification. ### Stop Rule After each output: if request satisfied, stop immediately. Evidence = requested item exists, not "enough". No extra search or polish. 1 个帖子 - 1 位参与者 阅读完整话题

如题，这两个都是站里大佬开发的开源项目。 有无大佬这两者都使用过的，哪一个更好？ 或者说什么时候该用哪一个？ 两个同时安装，使用的时候会有冲突吗？ 求各位彦祖佬友们解惑，自己没怎么看明白 1 个帖子 - 1 位参与者 阅读完整话题

一直想在内部推动 harness 的使用，包括开发流程和内部Agent的harness。 目前个人对trellis的使用比较多，简单了解 open spec / superpowers ，没用过 omc/omx 。真分享起来也不知道从哪里讲起，现在的迭代速度太快，站内的两个月前的分享已经变成了旧闻 。 想请问大家有无团队的harness经验分享或者最佳实践，比如： 内部harness流程和使用 Agent Harness 心得 3 个帖子 - 2 位参与者 阅读完整话题

0.5x版本，claudecode上默认会调用impletion子代理，这会导致一旦进入子代理开始代码实现阶段后，只有需要执行命令/修改文件的审批时才会有交互，交互体验会变得很差。比如，子代理请求修改文件，人拒绝并询问为什么要这么修改，子代理并不会回答问题，而是再发来一个修改文件请求。请教一下大家，这个目前有什么解决方案吗？ 1 个帖子 - 1 位参与者 阅读完整话题

用trellis框架，定好goal，让它跑 goal模式真是一个好发明，希望能直接把我周限干干完吧 更新：现在貌似会停了 1 个帖子 - 1 位参与者 阅读完整话题

前两周 Trellis 恨不得一天更新几版，但这周没有更新耶。 7 个帖子 - 7 位参与者 阅读完整话题

如题，可以用于团队内的技术分享会，晚点会更新到仓库去，主要沉淀了下从入门到团队使用 ppt采用slidev去展示的，不知道帖子会不会违规，如有违规请各位佬友提醒下，先谢谢啦。 trellis-lake.vercel.app Trellis 教程 - Slidev "## Trellis 教程\nAI 驱动的开发协作与编码框架\n" github.com GitHub - huangjunsen0406/trellis: trellis技术分享ppt trellis技术分享ppt 7 个帖子 - 6 位参与者 阅读完整话题

佬们有没有在用Trellis的时候感觉到触发trellis-brainstorm进行一问一答澄清需求的概率很低，很多时候就直接从输入需求到execute了 14 个帖子 - 7 位参与者 阅读完整话题

随着Trellis的更新, 上一个帖子: 个人codex使用Trellis的简单流程 也过时了. 现在Trellis在codex上也支持hook了, 最近一直在用, 分享下个人体会. 现在Trellis使用非常简单, 官方标准流程应该是: 直接输入需求. 此时Trellis会自动hook, 自动帮你创建hook, 并在每轮对话都自动hook注入上下文 开始实施, 如果任务简单的话会自动调用check, 也可以手动 $trellis-check commit $trellis-finish-work . 一般会自动归档 但成也hook, 败也hook. 现在的hook感觉太重太冗余了，收益有点低。 从以前少量的“创建task”变成现在不停的敲“不要创建task” 个人体验下来，创建task的情况总归是少数。我明白hook里也考虑到了这点，所以对创建task情况做了部分限制，但效果甚微。 一开始我是修改hook提示词，默认不创建，特定情况下才创建task，但后面实在受不了hook的冗余上下文，有次让AI跑多轮loop测试直接把上下文和输出给我跑爆了。于是就关闭hook了。 于是我现在的流程变为： $start 写需求，讨论或brainstorm，不要实施 /new → $start 实施task xxxxx /new → $start 某些地方需要修改，如何如何，如果和PRD不对齐就修改PRD 几轮下来后，差不多可以了，准备commit。 这里我使用 agent-toolkit/skills/commit-work at main · softaworks/agent-toolkit · GitHub 随便找的再让AI修改下，大概功能就是根据当前代码改动按要求分功能进行commit并给出commit message，确认后再commit /new → $trellis-check /new → $trellis-finish-work 差不多就这样，想到啥再更吧 2 个帖子 - 2 位参与者 阅读完整话题

介绍由codex生成。 感谢：那个男人！Member你就是我的神 ！ trellis项目的大佬 桃酥！ 我的搭配使用：开发框架：trellis 开发规范：卡帕西 拷打模糊细节skill：grill-me 使用方法，让claude cli、codex app同时配置Dual AI Collaboration Skill，在codex挂一堆“继续”，然后睡觉。也有人工审查模式，可自行开启关闭。 希望有佬友给我反馈。 Dual AI Collaboration Skill 说明文档 这是什么 dual-ai-collaboration 是一套让 Codex 负责开发、Claude 负责审查、用户保留最终决策权 的 AI 协作开发协议。 它不是一个具体项目框架，也不是某个语言的代码模板，而是一套跨项目可复用的协作规则：规定什么时候开发、什么时候交接、怎么审查、怎么记录上下文、怎么防止两个 AI 互相附和，以及在用户不在场时如何安全连续推进。 简单说，它解决的是： Codex 连续开发后，Claude 怎么知道最近到底改了什么； Claude 审查时如何不被 Codex 的说法带偏； 两个 AI 都同意时，哪些事仍然必须问用户； 用户睡觉或离开时，开发如何继续但不丢审查边界； 当项目质量慢慢变差时，AI 如何主动报警； 当功能做完但没有新开发价值时，AI 如何切到真实验收，而不是继续乱加功能。 适合谁 适合这些使用方式： 你经常用 Codex 做主要开发； 你希望 Claude 作为独立 Reviewer 审查 Codex 的工作； 你会一次性让 AI 连续开发较长时间； 你担心 AI 之间互相迎合、只会修修补补； 你希望新会话也能从项目文档恢复上下文； 你不是专业开发者，希望 AI 不要把技术选项丢给你，而是给出推荐方案和风险说明。 不太适合： 只做一次性小脚本； 不希望维护任何项目状态文档； 不需要代码审查或长期项目质量管理； 需要完全无人值守执行高风险生产操作。 核心角色 Codex：Primary AI Codex 负责主要开发和维护项目文件。 它需要： 实现功能； 更新状态、任务索引、交接日志； 在合适节点准备给 Claude 的 handoff； 独立判断 Claude 的建议是否真的应该采纳； 发现项目质量下降时主动提醒； 在连续开发或无人值守模式中切分可审查的工作批次。 Claude：Reviewer AI Claude 负责审查、挑战和提出改进建议。 它需要： 独立阅读项目文件和 diff； 不把 Codex 的 review_request 当作审查边界； 判断这次开发是否符合最终产品方向； 检查质量下降信号； 对 Codex 的 AI UAT 验收结果进行审查； 对高风险事项提醒用户，而不是替用户批准。 用户：最终决策者 用户不需要决定具体实现细节，但保留最终权力。 必须由用户决定的事情包括： 产品方向变化； 高风险数据操作； 真实 secrets、支付、公开发布； 隐私、权限、真实用户数据； 两个 AI 无法收敛的重大分歧； 是否接受或驳回重要风险。 主要能力 1. 标准交接与审查 Codex 完成一段工作后，会写 HANDOFF 。 Claude 根据 HANDOFF 、项目状态文件、当前 diff 和日志输出 REVIEW 。 人工流程是： Codex 写 HANDOFF -> 用户复制给 Claude -> Claude 输出 REVIEW -> 用户贴回 Codex 桥接流程是： Codex 写 HANDOFF -> Codex 调用本机 Claude CLI -> Claude 输出 REVIEW -> Codex 读取并归档 两者使用同一套文档和模板。 2. 连续开发与批量审查 用户可以让 Codex 不要每个小改动都停下来找 Claude，而是连续推进。 触发审查提醒的典型节点： 完成一个可运行功能切片； 一个页面/API/数据流打通； 触及 8 个以上重要文件； 有约 1000 行有意义改动； 累积 5 个小任务； 准备提交、发布、归档或标记完成。 时间本身不是硬限制。不是“开发 2 小时必须停”，而是看改动体量和风险。 3. 无人值守开发 当用户明确授权后，Codex 可以在用户离开、睡觉时继续低风险开发。 它必须： 记录授权范围； 记录停止条件； 到达审查节点时写入 review_pending ； 不把未审查内容当作已通过； 不跨越高风险边界； 不用用户预设的“继续”扩大权限。 如果用户预设多个“继续”，Codex 可以继续同一授权窗口内的低风险任务，但不能用它跳过高风险决策。 4. Quality Sentinel 质量哨兵 Sentinel 用来防止项目慢慢变烂。 它关注的不是“每次都找一个问题”，而是累积证据： 类似 bug 反复出现； 同一个 P2/P3 问题多次延期； 单文件过大且没有拆分计划； 测试、lint、type-check 被多次跳过； smoke/test 明显变慢； 低优先级问题在批量开发中积累； reviewer 反复给无证据 approval。 Sentinel 不允许 AI 为了显得严格而编造风险。所有告警必须有证据。 5. AI UAT / 拟人化验收 当“继续开发”已经没有明显价值，但最近功能需要验收时，Codex 应该切到 AI UAT。 AI UAT 要求 Codex 像真实用户一样操作产品： 启动或复用本地 dev server； 用 Browser/Playwright 点击、输入、刷新、提交； 测试 happy path； 测试一个合理的错误路径； 检查 console/runtime 错误； 检查加载、空状态、错误状态、持久化等； 小问题可以自修并复测。 AI UAT 不是用户验收。它只能作为 ai_generated 证据，不能代替用户最终确认。 6. 项目阶段与风险配置 协议区分不同项目阶段： personal_dev ：个人本地自用； prototype ：早期原型； internal_test ：内部测试； public_release ：公开发布或生产使用。 个人自用阶段可以放宽一些限制，例如没有登录系统、使用本地 .env.local 、临时 API/schema 调整等。 但有些事情永远不能自动放宽： 真实密钥提交到仓库； 不可逆删除真实数据； 真实扣费或生产支付； 公开发布或部署； 处理他人隐私数据； 不明原因的数据损坏或验证失败； P0/P1 风险。 7. 自主 Claude 审查桥接模式 这是默认关闭的高级模式。 启用后，Codex 可以在需要审查时调用本机 Claude CLI，让 Claude 自动审查，并读取结果。 重点规则： 必须由用户显式开启； 桥接只是替代复制粘贴，不改变审查协议； Codex 调用的是用户本机 claude CLI，使用用户自己的 Claude 配置/API/额度； 首次使用必须做 Claude 会话配对检查； 如果一个项目有多个 Claude 会话或多个子工程，推荐用户手动 /resume 到正确会话，再让 Codex 做配对验证； 上下文满、API 失败、权限失败、输出截断、进错会话等异常必须停止并报告用户。 桥接模式不会让两个 AI 自动批准高风险事项。 推荐项目文件 英文/code 项目常用： STATUS.md PLAN-CHANGELOG.md COLLAB-TASK-INDEX.md COLLAB-HANDOFF.md COLLAB-CONTEXT.md REVIEW-LOG.md QUALITY-SIGNALS.md 中文项目可对应为： 状态-当前闭环.md 计划-演进日志.md 协作-任务索引.md 协作-交接日志.md 协作-Codex上下文日志.md 审核-互审记录.md QUALITY-SIGNALS.md 这些文件让新会话、新 AI、Claude/Gemini 审查者都能从文档恢复上下文，而不是依赖聊天记忆。 推荐启动提示词 新项目可以这样对 Codex 说： 加载 trellis、karpathy-guidelines、dual-ai-collaboration。 请先初始化项目协作流程： 1. 判断当前项目阶段和风险配置； 2. 如果需求模糊，使用 grill-me 方式一次问我一个关键问题； 3. 建立或更新 STATUS.md、PLAN-CHANGELOG.md、COLLAB-TASK-INDEX.md、COLLAB-HANDOFF.md、COLLAB-CONTEXT.md、REVIEW-LOG.md、QUALITY-SIGNALS.md； 4. 写一份 INIT / HANDOFF，说明当前项目目标、已知状态、下一步计划，方便 Claude 审查； 5. 后续由 Codex 主要开发，Claude 独立审查，用户保留最终决策权。 已有项目可以这样纠偏： 加载 dual-ai-collaboration，并更正当前项目的协作使用方式。 请读取 STATUS.md、PLAN-CHANGELOG.md、COLLAB-TASK-INDEX.md、COLLAB-HANDOFF.md、COLLAB-CONTEXT.md、REVIEW-LOG.md。 如果缺少必要文件，请补齐最小可用版本。 然后： 1. 找到上次 Claude 已审查边界； 2. 汇总之后 Codex 新开发但未审查的内容； 3. 按合理批次准备 Claude 审查 handoff； 4. 不要只交接最新一小段； 5. 如果发现审查债、质量下降或方向风险，请按 Quality Sentinel 记录。 启用桥接模式可以这样说： 开启 dual-ai-collaboration 的自主 Claude 审查桥接模式。 先不要正式审查。请用 user_guided_cli_resume 方式初始化： 1. 启动本项目的 Claude CLI； 2. 等我手动 /resume 到正确 Claude 会话； 3. 记录启动和会话线索； 4. 发起只读 pairing_check； 5. 对比项目路径、子工程、当前任务、最近 handoff/review； 6. 结果匹配后让我回复 1 再绑定。 为什么值得用 普通 AI 开发的问题不是“不会写代码”，而是长期项目里容易出现这些情况： 上下文丢失； 只修眼前问题； 审查范围被开发者引导； 用户睡觉时积累大量未审查代码； AI 互相礼貌认可； 项目方向一点点偏离； 小质量问题长期堆积； 做完功能后没人像真实用户一样走流程。 这套 skill 的价值是把这些隐性风险变成显性流程。 它不会让 AI 变成完美工程师，但会让 Codex、Claude 和用户之间有清楚的边界、记录和复盘路径。 一句话推荐 如果你用 Codex 长时间开发，又希望 Claude 做独立审查， dual-ai-collaboration 可以把“人工复制粘贴式双 AI 协作”升级成一套可记录、可恢复、可审查、可无人值守推进的项目协作协议。 SKILL.txt (75.5 KB) 2 个帖子 - 2 位参与者 阅读完整话题

借鉴了这两位佬的思路，忽然想起来trellis的工作流本身就是规划任务拆分验证。 Trellis框架用户自然语言即可触发Goal命令。 goal 长任务 prompt 焚绝！ 开发调优 Goal Mode 工作流 当处于 goal mode，或用户 prompt 包含 /goal 时，必须进入本流程。 在当前涉及到的 project 下创建新的目录： goal-[num]/ input.md plan.md tasks.md 编号递增，不得覆盖已有目录。 如过目前没有 project，你需要新建。 input.md：完整保存用户原始输入，逐字保留，不得改… codex goal 焚绝 v2 开发调优 把他加入agents.md即可~~~或者为了节省上下文您可以自定义skill 在v1版本上进行了一些优化，提高了可用性 ============================================= Goal Mode 工作流 当处于 goal mode，或用户 prompt 包含 /goal 时，必须进入本流程。 在当前涉及到的 project 下创建新的目录： goal-… —————————————————————— 慎用 额度在天上尿失禁的看着我 1 个帖子 - 1 位参与者 阅读完整话题

最近在使用Trellis，主力codex，也学习了git worktree并行开发，但是对如何使用多个codex窗口通过Trellis自动化并行开发/合并还是有些懵逼，请问有什么资料可以参考学习一下？ 12 个帖子 - 6 位参与者 阅读完整话题

佬友们，我的codex安装trellis一直报错 failed to load configuration: d:\Projects\XX.codex\config.toml:32:1: data did not match any variant of untagged enum FeatureToml 但是我的配置是按照官方说明配的： [features.multi_agent_v2] enabled = true max_concurrent_threads_per_session = 6 min_wait_timeout_ms = 480000 default_wait_timeout_ms = 480000 max_wait_timeout_ms = 3600000 为啥还会报错呢？codex-cli 是0.131.0 5 个帖子 - 4 位参与者 阅读完整话题

本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 LonelyHerbivore/Trellis-Herbivore: Trellis-Meta 保留 Trellis 原有的能力，在 Trellis-0.6.0-beta.17 的基础上，针对 Claude Code 单工具工作流 做定向增强：引入以下策略： trellis-grill-me(基于prd追问细节) 当前会话持续开发，还是 subagent(开发策略, 用户可选 ) 当前分支直接开发，还是 worktree(开发策略, 用户可选 ) 走 Trellis 默认开发流程，还是 TDD(开发策略, 用户可选 ) trellis-spec-review(trellis-check之后二次检查spec是否执行完毕，是否有遗漏) trellis-code-review(代码守护者，代码质量是否合格) trellis-code-architecture-review(代码架构守护者，修改或新增代码是否污染当前架构，拒绝屎山代码) trellis-improve-codebase-architecture(代码深层架构分析师，二次检查修改或新增代码是否污染当前架构，拒绝屎山代码， 用户可选 ) trellis-merge-review(分支合并检查，对合并后的分支做最后的质量检查, 用户可选 ) 使用过程 用户自然语言提出需求 → 判断是否需要创建 Trellis 任务 → trellis-brainstorm → trellis-grill-me(基于prd追问细节并更新prd) → 开发策略决策 → trellis-implement → trellis-check → trellis-spec-review(spec二次检查) → trellis-code-review(代码守护者) → trellis-code-architecture-review(代码架构守护者) → trellis-improve-codebase-architecture(代码深层架构分析师,可选) → trellis-update-spec → 合并分支(可选) → trellis-merge-review(合并后的最终质量检查) → 编译/测试运行 → /trellis:finish-work 或 自然语言提出任务存档 安装 npm install -g trellis-hgl@latest 1 个帖子 - 1 位参与者 阅读完整话题

搭配Trellis简直折磨，但是我不用Trellis，正常用的话感觉也不慢，不知道为啥。 我现在换成用deepseek+trellis快很多，大佬们帮我看看这速度是正常的吗 4 个帖子 - 2 位参与者 阅读完整话题

trellis,cursor++,glm5.1, 272k跑了一半左右吧 倒反天罡，又是我来帮ai打工向ai汇报了 前面还算正常点表现吧，跑一半注意力就这了，这算长任务吗，真不能指望国模 5 个帖子 - 4 位参与者 阅读完整话题

一个简单的Python脚本，即使手工修改一下也就几分钟，Trellis花了整整1小时。自从装上Trellis后，原本分分钟的事都得以小时为单位了 3 个帖子 - 3 位参与者 阅读完整话题

我的理解是直接安装hook，然后直接使用即可。 但是0.5大版本感觉指令遵循度非常低，就是不强制，导致经常如果我不强调trellis，它就不去看文档。即便强调，基本上2 - 3轮对话之后就不再继续改文档啊之类的。跟没安装框架也差不多。 于是换了0.6beta，指令遵循度是好了，但是sub agent这功能只要开了（从inline切subagent）这东西就跟要死了一样疯狂开subagent，但是平时inline模式要求它开几个subagent就会提示它根本不能开，直接把这个功能废掉了。 再就是，状态机的推进仍然是有问题，就是文档之类的会记得更新，但是经常一不留神就留在planning，结果就是推进阶段AI非常难以推进，原因是注入的还是planning模式……然后我不太确定这个planning和in progress是怎么界定的，按照道理来说它改着改着会出新bug，那难道每次都要planning和in progress来切换吗？感觉用着一头雾水，AI也和我一样一头雾水…… 9 个帖子 - 4 位参与者 阅读完整话题