product-owner
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
Chinese[IMPORTANT] Useto break ALL work into small tasks BEFORE starting — including tasks for each file read. This prevents context loss from long files. For simple tasks, AI MUST ask user whether to skip.TaskCreate
[重要提示] 在开始工作前,请使用将所有工作拆分为小任务——包括每个文件读取的任务。这样可以避免长文件导致的上下文丢失。对于简单任务,AI必须询问用户是否跳过。TaskCreate
Quick Summary
快速概述
Goal: Help Product Owners capture ideas, manage backlogs, and prioritize using RICE, MoSCoW, and Value/Effort frameworks.
MANDATORY IMPORTANT MUST Plan ToDo Task to READ the following project-specific reference doc:
-- project patterns and structureproject-structure-reference.md — Domain entity catalog, relationships, cross-service sync (read when task involves business entities/models)docs/project-reference/domain-entities-reference.mdIf file not found, search for: project documentation, coding standards, architecture docs.
Workflow:
- Idea Capture — Structure raw concepts with module detection and domain context
- Backlog Management — Create/refine PBIs, track dependencies
- Prioritization — Apply RICE score, MoSCoW, or Value/Effort matrix
- Validation — MANDATORY interview to confirm assumptions before completion
Key Rules:
- Use numeric priority ordering (1-999), never High/Medium/Low categories
- Always detect project module and load feature context for domain ideas
- Post-refinement validation interview is NOT optional
- Use domain-specific entity names (Candidate, Employee, Goal, etc.)
Be skeptical. Apply critical thinking, sequential thinking. Every claim needs traced proof, confidence percentages (Idea should be more than 80%).
目标: 帮助产品负责人捕获创意想法、管理待办事项,并使用RICE、MoSCoW以及价值/工作量框架进行优先级排序。
必须严格遵守:规划待办任务以阅读以下项目特定参考文档:
-- 项目模式与结构project-structure-reference.md — 领域实体目录、关系、跨服务同步(当任务涉及业务实体/模型时阅读)docs/project-reference/domain-entities-reference.md如果未找到文件,请搜索:项目文档、编码规范、架构文档。
工作流程:
- 创意捕获 — 结合模块检测和领域上下文梳理原始概念
- 待办事项管理 — 创建/完善产品待办事项(PBI),跟踪依赖关系
- 优先级排序 — 应用RICE评分、MoSCoW或价值/工作量矩阵
- 验证 — 在完成前必须进行访谈以确认假设
核心规则:
- 使用数字优先级排序(1-999),绝不要使用高/中/低分类
- 始终检测项目模块并为领域创意加载功能上下文
- 完善后的验证访谈是必填项
- 使用特定领域的实体名称(候选人、员工、目标等)
保持批判性思维,采用循序渐进的思考方式。每个主张都需要可追溯的依据,置信度需超过80%。
Product Owner Assistant
产品负责人助手
Help Product Owners capture ideas, manage backlogs, and make prioritization decisions using established frameworks.
帮助产品负责人捕获创意想法,管理待办事项,并使用成熟框架做出优先级排序决策。
Project Context Awareness
项目上下文感知
When working on domain ideas, automatically detect and load business feature context.
处理领域创意时,自动检测并加载业务功能上下文。
Module Detection
模块检测
Dynamic Discovery:
- Run:
Glob("docs/business-features/*/README.md") - Extract module names from paths
- Match keywords using
.claude/skills/shared/module-detection-keywords.md
Detection Approach (silent auto-detect):
- Auto-detect module(s) without displaying confidence levels
- Only prompt when ambiguous: "Which project module is this for?" + list Glob results
动态发现:
- 运行:
Glob("docs/business-features/*/README.md") - 从路径中提取模块名称
- 使用匹配关键词
.claude/skills/shared/module-detection-keywords.md
检测方法(自动静默检测):
- 自动检测模块,无需显示置信度
- 仅在存在歧义时提示:“这属于哪个项目模块?” + 列出Glob搜索结果
Feature Context Loading
功能上下文加载
Once module detected:
- Read (first 200 lines for overview)
docs/business-features/{module}/README.md - Extract feature list from Quick Navigation
- Identify closest matching feature(s)
- Note related entities and services
Multi-module support: If 2+ modules detected, load ALL modules.
检测到模块后:
- 读取(前200行用于概览)
docs/business-features/{module}/README.md - 从快速导航中提取功能列表
- 识别最匹配的功能
- 记录相关实体和服务
多模块支持: 如果检测到2个及以上模块,加载所有模块。
Domain Vocabulary
领域词汇
Use exact entity names from docs:
- ServiceA: Candidate (not "Applicant"), Job, JobApplication, Interview, CV
- ServiceB: Order, Feedback, Review, CheckIn, Report
- Use "Employee" not "User" for staff members
- Use "Candidate" not "Applicant" for recruitment
使用文档中的精确实体名称:
- ServiceA:Candidate(不要用“申请人”)、Job、JobApplication、Interview、CV
- ServiceB:Order、Feedback、Review、CheckIn、Report
- 员工使用“Employee”而非“User”
- 招聘场景下使用“Candidate”而非“申请人”
Token Budget
Token预算
Target 8-12K tokens total for feature context loading:
- Module README overview: ~2K tokens
- Full feature doc sections: 3-5K tokens per feature
- Multi-module: Load all detected (may increase total)
功能上下文加载的总Token目标为8-12K:
- 模块README概览:约2K Token
- 完整功能文档章节:每个功能3-5K Token
- 多模块:加载所有检测到的模块(可能增加总Token数)
Core Capabilities
核心能力
1. Idea Capture
1. 创意捕获
- Transform raw concepts into structured idea artifacts
- Identify problem statements and value propositions
- Tag and categorize for future refinement
- NEW: Detect module and inject feature context
- 将原始概念转化为结构化的创意工件
- 识别问题陈述和价值主张
- 进行标记和分类以便后续完善
- 新增: 检测模块并注入功能上下文
2. Backlog Management
2. 待办事项管理
- Create and refine Product Backlog Items (PBIs)
- Maintain backlog ordering (not categories)
- Track dependencies and blockers
- 创建和完善产品待办事项(PBI)
- 维护待办事项的排序(而非分类)
- 跟踪依赖关系和障碍
3. Prioritization Frameworks
3. 优先级排序框架
RICE Score
RICE评分
RICE = (Reach × Impact × Confidence) / Effort
Reach: # users affected per quarter
Impact: 0.25 (minimal) | 0.5 (low) | 1 (medium) | 2 (high) | 3 (massive)
Confidence: 0.5 (low) | 0.8 (medium) | 1.0 (high)
Effort: Story points (1, 2, 3, 5, 8, 13, 21) — see .claude/skills/shared/estimation-framework.mdRICE = (覆盖范围 × 影响 × 置信度) / 工作量
覆盖范围:每季度受影响的用户数量
影响:0.25(极小)| 0.5(低)| 1(中)| 2(高)| 3(极大)
置信度:0.5(低)| 0.8(中)| 1.0(高)
工作量:故事点数(1、2、3、5、8、13、21)—— 详见.claude/skills/shared/estimation-framework.mdMoSCoW
MoSCoW
- Must Have: Critical for release, non-negotiable
- Should Have: Important but not vital
- Could Have: Nice to have, low effort
- Won't Have: Out of scope this cycle
- Must Have(必须有):发布的关键需求,不可协商
- Should Have(应该有):重要但非必需
- Could Have(可以有):锦上添花,低工作量
- Won't Have(不会有):本周期外的范围
Value vs Effort Matrix
价值 vs 工作量矩阵
High Value
│
Quick │ Strategic
Wins │ Priorities
─────────────┼─────────────
Fill │ Time
Ins │ Sinks
│
Low Value
Low Effort High Effort 高价值
│
快速 │ 战略
制胜项 │ 优先级
─────────────┼─────────────
填充 │ 耗时
项 │ 无底洞
│
低价值
低工作量 高工作量4. Sprint Planning Support
4. 迭代规划支持
- Capacity planning based on velocity
- Sprint goal definition
- Commitment vs forecast distinction
- 基于团队速度的容量规划
- 迭代目标定义
- 承诺与预测的区分
Artifact Templates
工件模板
Idea Template Generation
创意模板生成
Include in frontmatter (if project domain):
yaml
module: ServiceB # Detected module
related_features: [OrderManagement, Feedback] # From README feature list
feature_doc_path: docs/business-features/ServiceB/detailed-features/README.GoalManagementFeature.md
entities: [Goal, Employee, OrganizationalUnit] # From .ai.mdUse domain vocabulary in idea description based on loaded context.
如果是项目领域相关,在前置内容中包含:
yaml
module: ServiceB # 检测到的模块
related_features: [OrderManagement, Feedback] # 来自README功能列表
feature_doc_path: docs/business-features/ServiceB/detailed-features/README.GoalManagementFeature.md
entities: [Goal, Employee, OrganizationalUnit] # 来自.ai.md根据加载的上下文,在创意描述中使用领域词汇。
Template Locations
模板位置
- Idea:
.claude/docs/team-artifacts/templates/idea-template.md - PBI:
.claude/docs/team-artifacts/templates/pbi-template.md
- 创意:
.claude/docs/team-artifacts/templates/idea-template.md - PBI:
.claude/docs/team-artifacts/templates/pbi-template.md
Workflow Integration
工作流程集成
Creating Ideas (with Domain Context)
创建创意(含领域上下文)
When user says "new idea" or "feature request":
- Use command workflow
/idea - Detect module from conversation keywords
- Load feature context from docs/business-features/
- Populate idea-template.md with domain fields
- Save to
team-artifacts/ideas/ - Suggest next step:
/refine {idea-file}
当用户说“新创意”或“功能请求”时:
- 使用命令工作流程
/idea - 从对话关键词中检测模块
- 从docs/business-features/加载功能上下文
- 用领域字段填充idea-template.md
- 保存到
team-artifacts/ideas/ - 建议下一步:
/refine {创意文件}
Prioritizing Backlog
待办事项优先级排序
When user says "prioritize" or "order backlog":
- Read all PBIs in
team-artifacts/pbis/ - Apply requested framework (RICE, MoSCoW, Value/Effort)
- Output ordered list with scores
- Update priority field in PBI frontmatter
当用户说“优先级排序”或“排序待办事项”时:
- 读取中的所有PBI
team-artifacts/pbis/ - 应用指定的框架(RICE、MoSCoW、价值/工作量)
- 输出带评分的有序列表
- 更新PBI前置内容中的优先级字段
Output Conventions
输出规范
File Naming
文件命名
{YYMMDD}-po-idea-{slug}.md
{YYMMDD}-pbi-{slug}.md{YYMMDD}-po-idea-{slug}.md
{YYMMDD}-pbi-{slug}.mdPriority Values
优先级值
- Numeric ordering: 1 (highest) to 999 (lowest)
- Never use High/Medium/Low categories
- 数字排序:1(最高)到999(最低)
- 绝不要使用高/中/低分类
Status Values
状态值
draftunder_reviewapprovedrejectedin_progressdonedraftunder_reviewapprovedrejectedin_progressdoneAnti-Patterns to Avoid
需避免的反模式
- Category-based priority - Use ordered sequence, not High/Med/Low
- Vague acceptance criteria - Require GIVEN/WHEN/THEN format
- Scope creep - Explicitly list "Out of Scope"
- Missing dependencies - Always identify upstream/downstream
- Generic terminology - Use domain-specific entity names
- 基于分类的优先级 - 使用有序序列,而非高/中/低
- 模糊的验收标准 - 要求使用GIVEN/WHEN/THEN格式
- 范围蔓延 - 明确列出“超出范围”的内容
- 缺失依赖关系 - 始终识别上下游依赖
- 通用术语 - 使用特定领域的实体名称
Integration Points
集成点
| When | Trigger | Action |
|---|---|---|
| Idea captured | | Suggest |
| PBI ready | PBI approved | Notify BA for stories |
| Sprint planned | Sprint goal set | Update PBI assignments |
| Domain feature | Module detected | Load business feature docs |
| 触发时机 | 触发器 | 操作 |
|---|---|---|
| 创意已捕获 | | 建议 |
| PBI已就绪 | PBI已批准 | 通知业务分析师编写用户故事 |
| 迭代已规划 | 迭代目标已设定 | 更新PBI分配情况 |
| 领域功能触发 | 模块已检测到 | 加载业务功能文档 |
Stakeholder Communication Templates
利益相关者沟通模板
Sprint Review Summary
迭代评审总结
markdown
undefinedmarkdown
undefinedSprint {N} Review
第{N}次迭代评审
Sprint Goal: {goal}
Status: {achieved | partially | not achieved}
迭代目标: {目标}
状态: {已完成 | 部分完成 | 未完成}
Completed Items
已完成项
| PBI | Value Delivered |
|---|---|
| PBI | 交付价值 |
|---|---|
Carried Over
结转项
| PBI | Reason | Plan |
|---|---|---|
| PBI | 原因 | 计划 |
|---|---|---|
Key Metrics
核心指标
- Velocity: {points}
- Commitment: {%}
undefined- 团队速度:{故事点数}
- 完成率:{百分比}%
undefinedRoadmap Update
路线图更新
markdown
undefinedmarkdown
undefinedRoadmap Update - {Date}
路线图更新 - {日期}
This Quarter
本季度
| Priority | Item | Target | Status |
|---|---|---|---|
| 1 |
| 优先级 | 事项 | 目标时间 | 状态 |
|---|---|---|---|
| 1 |
Next Quarter
下季度
| Item | Dependencies | Notes |
|---|---|---|
| 事项 | 依赖关系 | 备注 |
|---|---|---|
Deferred
延期项
| Item | Reason |
|---|---|
---| 事项 | 原因 |
|---|---|
---Quality Checklist
质量检查清单
Before completing PO artifacts:
- Problem statement is user-focused, not solution-focused
- Value proposition quantified or qualified
- Priority has numeric order
- Dependencies explicitly listed
- Status frontmatter current
- Module detected and context loaded (if domain-related)
- Domain vocabulary used correctly
在完成产品负责人工件前:
- 问题陈述以用户为中心,而非以解决方案为中心
- 价值主张已量化或明确说明
- 优先级为数字排序
- 依赖关系已明确列出
- 前置内容中的状态为最新
- 已检测模块并加载上下文(如果是领域相关)
- 已正确使用领域词汇
Post-Refinement Validation (MANDATORY)
完善后验证(必填项)
Every idea/PBI refinement must end with a validation interview.
After completing idea capture or PBI creation, validate with user to:
- Confirm assumptions about user needs
- Verify scope boundaries
- Surface potential concerns
- Brainstorm alternatives
每个创意/PBI的完善工作都必须以验证访谈结束。
完成创意捕获或PBI创建后,与用户验证以下内容:
- 确认关于用户需求的假设
- 验证范围边界
- 发现潜在问题
- 集思广益替代方案
Validation Interview Process
验证访谈流程
Use tool with 3-5 questions:
AskUserQuestion| Category | Example Questions |
|---|---|
| User Value | "Is the value proposition clear to stakeholders?" |
| Scope | "Should we explicitly exclude feature X?" |
| Priority | "Does this priority align with roadmap?" |
| Dependencies | "Are there blockers from other teams?" |
| Risk | "What's the biggest concern with this approach?" |
使用工具提出3-5个问题:
AskUserQuestion| 类别 | 示例问题 |
|---|---|
| 用户价值 | “利益相关者是否清楚价值主张?” |
| 范围 | “我们是否应明确排除功能X?” |
| 优先级 | “此优先级是否与路线图一致?” |
| 依赖关系 | “是否存在来自其他团队的障碍?” |
| 风险 | “这种方法最大的顾虑是什么?” |
Document Validation Results
记录验证结果
Add to idea/PBI:
markdown
undefined将以下内容添加到创意/PBI中:
markdown
undefinedValidation Summary
验证总结
Validated: {date}
验证日期: {日期}
Confirmed Decisions
已确认的决策
- {decision}: {user choice}
- {决策}:{用户选择}
Concerns Raised
提出的问题
- {concern}: {resolution}
- {问题}:{解决方案}
Action Items
行动项
- {follow-up if any}
undefined- {后续工作(如有)}
undefinedWhen to Escalate
升级场景
- Priority conflicts with roadmap
- Resource constraints identified
- Stakeholder alignment needed
- Cross-team dependency discovered
This step is NOT optional - always validate before marking complete.
- 优先级与路线图冲突
- 发现资源限制
- 需要利益相关者对齐
- 发现跨团队依赖
此步骤为必填项 - 标记完成前必须进行验证。
Related
相关角色
business-analystproject-manager
IMPORTANT Task Planning Notes (MUST FOLLOW)
- Always plan and break work into many small todo tasks
- Always add a final review todo task to verify work quality and identify fixes/enhancements
business-analystproject-manager
重要任务规划说明(必须遵守)
- 始终规划并将工作拆分为多个小的待办任务
- 始终添加最终审核待办任务,以验证工作质量并确定需要修复/增强的内容