prd

Files (1)

• SKILL.md

SKILL.md (first lines)

## Artifact Types

| Artifact | When to Use |
|---|---|
| **Full PRD** | New product or major feature needing cross-functional alignment |
| **User Stories** | Breaking down a feature into implementable units |
| **Feature Spec** | Smaller feature not warranting a full PRD |
| **Competitive Analysis** | Evaluating market landscape or justifying decisions |
| **Release Notes** | Communicating shipped changes to users |
| **Stakeholder Update** | Reporting progress to leadership |

If ambiguous, ask which artifact before proceeding.

## Process

1. **Identify artifact type** from the table above
2. **Gather context** — ask user for missing critical info rather than inventing it
3. **Generate** using the appropriate structure below

## Full PRD Structure

```
# [Name] - Product Requirements Document
Metadata: Author, Date, Status, Version, Reviewers

1. Problem Statement: What problem, who has it, evidence/data, cost of inaction
2. Goals & Success Metrics: Objective, Key Results table (Metric|Current|Target|Timeline), Non-Goals
3. User Personas: Description, goals, pain points, technical proficiency
4. User Stories: Table (ID|Priority|Story|Acceptance Criteria)
5. Scope: In Scope, Out of Scope (with reasons), Future Considerations
6. Requirements:
   - Functional: Table (ID|Requirement|Priority P0-P3|Notes)
   - Non-Functional: Performance, Security, Scalability, Accessibility, Reliability
   - P0=launch blocker, P1=important with workarounds, P2=deferrable, P3=nice-to-have
7. User Flows: Numbered steps, wireframe descriptions, edge cases & error states
8. Technical Considerations: Dependencies, API requirements, constraints, data needs
9. Release Plan: Phases table (Phase|Scope|Date|Gate), rollout strategy, rollback criteria
10. Risks & Mitigations: Table (Risk|Likelihood|Impact|Mitigation)
11. Open Questions: Table (Question|Owner|Due|Resolution)
12. Appendix: Links to research, designs, glossary
```

## User Stories Format

Summary table first: `ID | Story | Priority | Points | Dependencies`

Each story:
```
## [US-XXX] [Title]
Priority, Story Points, Sprint/Milestone, Dependencies

As a [persona], I want [action], so that [benefit].

Acceptance Criteria (Given/When/Then scenarios for happy path, alternatives, edge cases)
Technical Notes (optional), Out of Scope (optional)
```

## Feature Spec Structure

```
# Feature Spec: [Name]
Metadata: Author, Date, Status, Parent PRD

Problem (2-3 sentences), Proposed Solution, User Stories (3-7),
Requirements table, Design notes, Technical Approach, Success Metrics, Risks, Open Questions
```

## Competitive Analysis Structure

```
# Competitive Analysis: [Area]
Date, Author, Purpose

Market Overview, Feature Comparison table, Competitor Deep Dives (Strengths/Weaknesses/Differentiator/Pricing),
Gaps & Opportunities, Recommendations, Sources
```

## Release Notes Structure

```
# Release Notes - [Product] [Version]
Release Date, Highlights, New Features, Improvements, Bug Fixes, Breaking Changes, Known Issues, Deprecations
```

When generating from commits/PRs: group by type, rewrite to user-facing language, omit internal refactors/CI changes, highlight breaking changes.

## Stakeholder Update Structure

```
# [Project] - Status Update
Period, Author, Overall Status (On Track/At Risk/Blocked)

Summary, Key Accomplishments, Metrics table, Risks & Blockers, Upcoming Milestones, Decisions Needed, Next Steps
```

## Writing Rules

1. Start with Why — problem before solution
2. Measurable success criteria are mandatory
3. Separate must-have (P0) from nice-to-have (P3) — if everything is P0, nothing is prioritized
4. Name risks with mitigations
5. Use plain language for the broadest audience
6. Reference real data; flag gaps as risks
7. Be explicit about scope boundaries
8. Ask for context before generating — never invent data

From bos-hieu/agent-skills, MIT.

More from bos-hieu/agent-skills