Penpot implement-plan 命令详解：从 Issue 到 Commit 的 AI Agent 端到端实现流水线

Penpot implement-plan 命令详解从 Issue 到 Commit 的 AI Agent 端到端实现流水线【免费下载链接】penpotPenpot: The open-source design platform for Product teams that need scalable collaboration.项目地址: https://gitcode.com/GitHub_Trending/pe/penpotPenpot 仓库内置了一套面向 AI 编程 AgentOpenCode的自动化研发流程其中 implement-plan 命令 是计划已就绪之后的执行入口它在一次调用内串联起创建 GitHub Issue、创建issue-NNNN分支、按计划实现功能、按 Penpot 提交规范落盘 commit 四个环节。读完本文你将掌握这条流水线的每一步设计意图、所依赖的 skill 与 workflow memory 的协作关系以及 Penpot 为 Agent 设定的安全边界如永不 push并能在自己的仓库中参考同样的模式组织 AI 辅助开发流程。命令定位一次计划就绪后的全链路执行implement-plan的完整定义位于 .opencode/commands/implement-plan.md其 YAML frontmatter 声明了它的基本属性description: Execute a ready plan end-to-end — create a GitHub issue, branch issue-NNNN, implement the plan, then commit via the create-commit skill agent: build两个关键点值得注意agent: build该命令在具有写代码能力的 build agent 下运行对照同目录的 resolve-git-conflicts.md 也使用 build agent而 review.md 则明确要求不修改任何代码。无额外参数文档原文明确写道——This command is run once a plan is ready (for example, from plan mode). Execute the plan already prepared in the current session context — it does not take extra arguments. 也就是说命令的全部输入来自当前会话上下文中已经准备好的计划它不负责重新规划只负责把计划端到端地执行完毕。这与上游的 planner skill 形成清晰的职责切分planner 扮演只读的高级软件架构师角色产出包含 Context、Affected Modules、Approach、Risks、Testing 五个部分的结构化实施计划并将其保存到.opencode/plans/YYYY-MM-DD-title.md而 implement-plan 接手之后的第一件事就是把这个计划物化为一个可追踪的 Issue再围绕 Issue 组织分支与提交。整个链条可以概括为planner只读规划 └─ implement-plan 命令 ├─ 1. create-issue skill → 获得 Issue 编号 NNNN ├─ 2. git checkout -b issue-NNNN ├─ 3. 按会话中的计划实现代码不提交 └─ 4. create-commit skill → 规范 commit不 push步骤 1创建 Issue —— 把计划转成可追踪的研发单元命令的第一步是Use thecreate-issueskill, following theCreating Issues from Draft Bodyflow inmem:workflow/creating-issues. Derive the issue title and body from the plan. 这一步有两条硬性要求标题与正文必须从计划派生而不是直接复用计划文件名必须捕获新 Issue 的编号文档把它记为NNNN——因为这个编号同时决定分支名和后续 commit 的引用格式是整条流水线的主键。create-issueskill 本身只是一个薄入口见 create-issue/SKILL.md所有真实规则——标题派生、元数据策略、正文模板、Issue Type ID——都集中存放在 workflow/creating-issues.md 这份 workflow memory 中implement-plan 指定的正是其中的Creating Issues from Draft Body流程没有现成 PR从计划/草稿正文出发建 Issue。这份 memory 提供了相当具体的可执行细节构成 implement-plan 第 1 步的完整操作手册标题派生规则Bug 标题用描述性现在时格式为[Where] [present-tense verb] when [condition]例如 Plugin API crashes when setting text fills禁止以 Fix 等祈使动词开头。Feature / Enhancement 标题用祈使句格式为[Imperative verb] [what] in/on [where]例如 Add customizable dash and gap length controls to dashed strokes in the sidebar。通用规则必须写清whereUI 位置或模块剥离bug:、feature:、:bug:等前缀纯文本、不用 emoji一个描述里若含两个相关问题用 and 把两者都写进标题。元数据与正文模板字段规则Labels社区贡献者 PR 加community contribution不加bug/enhancement标签用 Issue Type 代替Milestone当前或下一个计划里程碑不确定则省略Project固定为Mainproject number 8用--project MainIssue Typegh issue create无法直接设置需创建后用 GraphQL 补设正文则写入临时文件以避免 shell 引号问题Bug 与 Enhancement 各有固定模板Description / Steps to reproduce / Expected behavior / Affected versions或 Description / Use case / Affected versions并且要求不要软换行段落——每段在源码中保持单行换行只用于结构性分隔章节标题、列表项、代码围栏、空行以便后续 diff 更干净。建 Issue 的实际命令cat /tmp/issue-body.md ISSUE_BODY body content here ISSUE_BODY gh issue create \ --repo penpot/penpot \ --title Derived title \ --label label \ --project Main \ --body-file /tmp/issue-body.md命令输出形如https://github.com/penpot/penpot/issues/NUMBER这里的NUMBER就是 implement-plan 文档所说的NNNN。若需要设置 Issue Type则先通过 GraphQL 查询拿到 Issue 的 node id再执行updateIssuemutation 设置issueTypeIdmemory 中列出了 penpot/penpot 仓库六种 Issue Type 的 ID 表以及Bug report → Bug、feature request → Enhancement/Feature、文档 → Docs、其余 → Task的映射规则最后用gh issue view NUMBER --json ...验证标题、标签、里程碑与项目归属。步骤 2创建以 Issue 命名的分支Issue 创建成功后命令要求立即切换到以 Issue 命名的分支git checkout -b issue-NNNN其中NNNN替换为步骤 1 捕获的 Issue 编号。这个命名约定让分支与其追踪的 Issue 一一对应从分支名即可反查该次改动对应的需求单元也为后续 commit 中的Closes #NNNN引用建立了可校验的锚点。值得注意的是implement-plan 只要求创建并切换而不要求任何 push 或远端操作——这与 AGENTS.md 顶部的 HARD RULES 一致Nevergit push, force-push, or modifygit origin... The user pushes from their own shell. Agent 的全部活动被限制在本地工作区内。步骤 3执行计划 —— 只实现不提交第三步是流水线的主体Implement the prepared plan from the session context. Work methodically, keeping changes focused on what the issue requires.Do not commit— the commit happens in step 4.这里有两层设计意图聚焦实现改动严格限定在 Issue 所要求的内容上。上游 planner 在生成计划时已经按垂直切片原则把任务拆成 XS/S/M 级每个任务不超过约 5 个文件、附带验收标准与验证命令并依据 monorepo 依赖图frontend - common、backend - common、exporter - common、frontend - render-wasm排定顺序执行阶段要做的就是逐任务落地并逐段验证。提交权后置实现阶段禁止git commit把何时提交、如何写 message收敛到第 4 步的单一入口。这避免了实现中途产生碎片化提交也保证最终提交信息能一次性准确概括全部改动。同时AGENTS.md 要求 Agent 在编码前先读受影响模块的 core memory如frontend/core、backend/core、common/core并Never pipe test output directly to filters——测试输出必须先重定向到文件再检查以防隐藏失败。这些约束虽然不写在 implement-plan 文档内却是该命令执行环境的一部分。步骤 4通过 create-commit skill 落盘提交实现完成后命令要求load thecreate-commitskill and follow its workflow to commit the changes并特别指出要提供三样东西一段简要总结——实现了什么、为什么Issue 引用issue-NNNN当前运行的模型名称以便正确写入AI-assisted-bytrailer。create-commit skill 的职责边界写得很清楚它owns the commit format, staging review, and safety checks — it does not implement features or push。其工作流为暂存调用上下文指定的文件不向用户确认运行git diff --staged复查内容——若发现密钥、.env值、调试打印或与声明意图不符的内容立即停下并告知用户按规范起草 message正文每行 72 字符换行执行git commit -m subject -m body正文含特殊字符时可用git commit -F -AI-assisted-bytrailer 的取值由调用上下文提供原样使用。commit message 的完整规范在 workflow/creating-commits.md 中定义:emoji: Subject line (imperative, capitalized, no period, 70 chars) Body explaining what changed and why. Wrap lines at 72 characters — git log and tooling render long lines poorly. Keep each line concise. AI-assisted-by: model-name要点包括Emoji 类型菜单:bug:bug fix、:sparkles:enhancement、:tada:new feature、:recycle:refactor、:lipstick:cosmetic、:ambulance:critical fix、:books:docs、:wrench:config、:zap:perf、:whale:docker、:fire:removal、:globe_with_meridians:translations 等共 17 种。Issue 引用格式使用Closes #NNNN而不是Fixes #NNNN将 commit 关联到 GitHub Issue。AI-assisted-by规则只写裸模型名如mimo-v2.5不加opencode-go/之类前缀。身份来源不猜测、不使用--author作者身份取自本地 git config。create-commit 还附带一组硬约束不 push、不运行git reset/git checkout/git restore/git clean/rm、不改作者身份、未经明确要求不 amend 本会话之外的提交、不绕过 pre-commit hooks、不添加本会话未创建的未跟踪文件。安全边界流水线在哪里停下把整条命令串起来看implement-plan 的终点是本地的一次规范 commit其最后一句明确写道Do not push. Pushing is handled separately by the user. 即推送动作永远留给用户在自己的 shell 中完成。这一设计与 AGENTS.md 的硬规则永不 push、永不修改远端、已推送的 commit 未经明确要求不 amend共同构成了 Agent 的版本控制安全边界Agent 负责 issue 化、分支、实现与提交这些可本地验证的环节而所有影响远端仓库的操作都保留给人类。小结四个环节与它们的支撑文件环节动作关键支撑上游生成结构化实施计划只读planner skill、计划存至.opencode/plans/1从计划派生 Issue捕获编号 NNNNcreate-issue skill、creating-issues memory2git checkout -b issue-NNNN分支名与 Issue 一一对应3按会话中的计划实现不提交计划中的任务切片、验收标准与模块验证命令4按规范提交emoji 前缀、72 列正文、Closes #NNNN、AI-assisted-by不推送create-commit skill、creating-commits memoryimplement-plan 的价值在于它把AI 写代码中最容易失控的环节——需求追踪Issue、隔离分支、质量收敛单次规范提交、责任边界不 push、不篡改作者身份——固化成一条不可跳步的流水线每一步的格式细节都下沉到可独立维护的 skill 与 memory 中。对于希望在自己仓库中搭建类似 AI 辅助研发流程的团队这套command 只做编排、规则下沉到 skill/memory、推送权保留给人类的划分方式是一个值得直接参照的模板。【免费下载链接】penpotPenpot: The open-source design platform for Product teams that need scalable collaboration.项目地址: https://gitcode.com/GitHub_Trending/pe/penpot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考