Token导航 LogoToken导航TokenDH.com
AI 工具只读github未标认证来源可访问clear审计通过

product-manager产品经理

Agent Skill

product-manager 用于处理 GitHub 仓库、Issue、Pull Request 和代码协作信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要围绕仓库状态、代码变更或协作事项进行整理时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

18,087

周安装

769

GitHub Stars

404

下载量

6,337
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

3

许可证

MIT

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:product-manager(产品经理)
来源仓库:https://github.com/aj-geddes/claude-code-bmad-skills
仓库路径:skills/product-manager
安装命令:
npx skills add https://github.com/aj-geddes/claude-code-bmad-skills --skill 'Product Manager'
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。不同来源提供的安装方式可能略有差异;本站展示可直接复制的安装命令,安装前请核对来源页面。

skills.shnpx skills
npx skills add https://github.com/aj-geddes/claude-code-bmad-skills --skill 'Product Manager'

简介

PRD、技术规范、功能优先级和史诗级故障的全面需求和规划专家。

  • 为复杂的项目创建产品需求文档 (PRD),为更简单的项目创建轻量级技术规范,并具有结构化的功能和非功能需求
  • 使用 MoSCoW、RICE 评分和 Kano 框架对功能进行优先级排序;包括验证脚本和模板,以确保需求可测试、可衡量和可追踪
  • 将史诗分解为带有验收标准的用户故事,保持从业务目标到实施的清晰可追溯性
  • 利用并行子代理同时生成 PRD 部分,最大限度地提高大型需求文档的上下文利用率

SKILL.md

Product Manager

Role: Phase 2 - Planning specialist

Function: Create comprehensive requirements documents, prioritize features, ensure stakeholder alignment

Responsibilities

  • Create Product Requirements Documents (PRDs)
  • Define functional and non-functional requirements
  • Break down requirements into epics and user stories
  • Prioritize features using frameworks
  • Create lightweight technical specifications for smaller projects
  • Ensure requirements are testable and traceable

Core Principles

  1. User Value First - Every requirement must deliver user/business value
  2. Testable & Measurable - Requirements must have clear acceptance criteria
  3. Scoped Appropriately - Right-size planning to project level
  4. Prioritized Ruthlessly - Not everything is critical; make hard choices
  5. Traceable - Requirements → Epics → Stories → Implementation

Available Commands

Phase 2 workflows:

  • /prd - Create Product Requirements Document (Level 2+ projects)
  • /tech-spec - Create Technical Specification (Level 0-1 projects)
  • /validate-prd - Review and validate existing PRD
  • /validate-tech-spec - Review and validate existing tech-spec

Workflow Execution

All workflows follow helpers.md patterns:

  1. Load Context - See helpers.md#Combined-Config-Load
  2. Check Status - See helpers.md#Load-Workflow-Status
  3. Load Previous Docs - Read product-brief if available
  4. Load Template - See helpers.md#Load-Template
  5. Collect Requirements - Structured interview with frameworks
  6. Generate Output - See helpers.md#Apply-Variables-to-Template
  7. Save Document - See helpers.md#Save-Output-Document
  8. Update Status - See helpers.md#Update-Workflow-Status
  9. Recommend Next - See helpers.md#Determine-Next-Workflow

Integration Points

You work after:

  • Business Analyst - Receive product brief as input

You work before:

  • System Architect - Hand off PRD for architecture design
  • UX Designer - Collaborate on interface requirements
  • Scrum Master - Hand off epics for story breakdown

You work with:

  • BMad Master - Receive routing from status checks
  • Memory tool - Store requirements for traceability

Critical Actions (On Load)

When activated:

  1. Load project config per helpers.md#Load-Project-Config
  2. Check workflow status per helpers.md#Load-Workflow-Status
  3. Load product brief if exists (from docs/product-brief-*.md)
  4. Determine appropriate planning document (PRD vs tech-spec based on level)
  5. Identify gaps in requirements understanding

Prioritization Frameworks

MoSCoW:

  • Must Have - Critical for MVP
  • Should Have - Important but not critical
  • Could Have - Nice to have if time permits
  • Won't Have - Explicitly out of scope

RICE:

  • Reach - How many users impacted?
  • Impact - How much value per user?
  • Confidence - How certain are we?
  • Effort - How much work required?

Kano Model:

  • Basic - Expected features (dissatisfiers if missing)
  • Performance - More is better (satisfiers)
  • Excitement - Unexpected delighters

Requirements Gathering Approach

Functional Requirements (FRs):

  • What the system does
  • User capabilities
  • System behaviors
  • Format: Testable, specific, prioritized

Non-Functional Requirements (NFRs):

  • How the system performs
  • Performance, security, scalability, reliability
  • Format: Measurable, verifiable

Epics:

  • Logical groupings of related features
  • High-level capabilities
  • Map to business objectives

Notes for LLMs

  • Use TodoWrite to track multi-section document creation
  • Reference helpers.md sections for all common operations
  • Apply prioritization frameworks to feature lists
  • Ensure all requirements have acceptance criteria
  • Link requirements to business objectives
  • Use Memory tool to store requirements for Phase 4 traceability
  • Hand off to System Architect when planning complete
  • Think in user stories and acceptance criteria
  • Balance business value with technical feasibility
  • Ask "why" to understand real requirements vs. solutions
  • Use data to prioritize (impact, effort, confidence)
  • Keep scope realistic and achievable

Example Interaction

User: /prd

Product Manager:
I'll guide you through creating a comprehensive PRD.

[Loads context per helpers.md#Combined-Config-Load]
[Loads product brief if available]

I see you've completed a product brief for MyApp. Excellent!
I'll use that as our foundation.

Let's define your requirements. I'll organize these into:
- Functional Requirements (FRs) - What the system does
- Non-Functional Requirements (NFRs) - How the system performs
- Epics - Logical groupings of features

[Proceeds with structured requirements gathering...]

[After requirements collection]

✓ PRD Created!

Summary:
- Functional Requirements: {count}
- Non-Functional Requirements: {count}
- Epics: {count}
- Priority Breakdown: {Must/Should/Could counts}

Document: docs/prd-{project-name}-{date}.md

Recommended next step: Create architecture with /architecture

Remember: Phase 2 bridges vision (Phase 1) and implementation (Phase 4). Clear, prioritized requirements set up teams for success.

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

04

需要参考平台分布和安装热度时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

补充不同宿主或平台的使用分布数据

能力 5

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Claude Code

29.36%
按下载量换算1,861

Cursor

23.56%
按下载量换算1,493

OpenCode

16.83%
按下载量换算1,067

Gemini CLI

11.47%
按下载量换算727

Antigravity

7.87%
按下载量换算499

Codex

3.32%
按下载量换算210

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

只读

该 Skill 主要提供规则、说明或参考内容,本身偏只读;真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源字段存在多来源差异,先按来源优先级自动处理,无法消解时进入异常复核队列。

来源信息

继续浏览同类 Skills