AgentSkillsCN

prd

将零散的想法转化为结构化的PRD（产品需求文档），在工程开发开始之前，先获得利益相关方的一致认可。适用于：撰写PRD、产品需求、需求文档、功能规格。

SKILL.md
--- frontmatter
name: prd
description: "Transform messy ideas into structured PRDs that get stakeholder alignment before engineering starts building. Use when: write prd, product requirements, requirements document, feature spec."

PRD Generator

Transform messy ideas into structured PRDs that get stakeholder alignment before engineering starts building.

When to Use This Skill

  • •Starting a new feature from scratch
  • •Formalizing something you've been discussing verbally
  • •Getting alignment before engineering starts work

What You'll Need

  • •Clear description of the problem you're trying to solve
  • •Evidence that this problem is real (research, data, feedback)
  • •Initial thoughts on approach (optional)

Process

Step 1: Check Your Context

First, read the user's context files to understand what you already know (context/product.md, personas.md, etc.). If they just downloaded Second, these might be empty — that's fine, I'll ask for what I need.

What to look for:

  • •context/ROADMAP.md - the product vision
  • •context/VISION.md - the product vision
  • •context/UL.md - the ubiquitous language definitions
  • •context/user-stories.md - early drafts of user experiences we want to create
  • •context/product.md — Is this feature already on the roadmap? What's the current state?
  • •context/personas.md — Who experiences this problem? What do we know about their pain?
  • •context/company.md — Does this align with strategic priorities?
  • •context/competitors.md — Do competitors have this? Is it table stakes?

Tell the user what you found. For example:

"I found 'Workload Balancer' in your product roadmap — it's marked as Planned for Q2. Your PM persona (Jordan) mentions finding out about overloaded team members only when deadlines slip. Let me use this context for the PRD."

This helps users understand that Second is reading their files and getting smarter over time.

Step 2: Problem Clarification

With context in hand, ask only what's missing. Don't re-ask things you already know.

Critical inputs (ask if missing):

  1. •What problem are you trying to solve?
  2. •Who experiences this problem?

Nice-to-have (generate with assumptions if missing): 3. How do you know it's a real problem? (evidence) 4. Why is it important to solve now?

If context is thin, prompt for uploads: When you don't have enough context to write a solid PRD, offer to help the user add more:

"I don't have much context about your users. Do you have any of these I could look at?

  • •User research or interview notes
  • •Support tickets or feedback
  • •Analytics or usage data

You can drop files in your context/ folder or paste them here."

This teaches users how to make Second smarter over time.

If you have enough from context files, say so:

"Based on your personas and product docs, I have enough to draft this PRD. I'll flag any assumptions."

Step 3: Success Criteria

Define what success looks like with BOTH lagging and leading indicators:

Lagging Indicators (post-launch outcomes):

  • •What behavior or metric should change?
  • •How will you measure if this worked?
  • •What's the target and timeframe?

Leading Indicators (pre-launch signals):

  • •What early signals predict success before launch?
  • •Examples: Internal dogfooding usage → predicts adoption, Beta support tickets → predicts quality, Time-to-value in onboarding → predicts retention

Important: If you don't have actual metrics, don't make them up. Instead:

  • •Mark them as [PLACEHOLDER — need actual baseline]
  • •Or ask: "What metric would tell you this worked? Do you have a current baseline?"

Step 4: Dependencies Check

Before diving into solution, identify what this feature depends on:

  • •Feature dependencies — Does this require other features/systems to exist first?
  • •Team dependencies — Do we need work from other teams (design, eng, legal)?
  • •External dependencies — Third-party APIs, vendor integrations, compliance?

Flag the critical path — which dependency would block launch if delayed?

Step 5: Solution Exploration

Once the problem is clear:

  • •What's your proposed approach?
  • •Include 2-3 concrete user stories to illustrate the solution
  • •What's explicitly OUT of scope?
  • •What are the key risks or assumptions?

Step 6: Risk Assessment (Value/Usability/Feasibility/Viability)

Evaluate risks across four dimensions (check ✅ when validated, leave ⬜ if still uncertain):

Risk TypeQuestionStatus
ValueWill users want this?⬜
UsabilityCan users figure it out?⬜
FeasibilityCan we build it?⬜
ViabilityDoes it work for the business?⬜

Step 7: Generate PRD

Output follows this structure:

  1. •Context Summary (what you pulled from their files)
  2. •Problem Statement
  3. •Evidence
  4. •Success Criteria (Lagging + Leading Indicators)
  5. •Proposed Solution (with example user stories)
  6. •Non-Goals
  7. •Future Considerations (forward-looking design hints)
  8. •Dependencies (Feature, Team, External + Critical Path)
  9. •Risks & Mitigations
  10. •Open Questions (with validation experiments)

Important: Focus PRDs on WHAT to build and WHY, not HOW to build it. Leave implementation details to designers and engineers.

Output Template

markdown
# PRD: [Feature Name]

**Status:** Draft | Problem Review | Solution Review | Approved
**Owner:** [PM Name]
**Last Updated:** [Date]
**Target Release:** [Date/Quarter]
**Availability:** [All users | Business tier | Pro tier | Enterprise only]
**Rationale:** [Why this tier?]

## Context

_What I found in your files:_

- **Roadmap:** [Feature status from product.md, or "Not currently on roadmap"]
- **Persona pain:** [Relevant quote or insight from personas.md]
- **Strategic fit:** [How this aligns with priorities from company.md]
- **Competitive:** [Do competitors have this? From competitors.md]

## Problem

[What problem? Who has it? In what situation?]

## Evidence

[User research, support tickets, data, quotes]

_Mark assumptions clearly:_

- ✅ **Validated:** [Evidence you have]
- ⚠️ **Assumed:** [Things you're inferring — flag for validation]

## Success Criteria

### Lagging Indicators (post-launch outcomes)

| Metric     | Current                | Target  | Timeframe |
| ---------- | ---------------------- | ------- | --------- |
| [Metric 1] | [Value or PLACEHOLDER] | [Value] | [When]    |
| [Metric 2] | [Value or PLACEHOLDER] | [Value] | [When]    |

### Leading Indicators (pre-launch signals)

| Metric     | Current                | Target  | What This Predicts         |
| ---------- | ---------------------- | ------- | -------------------------- |
| [Metric 1] | [Value or PLACEHOLDER] | [Value] | [e.g., predicts adoption]  |
| [Metric 2] | [Value or PLACEHOLDER] | [Value] | [e.g., predicts quality]   |
| [Metric 3] | [Value or PLACEHOLDER] | [Value] | [e.g., predicts retention] |

💡 **Leading indicators help you course-correct before launch.**

## Proposed Solution

### How It Works

[Describe WHAT happens and WHY, not HOW to implement it]

**Focus on:**
- What data is required
- What outputs are provided
- Key constraints (SSR required, phone verification for spam prevention)
- High-level flow at outcome level (user does X → system does Y → user receives Z)

**Avoid:**
- UI implementation details (modal vs inline form, specific screens)
- Exact copy text or button labels
- Visual design directives (button sizes, colors, "big primary button")
- Technical implementation (session cookies, database operations)
- Prescriptive flows that belong in design/engineering specs

### User Stories (Examples)

_Include 2-3 concrete user stories to illustrate the solution and help engineering understand edge cases and scope boundaries._

**Story 1:**

- **As a** [persona]
- **I want to** [action]
- **So that** [benefit]

**Story 2:**

- **As a** [persona]
- **I want to** [action]
- **So that** [benefit]

**Story 3 (if needed):**

- **As a** [persona]
- **I want to** [action]
- **So that** [benefit]

## Non-Goals

- [What we're explicitly NOT doing]

## Future Considerations

_Features not in scope for MVP, but have **explicit evidence** they'll be needed soon enough to influence architectural decisions today._

**IMPORTANT:** Do NOT invent "maybes" without making an explicit choice. Only include features that:
1. Are **extensions of things already in Non-Goals** (e.g., Non-Goal says "No email auth" → Future Consideration for email auth)
2. Are **mentioned in user stories or context files** as likely next steps
3. Have **competitive evidence** (competitors have this, so we'll probably need it)
4. Are **explicit deferments** from risks or open questions

**Litmus test for Design Hints:** "Does this advice prevent you from painting yourself into a corner, or is it just premature implementation?"
- ✅ GOOD: "Link engagements to opportunity_id instead of hardcoding 'Show Up'" (structural decision that's hard to change later)
- ❌ BAD: "Add nullable max_participants field now" (trivial to add when needed, just premature optimization)

**If you think of potential future features but don't have evidence:** ASK the user first. Don't just add them.

**It's OK to have NO Future Considerations section** if nothing meets these criteria. Don't invent work.

| Future Capability | Likelihood | Design Hint |
| ----------------- | ---------- | ----------- |
| [Future feature from Non-Goals/Risks/Evidence] | High/Medium/Low (When) | [How to design for this now without building it] |

💡 **The pattern:** Build the **data model** for extensibility now (costs ~zero), but don't build the **UI/logic** until needed.

## Dependencies

### Feature Dependencies

- **[Feature/System]**: [Why we need it] — [Status/Timeline]
- **[Feature/System]**: [Why we need it] — [Status/Timeline]

### Team Dependencies

- **[Team]**: [What we need from them] — [Timeline]

### External Dependencies

- **[Third-party/API]**: [What we need] — [Risk if delayed]

**Critical Path:** [Which dependency blocks launch if delayed?]

💡 **Flag dependencies early to avoid last-minute surprises.**

## Risks

_Risk types: V=Value, U=Usability, F=Feasibility, B=Business Viability. Impact: H=High, M=Medium, L=Low_

| Risk   | Type    | Impact | Mitigation |
| ------ | ------- | ------ | ---------- |
| [Risk] | V/U/F/B | H/M/L  | [Plan]     |

## Open Questions

_For each unknown, suggest a validation approach to turn assumptions into testable hypotheses._

| Question     | Assumption            | How to Validate     | Timeline              |
| ------------ | --------------------- | ------------------- | --------------------- |
| [Question 1] | [What we're assuming] | [Experiment to run] | [When we need answer] |
| [Question 2] | [What we're assuming] | [Experiment to run] | [When we need answer] |

**Example:**
| Do agencies want automated balancing or manual control? | Automated preferred | 5 user interviews + prototype test | Before sprint 1 |

Framework Reference

This skill uses Marty Cagan's V/U/F/V Risk Framework from Inspired and Empowered:

  • •Value Risk: Will customers buy/use this?
  • •Usability Risk: Can users figure out how to use it?
  • •Feasibility Risk: Can engineering build it with current resources?
  • •Viability Risk: Does it work for sales, legal, finance, etc.?

The goal is to address the biggest risks BEFORE building, not after.

Tips for Best Results

  1. •Keep your context files updated — The more I know about your product, the better this PRD will be
  2. •Be honest about evidence — "I think" is fine, just label it as assumption
  3. •Non-goals are as important as goals — They prevent scope creep
  4. •Update the PRD as you learn — It's a living document, not a contract