jpskill.com
🛠️ 開発・MCP コミュニティ

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本体の挙動とは独立した参考情報です。

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux
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
🪟 Windows (PowerShell)
$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. 1. 下の青いボタンを押して prd-creator.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → prd-creator フォルダができる
  3. 3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
  4. 4. Claude Code を再起動

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

  1. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

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 をコンテキスト化するために、プロジェクトを理解すること。

エージェントは(静かに、質問せずに)以下を行います。

  1. package.json / go.mod / pyproject.toml / Cargo.toml を読み、ドメインを理解します。
  2. README.md が存在する場合は読みます。
  3. 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 に必要なすべてのビジネス情報を収集すること。

絶対的なルール

  1. 常に question ツールを使用する — プレーンテキストで質問しない
  2. 1 ラウンドあたり最大 4 つの質問 — これ以上は絶対にしない
  3. 必要な情報の種類に応じて、選択肢のある質問と自由記述式の質問を混ぜる
  4. question ツールは自動的に "Type your own answer" を追加します
  5. 以前の回答が質問を既にカバーしている場合 → スキップする
  6. 回答が新しい曖昧さを生み出す場合 → 次のラウンドに追加する
  7. 技術スタック、テクノロジー、または実装について質問しない — PRD はビジネスに関するものです
  8. 質問をコンテキストに適応させる — ユーザーが既に情報を提供している場合は、一般的な質問を使用しない

ラウンドの構成

質問バンク全体は 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):

  1. Lee package.json / go.mod / pyproject.toml / Cargo.toml para entender el dominio
  2. Lee README.md si existe
  3. 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

  1. SIEMPRE usar la herramienta question — nunca preguntas en texto plano
  2. Máximo 4 preguntas por ronda — nunca más
  3. Mezclar preguntas con opciones y abiertas según el tipo de información necesaria
  4. La herramienta question agrega "Type your own answer" automáticamente
  5. Si una respuesta anterior ya cubre una pregunta → saltarla
  6. Si una respuesta genera nueva ambigüedad → agregarla a la siguiente ronda
  7. NUNCA preguntar sobre stack técnico, tecnologías, o implementación — el PRD es de negocio
  8. 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.

  1. Crear el directorio docs/prd/ si no existe
  2. 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
  3. Escribir el archivo
  4. 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

  1. SIEMPRE usar herramienta question — nunca preguntas en texto plano
  2. Máximo 4 preguntas por ronda
  3. El PRD es de NEGOCIO — nunca mencionar stack técnico, lenguajes, frameworks, bases de datos, APIs en el output
  4. Adaptar las preguntas — si el usuario ya dio contexto, no preguntar lo obvio
  5. Derivar lo que falta — si el usuario no mencionó criterios de éxito o items fuera de alcance, el agente los propone
  6. El archivo va en docs/prd/ con formato YYYY-MM-DD-<nombre>.md
  7. Mezclar preguntas con opciones y abiertas según el tipo de información