用 lfg 把已定需求自动跑通计划、实现、审查、浏览器测试并打开 PR【免费下载链接】compound-engineering-pluginOfficial Compound Engineering plugin for Claude Code, Codex, Cursor, and more项目地址: https://gitcode.com/GitHub_Trending/ev/compound-engineering-plugin当你已经用/ce-brainstorm把需求讨论定稿或者手里有一个边界清晰的软件任务但不想逐步批准计划、diff 和审查结果时Compound Engineering 插件的lfg技能就是为此设计的它把 plan、work、simplify、review、浏览器测试、commit/push/PR、CI 修复串成一次无人值守的长任务推分支并打开 PR但从不合并。如果你的工作仓库没有配置 git remote它只提交到本地就结束——这是正常的终态不是报错。准备条件lfg本身不是一个独立安装项它是 Compound Engineering 插件里的一个技能。插件支持 14 个 agent 宿主以下三条是 README 列出的主路径选你实际使用的那一条# Claude Code /plugin marketplace add EveryInc/compound-engineering-plugin /plugin install compound-engineering# Codex CLI codex plugin marketplace add EveryInc/compound-engineering-plugin codex plugin add compound-engineeringcompound-engineering-plugin# Cursor Agent chat /add-plugin compound-engineering安装完成后在项目里运行/ce-setup它会报告可选工具能力、在缺失时创建.compound-engineering/config.yaml并刷新提交用的示例配置。跑lfg前还需要满足两个条件需求已定型。文档建议的最佳起点是/ce-brainstorm头脑风暴产出的统一计划工件unified plan artifact会让lfg计划阶段对着真实需求而不是单行提示词工作。软件类头脑风暴的收尾在满足条件时会主动提供 Ship it autonomously withlfg 选项。期望分支可被推送。仓库有 remote 时才会 push、开 PR、看 CI没有 remote 时结果只有本地提交。lfg从不适用的情况非软件任务、你还想交互地塑造产品、你想逐阶段审查并批准那就分别手动跑/ce-plan、/ce-work、/ce-code-review、/ce-commit-push-pr。启动方式四条调用路径覆盖从刚脑暴完到已有计划文件的情形以下均为文档给出的真实示例# 最常见先定需求再从该上下文出发跑流水线 /ce-brainstorm design account-level notification controls for enterprise teams /lfg# 边界清晰的软件任务直接跑产品上下文比脑暴弱 /lfg add a CSV export button to the account reports page# 就地补全一份 requirements-only 计划文件然后跑流水线 /lfg docs/plans/feedback-sweep-plan.md# 指定计划阶段的模型fable、opus 是文档示例中的模型别名 /lfg plan with fable第三个参数形式说明空参数表示从当前上下文包括刚结束的脑暴规划一段功能描述会传给/ce-plan一个 requirements-only 计划路径会让/ce-plan就地补全该文件再进入流水线。可选分支给两个阶段分别指派模型或 harnesslfg允许你只路由两个阶段而不是整次运行规划阶段只能提升模型model elevation即plan with fable这类写法把 harness 指给规划如 plan with codex不受支持lfg会把它作为路由阻塞直接停下。实现阶段可以换 harnessuse Codex for implementation是偏好prefer该路线不可用时回退原生并披露一次only use Composer for implementation是硬性要求require路线不可用时会停止。cursor指 Cursor harness 及其默认模型composer指经 Cursor 调用的 Composer 系模型。未写明阶段的指派如单独说 use fable默认只绑定到实现阶段lfg会在开场行里声明这一点交互式会话中若确实有歧义它只允许问一个问题之后照旧无人值守。功能文案里的普通提及引用、对比、文件名不会触发路由。持久化的实现作者偏好也可以写在.compound-engineering/config.yaml的work_engine_mode/work_engine_preferences键里写法见 configuration但当前任务的显式指令优先于配置。流水线内部发生什么lfg严格按顺序执行十个步骤每步有明确的闸门任何一步不满足条件整条流水线就停在那里并说明原因而不是跳过或直接写代码。以下摘自 lfg 指南 与其运行规格 skills/lfg/SKILL.md规划/ce-plan。lfg先从对话中整理一份 settled-decisions 简报每条决策、其来源类别、被否掉的替代方案、一行理由传给/ce-plan避免这些已定选择被重新询问对话里没有已定决策时则完全跳过简报。规划必须产出实现就绪的代码计划才能继续requirements-only、knowledge-work 计划或非软件结果都会终止流水线显式的status: blocked报告永远不重试。实现/ce-work。以mode:return-to-caller运行使lfg保留后续发布步骤。只有status: complete的返回能前进行为变更必须携带验证证据证据缺失时允许一次恢复性调用补齐仍不达标就停止而不是盲发。若你用了require强度路由实际路线与请求不符时流水线停止。简化/ce-simplify-code。在审查之前跑作用于分支 diff使审查覆盖的是简化后的代码。仅当改动是纯文档或大约少于 10 行时跳过。审查/ce-code-review mode:agent。mode:agent是只报告、不编辑代码树的设计lfg自己接管第 5 步的应用动作。带settled_conflict标记且证据表明已定决策不可行的发现会在此处阻塞流水线。应用合格修复并落盘。只有同时满足suggested_fix具体、置信度为 100或 75 且报告注明跨 persona 一致、修复是机械性的单一改动、证据与file:line当前代码仍吻合——四项全中才会应用并以fix(review): apply review findings提交有 remote 时先 push 再进入下一步。残余交接。第 5 步未应用的 actionable 发现、冲突标记和带标记的已定决策冲突会汇总成## Unapplied review findings复选清单写进 PR 描述由 PR 评审人逐条决定在分支内修、驳回或立项。没有 PR 时无 remote则立为 tracker 票据并在 DONE 报告里原文陈述失败的条目。浏览器测试/ce-test-browser mode:pipeline。pipeline 模式自动在后台启动 dev server、从首选端口向上扫描空闲端口、无交互提示驱动受 diff 影响的页面并截图。驱动策略上它优先宿主原生集成的浏览器否则回退agent-browser不会现装 Playwright/Puppeteer 之类独立栈。发布/ce-commit-push-pr mode:pipeline branding:on。提交剩余改动、push、有 remote 时开 PR。若该分支已有 PR跳过创建但仍提交并推送未提交改动。若项目自己的指令指定了发布流程比如某个自定义 skill则走项目流程而不是默认交接。看 CI/ce-babysit-pr mode:pipeline pr-url。有界循环真实 CI 失败交给/ce-debug修复、新评论交给/ce-resolve-pr-feedback处理默认3 轮修复预算停在 CI decided不停在 merged。输出DONE。收尾会给出可执行的两行交接命令/ce-explain 概念名若出现New concepts:尾部以及/ce-babysit-pr pr-url继续看 PR 到合并若计划里明确声明了尚未规划的未来区域它只提供一次/ce-handoff建议不会自己继续做那块。如何判断这次运行发生了什么lfg从不中途停下来要批准所以你靠它停在哪、留下什么记录来判断结果规划阶段停止任务被判定非软件、ce-plan返回status: blocked、或计划不是implementation-ready的代码计划——流水线在实现开始前终止原因会被报告。实现阶段停止返回状态不是status: complete或require路由下实际路线与请求路线不一致会报告requested_route、actual_route和fallback_reason。CI 在预算内修不好未解决的失败会被记录babysitter 的运行报告评论而不是塞进 PR 描述正文运行照常结束。needs-human类残余需要产品或设计拍板被延后交给你在收尾的## Needs your decision里逐条呈现而不是被猜一个答案。没有 remote全部提交保留在本地跳过 push、PR 创建和 CI 监控未应用的审查发现以票据形式记录。文档明确这是终态不应重试推送。成功完成代码变更、提交、通常一个 PR收尾指向/ce-babysit-pr让你自己把 PR 看进合并。边界与后续lfg不合并 PR。流水线内的 babysit 只负责把 CI 推到已决状态合并始终是你的动作。想看 PR 走完评审到合并运行/ce-babysit-pr pr-url。配置里的auto_babysit: false只关闭 PR 打开后那种不限时的常开监控不影响lfg流水线内有界3 轮、自终止的 babysit——文档强调即使 CI 看起来会干净也不要用gh pr checks轮询替代这一步因为 babysit 还要处理评审评论。运行结束后若这次改动沉淀了可复用经验可跑/ce-compound写入docs/solutions/供下一轮循环读取若lfg打印了New concepts:尾部按提示用/ce-explain name展开。各阶段技能的独立用法包括ce-plan的计划工件字段、ce-work的路线回退细节、ce-babysit-pr的 posture 选项可分别查 ce-plan、ce-work、ce-test-browser、ce-babysit-pr 的文档页lfg自身的完整契约以 docs/guides/lfg.md 和 skills/lfg/SKILL.md 为准。【免费下载链接】compound-engineering-pluginOfficial Compound Engineering plugin for Claude Code, Codex, Cursor, and more项目地址: https://gitcode.com/GitHub_Trending/ev/compound-engineering-plugin创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 用 lfg 把已定需求自动跑通计划、实现、审查、浏览器测试并打开 PR
用 lfg 把已定需求自动跑通计划、实现、审查、浏览器测试并打开 PR【免费下载链接】compound-engineering-pluginOfficial Compound Engineering plugin for Claude Code, Codex, Cursor, and more项目地址: https://gitcode.com/GitHub_Trending/ev/compound-engineering-plugin当你已经用/ce-brainstorm把需求讨论定稿或者手里有一个边界清晰的软件任务但不想逐步批准计划、diff 和审查结果时Compound Engineering 插件的lfg技能就是为此设计的它把 plan、work、simplify、review、浏览器测试、commit/push/PR、CI 修复串成一次无人值守的长任务推分支并打开 PR但从不合并。如果你的工作仓库没有配置 git remote它只提交到本地就结束——这是正常的终态不是报错。准备条件lfg本身不是一个独立安装项它是 Compound Engineering 插件里的一个技能。插件支持 14 个 agent 宿主以下三条是 README 列出的主路径选你实际使用的那一条# Claude Code /plugin marketplace add EveryInc/compound-engineering-plugin /plugin install compound-engineering# Codex CLI codex plugin marketplace add EveryInc/compound-engineering-plugin codex plugin add compound-engineeringcompound-engineering-plugin# Cursor Agent chat /add-plugin compound-engineering安装完成后在项目里运行/ce-setup它会报告可选工具能力、在缺失时创建.compound-engineering/config.yaml并刷新提交用的示例配置。跑lfg前还需要满足两个条件需求已定型。文档建议的最佳起点是/ce-brainstorm头脑风暴产出的统一计划工件unified plan artifact会让lfg计划阶段对着真实需求而不是单行提示词工作。软件类头脑风暴的收尾在满足条件时会主动提供 Ship it autonomously withlfg 选项。期望分支可被推送。仓库有 remote 时才会 push、开 PR、看 CI没有 remote 时结果只有本地提交。lfg从不适用的情况非软件任务、你还想交互地塑造产品、你想逐阶段审查并批准那就分别手动跑/ce-plan、/ce-work、/ce-code-review、/ce-commit-push-pr。启动方式四条调用路径覆盖从刚脑暴完到已有计划文件的情形以下均为文档给出的真实示例# 最常见先定需求再从该上下文出发跑流水线 /ce-brainstorm design account-level notification controls for enterprise teams /lfg# 边界清晰的软件任务直接跑产品上下文比脑暴弱 /lfg add a CSV export button to the account reports page# 就地补全一份 requirements-only 计划文件然后跑流水线 /lfg docs/plans/feedback-sweep-plan.md# 指定计划阶段的模型fable、opus 是文档示例中的模型别名 /lfg plan with fable第三个参数形式说明空参数表示从当前上下文包括刚结束的脑暴规划一段功能描述会传给/ce-plan一个 requirements-only 计划路径会让/ce-plan就地补全该文件再进入流水线。可选分支给两个阶段分别指派模型或 harnesslfg允许你只路由两个阶段而不是整次运行规划阶段只能提升模型model elevation即plan with fable这类写法把 harness 指给规划如 plan with codex不受支持lfg会把它作为路由阻塞直接停下。实现阶段可以换 harnessuse Codex for implementation是偏好prefer该路线不可用时回退原生并披露一次only use Composer for implementation是硬性要求require路线不可用时会停止。cursor指 Cursor harness 及其默认模型composer指经 Cursor 调用的 Composer 系模型。未写明阶段的指派如单独说 use fable默认只绑定到实现阶段lfg会在开场行里声明这一点交互式会话中若确实有歧义它只允许问一个问题之后照旧无人值守。功能文案里的普通提及引用、对比、文件名不会触发路由。持久化的实现作者偏好也可以写在.compound-engineering/config.yaml的work_engine_mode/work_engine_preferences键里写法见 configuration但当前任务的显式指令优先于配置。流水线内部发生什么lfg严格按顺序执行十个步骤每步有明确的闸门任何一步不满足条件整条流水线就停在那里并说明原因而不是跳过或直接写代码。以下摘自 lfg 指南 与其运行规格 skills/lfg/SKILL.md规划/ce-plan。lfg先从对话中整理一份 settled-decisions 简报每条决策、其来源类别、被否掉的替代方案、一行理由传给/ce-plan避免这些已定选择被重新询问对话里没有已定决策时则完全跳过简报。规划必须产出实现就绪的代码计划才能继续requirements-only、knowledge-work 计划或非软件结果都会终止流水线显式的status: blocked报告永远不重试。实现/ce-work。以mode:return-to-caller运行使lfg保留后续发布步骤。只有status: complete的返回能前进行为变更必须携带验证证据证据缺失时允许一次恢复性调用补齐仍不达标就停止而不是盲发。若你用了require强度路由实际路线与请求不符时流水线停止。简化/ce-simplify-code。在审查之前跑作用于分支 diff使审查覆盖的是简化后的代码。仅当改动是纯文档或大约少于 10 行时跳过。审查/ce-code-review mode:agent。mode:agent是只报告、不编辑代码树的设计lfg自己接管第 5 步的应用动作。带settled_conflict标记且证据表明已定决策不可行的发现会在此处阻塞流水线。应用合格修复并落盘。只有同时满足suggested_fix具体、置信度为 100或 75 且报告注明跨 persona 一致、修复是机械性的单一改动、证据与file:line当前代码仍吻合——四项全中才会应用并以fix(review): apply review findings提交有 remote 时先 push 再进入下一步。残余交接。第 5 步未应用的 actionable 发现、冲突标记和带标记的已定决策冲突会汇总成## Unapplied review findings复选清单写进 PR 描述由 PR 评审人逐条决定在分支内修、驳回或立项。没有 PR 时无 remote则立为 tracker 票据并在 DONE 报告里原文陈述失败的条目。浏览器测试/ce-test-browser mode:pipeline。pipeline 模式自动在后台启动 dev server、从首选端口向上扫描空闲端口、无交互提示驱动受 diff 影响的页面并截图。驱动策略上它优先宿主原生集成的浏览器否则回退agent-browser不会现装 Playwright/Puppeteer 之类独立栈。发布/ce-commit-push-pr mode:pipeline branding:on。提交剩余改动、push、有 remote 时开 PR。若该分支已有 PR跳过创建但仍提交并推送未提交改动。若项目自己的指令指定了发布流程比如某个自定义 skill则走项目流程而不是默认交接。看 CI/ce-babysit-pr mode:pipeline pr-url。有界循环真实 CI 失败交给/ce-debug修复、新评论交给/ce-resolve-pr-feedback处理默认3 轮修复预算停在 CI decided不停在 merged。输出DONE。收尾会给出可执行的两行交接命令/ce-explain 概念名若出现New concepts:尾部以及/ce-babysit-pr pr-url继续看 PR 到合并若计划里明确声明了尚未规划的未来区域它只提供一次/ce-handoff建议不会自己继续做那块。如何判断这次运行发生了什么lfg从不中途停下来要批准所以你靠它停在哪、留下什么记录来判断结果规划阶段停止任务被判定非软件、ce-plan返回status: blocked、或计划不是implementation-ready的代码计划——流水线在实现开始前终止原因会被报告。实现阶段停止返回状态不是status: complete或require路由下实际路线与请求路线不一致会报告requested_route、actual_route和fallback_reason。CI 在预算内修不好未解决的失败会被记录babysitter 的运行报告评论而不是塞进 PR 描述正文运行照常结束。needs-human类残余需要产品或设计拍板被延后交给你在收尾的## Needs your decision里逐条呈现而不是被猜一个答案。没有 remote全部提交保留在本地跳过 push、PR 创建和 CI 监控未应用的审查发现以票据形式记录。文档明确这是终态不应重试推送。成功完成代码变更、提交、通常一个 PR收尾指向/ce-babysit-pr让你自己把 PR 看进合并。边界与后续lfg不合并 PR。流水线内的 babysit 只负责把 CI 推到已决状态合并始终是你的动作。想看 PR 走完评审到合并运行/ce-babysit-pr pr-url。配置里的auto_babysit: false只关闭 PR 打开后那种不限时的常开监控不影响lfg流水线内有界3 轮、自终止的 babysit——文档强调即使 CI 看起来会干净也不要用gh pr checks轮询替代这一步因为 babysit 还要处理评审评论。运行结束后若这次改动沉淀了可复用经验可跑/ce-compound写入docs/solutions/供下一轮循环读取若lfg打印了New concepts:尾部按提示用/ce-explain name展开。各阶段技能的独立用法包括ce-plan的计划工件字段、ce-work的路线回退细节、ce-babysit-pr的 posture 选项可分别查 ce-plan、ce-work、ce-test-browser、ce-babysit-pr 的文档页lfg自身的完整契约以 docs/guides/lfg.md 和 skills/lfg/SKILL.md 为准。【免费下载链接】compound-engineering-pluginOfficial Compound Engineering plugin for Claude Code, Codex, Cursor, and more项目地址: https://gitcode.com/GitHub_Trending/ev/compound-engineering-plugin创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考