mcpField
G
generate-prd

generate-prd

github.com/revitalb-portDevelopment052 installsUpdated 10w ago
Repository

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

  1. 01Retrieve service and team details
  2. 02Assess risks using recent incidents
  3. 03Adapt requirements to service tier
  4. 04Analyze dependencies and change complexity
  5. 05Optionally add PRD content to a work item

Use cases

  1. 01Write a PRD for a new feature
  2. 02Enrich a Jira or Linear ticket with requirements
  3. 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-prd

After installing, type/generate-prdin Claude Code to confirm it loaded.

Details

From the project README

Generate 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:

TierAvailability SLAPerformanceTesting
Tier1-Critical99.99%<100ms p99Full E2E, load test
Tier2-Core99.9%<500ms p99Integration tests
Tier3-Supporting99%<1s p99Unit tests
Step 4: Risk Analysis

Flag risks based on:

  1. Recent incidents on the service
  2. Number of dependencies
  3. Service tier (higher tier = more risk)
  4. 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