to-prd について
既存の会話とプロジェクトの文脈を、課題トラッカーに登録する構造化 PRD にまとめるスキルです。作業を課題に分ける前の要件整理に向けて、モジュール設計と品質確認も行います。
主な機能
- 01既存のプロジェクト文脈の整理
- 02モジュールとインターフェースの特定
- 03PRD形式での要件整理
- 04needs-triageラベル付きで登録
- 05PRD品質の確認
活用シーン
- 01議論済み要件の正式な文書化
- 02課題分割前の機能仕様作成
- 03ユーザーストーリーとともに設計判断を記録
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ akillness/ jeo-skills --skill to-prdインストール後、Claude Code で/to-prdを入力して読み込まれたか確認します。
詳細
PRD への変換
現在の会話コンテキストを、プロジェクトの課題管理ツールに公開するための構造化された PRD に変換します。
このスキルを使用する場合
- 既存の議論から要件を文書化する場合
- 作業を課題に分割する前に正式な仕様を作成する場合
- ユーザーストーリーと併せてアーキテクチャ上の決定を記録する場合
このスキルを使用しない場合
- 作業をチケットに分割する場合 →
to-issuesを使用します - 技術的な内部ドキュメントを作成する場合 →
technical-writingを使用します - 簡単なタスクメモを作成する場合 →
task-planningを使用します
プロセス
1. 調査して理解する
プロジェクトのドメイン用語(CONTEXT.md)と関連する ADR を使用して、コードベースを確認します。ユーザーに質問せず、既存のコンテキストから内容をまとめます。
2. モジュールを設計する
構築または変更する主要なコンポーネントを特定します。深いモジュールを重視します。つまり、シンプルでテスト可能なインターフェースと、安定した契約を備えたモジュールです。前提をユーザーと確認し、テスト対象とするモジュールを確定します。
3. 文書化して公開する
PRD テンプレートを完成させ、needs-triage ラベルを付けて課題管理ツールに提出します。
PRD テンプレート
# [Feature/Change Name]
## Problem Statement
[User-facing description of the issue or opportunity. What pain does this solve?]
## Solution
[User-facing description of the resolution approach.]
## User Stories
1. As a [actor], I want [feature], so that [benefit].
2. As a [actor], I want [feature], so that [benefit].
[... comprehensive list covering all use cases]
## Implementation Decisions
### Modules
[Major components to build/modify with interface descriptions]
### Technical Choices
[Architecture decisions, schema design, API contracts — avoid file paths and code snippets]
### ADR References
[Links to relevant Architecture Decision Records]
## Testing Decisions
[Testing philosophy for this feature, which modules need coverage, relevant test precedents]
## Out of Scope
- [Explicitly excluded item]
- [Explicitly excluded item]
## Further Notes
[Additional context, open questions, or dependencies]
品質チェックリスト
- 問題の説明がユーザーの視点で書かれている(技術的な内容ではない)
- ユーザーストーリーで、すべてのアクターとユースケースが網羅されている
- 実装上の決定で、既存のドメイン用語が参照されている
- スコープ外のセクションにより、スコープの拡大を防いでいる
- PRD にファイルパスやコードが含まれていない(これらは課題に記載する)
手順
- タスクのきっかけと期待される出力を特定します。
- このスキルのワークフローに沿って、上から順に手順を進めます。
- 次の手順に進む前に、出力を検証します。
- 手順が失敗した場合は、阻害要因と代替手段を記録します。
例
- 例:まずこのスキルを小さな範囲に適用し、検証に合格してから全体の範囲に拡大します。
ベストプラクティス
- 出力の決定性と監査可能性を保ちます。
- 広範でリスクの高い編集より、小さく元に戻せる変更を優先します。
- 前提を明示的に記録します。
参考資料
- プロジェクト標準:
.agent-skills/skill-standardization/SKILL.md - バリデーターのスクリプト:
.agent-skills/skill-standardization/scripts/validate_skill.sh
コメント
Markdown 対応