prd-creator
ユーザーとの対話を通じて、問題の理解、複雑さの分類、ビジネス要件の収集を行い、ビジネス上の問題と要件に焦点を当てた製品要件定義書(PRD)を作成するSkill。
📜 元の英語説明(参考)
Genera Product Requirements Documents (PRDs) completos a partir de una conversación interactiva con el usuario. Usa preguntas adaptativas con la herramienta `question` para entender el problema, clasificar su complejidad, y recopilar requisitos de negocio. El output es un .md orientado a problemas de negocio y requisitos (NO técnico). Usar cuando el usuario quiere crear un PRD, documentar requisitos de producto, definir un problema a resolver, o dice "quiero un PRD", "documentar requisitos", "definir qué vamos a construir".
🇯🇵 日本人クリエイター向け解説
ユーザーとの対話を通じて、問題の理解、複雑さの分類、ビジネス要件の収集を行い、ビジネス上の問題と要件に焦点を当てた製品要件定義書(PRD)を作成するSkill。
※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o prd-creator.zip https://jpskill.com/download/10603.zip && unzip -o prd-creator.zip && rm prd-creator.zip
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/10603.zip -OutFile "$d\prd-creator.zip"; Expand-Archive "$d\prd-creator.zip" -DestinationPath $d -Force; ri "$d\prd-creator.zip"
完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
prd-creator.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
prd-creatorフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-18
- 取得日時
- 2026-05-18
- 同梱ファイル
- 1
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
プロトコル prd-creator
全体的な流れ
フェーズ 0: プロジェクトのコンテキストの調査
↓ 静かな要約 (チェックポイントなし — ユーザーに通知するのみ)
フェーズ 1: 問題の受付
↓ 複雑性の分類
フェーズ 2: 適応型インタビュー (`question` ツールによる質問)
↓ チェックポイント — ユーザーがよく理解したことを確認
フェーズ 3: PRD の生成
↓ チェックポイント — ユーザーが .md を承認
フェーズ 4: 永続化
フェーズ 0 — プロジェクトのコンテキストの調査
目的: 質問と PRD をコンテキスト化するために、プロジェクトを理解すること。
エージェントは(静かに、質問せずに)以下を行います。
package.json/go.mod/pyproject.toml/Cargo.tomlを読み、ドメインを理解します。README.mdが存在する場合は読みます。docs/prd/を検索して既存の PRD を確認し、スタイルを理解します。
重要: この情報は、エージェントの内部コンテキスト用です。出力 PRD は、特定の技術スタックに言及すべきではありません — ビジネスと要件に焦点を当てる必要があります。
その後、簡単な要約を表示します。
プロジェクトのコンテキストを理解しました:
- ドメイン: [検出されたドメイン]
- 既存の PRD: [リストまたは "なし"]
教えてください: どのような問題を解決したいですか、または何を構築する必要がありますか?
ユーザーが最初のメッセージで既に問題を提示している場合は、直接フェーズ 1 にスキップします。
フェーズ 1 — 問題の受付と分類
目的: ユーザーからの入力を受け取り、複雑さを分類して、質問の回数を決定すること。
複雑性の分類
ユーザーの入力に基づいて、以下のように分類します。
| 複雑性 | シグナル | 質問ラウンド数 | 合計質問数 (概算) |
|---|---|---|---|
| シンプル | ポイント修正、小規模な改善、明確なスコープ | 0-1 ラウンド | 0-4 |
| ミディアム | 新しい機能、複数のユーザー、いくつかのフロー | 1-2 ラウンド | 4-8 |
| ハイ | 新しいシステム、複数のアクター、複雑なビジネスルール | 2-3 ラウンド | 8-15 |
| 非常に高い | プラットフォーム、複数のモジュール、コンプライアンス、統合 | 3-4 ラウンド | 15-20 |
ユーザーが既に十分なコンテキストを提供している場合 (明確な問題、ユーザー、範囲を含む 150 語以上の詳細な説明): 明確にするために必要な質問のみに減らします。
入力があいまいな場合 (<30 語): 幅広い発見的な質問から始めます。
分類をユーザーに表示します。
あなたのリクエストを複雑性 [X] として分類しました。
必要なものをよく理解するために、[N] 個の質問をします。
フェーズ 2 — 適応型インタビュー
目的: PRD に必要なすべてのビジネス情報を収集すること。
絶対的なルール
- 常に
questionツールを使用する — プレーンテキストで質問しない - 1 ラウンドあたり最大 4 つの質問 — これ以上は絶対にしない
- 必要な情報の種類に応じて、選択肢のある質問と自由記述式の質問を混ぜる
questionツールは自動的に "Type your own answer" を追加します- 以前の回答が質問を既にカバーしている場合 → スキップする
- 回答が新しい曖昧さを生み出す場合 → 次のラウンドに追加する
- 技術スタック、テクノロジー、または実装について質問しない — PRD はビジネスに関するものです
- 質問をコンテキストに適応させる — ユーザーが既に情報を提供している場合は、一般的な質問を使用しない
ラウンドの構成
質問バンク全体は references/question-bank.md にあります。複雑さと問題の種類に応じて適切な質問を選択するには、そのファイルを参照してください。
構成の概要:
ラウンド 1 → 問題とコンテキスト + ユーザーと範囲
最大 4 つの質問、最もオープンで幅広い質問
ラウンド 2 → フローと動作 + 成功基準
最大 4 つの質問、ラウンド 1 の回答に適応
(複雑性が >= ミディアムの場合のみ)
ラウンド 3 → エッジケース + 優先順位付け
最大 4 つの質問
(複雑性が >= ハイの場合のみ)
ラウンド 4 → ビジネス上の制約 + インパクト指標
最大 4 つの質問
(複雑性が = 非常に高い場合のみ)
各ラウンドの最後に (最後のラウンドを除く)
これまでの理解:
- [箇条書きの要約]
- [箇条書きの要約]
- [箇条書きの要約]
続行する前に、何か間違っていることや追加したいことはありますか?
インタビューの最終チェックポイント
最後のラウンドの後、完全な要約を提示します。
理解したことの要約:
**問題**: [1〜2 文での要約]
**ユーザー**: [誰]
**範囲**: [何を含み、何を含まないか]
**主なフロー**: [要約]
**成功基準**: [要約]
これは完全ですか? PRD を生成する前に、何か重要なものが不足していますか?
ユーザーが確認するか、修正を行います。
フェーズ 3 — PRD の生成
目的: ビジネス指向の完全な .md ドキュメントを生成すること。
references/prd-template.md で定義されたテンプレートを使用します。
生成ルール
| セクション | ルール |
|---|---|
| 問題 | 最大 2 段落。ビジネス言語、技術的な専門用語はゼロ。 |
| ユーザー | 一般的なプロファイルではなく、実際のペインポイントを持つ人物を説明します。 |
| 目標 | 可能な場合は測定可能。技術的な指標ではなく、ビジネス指標を使用します。 |
| 範囲 — 範囲外 | 少なくとも 2 つの範囲外の項目が必須。ユーザーが言及していない場合、エージェントが提案します。 |
| 機能要件 | P0/P1/P2 で優先順位付け。それぞれに受け入れ基準があります。 |
| 非機能要件 | インタビューで発生した場合のみ。技術的な用語 ("レイテンシ < 200ms") ではなく、ビジネス用語 ("ユーザーは 2 秒以上待つべきではありません") で表現します。 |
| フロー | インタビューで発生したもののみ。該当しない場合はセクションを省略します。 |
| 成功基準 | 簡略化された Gherkin 形式 (Given/When/Then)。常に生成されます — ユーザーが言及していない場合、エージェントがフローから導き出します。 |
| リスク | 複雑性が高いまたは非常に高い場合のみ。 |
| 未解決の質問 | インタビュー中に検出された保留中の決定または曖昧さ。 |
ユーザーへの提示
以下を表示します。
(原文がここで切り詰められています)
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Protocolo prd-creator
Flujo general
FASE 0: Exploración del Contexto del Proyecto
↓ resumen silencioso (no checkpoint — solo informa al usuario)
FASE 1: Recepción del Problema
↓ clasificación de complejidad
FASE 2: Entrevista Adaptativa (preguntas con `question` tool)
↓ checkpoint — usuario confirma que se entendió bien
FASE 3: Generación del PRD
↓ checkpoint — usuario aprueba el .md
FASE 4: Persistencia
FASE 0 — Exploración del Contexto del Proyecto
Objetivo: Entender el proyecto para contextualizar las preguntas y el PRD.
El agente (silenciosamente, sin preguntar):
- Lee
package.json/go.mod/pyproject.toml/Cargo.tomlpara entender el dominio - Lee
README.mdsi existe - Busca
docs/prd/para ver PRDs existentes y entender el estilo
IMPORTANTE: Esta información es para contexto interno del agente. El PRD de salida NO debe mencionar stack técnico específico — debe ser orientado a negocio y requisitos.
Luego muestra un resumen breve:
Entendí el contexto del proyecto:
- Dominio: [dominio detectado]
- PRDs existentes: [lista o "ninguno"]
Contame: ¿qué problema querés resolver o qué necesitás construir?
Si el usuario ya proporcionó el problema en su mensaje inicial, saltar directamente a FASE 1.
FASE 1 — Recepción del Problema y Clasificación
Objetivo: Recibir el input del usuario y clasificar la complejidad para determinar cuántas preguntas hacer.
Clasificación de complejidad
Basándose en el input del usuario, clasificar:
| Complejidad | Señales | Rondas de preguntas | Total preguntas aprox |
|---|---|---|---|
| simple | Cambio puntual, mejora menor, scope claro | 0-1 rondas | 0-4 |
| media | Feature nueva, múltiples usuarios, algunos flujos | 1-2 rondas | 4-8 |
| alta | Sistema nuevo, múltiples actores, reglas de negocio complejas | 2-3 rondas | 8-15 |
| muy alta | Plataforma, múltiples módulos, compliance, integraciones | 3-4 rondas | 15-20 |
Si el usuario ya dio suficiente contexto (descripción detallada >150 palabras con problema claro, usuarios, alcance): reducir preguntas a solo lo que falta clarificar.
Si el input es vago (<30 palabras): empezar con preguntas amplias de descubrimiento.
Mostrar clasificación al usuario:
Clasifiqué tu solicitud como complejidad [X].
Voy a hacerte [N] preguntas para entender bien lo que necesitás.
FASE 2 — Entrevista Adaptativa
Objetivo: Recopilar toda la información de negocio necesaria para el PRD.
Reglas absolutas
- SIEMPRE usar la herramienta
question— nunca preguntas en texto plano - Máximo 4 preguntas por ronda — nunca más
- Mezclar preguntas con opciones y abiertas según el tipo de información necesaria
- La herramienta
questionagrega "Type your own answer" automáticamente - Si una respuesta anterior ya cubre una pregunta → saltarla
- Si una respuesta genera nueva ambigüedad → agregarla a la siguiente ronda
- NUNCA preguntar sobre stack técnico, tecnologías, o implementación — el PRD es de negocio
- Adaptar las preguntas al contexto — no usar preguntas genéricas si el usuario ya dio info
Estructura de rondas
El banco de preguntas completo está en references/question-bank.md. Consultar ese archivo para elegir las preguntas adecuadas según la complejidad y el tipo de problema.
Resumen de la estructura:
Ronda 1 → Problema y Contexto + Usuarios y Alcance
máx 4 preguntas, las más abiertas y amplias
Ronda 2 → Flujos y Comportamiento + Criterios de Éxito
máx 4 preguntas, adaptadas a respuestas de Ronda 1
(solo si complejidad >= media)
Ronda 3 → Edge Cases + Priorización
máx 4 preguntas
(solo si complejidad >= alta)
Ronda 4 → Restricciones de Negocio + Métricas de Impacto
máx 4 preguntas
(solo si complejidad = muy alta)
Al final de cada ronda (excepto la última)
Hasta ahora entiendo:
- [bullet resumen]
- [bullet resumen]
- [bullet resumen]
¿Hay algo incorrecto o querés agregar algo antes de continuar?
Checkpoint final de la entrevista
Después de la última ronda, presentar un resumen completo:
Resumen de lo que entendí:
**Problema**: [resumen en 1-2 oraciones]
**Usuarios**: [quiénes]
**Alcance**: [qué incluye y qué no]
**Flujos principales**: [resumen]
**Criterios de éxito**: [resumen]
¿Está completo? ¿Falta algo importante antes de generar el PRD?
El usuario confirma o hace correcciones.
FASE 3 — Generación del PRD
Objetivo: Generar el documento .md completo orientado a negocio.
Usar el template definido en references/prd-template.md.
Reglas de generación
| Sección | Regla |
|---|---|
| Problema | Máx 2 párrafos. Lenguaje de negocio, cero jerga técnica. |
| Usuarios | Describir personas con pain points reales, no perfiles genéricos. |
| Objetivos | Medibles cuando sea posible. Usar métricas de negocio, no técnicas. |
| Alcance — fuera de alcance | Obligatorio con al menos 2 items fuera de alcance. Si el usuario no los mencionó, el agente los propone. |
| Requisitos funcionales | Priorizados P0/P1/P2. Cada uno con criterio de aceptación. |
| Requisitos no funcionales | Solo si surgieron en la entrevista. Expresados en términos de negocio ("el usuario no debe esperar más de 2 segundos") no técnicos ("latencia < 200ms"). |
| Flujos | Solo los que surgieron en la entrevista. Omitir sección si no aplica. |
| Criterios de éxito | Formato Gherkin simplificado (Dado/Cuando/Entonces). Siempre se genera — el agente los deriva de los flujos si el usuario no los mencionó. |
| Riesgos | Solo si la complejidad es alta o muy alta. |
| Preguntas abiertas | Cualquier decisión pendiente o ambigüedad detectada durante la entrevista. |
Presentación al usuario
Mostrar el PRD completo y preguntar:
¿Aprobás este PRD para guardarlo?
Podés pedirme ajustes antes de confirmar.
El usuario puede pedir ajustes. El agente los incorpora y vuelve a presentar.
Checkpoint: El usuario aprueba el PRD.
FASE 4 — Persistencia
Objetivo: Guardar el PRD como archivo .md en el repositorio.
- Crear el directorio
docs/prd/si no existe - Generar nombre de archivo:
YYYY-MM-DD-<nombre-kebab-case>.md- La fecha es la fecha actual
- El nombre se deriva del título del PRD en kebab-case
- Ejemplo:
2026-03-06-sistema-de-notificaciones.md
- Escribir el archivo
- Mostrar confirmación:
PRD guardado: docs/prd/YYYY-MM-DD-nombre-del-prd.md
¿Necesitás algo más con este PRD?
Ejemplos de uso
Ejemplo 1: Solicitud simple
Usuario: "quiero agregar notificaciones por email cuando un pedido cambia de estado"
→ Complejidad: simple (scope claro, un flujo principal) → 1 ronda de 3-4 preguntas
Pregunta 1: "¿Qué cambios de estado deben disparar la notificación?"
- Todos los cambios
- Solo cambios críticos (cancelado, entregado, devuelto)
- Solo cuando pasa a "enviado" y "entregado"
Pregunta 2: "¿Quién recibe las notificaciones?"
- Solo el cliente que hizo el pedido
- El cliente + el vendedor
- Configurable por el usuario
Pregunta 3: "¿El usuario puede desactivar las notificaciones?"
- Sí, debe poder elegir cuáles recibir
- Sí, todo o nada
- No, siempre se envían
Ejemplo 2: Solicitud compleja
Usuario: "necesito un sistema de gestión de inventario para nuestros 3 almacenes"
→ Complejidad: alta (múltiples ubicaciones, múltiples actores, reglas de negocio) → 3 rondas de 3-4 preguntas cada una
Ronda 1: Problema y contexto
Pregunta 1: "¿Cómo gestionan el inventario hoy?"
- Planillas de Excel
- Sistema actual que quieren reemplazar
- No hay sistema, todo manual/verbal
Pregunta 2: "¿Quiénes van a usar el sistema?"
- Solo encargados de almacén
- Encargados + vendedores + gerencia
- Todo el equipo
Pregunta 3: "¿Qué es lo más urgente o doloroso del proceso actual?"
[ABIERTA - que describa el pain point principal]
Pregunta 4: "¿Los 3 almacenes manejan los mismos productos o son independientes?"
- Mismos productos, stock compartido
- Productos distintos por almacén
- Mix: algunos compartidos, otros exclusivos
Ejemplo 3: Solicitud vaga
Usuario: "quiero mejorar cómo manejamos los clientes"
→ Complejidad: no determinada — necesita preguntas amplias de descubrimiento
Pregunta 1: "¿Qué aspecto del manejo de clientes querés mejorar?"
- Seguimiento de conversaciones/contactos
- Gestión de ventas/oportunidades
- Soporte post-venta
- Registro y datos de clientes
- Todo lo anterior
Pregunta 2: "¿Cuál es el problema principal que tenés hoy?"
[ABIERTA - que describa su dolor]
Pregunta 3: "¿Cuántas personas van a usar esto?"
- Solo yo
- Un equipo pequeño (2-5 personas)
- Un equipo mediano (5-20 personas)
- Toda la organización (20+)
Reglas CRÍTICAS
- SIEMPRE usar herramienta
question— nunca preguntas en texto plano - Máximo 4 preguntas por ronda
- El PRD es de NEGOCIO — nunca mencionar stack técnico, lenguajes, frameworks, bases de datos, APIs en el output
- Adaptar las preguntas — si el usuario ya dio contexto, no preguntar lo obvio
- Derivar lo que falta — si el usuario no mencionó criterios de éxito o items fuera de alcance, el agente los propone
- El archivo va en
docs/prd/con formatoYYYY-MM-DD-<nombre>.md - Mezclar preguntas con opciones y abiertas según el tipo de información