技能版本 1.0.0

product-management-workflows

Complete product management workflows including feature specs, roadmap management, stakeholder updates, user research synthesis, competitive analysis, and metrics review

价格

免费

  • 安装:免费

在组织开通时一次性收取;再次读取清单或下载不重复收费。

以上为公开标价。你的组织可能有协议价,以控制台显示的价格为准。

如何使用

  1. 为组织安装

    开通即安装:组织固定使用开通时的版本(当前为 1.0.0)。升级到新版本需要取消后重新开通。

  2. 创建凭证

    客户端使用组织凭证读取;绑定到数字人后,数字人使用绑定凭证按需加载。请求中携带:

    Authorization: Bearer $ZGI_MARKET_KEY

  3. 读取清单与安装包

    清单列出版本、文件和校验值;安装包是一个 zip 文件。

    读取清单
    curl "https://market-api.zgi.im/v1/market/skills/product-management-workflows/manifest" \
      -H "Authorization: Bearer $ZGI_MARKET_KEY"
    下载安装包
    curl "https://market-api.zgi.im/v1/market/skills/product-management-workflows/package" \
      -H "Authorization: Bearer $ZGI_MARKET_KEY" \
      -o product-management-workflows.zip

    读取清单和下载安装包不计入用量。下载后请用响应头中的 SHA-256 校验文件。

技能说明

名称
product-management-workflows
说明
Complete product management workflows including feature specs, roadmap management, stakeholder updates, user research synthesis, competitive analysis, and metrics review
仅指令

技能包内没有脚本文件:这个技能是供模型阅读的文本。

SKILL.md 节选

# Product Management Workflows

This skill provides comprehensive product management capabilities across the full PM workflow. Use these workflows to write specs, plan roadmaps, communicate with stakeholders, synthesize research, analyze competitors, and review metrics.

## Available Workflows

### 1. Write Feature Spec / PRD

Write a feature specification or product requirements document (PRD).

#### When to Use
- Speccing out a new feature or product
- Creating a PRD from a problem statement
- Documenting requirements for a feature idea
- Need structured requirements for engineering

#### Workflow

**Step 1: Understand the Feature**

Ask the user what they want to spec. Accept any of:
- A feature name ("SSO support")
- A problem statement ("Enterprise customers keep asking for centralized auth")
- A user request ("Users want to export their data as CSV")
- A vague idea ("We should do something about onboarding drop-off")

**Step 2: Gather Context**

Ask the user for the following. Be conversational — do not dump all questions at once. Ask the most important ones first and fill in gaps as you go:

- **User problem**: What problem does this solve? Who experiences it?
- **Target users**: Which user segment(s) does this serve?
- **Success metrics**: How will we know this worked?
- **Constraints**: Technical constraints, timeline, regulatory requirements, dependencies
- **Prior art**: Has this been attempted before? Are there existing solutions?

User can provide context through:
- Pasted text or descriptions
- Uploaded files (existing docs, research)
- Screenshots or mockups
- Links to related work

**Step 3: Generate the PRD**

Produce a structured PRD with these sections. See the **feature-spec** skill for detailed guidance on user stories, requirements categorization, acceptance criteria, and success metrics.

- **Problem Statement**: The user problem, who is affected, and impact of not solving it (2-3 sentences)
- **Goals**: 3-5 specific, measurable outcomes tied to user or business metrics
- **Non-Goals**: 3-5 things explicitly out of scope, with brief rationale for each
- **User Stories**: Standard format ("As a [user type], I want [capability] so that [benefit]"), grouped by persona
- **Requirements**: Categorized as Must-Have (P0), Nice-to-Have (P1), and Future Considerations (P2), each with acceptance criteria
- **Success Metrics**: Leading indicators (change quickly) and lagging indicators (change over time), with specific targets
- **Open Questions**: Unresolved questions tagged with who needs to answer (engineering, design, legal, data)
- **Timeline Considerations**: Hard deadlines, dependencies, and phasing

**Step 4: Review and Iterate**

After generating the PRD:
- Ask the user if any sections need adjustment
- Offer to expand on specific sections
- Offer to create follow-up artifacts (design brief, engineering ticket breakdown, stakeholder pitch)

**Output Format**: Use markdown with clear headers. Keep the document scannable — busy stakeholders should be able to read just the headers and bold text to get the gist.

**Tips**:
- Be opinionated about scope. It is better to have a tight, well-defined spec than an expansive vague one.
- If the user's idea is too big for one spec, suggest breaking it into phases and spec the first phase.
- Success metrics should be specific and measurable, not vague ("improve user experience").
- Non-goals are as important as goals. They prevent scope creep during implementation.
- Open questions should be genuinely open — do not include questions you can answer from context.

---

### 2. Roadmap Management

Update, create, or reprioritize a product roadmap.

#### When to Use
- Creating a new product roadmap
- Adding features to existing roadmap
- Reprioritizing roadmap items
- Updating status of roadmap items
- Adjusting timelines or dates
- Communicating roadmap changes

#### Workflow

**Step 1: Understand Current State**

Ask the user to describe their current roadmap or paste/upload it. Accept any format: list, table, spreadsheet, screenshot, or prose description.

SKILL.md 不止这些内容,安装后可阅读全文。

技能包内容

共 1 个文件,合计 25.4 KiB

  • SKILL.md25.4 KiB

来源与审核

审核状态
尚未审核,内容来自上游来源
许可证
未说明

审核状态是平台对上架信息的记录,不构成对上游服务质量或可用性的担保。