Mastra Software Factory 中的 factory-complete-issue 技能把已完成的 GitHub Issue 干净利落地标记为 Done【免费下载链接】mastraMastra is the modern TypeScript framework for AI-powered applications and agents.项目地址: https://gitcode.com/GitHub_Trending/ma/mastraMastra Software Factory位于本仓库mastracode/factory是一套基于mastra/factory的软件交付流水线Agent 依次经过 Intake接单、Triage分诊、Planning规划、Execute执行、Review审查最终在 Work 看板的done终态阶段完成收尾。factory-complete-issue正是这条流水线的最后一公里技能——它负责把流水线背后关联的 GitHub Issue 正式标记为已完成并同步清理之前各阶段留下的状态标签。读完本文你将掌握该技能在 Factory 流水线中的触发位置与调用契约、它精确执行的标签变更与评论动作、它与factory-triage等上游技能之间完整的状态标签生命周期以及它的幂等设计与安全边界。技能在 Factory 流水线中的位置done阶段的入口处理器factory-complete-issue并不是一个需要人工调用的工具而是 Work 看板进入终态时的自动动作。看 Work 看板的定义mastracode/factory/src/boards/work.tsdone: { title: Done, kind: terminal, outcomes: allOtherPhases, onEnter: { issue: completeIssue }, },当一张卡片通过factory_transition_work_item被推进到done阶段时completeIssue处理器被触发mastracode/factory/src/boards/work.ts#L91-L99function completeIssue(context: FactoryStageRuleContext) { return { type: invokeSkill, idempotencyKey: ${context.ingress.id}:factory-complete-issue, role: triage, skillName: factory-complete-issue, arguments: context.item.url ? GitHub issue (${context.item.url}) : context.item.title, } as const; }这段实现揭示了几条关键信息触发条件只有done阶段且事件来源为issue即 GitHub Issue时才调用该技能从源码结构看Linear Issue 等来源不经过completeIssue分支。入参来源技能的$ARGUMENTS由context.item.url提供形如GitHub issue (url)无 URL 时退化为工作项标题——这正好对应技能正文要求的从$ARGUMENTS解析 Issue URL 或编号。幂等键${context.ingress.id}:factory-complete-issue由不可变的 ingress 身份派生保证同一次进入done的动作最多被交付一次。角色role: triage复用 triage 席位承载这个收尾动作而不是为它注册独立 Agent——这与 README 中Working roles name bindings on the shared Code Agent的设计一致。技能目录六个内置 Factory 技能之一该技能文件本身位于 mastracode/factory/factory-skills/factory-complete-issue/SKILL.md是 Factory 服务端捆绑的六个内置技能之一。其注册清单见 mastracode/factory/src/workspace.ts#L81-L88export const FACTORY_SKILL_NAMES new Set([ configure-factory-rules, factory-complete-issue, factory-plan, factory-rereview, factory-review, factory-triage, ]);技能的加载与展示逻辑由 mastracode/factory/src/skills/catalog.ts 实现它逐个读取SKILL.md剥离 YAML frontmattername与description把正文作为技能内容提供给设置界面与运行时。路由层则通过GET /web/factory/projects/:id/skills之类的技能接口对外暴露routes/skills.test.ts中也有对应断言mastracode/factory/src/routes/skills.test.ts#L510-L513确认factory-complete-issue会出现在技能清单中。核心动作契约精确的标签清理与状态回写SKILL.md 正文定义了该技能的完整操作序列这里逐条展开第 1 步解析并读取现状。从$ARGUMENTS中解析出 GitHub Issue 的 URL 或编号然后用gh issue view读取其当前状态open / closed与全部标签。第 2 步清理三枚分诊标签。若以下标签存在于该 Issue 上逐一用gh issue edit移除status: needs triagestatus: auto-triagedstatus: needs approval第 3 步按状态分支处理核心判断逻辑Issue 仍处于 open 状态若status: pending-close尚未存在则添加之并发布评论This issue has now been marked as done.仅当该评论尚未存在时。Issue 已处于 closed 状态不添加status: pending-close也不发布评论。第 4 步边界约束Do not清单不修改任何其他标签或 Issue 字段不关闭、不重新打开、不指派assign该 Issue不请求另一次 Factory 阶段流转。换言之这个技能把关闭 Issue的最终决定权留给外部流程如定时 sweep 依据status: pending-close标签处理关闭Agent 只负责在 Issue 上留下一致的、可审计的状态痕迹。这也与mastra/factoryREADME 中transition decisions are governed by server rules的总体设计一致——技能本身不越权执行阶段流转。状态标签生命周期从 Triage 到 Complete要理解这些标签为何要被清理需要对照上游技能factory-triagemastracode/factory/factory-skills/factory-triage/SKILL.md为 Issue 打上的状态标签由谁添加含义status: needs triagetriage 阶段 Phase 1Issue 尚无status:标签时等待人工/自动分诊status: auto-triagedtriage 阶段 Phase 5发布分诊评论后所有 GitHub Issue已由 Factory 自动分诊status: needs approvaltriage 阶段当Route: Await approval或推荐动作需要维护者批准时等待批准status: pending-closefactory-complete-issueIssue 仍 open 时工作已完成等待外部流程关闭effort:level/impact:leveltriage 阶段工作量与影响分级因此factory-complete-issue实质上承担了标签生命周期的收尾清理职责把整个分诊过程留下的三枚status:标签全部移除同时打上终态标签status: pending-close使 Issue 的标签状态与流水线卡片的done阶段保持一致。而effort:/impact:标签与领域标签如mastra/core不在移除范围内——它们是对问题的长期归档信息这正体现了只动状态标签、不碰其他元数据的克制设计。幂等与防重为什么评论已存在就不重复发布SKILL.md 反复强调除非该评论已存在与仅当status: pending-close尚不存在时添加这是为重复执行replay / re-entry设计的幂等保护。结合completeIssue的idempotencyKey整套机制可以归纳为进入done阶段的动作是幂等的同一次 ingress 不会重复调用技能技能内部的写操作也各自幂等标签添加、评论发布都先检查再写入即使技能因重放被再次执行也不会产生重复评论或重复标签关闭 Issue 被明确排除在技能职责之外避免 Agent 在边界不清时做出不可逆操作。从源码结构看mastracode/factory/src/boards/work.ts 中done为kind: terminal终态Work 看板另有canceled终态两者均无对外二次流转整个收尾链条是单向且闭合的——技能完成后流水线不再请求新的阶段流转这与 SKILL.md 最后一条Do not request another Factory transition完全对应。运行前提与验证方式要实际看到该技能被执行部署环境需要满足 mastracode/factory/README.md 描述的基本条件配置好FactoryStorage后端、GitHub 集成、已连接的项目仓库并通过宿主应用的prepare()→new Mastra(...)→finalize()序列完成装配。同时满足一个 GitHub Issue 已被接单并走完intake → triage → planning → execute → review流程卡片通过受管制的factory_transition_work_item被推进到 Work 看板的done阶段运行环境拥有对目标仓库调用gh issue view与gh issue edit的权限。验证时可以对比 Issue 标签前后状态执行前若存在status: needs triage/status: auto-triaged/status: needs approval中的任意组合执行后应全部消失若 Issue 原本 open则新增status: pending-close与This issue has now been marked as done.评论若原本 closed则两者都不出现。routes/skills.test.ts与skills/catalog.ts的测试/实现可用于验证技能在技能清单中的注册与 frontmatter 解析是否正确mastracode/factory/src/routes/skills.test.ts#L510-L513。小结factory-complete-issue是 Mastra Software Factory 收尾环节的关键拼图它由 Work 看板done终态的onEnter处理器自动触发通过一组精确、幂等的 GitHub 标签与评论操作把流水线已完成这一事实同步回源 Issue同时把关闭动作留给外部机制。理解它也就理解了 Factory 如何在整个软件交付循环中维持卡片状态、Issue 状态、标签状态三者的一致性。【免费下载链接】mastraMastra is the modern TypeScript framework for AI-powered applications and agents.项目地址: https://gitcode.com/GitHub_Trending/ma/mastra创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考