About generate-prd
generate-prd is a skill for producing engineering-ready product requirements from Port service catalog data. It supports feature planning and work-item preparation by factoring in service tiers, dependencies, and recent incidents.
Key features
- 01Retrieve service and team details
- 02Assess risks using recent incidents
- 03Adapt requirements to service tier
- 04Analyze dependencies and change complexity
- 05Optionally add PRD content to a work item
Use cases
- 01Write a PRD for a new feature
- 02Enrich a Jira or Linear ticket with requirements
- 03Prepare a work item for a development sprint
Install
Copy the command and run it in a terminal.
$
npx skills add https:/ / github.com/ revitalb-port/ skills-registry-demo --skill generate-prdAfter installing, type/generate-prdin Claude Code to confirm it loaded.
Details
From the project READMEGenerate PRD Skill
Create engineering-ready Product Requirements Documents using Port's service catalog data.
When to Use
- Creating a PRD for a new feature
- Enriching a Jira/Linear ticket with requirements
- Preparing a work item for development sprint
PRD Generation Process
Step 1: Gather Context from Port
Query the target service:
get_entity(blueprint="service", identifier="target-service", include=[
"tier", "team", "depends_on", "readme_url", "codeowners"
])
Get recent incidents (for risk context):
list_entities(blueprint="incident", query={
primary_service: "target-service",
created_at: "<90d"
})
Step 2: Structure the PRD
# PRD: [Feature Name]
## Overview
**Service**: [service-name]
**Team**: [team from Port]
**Tier**: [service tier]
**Target Release**: [date]
## Problem Statement
[What problem does this solve?]
## User Stories
As a [user type], I want to [action] so that [benefit].
## Requirements
### Functional Requirements
1. [Requirement with acceptance criteria]
2. [Requirement with acceptance criteria]
### Non-Functional Requirements
- **Performance**: [metrics]
- **Availability**: [SLA based on tier]
- **Security**: [requirements]
## Technical Considerations
### Dependencies
[List from Port's depends_on relation]
### Risk Assessment
Based on incident history:
- [Risk 1 from past incidents]
- [Risk 2]
### CODEOWNERS
[From Port data - who needs to review]
## Success Metrics
- [Metric 1]
- [Metric 2]
## Out of Scope
- [What we're NOT building]
Step 3: Tier-Based Requirements
Adjust requirements based on service tier:
| Tier | Availability SLA | Performance | Testing |
|---|---|---|---|
| Tier1-Critical | 99.99% | <100ms p99 | Full E2E, load test |
| Tier2-Core | 99.9% | <500ms p99 | Integration tests |
| Tier3-Supporting | 99% | <1s p99 | Unit tests |
Step 4: Risk Analysis
Flag risks based on:
- Recent incidents on the service
- Number of dependencies
- Service tier (higher tier = more risk)
- Change complexity
Step 5: Update Work Item
If integrated with Jira/Linear, call the appropriate action:
run_action("enrich_work_item", {
work_item_id: "PROJ-123",
prd_content: "[generated PRD]",
risk_level: "medium"
})
Quality Checklist
- Used actual service data from Port
- Requirements match service tier
- Listed real dependencies
- Analyzed incident history for risks
- Identified correct CODEOWNERS
- Clear acceptance criteria
Comments
Markdown supported