mcpField
G
generate-prd

generate-prd

github.com/revitalb-port開発052 回インストール10 週間前に更新
リポジトリ

generate-prd について

generate-prdは、Portのサービスカタログデータを使って開発向けの製品要件書を作成するスキルです。サービス階層、依存関係、最近のインシデントを考慮し、機能計画や開発チケットの準備を支援します。

主な機能

  1. 01サービスとチームの情報を取得
  2. 02最近のインシデントからリスクを評価
  3. 03サービス階層に応じて要件を調整
  4. 04依存関係と変更の複雑さを分析
  5. 05PRDの内容をチケットに追加可能

活用シーン

  1. 01新機能のPRD作成
  2. 02JiraまたはLinearのチケットに要件を補足
  3. 03開発スプリント向け作業項目の準備

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/revitalb-port/skills-registry-demo --skill generate-prd

インストール後、Claude Code で/generate-prdを入力して読み込まれたか確認します。

詳細

PRD 生成スキル

Port のサービスカタログデータを使用して、エンジニアリングですぐに使えるプロダクト要件定義書を作成します。

使用するタイミング

  • 新機能の PRD を作成するとき
  • Jira/Linear のチケットに要件を追加するとき
  • 開発スプリントに向けて作業項目を準備するとき

PRD の生成プロセス

ステップ 1:Port からコンテキストを収集する

対象サービスを検索します:

get_entity(blueprint="service", identifier="target-service", include=[
  "tier", "team", "depends_on", "readme_url", "codeowners"
])

リスクの把握に役立つ最近のインシデントを取得します:

list_entities(blueprint="incident", query={
  primary_service: "target-service",
  created_at: "<90d"
})
ステップ 2: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]
ステップ 3:ティアに基づく要件

サービスのティアに応じて要件を調整します:

ティア可用性 SLAパフォーマンステスト
Tier1-Critical99.99%<100ms p99完全な E2E、負荷テスト
Tier2-Core99.9%<500ms p99統合テスト
Tier3-Supporting99%<1s p99単体テスト
ステップ 4:リスク分析

次の項目に基づいてリスクを特定します:

  1. サービスで発生した最近のインシデント
  2. 依存関係の数
  3. サービスのティア(ティアが高いほどリスクも高くなります)
  4. 変更の複雑さ
ステップ 5:作業項目を更新する

Jira/Linear と連携している場合は、適切なアクションを呼び出します:

run_action("enrich_work_item", {
  work_item_id: "PROJ-123",
  prd_content: "[generated PRD]",
  risk_level: "medium"
})

品質チェックリスト

  • Port の実際のサービスデータを使用した
  • 要件がサービスのティアに合っている
  • 実際の依存関係を記載した
  • リスクを把握するためにインシデント履歴を分析した
  • 正しい CODEOWNERS を特定した
  • 明確な受け入れ基準を設定した

コメント