awesome-copilot 中的 SE: Product Manager 定制 Agent从用户问到可执行 GitHub Issue 的产品管理流程【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot本文基于 awesome-copilot 仓库中的 se-product-manager-advisor.agent.md 展开完整解读这个 GitHub Copilot 定制 Agent 的工作机制它以“先提问、不假设需求”为原则围绕三大提问框架澄清用户价值再按照强制性的 Issue 规模与标签规范产出结构化的 GitHub Issue、Epic 与配套产品文档。读完后你将能够在自己的仓库中安装并使用该 Agent或 software-engineering-team 插件并理解其 Issue 模板、标签体系与假设驱动验证流程从而把产品需求管理沉淀为一套可复用的工程流程。一、Agent 定义frontmatter 与工具授权这个 Agent 以标准 Copilot 定制 Agent 文件形式存放在仓库agents/目录下文件头部是 YAML frontmatter声明了身份与能力边界name: SE: Product Manager description: Product management guidance for creating GitHub issues, aligning business value with user needs, and making># Using Copilot CLI copilot plugin install software-engineering-teamawesome-copilot单文件安装按 docs/README.agents.md 的说明点击对应 Agent 的 VS Code 安装按钮或直接下载*.agent.md文件放入目标仓库。该 Agent 在仓库 Agent 索引中注册为 “SE: Product Manager”描述与 frontmatter 一致。二、核心使命Build the Right ThingAgent 正文开篇即给出使命宣言Build the Right Thing. No feature without clear user need. No GitHub issue without business context.Ensure every feature addresses a real user need with measurable success criteria. Create comprehensive GitHub issues that capture both technical implementation and business value.其设计思路是把产品经理的工作拆成三步流水线Step 1 澄清需求Question-First→ Step 2 创建可执行的 GitHub Issue → Step 3 多请求优先级排序并配套“文档产物”与“假设驱动验证”两个支撑环节。下面按原文档结构逐一展开。三、Step 1Question-First——绝不假设需求文档明确要求每当有人提出功能请求Agent 必须先提问而不是直接接受需求。三组必问如下引号内为 Agent 实际使用的提问话术1. Whos the user?用户是谁要具体他的角色developer、manager、end customer技能水平beginner、expert使用频率daily、monthly2. What problem are they solving?在解决什么问题他们现在怎么做描述当前精确的工作流哪个环节会断掉具体痛点这个问题让他们损失多少时间/金钱3. How do we measure success?如何衡量成功怎样算“有效果”具体的度量指标目标值是多少快 50%覆盖 90% 用户节省 $X什么时候需要看到结果时间线这三组问题的输出会直接灌入后续 Issue 模板用户画像填入 User Story现状与痛点填入 Context成功指标写入 Acceptance Criteria 的 “Success [specific measurement with target]”。可以看到模板中的[specific user from step 1]、[measurable outcome from step 3]占位符与 Step 1 的输出严格对应——这是该 Agent “需求先澄清、文档后填充” 工作流的骨架。四、Step 2创建可执行的 GitHub Issue文档在此处给出了一条无例外的规则Every code change MUST have a GitHub issue. No exceptions.为此它定义了三套强制规范4.1 Issue 规模指引MANDATORY规模工作量标签适用场景Small1–3 天size: small单一组件、范围清晰Medium4–7 天size: medium多处改动、有一定复杂度Large8 天epicsize: large创建 Epic 并拆分子 Issue强制规则超过 1 周工作量的功能必须创建 Epic 并拆解为子 Issue。4.2 标签体系每个 Issue 至少 3 个标签必选三类Component组件frontend、backend、ai-services、infrastructure、documentationSize规模size: small、size: medium、size: large或epicPhase阶段phase-1-mvp、phase-2-enhanced等可选但推荐Prioritypriority: high/medium/lowTypebug、enhancement、good first issueTeamteam: frontend、team: backend4.3 完整 Issue 模板这是文档中最具复用价值的资产全文继承如下占位符为[...]可直接复制到自己的仓库作为 Issue 模板使用## Overview [1-2 sentence description - what is being built] ## User Story As a [specific user from step 1] I want [specific capability] So that [measurable outcome from step 3] ## Context - Why is this needed? [business driver] - Current workflow: [how they do it now] - Pain point: [specific problem - with data if available] - Success metric: [how we measure - specific number/percentage] - Reference: [link to product docs/ADRs if applicable] ## Acceptance Criteria - [ ] User can [specific testable action] - [ ] System responds [specific behavior with expected outcome] - [ ] Success [specific measurement with target] - [ ] Error case: [how system handles failure] ## Technical Requirements - Technology/framework: [specific tech stack] - Performance: [response time, load requirements] - Security: [authentication, data protection needs] - Accessibility: [WCAG 2.1 AA compliance, screen reader support] ## Definition of Done - [ ] Code implemented and follows project conventions - [ ] Unit tests written with ≥85% coverage - [ ] Integration tests pass - [ ] Documentation updated (README, API docs, inline comments) - [ ] Code reviewed and approved by 1 reviewer - [ ] All acceptance criteria met and verified - [ ] PR merged to main branch ## Dependencies - Blocked by: #XX [issue that must be completed first] - Blocks: #YY [issues waiting on this one] - Related to: #ZZ [connected issues] ## Estimated Effort [X days] - Based on complexity analysis ## Related Documentation - Product spec: [link to docs/product/] - ADR: [link to docs/decisions/ if architectural decision] - Design: [link to Figma/design docs] - Backend API: [link to API endpoint documentation]模板的设计要点值得注意Acceptance Criteria 强制包含可度量的成功项与失败路径Success ...与Error case: ...使验收标准同时覆盖正常流与异常流Definition of Done 内嵌量化门槛单元测试覆盖率 ≥85%、集成测试通过、至少 1 名 Reviewer 批准、PR 合并入 mainDependencies 段用 Blocked by / Blocks / Related to 三类关系显式声明 Issue 依赖图便于排期与阻塞管理Related Documentation 把 Issue 挂接到产品文档体系docs/product/、docs/decisions/的 ADR与后文“文档创建与管理”环节形成闭环。4.4 Epic 结构1 周的大功能Issue Title: [EPIC] Feature Name Labels: epic, size: large, [component], [phase] ## Overview [High-level feature description - 2-3 sentences] ## Business Value - User impact: [how many users, what improvement] - Revenue impact: [conversion, retention, cost savings] - Strategic alignment: [company goals this supports] ## Sub-Issues - [ ] #XX - [Sub-task 1 name] (Est: 3 days) (Owner: username) - [ ] #YY - [Sub-task 2 name] (Est: 2 days) (Owner: username) - [ ] #ZZ - [Sub-task 3 name] (Est: 4 days) (Owner: username) ## Progress Tracking - **Total sub-issues**: 3 - **Completed**: 0 (0%) - **In Progress**: 0 - **Not Started**: 3 ## Dependencies [List any external dependencies or blockers] ## Definition of Done - [ ] All sub-issues completed and merged - [ ] Integration testing passed across all sub-features - [ ] End-to-end user flow tested - [ ] Performance benchmarks met - [ ] Documentation complete (user guide technical docs) - [ ] Stakeholder demo completed and approved ## Success Metrics - [Specific KPI 1]: Target X%, measured via [tool/method] - [Specific KPI 2]: Target Y units, measured via [tool/method]Epic 模板相对普通 Issue 多了三块内容Business Value用户影响 / 收入影响 / 战略对齐、Sub-Issues 清单每条带预估工作量与 Owner、Progress Tracking 进度快照总数、完成百分比、进行中、未开始。其 Definition of Done 也升级为 Epic 级别所有子 Issue 合并、跨子功能的集成测试、端到端用户流测试、性能基准达标、文档齐备、干系人演示通过。五、Step 3优先级排序当存在多个并发请求时Agent 用两组问题辅助排序Impact vs Effort影响 vs 成本“这影响多少用户”impact“实现它有多复杂”effortBusiness Alignment业务对齐“它帮助我们达成 [业务目标] 吗”“如果不做会怎样”紧迫度本质上是一个二维决策框架以用户影响面和实现复杂度定象限再叠加业务目标对齐度与“不做的代价”来判断紧急性。六、文档产物每个功能请求的三个交付物文档规定针对每个功能请求Agent 需要创建三类产物Product Requirements DocumentPRD——保存到docs/product/[feature-name]-requirements.mdGitHub Issues——按上述模板创建User Journey Map用户旅程图——保存到docs/product/[feature-name]-journey.md这与仓库中同系列的 se-ux-ui-designer.agent.md 形成上下游关系UX Agent 负责 Jobs-to-be-Done 分析与旅程图Product Manager Agent 则消费这些输入并产出 PRD 与 Issue两者共同构成 SE 团队插件中“用户研究 → 需求管理”的链条。PRD 模板中的Related Documentation段也正是回指docs/product/目录的锚点。七、产品发现与验证假设驱动开发文档最后给出 5 步假设驱动开发Hypothesis-Driven Development流程Hypothesis Formation我们相信什么、为什么Experiment Design验证假设的最小方案Success Criteria能证实或证伪假设的具体指标Learning Integration洞察如何影响后续产品决策Iteration Planning基于学习继续构建必要时转向pivot这 5 步与 Issue 模板中的 “Success [specific measurement with target]” 一脉相承每个 Issue 的成功标准本身就是一次可证伪的假设。八、升级到人类的边界文档明确列出三种必须升级给人类判断的情形业务战略不清晰Business strategy unclear需要预算决策Budget decisions needed需求互相冲突Conflicting requirements并以一句总结收尾“Better to build one thing users love than five things they tolerate.”做一个用户热爱的东西好过做五个他们将就的东西。这为 Agent 的自主性划定了明确边界它负责澄清、结构化与度量但不替人做战略与预算决定。九、在仓库工程体系中的位置插件物化机制从源码结构看这个 Agent 不只是目录里的一份 Markdown而是被仓库的插件构建管线统一管理plugins/software-engineering-team/plugin.json 在extensions[com.github.awesome-copilot].agents中列出了全部 7 个 SE Agent./agents/se-product-manager-advisor.md等并声明了team、product、ux、security等关键词构建脚本 eng/materialize-plugins.mjs 中的resolveSource()负责把插件清单里的./agents/se-product-manager-advisor.md解析到仓库源文件 agents/se-product-manager-advisor.agent.md即agents/name.agent.md命名约定materializePlugins()再将其拷贝进com.github.copilot/内容目录同时依据 SPEC_FIELDS 白名单生成面向市场分支的规范 manifestdocs/README.agents.md 的 Agent 索引表中本 Agent 以 “SE: Product Manager” 注册并提供 VS Code / VS Code Insiders 安装入口。这意味着修改agents/se-product-manager-advisor.agent.md源文件后经由插件物化流程即可同步到所有引用它的插件而使用者侧只需copilot plugin install software-engineering-teamawesome-copilot一条命令即可获得完整团队。十、小结se-product-manager-advisor.agent.md是一个把产品经理方法论“提示词工程化”的范例流程层Question-First 三问 → Issue 强制规范化规模/标签/模板→ Impact vs Effort 排序三步流水线保证每个功能先有业务语境再有代码改动资产层完整 Issue 模板、Epic 模板、PRD 与旅程图的落盘路径docs/product/让需求产物可追溯、可检索边界层假设驱动验证给出度量闭环升级规则把战略与预算决策留给人类。如需在自己的项目中使用可直接安装 software-engineering-team 插件或参照本文的模板与标签体系在自己的仓库中复刻一套产品管理 Issue 规范。参考资料仓库内路径Agent 定义agents/se-product-manager-advisor.agent.md插件清单plugins/software-engineering-team/plugin.json插件说明plugins/software-engineering-team/README.mdAgent 索引与安装方式docs/README.agents.md插件物化脚本eng/materialize-plugins.mjs同系列 UX Agentagents/se-ux-ui-designer.agent.md【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考