mcpField
T
to-prd

to-prd

github.com/akillness開発53258 回インストール今日更新
リポジトリ

to-prd について

既存の会話とプロジェクトの文脈を、課題トラッカーに登録する構造化 PRD にまとめるスキルです。作業を課題に分ける前の要件整理に向けて、モジュール設計と品質確認も行います。

主な機能

  1. 01既存のプロジェクト文脈の整理
  2. 02モジュールとインターフェースの特定
  3. 03PRD形式での要件整理
  4. 04needs-triageラベル付きで登録
  5. 05PRD品質の確認

活用シーン

  1. 01議論済み要件の正式な文書化
  2. 02課題分割前の機能仕様作成
  3. 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 にファイルパスやコードが含まれていない(これらは課題に記載する)

手順

  1. タスクのきっかけと期待される出力を特定します。
  2. このスキルのワークフローに沿って、上から順に手順を進めます。
  3. 次の手順に進む前に、出力を検証します。
  4. 手順が失敗した場合は、阻害要因と代替手段を記録します。

例

  • 例:まずこのスキルを小さな範囲に適用し、検証に合格してから全体の範囲に拡大します。

ベストプラクティス

  • 出力の決定性と監査可能性を保ちます。
  • 広範でリスクの高い編集より、小さく元に戻せる変更を優先します。
  • 前提を明示的に記録します。

参考資料

  • プロジェクト標準:.agent-skills/skill-standardization/SKILL.md
  • バリデーターのスクリプト:.agent-skills/skill-standardization/scripts/validate_skill.sh

コメント