prd-done

Name: prd-done
Author: vtmocanu

github.com/vtmocanu開発3289 回インストール今日更新

prd-done について

prd-done は、検証やブランチ管理からプルリクエスト作成、issue のクローズまで、PRD 実装の完了を支援するエージェントスキルです。ドキュメントのみの変更とコード変更を区別し、利用中の forge に応じて Git 操作を切り替えます。

主な機能

01ドキュメントのみかコード変更かを判定
02PRD 要件とドキュメントを検証
03コミットとブランチのフローを管理
04プルリクエストテンプレートの要件を確認・実行
05GitHub、GitLab、Forgejo、Gitea に対応した操作

活用シーン

01コード変更を含む PRD を完了
02ドキュメントのみの PRD 更新を反映
03forge に応じたプルリクエストを準備して issue をクローズ

インストール

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

$npx skills add https://github.com/vtmocanu/skills --skill prd-done

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

詳細

vfarcic/dot-ai の shared-prompts/prd-done.md から取り込まれたものです（MIT、Copyright (c) 2025 Viktor Farcic）。原著者：Viktor Farcic。

PRD の実装を完了する

ブランチ管理、プルリクエストの作成、イシューのクローズを含む PRD 実装ワークフローを完了します。

Forge に依存しません：以下の gh コマンドは GitHub の例です。git remote get-url origin から Forge を判定し、対応する CLI を使って各動詞を同等の操作に置き換えてください。GitHub → gh、GitLab → glab（PR は マージリクエスト、glab mr …）、Forgejo/Gitea → tea。必要な CLI がない場合は、ユーザーに伝え、インストールページへのリンクを案内してください。

ワークフローの手順

0. 実装タイプの判定

最初に、適切なワークフローを選ぶため、PRD 完了のタイプを判定してください

ドキュメントのみの完了（PR ワークフローを省略）：

✅ 変更対象が PRD ファイルまたはプロジェクト管理ドキュメントのみ
✅ ソースコードの変更なし
✅ 設定の変更なし
✅ 機能は以前の作業ですでに実装済み
→ 簡略化ワークフローを使用（手順 1、2-simplified、5 のみ）

コード実装の完了（完全な PR ワークフロー）：

✅ ソースコードの変更を含む
✅ 設定の変更を含む
✅ 新機能または変更を含む
✅ テストと統合が必要
→ 完全なワークフローを使用（手順 1～6）

1. 完了前の検証

PRD のチェックボックスがすべて完了：すべての要件が実装され、テスト済みであることを確認します。ライブ受け入れチェックは PRD のチェックボックスではありません。PRD に残っているものは、リンクされた acceptance イシューに移してください（sweep ラベルは使用しないでください）。PRD はマージ時に完了となります。ドキュメントのみの完了の場合は、そのドキュメントの変更が取り込まれた時点で完了となります。ライブ受け入れによって PRD を未完了のままにしてはいけません。
ドキュメントを更新：ユーザー向けドキュメントに実装済みの機能がすべて反映されていることを確認します
未解決の阻害要因がない：すべての依存関係が解決され、技術的負債に対処済みであることを確認します
PRD のステータスを更新：PRD を「Complete」にし、完了日を記載します
PRD ファイルをアーカイブ：プロジェクトを整理するため、完了した PRD を ./prds/done/ ディレクトリに移動します
ROADMAP.md を更新（存在する場合）：ファイルが存在する場合、ロードマップの docs/ROADMAP.md から完了した機能を削除します

注：PR が作成されると、CI/CD パイプラインでテストが自動的に実行されます。完了ワークフロー中にローカルでテストを実行しないでください。

2. ブランチとコミットの管理

ドキュメントのみの完了の場合：

main に直接コミット：git add [prd-files] を実行し、CI スキップフラグを付けてコミットします
CI スキップ用のコミットメッセージを使用：不要な CI 実行を避けるため、コミットメッセージに CI スキップパターンを含めます
- 一般的なパターン：[skip ci]、[ci skip]、***NO_CI***、[skip actions]
- 正しいパターンは、プロジェクトの CI 設定で確認してください
リモートにプッシュ：変更を同期するため、git pull --rebase origin main && git push origin main を実行します

コード実装の完了の場合：

機能ブランチを作成：git checkout -b feature/prd-[issue-id]-[feature-name]
すべての変更をコミット：実装作業がすべてコミットされていることを確認します
コミット履歴を整理：履歴が明確になるよう、コミットをスカッシュするか整理します
リモートにプッシュ：git push -u origin feature/prd-[issue-id]-[feature-name]

3. プルリクエストの作成

重要：利用可能な場合は、必ず PR テンプレートを確認して使用してください

3.1. PR テンプレートの検出と解析

PR テンプレートを確認します。一般的な場所は次のとおりです。
- .github/PULL_REQUEST_TEMPLATE.md
- .github/pull_request_template.md
- .github/PULL_REQUEST_TEMPLATE/（複数のテンプレートを含むディレクトリ）
- docs/pull_request_template.md
テンプレートを包括的に読み取り、解析します。見つかった場合は、テンプレートを分析して次の内容を抽出します。
- 構造要素：必須セクション、チェックリスト、形式要件
- コンテンツ要件：各セクションで提供が必要な情報
- プロセスの指示：テンプレートに指定されたワークフローの改善点や前提条件
- 検証要件：記載されているチェック、承認、検証
テンプレートから実行可能な指示を抽出します。
- コミット要件：DCO サインオフ、コミットメッセージの形式、コミット署名の要件を確認
- 提出前の作業：ビルドコマンド、テストコマンド、リンティング、フォーマットチェック
- ドキュメント要件：更新が必要なドキュメント、追加が必要なリンク
- レビュー要件：必須のレビュアー、承認プロセス、特別な考慮事項
特定して実行するテンプレートの指示例：
- 「すべてのコミットに Signed-off-by 行を含めること」→ コミットに DCO サインオフがあるか検証し、ない場合は修正します
- 「提出前に npm test を実行すること」→ テストコマンドを実行します
- 「PR タイトルは Conventional Commits 形式に従うこと」→ タイトルの形式を検証します
- 「CHANGELOG.md を更新すること」→ 変更履歴が更新されているか確認します
- コードブロックに記載された bash コマンド → 実行すべきか検討します

3.2. PR の内容に向けた変更の分析

git diff を確認します：git diff main...HEAD を分析し、変更の範囲を把握します
コミット履歴を確認します：git log main..HEAD を使用して、実装の進行状況を把握します
変更の種類を特定します。変更に次の内容が含まれているか判断します。
- 新機能、バグ修正、リファクタリング、ドキュメント、テスト、設定、依存関係
- 破壊的変更または後方互換性のある変更
- パフォーマンスの改善またはセキュリティ修正
変更されたファイルを確認します。コードベースのどの領域が影響を受けたか特定します。
- ソースコードファイル
- テストファイル
- ドキュメントファイル
- 設定ファイル

3.3. PR 情報の自動入力

分析から推測できる内容を自動的に入力します。

PR タイトル：
- 指定されている場合は、テンプレートのタイトル形式に従います（例：Conventional Commits：feat(scope): description）
- PRD のタイトルや説明、コミットメッセージから抽出します
- テンプレートで必要とされている場合は、Issue の参照を含めます
説明の各セクション：
- 内容／理由：PRD の目的と実装の詳細から抽出します
- 関連 Issue：Closes #[issue-id] または Fixes #[issue-id] を使用して自動的にリンクします
- 変更の種類：ファイル分析に基づいて適切なチェックボックスを選択します
テストのチェックリスト：
- テストファイルを変更した場合は、「テストを追加／更新」を選択します
- 注：テストは CI/CD で自動的に実行されます
ドキュメントのチェックリスト：
- 更新したドキュメント（README、API ドキュメント、コードコメント）に応じて項目を選択します
- CONTRIBUTING.md のガイドラインに従っているか確認します
セキュリティのチェックリスト：
- コミットをスキャンして、潜在的なシークレットや認証情報を確認します
- 認証／認可コードが変更されている場合は、フラグを付けます
- 依存関係の更新があれば記載します

3.4. 推測できない情報をユーザーに尋ねる

重要：ただ尋ねるのではなく、分析して回答案を提示し、ユーザーに確認または修正してもらってください

各項目について、利用可能なコンテキストを使って回答案を作成し、ユーザーに確認してください。

手動テストの結果：
- PRD のテスト戦略セクションを分析し、予定されていたテストを把握します
- git のコミットを確認し、テスト関連のメッセージを探します
- 変更の種類に基づいてテスト方法を提案します（例：「ドキュメントの正確性と明瞭さを確認し、相互参照を検証しました」）
- 提案を提示し、「これは正確ですか？変更したい点はありますか？」と尋ねます
破壊的変更：
- コミットと PRD を確認し、破壊的変更の兆候を探します
- 検出された場合、PRD の内容に基づいて移行手順を提案します
- 検出されなかった場合は、「破壊的変更は検出されませんでした。正しいですか？」と確認します
パフォーマンスへの影響：
- 変更の種類を分析します。通常、ドキュメントや設定の変更はパフォーマンスに影響しません
- 分析に基づいて回答を提案します（例：「パフォーマンスへの影響はありません。ドキュメントのみの変更です」）
- 「正しいですか？パフォーマンスに関する考慮事項はありますか？」と尋ねます
セキュリティに関する考慮事項：
- セキュリティ上重要なファイル（認証、認証情報、API キー）が変更されたかどうかを確認します
- コミットを確認し、セキュリティ関連のキーワードを探します
- セキュリティ状況を提案します（例：「セキュリティへの影響はありません。ドキュメントの変更のみです」）
- 「正確ですか？記載すべきセキュリティ上の考慮事項はありますか？」と尋ねます
レビュアーが注目すべき点：
- PRD の目的と git の変更を分析し、重要な確認箇所を特定します
- 具体的な確認箇所を提案します（例：「ドキュメントの正確性を確認し、相互参照リンクをチェックし、ワークフローの例が実装と一致していることを確認する」）
- リストを提示し、「これらは適切な確認箇所ですか？調整が必要ですか？」と尋ねます
今後の作業：
- PRD の「今後の拡張」または「対象外」セクションを確認します
- prds/ ディレクトリ内の他の PRD を分析し、関連作業を探します
- 該当する場合は今後の作業項目を提案します（例：「PRD に記載された今後の拡張：テンプレートの検証、AI による説明の生成」）
- 「これらを記載しますか？ほかに今後の作業はありますか？」と尋ねます
追加のコンテキスト：
- PRD を確認し、特別な考慮事項を探します
- これがドッグフーディングまたはテスト用の PR かどうかを確認します
- 関連するコンテキストを提案します（例：「この PR 自体が、説明対象の強化されたワークフローをテストしています」）
- 「レビュアーが知っておくべきことはほかにありますか？」と尋ねます

提示形式： 提案する回答をすべてまとめ、要約形式で提示します。

📋 **Proposed PR Information** (based on analysis)

**Manual Testing:** [proposed answer]
**Breaking Changes:** [proposed answer]
**Performance Impact:** [proposed answer]
**Security Considerations:** [proposed answer]
**Reviewer Focus:** [proposed list]
**Follow-up Work:** [proposed items or "None"]
**Additional Context:** [proposed context or "None"]

Please review and respond:
- Type "yes" or "confirm" to accept all
- Specify corrections for any items that need changes

3.5. テンプレートの要件を実行する

重要：PR を作成する前に、テンプレート内の実行可能な要件を特定して実行してください

テンプレートに含まれる実行可能な指示を分析する：
- テンプレートの内容を確認し、命令文、要件、コマンドを探します
- 「必須」「すべき」「実行」「確認」「検証」などのパターンを探します
- 前提条件と思われるコードブロック内の bash コマンドを探します
- チェックリストに記載された検証要件を抽出します
特定した要件を分類する：
- コミット時の作業：署名、フォーマット、検証
- 提出前のコマンド：テスト、ビルド、リント、フォーマットチェック
- 検証項目：ファイルの存在、フォーマットの準拠、内容要件
- ドキュメント関連の作業：必須の更新、追加するリンク
要件を提案して実行する：
- 特定した要件をユーザーに提示します：「テンプレートには次の作業が指定されています：[リスト]」
- 各要件について、自動化できるかどうかを判断します
- 実行を提案します：「今すぐ実行しますか？」
- 確認された作業を実行し、結果を報告します
- 失敗には適切に対処し、次の進め方をユーザーに尋ねます

PR 作成前の要約：

✅ Template Requirements Status:
[List each requirement with status: executed/validated/skipped/failed]

Ready to create PR? (yes/no)

3.6. PR ラベルの検出と適用（`release.yml` が存在する場合）

重要：.github/release.yml が存在する場合にのみラベルを適用します。処理はこのファイルの内容に基づいて完全に動的に行います

.github/release.yml の有無を確認します：
- ファイルが存在する場合 → ラベルの検出に進みます
- ファイルが存在しない場合 → ラベルの検出をスキップし、ラベルなしで PR を作成します
release.yml が存在する場合、内容を解析して利用可能なカテゴリーとラベルを確認します：
- YAML ファイルを読み込みます
- 各カテゴリーの定義と、それに関連付けられたラベルをすべて抽出します
- カテゴリー → ラベルのリストの対応関係を作成します
- カテゴリーの順序を確認します（先に記載されているカテゴリーほど、重要度が高い傾向があります）
PR の特性を分析します：
- 主な変更の種類：この PR の主な目的は何ですか？
- ファイルの変更：変更されたファイルの種類（拡張子、パス、用途）
- 変更の範囲：コードベースのどの領域に影響しますか？
- コミットメッセージ：キーワード、パターン、プレフィックス
- PR のタイトルと説明：変更の種類を示すキーワード
- PRD のコンテキスト：元の問題や解決策の説明
最も適合するラベルを1つだけ選択します：
- release.yml の各カテゴリーについて、PR の主な目的にどの程度一致するかを評価します
- release.yml に記載された重要度の順序を考慮します：
  - 破壊的変更 > 新機能 > バグ修正 > ドキュメント > 依存関係 > その他
- 主な変更を最もよく表すカテゴリーからラベルを1つ選択します
- ラベルを1つだけ選ぶ理由： PR が複数のリリースノートカテゴリーに表示されるのを防ぎます
- 選択の優先順位：
  1. 破壊的変更がある場合 → breaking-change または breaking を使用します
  2. 主に新機能を追加する場合 → feat、feature、または enhancement を使用します
  3. 主にバグを修正する場合 → fix、bug、または bugfix を使用します
  4. 主にドキュメントを変更する場合 → documentation または docs を使用します
  5. 主に依存関係を変更する場合 → dependencies、deps、または dependency を使用します
  6. それ以外の場合 → 特定のラベルは不要です（「その他の変更」に表示されます）
検出したラベルを適用します：PR 作成コマンドに、最も適合するラベルを1つ追加します
- 例：gh pr create --title "..." --body "..." --label "fix"

3.7. プルリクエストの作成

PR 本文を作成します：自動入力された情報とユーザー提供の情報を、テンプレートの構成に沿ってまとめます
PR を作成します：
- ラベルが検出された場合：gh pr create --title "[title]" --body "[body]" --label "[single-label]"
- release.yml がない場合、または適合するラベルがない場合：gh pr create --title "[title]" --body "[body]"
PR の作成を確認します：PR が正常に作成され、テンプレートが正しく入力され、該当する場合はラベルが適用されていることを確認します
レビューを依頼します：指定されている場合は、コードレビューを担当する適切なチームメンバーを割り当てます

3.8. テンプレートがないプロジェクトでのフォールバック

PR テンプレートが見つからない場合は、適切なデフォルト構成を作成します。

## Description
[What this PR does and why]

## Related Issues
Closes #[issue-id]

## Changes Made
- [List key changes]

## Testing
- [Testing approach and results]

## Documentation
- [Documentation updates made]

4. レビューとマージのプロセス

5. Issue のクローズ

Issue の PRD リンクを更新する：GitHub Issue の説明を更新し、./prds/done/ ディレクトリ内の新しい PRD のパスを参照するようにします
GitHub Issue をクローズする：最終完了コメントを追加してクローズします
成果物をアーカイブする：必要に応じて、一時ファイルやテストデータを保存します
チームに通知する：関係者に機能の完了を知らせます

6. ブランチのクリーンアップ

main ブランチに切り替えます：git checkout main
最新の変更を取得します：git pull origin main を実行して、ローカルの main が最新であることを確認します
ローカルの機能ブランチを削除します：git branch -d feature/prd-[issue-id]-[feature-name]
リモートの機能ブランチを削除します：git push origin --delete feature/prd-[issue-id]-[feature-name]

成功基準

✅ 機能が公開され、正常に動作していること
✅ 本番環境ですべてのテストに合格していること
✅ ドキュメントが正確かつ完全であること
✅ 完了の概要を添えて PRD の課題がクローズされていること
✅ 機能が利用可能になったことがチームに通知されていること

ユーザーがドキュメントに記載されたとおりに機能を正常に使用できるようになって初めて、PRD の実装は完了とみなされます。

Markdown 対応

ログインしてコメント

基本情報

作者: vtmocanu
リポジトリ: vtmocanu/skills
カテゴリ: 開発
インストール数: 289
GitHub スター: 3

問題を報告