首页 / 资讯中心 / 文章详情

OpenRig exec-summary 技能解析:让 Agent 用一份执行摘要同时说服销售、管理层与工程

OpenRig exec-summary 技能解析:让 Agent 用一份执行摘要同时说服销售、管理层与工程 ★ FEATURED ARTICLE
人工智能AI Agent多智能体Agent 编排代码智能体CLI【免费下载链接】openrigBuild your own network of agents from Claude Code, Codex and Pi: persistent teams with roles, shared context and owned work.项目地址https://gitcode.com/GitHub_Trending/op/openrig点击查看免费下载本篇围绕 OpenRig 仓库中的 PM 技能exec-summary展开它规定了一个 Agent 技能如何从特性文件夹的既有产物SPEC、验证记录、背景研究、ASCII 线框图提炼出一份 600–800 词、现在时态、面向销售/管理层/工程三方读者的executive-summary.md。读完你会掌握该技能的完整输入源约定、12 节输出模板、硬性写作约束以及它在 OpenRig PM Agent 八步特性流程中的位置与技能分发机制从而理解一个「决策就绪decision-ready」文档是如何被 Agent 稳定生产出来的。技能定位一份文档三个读者exec-summary 技能定义在 skills/_canonical/pm/exec-summary/SKILL.md其 frontmatter 只有两个字段--- name: exec-summary description: Generate a 1-2 page executive summary for a feature — orients sales, leadership, and engineering from a single document. ---这里的description不是给人看的注释而是技能触发器trigger在 OpenRig 的渐进式上下文注入progressive-disclosure context injection模型里frontmatter 常驻在 Agent 的「热层」用于廉价的模式匹配正文则只在触发命中后才加载。这一点在 skills/README.md 中有明确定义「frontmatter 在 Agent 的热层对触发描述做廉价模式匹配正文在激活时加载文件夹内的引用文件按需加载」。技能正文开宗明义它为「已准备好进入开发的功能」生成执行摘要且必须从一份文档同时服务三类受众受众从文档中获取什么对应章节销售对外话术pitch、可用性口径、竞品定位The Problem / The Solution / FAQ (For Sales)管理层战略理由、机会成本、风险Why Now / Key Decisions / FAQ (For Leadership)工程行为层面的功能概览、依赖与延期项How It Works / Dependencies / FAQ (For Engineering)核心思想是避免「同一功能三套材料」PM 只写一次三个角色各取所需。产物规范executive-summary.md 的硬性约束技能对产物给出了三个不容协商的规格What You Produce位置特性文件夹feature folder内的单个executive-summary.md文件篇幅600–800 词——不含mockup 与 FAQ 部分正文核心内容「硬上限 2 页」FAQ 允许占第 3 页时态全程现在时present tense仿佛功能已经存在。现在时态这条规则值得强调它要求摘要不是「我们计划做什么」的愿景文而是「这个功能就是这样工作的」的行为描述。这直接服务于工程读者——开发者读到的是可对照实现的行为而非模糊的承诺。输入源写摘要前必须静默收集的 4 类材料技能规定了「Sources to Read」清单——动笔前从特性文件夹静默silently即不打断对话流收集全部上下文SPEC.md— 验收标准、业务规则、范围、用户故事background.md— 客户驱动因素、竞争格局、监管考量validation.md— 需求证据、现状、渴望用户desperate user、最窄切入点narrowest wedge;supporting/mockup-ascii.md— 视觉线框图摘取 2–3 个关键屏幕。从源码结构看这四类材料恰好对应 OpenRig PM Agent 八步特性流程的前序产物。packages/daemon/specs/agents/product-management/pm/guidance/role.md 定义了特性文件夹的标准结构{feature}/ ├── validation.md ← 第 2 步 office-hours 产出 ├── background.md ← 第 3 步 context-builder 产出 ├── SPEC.md ← 第 4 步 requirements-writer 产出 ├── executive-summary.md ← 第 7 步 exec-summary 产出 └── supporting/ ├── mockup-ascii.md ← 第 5 步 ui-mockup 产出 └── mockup-*.html也就是说 exec-summary 本身不产生新事实它是整个产物链的「聚合端」需求证据validation、背景background、契约SPEC、视觉叙事mockup四类证据被压缩进一份决策文档。role.md 也明确SPEC.md是特性文件夹中「唯一的需求权威」其余均为支撑性产物——这与 exec-summary 技能把 SPEC.md 列在输入源第一位的优先级一致。输出结构12 节模板逐节拆解技能内置了完整的输出模板含 YAML frontmatter 与全部章节。frontmatter 携带 5 个元数据字段让摘要本身可被程序化追踪字段取值作用titleExecutive Summary: [功能名]文档标题feature特性文件夹名锚定到具体特性statusready/in-progress/shipped生命周期状态jira工单号关联跟踪系统updated当天日期时效性标记正文共 12 节每节都有明确的内容规格逐节说明其意图与写作约束章节规格写作意图The Problem2–3 句用客户自己的语言描述痛点点名真实客户/潜在客户The Solution2–3 句现在时描述「我们构建了什么」禁用行话Who Its For—主要画像 正在等待该功能的具名客户/潜在客户Why Now—解锁哪些交易、弥合哪个竞争差距、使什么成为可能How It Works5–8 项关键能力描述真实的用户可见行为——粒度要够一个开发者理解该构建什么Key Decisions5–8 条不显而易见的业务规则与设计取舍聚焦反直觉项Visual Preview2–3 个 ASCII 屏幕从supporting/挑选「讲得出故事」的关键屏幕What Were NOT Building5–8 项关键范围外事项 简短理由Dependencies Sequencing—必须先交付什么、跨特性依赖、前置条件Success Metrics2–4 个可量化结果混用使用指标与业务指标FAQ / For Sales2–3 问何时可用、对潜在客户说什么、竞品定位FAQ / For Leadership2–3 问机会成本、战略契合、风险FAQ / For Engineering2–3 问依赖、已知风险、延期项、数据模型影响注意模板中 FAQ 被拆成三个子节For Sales / For Leadership / For Engineering与前文「一份文档、三类读者」的主张严格对应——每一类读者都能直接翻到与自己相关的那一问一答。写作指南8 条可审计的质量约束技能的 Writing Guidelines 部分给出了 8 条硬性写作规则它们实质上是一份「摘要质量验收清单」全文现在时——仿佛功能已存在客户可读——第 1–5 节Problem 到 How It Works必须让潜在客户prospect直接读懂具体而非模糊——点名交易、金额、竞争对手Key Decisions 要有惊喜感——不要罗列显而易见的事情只写反直觉的取舍Mockup 是精选的——只挑 2–3 个讲得出故事的屏幕不做全量粘贴FAQ 回答要直接——不做对冲no hedging核心内容硬上限 2 页FAQ 可占第 3 页由 What You Produce 补充正文 600–800 词mockup 与 FAQ 不计入。这套约束的组合意图很清晰用字数上限与「现在时 具体化」强制产出可决策的文档用「Key Decisions 要反直觉」防止摘要退化为 SPEC 的目录化复述。在 PM Agent 八步特性流程中的位置exec-summary 不是孤立技能它是 OpenRig 产品经理PMAgent 八步特性流程的第 7 步。packages/daemon/specs/agents/product-management/pm/agent.yaml 的profiles.default.uses.skills列出了 PM 角色装载的全部 7 个 PM 技能profiles: default: uses: skills: - office-hours - context-builder - requirements-writer - ui-mockup - plan-review - exec-summary - backlog-capture对应的八步流程见 role.md为Capture—backlog-capture把想法记入idea_backlog.mdValidate—office-hours产出带GO/REFINE/PAUSE裁决的validation.mdContext—context-builder产出background.mdRequire—requirements-writer产出SPEC.mdMockup—ui-mockup产出supporting/mockup-ascii.md与mockup-*.htmlReview—plan-review在交接前记录问题与修订Summarize—exec-summary从完整产物集the full artifact set生成executive-summary.mdHandoff— 仅在前序产物自洽后准备分支/工单交接。流程规范同时要求「每步的输出喂给下一步」且 role.md 的「Key Outputs」明确把executive-summary.md定义为「一份同时面向销售、管理层与工程的单一文档」——与技能正文的三受众定位逐字对应。值得注意的上下游耦合上游的plan-review技能在第 4 步「Generate Executive Summary」中直接写明——评审完成且问题解决后「使用 exec-summary 技能生成执行摘要保存为特性文件夹中的executive-summary.md」见 skills/_canonical/pm/plan-review/SKILL.md。也就是说 exec-summary 是 PM 技能族中唯一被其他技能显式点名的「终端产出技能」所有评审、验证、需求工作的叙事最终都收敛到它。而技能索引 skills/_canonical/core/openrig-skills/SKILL.md 对它的分类描述是「为人类撰写决策就绪的摘要writing a decision-ready summary for a human」——点出了它存在的根本理由Agent 团队的中间产物是给 Agent 读的但这一份是给人销售/管理层读并据以做决策的。技能的加载与分发机制从产品源码到 seat理解 exec-summary 如何在真实运行中生效需要看 OpenRig 的技能分发链。以 skills/README.md 与仓库脚本为证链路为产品源码source of truth for shipping技能实际打包的源码位于packages/daemon/specs/agents/shared/skills/——本技能对应 packages/daemon/specs/agents/shared/skills/pm/exec-summary/SKILL.md与仓库根镜像内容逐字一致仓库根镜像skills/_canonical/由npm run mirror-skills从产品源码严格复制而来实现见 scripts/mirror-skills.mjs镜像只读——直接编辑_canonical/中的文件是禁止的漂移检测门禁npm run test:repo会运行mirror-skills --check若产品源码变更后未重新执行镜像测试将以指明补救脚本名的清晰报错失败按 profile 装载安装 OpenRig 后技能随 npm 包分发「每个 seat 获得其 profile 选中的那些技能」。对 PM Agent 而言正是 agent.yaml 中uses.skills列出的 7 个技能。技能被 seat 自动发现通常无需显式调用若需手动查看/加载索引文档给出方式为在 profile 的uses.skills中选择或直接打开packages/daemon/specs/agents/shared/skills/pm/exec-summary/SKILL.md仓库内路径安装态下等价于rig context get读取。这条链路的工程意义技能变更与加载它的 daemon 版本在同一个 PR 中原子发布避免「技能文本与加载器版本错配」的风险而镜像 漂移门禁保证了你在仓库根目录读到的技能文本与线上加载的文本严格一致。实践要点如何写出一份符合该技能的执行摘要综合以上机制人工撰写或评审 Agent 产出执行摘要时的核对清单检查输入完备性动笔前确认特性文件夹齐备SPEC.md、background.md、validation.md、supporting/mockup-ascii.md四源缺任何一源摘要的对应章节Why Now / Key Decisions / Visual Preview就会退化为猜测核对 frontmatter 五字段title/feature/status/jira/updated其中status三态ready / in-progress / shipped是文档随功能生命周期滚动更新时的状态机计量口径600–800 词只统计正文 12 节mockup 屏幕与 FAQ 不计入核心 2 页硬上限 FAQ 第 3 页时态审计全文搜一遍「will」「going to」「planned」把它们改写为现在时的行为描述具体性审计The Problem 与 Why Now 是否点出了真实客户/交易/竞品名FAQ 是否存在「可能」「大概」类对冲措辞Key Decisions 反直觉性检查如果某条决策删掉也不损失信息说明它太显然应替换为真正有取舍张力的规则。小结exec-summary 是 OpenRig PM 技能族中把「Agent 产出的特性文档流」翻译回「人类决策语言」的终端技能它不新增事实只负责把validation.md的需求证据、background.md的竞争与监管背景、SPEC.md的行为契约和 ASCII 线框叙事压缩成一份 600–800 词、现在时、带元数据 frontmatter 与三受众 FAQ 的executive-summary.md。仓库中从 PM Agent 的 agent.yaml技能选择、role.md八步流程与产物契约、plan-review 技能显式调用到 mirror-skills 镜像门禁版本一致性构成了一条完整可追溯的「技能定义 → 流程编排 → 产物规范 → 分发一致性」证据链可作为研究「Agent 团队如何以受控方式产出面向人的决策文档」的完整样本。赞分享人工智能AI Agent多智能体Agent 编排代码智能体CLI【免费下载链接】openrigBuild your own network of agents from Claude Code, Codex and Pi: persistent teams with roles, shared context and owned work.项目地址https://gitcode.com/GitHub_Trending/op/openrig点击查看免费下载相关推荐OpenRig exec-summary 技能实战用一份文档同时向销售、管理层与工程对齐特性决策OpenRig exec summary 技能实战用一份文档同时向销售、管理层与工程对齐特性决策 导读 本文讲解 OpenRig 内置的 exec summa人工智能AI Agent多智能体Agent 编排代码智能体CLI解决GAN训练不稳定难题PyTorch-Spectral-Normalization-GAN核心代码逐行解读解决GAN训练不稳定难题PyTorch Spectral Normalization GAN核心代码逐行解读 PyTorch Spectral NormaliClaude Code Agent Summary 生成提示词解析3–5 词的现在进行时行动摘要规范Claude Code Agent Summary 生成提示词解析3–5 词的现在进行时行动摘要规范 Agent Summary代理摘要是 Claude文档提示工程人工智能上一篇企业级AI工作流编排实战5个深度技巧快速构建智能应用下一篇在Windows上免费体验macOS5步搭建Hyper-V虚拟机完整指南创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
阅读完成 · 觉得有帮助?
咨询建站