---
name: ai-product-team-prd
description: Turn fragmented product ideas from Feishu, Telegram, chat exports, notes, interviews, or plain pasted text into a structured PRD with traceable evidence, assumptions, product-team critique, MVP scope, and next actions.
---

# AI Product Team PRD

Use this skill when the user has scattered product thoughts and wants a rigorous PRD, proposal, product brief, MVP plan, or product-team discussion summary.

The input may come from Feishu, Telegram, WeChat, Slack, interviews, screenshots transcribed by the user, meeting notes, support tickets, research notes, or raw pasted fragments. Do not require a live integration. If the user provides an export file or pasted text, work from that. If they ask you to connect to Feishu, Telegram, or another external service, ask for explicit authorization and use the available connector/tool only when the environment provides one.

## Core Promise

Convert messy signals into a PRD that a designer, engineer, PM, or founder can actually act on.

Your job is not to beautify vague notes. Your job is to:

1. Preserve evidence from the original fragments.
2. Separate facts, assumptions, decisions, and open questions.
3. Run a small virtual product team debate.
4. Make the product direction concrete enough for execution.
5. Output a PRD with MVP scope, acceptance criteria, metrics, risks, and next steps.

## Safety And Truth Rules

- Never invent user quotes, dates, customer evidence, market facts, integrations, or technical constraints.
- If a point is inferred, mark it as `Assumption`.
- If a point comes directly from user-provided material, attach a source tag like `[S03]`.
- If the source is unclear, mark it as `Unverified`.
- Do not expose private tokens, API keys, phone numbers, emails, or user identifiers in the PRD. Redact them unless the user explicitly asks to keep them.
- Do not send pasted notes to any external system unless the user explicitly authorizes that destination.
- Ask at most 5 clarifying questions before drafting. If the user prefers speed, proceed with assumptions.

## Intake Format

Accept any of these:

```text
Idea:
I want to build a small app for ...

Feishu notes:
- ...

Telegram dump:
[2026-07-30 09:15] Alice: ...

Constraints:
- Budget ...
- Team ...
- Deadline ...
```

Normalize inputs into source notes:

```text
[S01]
source: Feishu / Telegram / manual note / meeting / unknown
time: known date or unknown
speaker: known speaker or unknown
quote: direct user-provided content, shortened only if necessary
signal: pain / request / constraint / behavior / solution idea / risk / metric
confidence: high / medium / low
```

## Workflow

### 1. Triage The Raw Material

Read all fragments first. Then produce a short triage:

- `Signal count`: number of usable notes.
- `Dominant problem`: the main user/job/pain.
- `Current product idea`: what the user seems to want.
- `Missing inputs`: important gaps.
- `Recommended mode`: `fast PRD`, `council debate`, `research brief`, or `MVP spec`.

If there are fewer than 3 meaningful notes, still proceed. Ask the user for more context only if the request cannot be scoped responsibly.

### 2. Cluster The Signals

Group notes into 4-8 clusters. Each cluster should include:

- Cluster name.
- What users are trying to do.
- Evidence tags.
- Product implication.
- Confidence.

Use labels such as:

- Persona and scenario.
- Pain and motivation.
- Existing workaround.
- Feature request.
- Workflow friction.
- Trust or safety concern.
- Business constraint.
- Technical or integration constraint.

### 3. Run The Virtual Product Team

Simulate a compact product review with these roles:

- Product Lead: scope, value, sequencing, tradeoffs.
- User Researcher: jobs-to-be-done, evidence quality, user behavior.
- UX Designer: flow, information architecture, first-run experience, failure states.
- Tech Lead: feasibility, data model, integration path, operational risk.
- Growth/Business: adoption, pricing, distribution, retention.
- Red Team: reasons this can fail, hidden assumptions, abuse cases, edge cases.

For each role, output:

- 3-5 observations.
- 1 recommended decision.
- 1 concern or question.

Then synthesize:

- Agreements.
- Disagreements.
- Product decisions.
- Open questions that genuinely require the user.

### 4. Decide The Product Shape

Create a decision log. Each decision must include:

```text
D01. Decision name
Choice: ...
Why: ...
Evidence: [S01], [S04] or Assumption
Cost if wrong: low / medium / high
Reversal plan: ...
```

Favor decisions that reduce build cost and learning time. For early products, prefer a narrow MVP over a broad platform.

### 5. Draft The PRD

Output a PRD in this structure unless the user requests another format:

```markdown
# PRD: <Product / Feature Name>

## 1. One-Line Summary

## 2. Background
- Source context
- User problem
- Why now

## 3. Goals
- User goals
- Business goals
- Learning goals

## 4. Non-Goals

## 5. Target Users And Scenarios
| Persona | Scenario | Current workaround | Evidence |

## 6. Problem Statement

## 7. Proposed Solution
- Core concept
- User flow
- Key screens or touchpoints
- AI behavior, if any

## 8. MVP Scope
| Priority | Requirement | User story | Acceptance criteria | Evidence |

## 9. Out Of Scope For MVP

## 10. Functional Requirements

## 11. AI/Product Logic Requirements
- Input handling
- Summarization or reasoning behavior
- Confidence labels
- Human confirmation points
- Failure handling

## 12. Data And Integrations
- Data objects
- Fields
- Feishu / Telegram / other channel handling
- Permissions and privacy notes

## 13. Metrics
- Activation
- Engagement
- Quality
- Retention
- Risk/safety

## 14. Risks And Mitigations

## 15. Rollout Plan

## 16. Timeline And Milestones

## 17. Open Questions

## 18. Appendix: Evidence Map
```

### Requirement Quality Bar

Every MVP requirement must have:

- A user story.
- Acceptance criteria.
- Priority.
- Evidence or `Assumption`.
- Owner suggestion when useful.

Acceptance criteria should be testable. Avoid vague phrases like "better experience" unless you define how to observe it.

### AI Feature Quality Bar

If the product uses AI, define:

- Input types.
- Output format.
- Model behavior constraints.
- Hallucination handling.
- User correction loop.
- Human approval points.
- Logging or traceability needs.
- Evaluation examples.

## Output Modes

Choose one based on the user's request:

### Fast PRD

Use when the user says "直接出 PRD", "快点", "先给版本", or provides limited material.

Output:

1. Triage.
2. Assumptions.
3. PRD.
4. Next 7 actions.

### Council Debate

Use when the user asks for multiple perspectives, "帮我讨论", "产品团队", "开会", or the idea is early/uncertain.

Output:

1. Signal clusters.
2. Six-role debate.
3. Decision log.
4. PRD.

### Research Brief

Use when the notes are mostly interviews, customer feedback, support records, or market observations.

Output:

1. Evidence map.
2. JTBD.
3. User segments.
4. Opportunity areas.
5. PRD draft or product brief.

### MVP Spec

Use when the user already has a direction and needs engineering-ready scope.

Output:

1. MVP user flow.
2. Requirements table.
3. Data model.
4. Integration notes.
5. Acceptance criteria.
6. Risks.

## Clarifying Questions

Ask only questions that materially change the PRD. Prefer these:

- Who is the first user group?
- What channel will the first version run in?
- What must the MVP prove in 2 weeks?
- What data is available today?
- What budget, deadline, or team constraint is fixed?

If the user does not answer, continue with explicit assumptions.

## Final Response Style

Use the user's language by default. For Chinese users, write concise Chinese with product-team vocabulary.

Be concrete. Replace generic recommendations with actual choices, tables, and acceptance criteria.

End with the next action list, not a vague invitation.

## Quick Start Prompt

When the user wants to use the skill immediately, ask them to paste notes in this shape:

```text
请按 AI Product Team PRD Skill 处理下面这些碎片，先归类，再开产品团队讨论，最后输出 PRD。

目标:
<我想做什么>

碎片:
<从飞书、Telegram、会议、聊天里复制来的原始内容>

约束:
<预算 / 时间 / 团队 / 技术 / 渠道>

输出模式:
fast PRD / council debate / research brief / MVP spec
```