AgentSkillsCN

prd-writing

提供用于编写库需求说明书（LRD）的详细指南与模板，仅在编写 LRD 时使用。

SKILL.md
--- frontmatter
name: prd-writing
description: ライブラリ要求定義書(LRD)を作成するための詳細ガイドとテンプレート。LRD作成時にのみ使用。
allowed-tools: Read, Write

LRD作成スキル

このスキルは、高品質なライブラリ要求定義書(LRD: Library Requirements Document)を作成するための詳細ガイドです。

前提条件

LRD作成を開始する前に、以下が完了している必要があります:

プロジェクトファイルが /new-project コマンドから渡される

このスキルは /new-project コマンドから呼び出されます。 /new-project コマンドの引数で指定されたプロジェクトファイル（src/<library_name>/docs/project.md）の内容がコンテキストに含まれています。

プロジェクトファイルには以下の内容が含まれていることが推奨されます:

  • •パッケージの概要と背景
  • •解決する課題
  • •実装計画（マイルストーンと機能一覧）
  • •技術的考慮事項
  • •最小実装（MVI: Minimum Viable Implementation）の範囲

LRD作成時には、このプロジェクトファイルの内容を参照して詳細化を行います。

インタビュー結果がコンテキストに含まれている

/new-project コマンドのインタビューフェーズ（ステップ1-1）で収集した情報がコンテキストに含まれています。 インタビューで得られた以下の情報を活用してLRDを作成してください:

  • •機能要件の詳細
  • •技術的実装の方針
  • •API設計の方針
  • •スコープと優先度
  • •懸念点とトレードオフ
  • •テスト・品質基準

既存ドキュメントの優先順位

重要: src/<library_name>/docs/library-requirements.md に既存のLRDがある場合、 以下の優先順位に従ってください:

  1. •

    既存のLRD (src/<library_name>/docs/library-requirements.md) - 最優先

    • •ライブラリ固有の要件が記載されている
    • •このスキルのガイドより優先する
  2. •

    このスキルのガイド - 参考資料

    • •汎用的なテンプレートと例
    • •既存LRDがない場合、または補足として使用

新規作成時: このスキルのテンプレートとガイドを参照 更新時: 既存LRDの構造と内容を維持しながら更新

出力先

作成したLRDは以下に保存してください:

code
src/<library_name>/docs/library-requirements.md

注意: <library_name> は /new-project コマンドの引数パスから抽出してください。

テンプレートの参照

LRDを作成する際は、次のテンプレートを使用してください: ./template.md

LRD作成プロセス

1. プロジェクトファイルの確認

/new-project コマンドで指定されたプロジェクトファイルの内容を確認します。 （このスキルは /new-project コマンドから呼び出され、プロジェクトファイルの内容がコンテキストに含まれています）

2. LRDドラフトの生成

プロジェクトファイルの内容をもとに、テンプレートに従ってLRDを生成します。

3. LRDのレビューと改善

生成されたLRDを以下の観点でレビューします:

レビュー観点

  1. •ライブラリの目的は明確か
  2. •想定する利用者（開発者）は具体的か
  3. •成功指標は測定可能か
  4. •機能要件は実装可能なレベルまで詳細化されているか
  5. •非機能要件は網羅されているか

レビュー結果の評価基準

生成したLRDは以下の形式で評価します:

良い点

  • •明確な目的が測定可能で具体的に記述されている
  • •API仕様が実装レベルまで詳細化されている
  • •品質指標が定量的に定義されている

改善が必要な点

機能要件の曖昧さ:

  • •問題: 具体的なAPI仕様が不明確な箇所がある
  • •推奨: 具体的な関数シグネチャやエラーハンドリングを明記

成功指標の測定方法:

  • •問題: 測定方法が不明確
  • •推奨: 測定方法と具体的なベンチマークを明記

4. レビュー後の改善

レビューで指摘された問題を一つずつ確認し、具体化が必要な箇所を改善します:

  1. •指摘された問題を一つずつ確認
  2. •具体化が必要な箇所を改善
  3. •改善後、再度レビューを実施
  4. •問題がなくなるまで繰り返す

注意点:

  • •AIのレビューを鵜呑みにせず、最終的な判断は必ず人間が行う
  • •レビュー観点は明確に指定する
  • •改善提案の妥当性を人間が検証する

LRD作成の重要なポイント

1. 具体性と測定可能性

すべての要件は具体的で測定可能でなければなりません。

悪い例:

  • •ライブラリは高速である必要がある
  • •開発者は使いやすいと感じる

良い例:

  • •主要関数の実行時間: 10ms以内（1000要素のリスト処理時）
  • •新規利用者が5分以内に基本的なAPI呼び出しを実装できる（サンプルコード参照）

2. 利用者中心設計

すべての機能は、明確な開発者の課題を解決するものでなければなりません。

使用例のフォーマット:

code
[開発者]として、[目的]のために、[機能]が欲しい

例:

code
Pythonアプリケーション開発者として、データ変換処理を簡潔に記述するために、
型安全なパイプライン構築APIが欲しい

3. 優先順位の明確化

すべての機能に優先度を設定します:

  • •P0(必須): MVI(Minimum Viable Implementation)に含める機能。これがないとライブラリとして成立しない
  • •P1(重要): 初期リリース後すぐに追加すべき機能
  • •P2(できれば): 将来的に追加を検討する機能

LRDの主要セクション詳細

1. ライブラリ概要

構成要素

  1. •名称: ライブラリ名とサブタイトル
  2. •ライブラリの目的: 3つの主要な目的
  3. •解決する課題: 目指す解決策を3-5文で
  4. •提供する価値: 具体的な価値のリスト

例

markdown
### 名称
**dataflow** - 型安全なデータパイプラインライブラリ

### ライブラリの目的
- 型安全なデータ変換: 型ヒントによるコンパイル時エラー検出
- 直感的なパイプライン構築: メソッドチェーンによる可読性の高い記述
- 高い拡張性: カスタム変換器の簡単な追加

### 解決する課題
データ変換処理は複雑になりがちで、型の不整合によるランタイムエラーが発生しやすい。
本ライブラリは型安全なパイプラインAPIを提供し、開発時にエラーを検出可能にする。
これにより、堅牢で保守性の高いデータ処理コードの記述を支援する。

具体的な価値提案を含める

悪い例:

code
便利なデータ処理ライブラリを作る

良い例:

code
型安全なデータパイプラインを構築するPythonライブラリ。

提供する価値:
- 型エラーの早期発見（実行前に pyright/mypy で検出）
- 可読性の向上（メソッドチェーンで処理フローが一目瞭然）
- テスト容易性（各変換器を独立してテスト可能）

2. 想定利用者（ペルソナ）

必須要素

  1. •基本属性: 職種、経験年数、技術レベル
  2. •技術スタック: 使用しているツールや言語
  3. •現在の課題: 具体的な痛み点
  4. •期待する解決策: どうなりたいか
  5. •典型的な使用シナリオ

例

markdown
### プライマリー利用者: バックエンドエンジニア（経験3年以上）
- Python でデータ処理アプリケーションを開発
- 型ヒントと静的解析ツールを活用
- データ変換の型安全性に課題を感じている
- pandas や dataclasses との連携を期待

3. 成功指標

SMART原則

  • •Specific(具体的): 何を測定するか明確
  • •Measurable(測定可能): 数値で測定できる
  • •Achievable(達成可能): 現実的な目標
  • •Relevant(関連性): ライブラリの目的と関連
  • •Time-bound(期限): 達成期限を設定

例

markdown
### 品質指標
- テストカバレッジ: 90%以上
- 型カバレッジ: 100%（py.typed 対応）
- ドキュメントカバレッジ: 全公開APIに docstring

### パフォーマンス指標
- 1000要素のパイプライン処理: 10ms以内
- メモリ効率: イテレータベースで大量データ対応

4. 機能要件

コア機能(MVI)

各機能には以下を含めます:

  • •使用例（ユーザーストーリー形式）
  • •受け入れ条件（チェックリスト形式）
  • •優先度（P0/P1/P2）

フォーマット:

markdown
### [機能名]

使用例:
[開発者]として、[目的]のために、[機能]が欲しい

受け入れ条件:
- [ ] 条件1（測定可能）
- [ ] 条件2（測定可能）

優先度: P0(必須) / P1(重要) / P2(できれば)

APIインターフェース

ライブラリの場合、具体的なAPI例を記載します:

python
# 基本的な使用例
from dataflow import Pipeline

pipeline = (
    Pipeline[dict, User]()
    .map(validate_input)
    .filter(is_active)
    .transform(to_user)
)

result = pipeline.run(raw_data)

5. 非機能要件

測定可能な形で記述します:

例:

markdown
### パフォーマンス
- 主要関数の実行時間: 10ms以内（1000要素処理時）
- メモリ使用量: 入力データの2倍以内

### 互換性
- Python 3.10+ 対応
- 主要な型チェッカー（mypy, pyright）対応
- 主要OSでの動作確認（Linux, macOS, Windows）

### 信頼性
- 全公開APIのテストカバレッジ: 90%以上
- エラー発生時の明確なメッセージ

品質基準とチェックポイント

LRDの品質を確保するため、以下のチェックポイントを確認してください:

目的と価値

  • • ライブラリの目的が明確で測定可能か
  • • 提供する具体的な価値が定義されているか
  • • 解決する課題が明確か

想定利用者

  • • ペルソナが具体的に定義されているか
  • • 現在の課題と期待する解決策が明確か
  • • 技術スタックと使用シナリオが記述されているか

成功指標

  • • SMART原則に従った指標が定義されているか
  • • 測定方法が明確か
  • • 達成期限が設定されているか

機能要件

  • • すべての機能が使用例形式で記述されているか
  • • 受け入れ条件が測定可能な形で定義されているか
  • • 優先度（P0/P1/P2）が明確に設定されているか

非機能要件

  • • パフォーマンス基準が具体的な数値で定義されているか
  • • 互換性要件が明確か
  • • 信頼性とテスト要件が明確か

まとめ

LRD作成の成功のポイント:

  1. •プロジェクトファイルをベースに作成: /new-project で指定されたプロジェクトファイルの内容を参照
  2. •具体性と測定可能性: すべての要件を明確に
  3. •利用者中心: 開発者の課題を解決する機能のみ
  4. •優先順位の明確化: P0/P1/P2で分類
  5. •レビューと改善: 自己レビューと人間による最終判断
  6. •SMART原則の適用: 特に品質指標定義において重要