the-product-playbook 2.6.0 → 2.6.2

package/SKILL.md

@@ -128,7 +128,7 @@ description: |
 | 🔄 改版模式 | `references/rules-revision.md` |
 | ✏️ 自訂模式 | `references/rules-custom.md` |
 | ⚡ 直接實作模式 | `references/rules-build.md` |
-| 🔧 功能擴充模式 | `references/rules-build.md`（功能擴充路徑段落） |
+| 🔧 功能擴充模式 | `references/rules-build.md` → 直接跳到「🔧 功能擴充快速路徑」段落 |
 
 確認產品類型後，讀取 `references/rules-product-type.md` 取得 B2B/B2C 差異化調整。
 

package/i18n/en/SKILL.md

@@ -128,7 +128,7 @@ After confirming the mode, **read the corresponding mode rules file** for the st
 | 🔄 Revision Mode | `references/rules-revision.md` |
 | ✏️ Custom Mode | `references/rules-custom.md` |
 | ⚡ Build Mode | `references/rules-build.md` |
-| 🔧 Feature Extension Mode | `references/rules-build.md` (Feature Extension path section) |
+| 🔧 Feature Extension Mode | `references/rules-build.md` → jump directly to "🔧 Feature Extension Quick Path" section |
 
 After confirming the product type, read `references/rules-product-type.md` for B2B/B2C differentiation adjustments.
 

package/i18n/en/references/rules-change-propagation.md

@@ -42,6 +42,15 @@ North Star / Metrics      → Hypothesis Validation Plan, Product Spec Summary
 Product Spec Summary      → HTML Report, PRD (if already generated)
 ```
 
+### Feature Extension dependency:
+```
+Feature Extension dependency:
+─────────────────────────────────────────────────────
+S1 (Problem + Context)  → S2 (Solutions), S3 (Risks), S4 (Execution Scope)
+S2 (Selected Solution)  → S3 (Risks), S4 (Execution Scope)
+S3 (Risk Assessment)    → S4 (Execution Scope)
+```
+
 ## Execution Process
 
 1. **Inform the user of the impact scope**: "You modified [step]. This affects [list of downstream steps]. I will update each one."

package/i18n/en/references/rules-commands.md

@@ -58,6 +58,10 @@ When the user says "skip user research," "problem is already known," "go straigh
 
 > Remind the user: "Skipping the user research phase means your solution is built on assumptions. We recommend conducting Continuous Discovery as soon as possible after execution to validate."
 
+## Feature Extension Mode Trigger
+
+- "Add a feature" / "I want to add a new feature" / "new feature for existing product" → triggers Feature Extension Mode (reads `references/rules-build.md` → Feature Extension Quick Path)
+
 ## Supplementary Commands
 
 | Command | Behavior |

package/i18n/en/references/rules-context.md

@@ -188,6 +188,8 @@ When the context file exists but some sections are empty, determine whether to s
 | Decision History | Can skip | Include if available, skip if not | The flow itself will produce this |
 | Accumulated Insights | Can skip | Include if available, skip if not | The flow itself will produce this |
 
+| Feature Extension | Identity (confirm only), Architecture & Tech Stack (required), Core Strategy (skip allowed) |
+
 **Principle**: Empty sections **do not block the flow**. Only sections that are "required" for the current mode and are empty will trigger collection.
 
 ---

package/i18n/en/references/rules-end-of-flow.md

@@ -13,6 +13,58 @@ Before producing the final integrated output, the following must be verified:
 
 Violations of this rule include: Independently deciding that "the remaining steps are not important" and skipping them, marking incomplete steps as completed, or combining multiple steps into a single output.
 
+## 🔍 Decision Consistency Check
+
+Before generating the final integrated output, scan ALL completed steps and verify cross-step consistency:
+
+### Checks by Mode
+
+**🚀 Quick Mode** (3 steps — check 2 cross-references):
+1. JTBD ↔ PR-FAQ: Does the PR-FAQ address the same problem as the JTBD statement?
+2. PR-FAQ ↔ North Star: Does the North Star measure the outcome the PR-FAQ promises?
+
+**📦 Full Mode** (20 steps — check all 7):
+1. Target User — same persona referenced across JTBD, Positioning, PR-FAQ, and North Star?
+2. Core Problem / JTBD — PR-FAQ addresses the same problem? MVP solves it?
+3. Positioning — reflected in PR-FAQ headline and solution direction?
+4. Solution Direction — selected solution matches MVP scope?
+5. MVP Scope — consistent with PR-FAQ promises? "Not Doing" items respected?
+6. North Star Metric — measures JTBD outcome? Achievable with MVP scope?
+7. Pre-mortem Risks — still relevant given final solution and MVP?
+
+**🔄 Revision Mode** (12 steps — check 4):
+1. Existing JTBD ↔ Pain Points ↔ Positioning: consistent after re-evaluation?
+2. PR-FAQ ↔ MVP Scope: revision scope matches what PR-FAQ describes?
+3. North Star ↔ Before/After: metric comparison is logical?
+4. Pre-mortem Risks: still relevant for the revised product?
+
+**⚡ Build Mode** (7 steps — check 4):
+1. Problem Statement ↔ PR-FAQ: same problem addressed?
+2. Solution Direction ↔ MVP Scope: selected solution matches MVP?
+3. North Star ↔ MVP: metric achievable with MVP scope?
+4. Pre-mortem Risks: still relevant for final solution?
+
+**🔧 Feature Extension Mode** (4 steps — check 3):
+1. Problem ↔ Selected Solution: solution directly addresses the stated problem?
+2. Solution ↔ Execution Scope: scope correctly implements the selected solution?
+3. Risk Assessment: identified risks still relevant for the execution scope?
+
+**✏️ Custom Mode** — only check cross-references between steps the user actually executed. Skip checks for steps that were not part of the custom selection.
+
+### Execution
+1. List each core decision as a one-liner (e.g., "Target User: Early-stage startup founders")
+2. Check for contradictions or outdated references between steps
+3. If inconsistencies are found:
+   - Display: "⚠️ Consistency check found [N] issue(s) before final output:"
+   - List each issue with the affected steps
+   - Ask user: "Should I fix these before generating the final output, or proceed as-is?"
+4. If all consistent:
+   - Display: "✅ Decision consistency check passed — all steps aligned."
+   - Proceed to final output
+
+### Why This Matters
+During iterative planning, users may modify upstream decisions (e.g., change JTBD) while some downstream steps retain outdated content. This check catches those gaps before the final document is produced, preventing inconsistent deliverables.
+
 ## 📦 Product Context Auto-Extraction
 
 After all steps are completed and while producing the final integrated output, read `references/rules-context.md` Section 8 to perform context extraction:
@@ -43,7 +95,7 @@ Analysis points: Most worthwhile problem to solve / Core JTBD / Product position
 
 | Mode | Final Integrated Output |
 |------|------------------------|
-| ⚡ Feature Extension (Build Mode variant) | Feature development spec: Problem → Selected solution → Impact scope → Execution scope → Risks |
+| 🔧 Feature Extension Mode | Feature development spec: Problem → Selected solution → Impact scope → Execution scope → Risks |
 | 🚀 Quick Mode | One-page direction summary: Problem → Solution → Success Definition |
 | 📦 Full Mode | Best Entry Point Analysis + Product Spec Summary |
 | 🔄 Revision Mode | Revision product spec summary: Before/after comparison + What to change/What not to change + Success metrics |

package/i18n/en/references/rules-progress.md

@@ -29,6 +29,16 @@ After each step is completed, create or update `.product-playbook-progress.md` i
 - ...
 ```
 
+### Feature Extension Mode Example
+```markdown
+Mode: Feature Extension
+Step: S2/S4
+S1: Problem + existing system context ✅
+S2: Three parallel solutions + AI recommendation ▶️
+S3: Risk assessment ⬜
+S4: Execution scope ⬜
+```
+
 ## Trigger Rules
 
 1. **Auto-save**: After each step is completed and confirmed by the user, immediately update the progress file

package/i18n/es/SKILL.md

@@ -128,7 +128,7 @@ Después de confirmar el modo, **lee el archivo de reglas del modo correspondien
 | 🔄 Modo Revisión | `references/rules-revision.md` |
 | ✏️ Modo Personalizado | `references/rules-custom.md` |
 | ⚡ Modo Build | `references/rules-build.md` |
-| 🔧 Modo Extensión de Feature | `references/rules-build.md` (sección de ruta de Extensión de Feature) |
+| 🔧 Modo Extensión de Feature | `references/rules-build.md` → saltar directamente a la sección "🔧 Ruta Rápida de Extensión de Feature" |
 
 Después de confirmar el tipo de producto, lee `references/rules-product-type.md` para ajustes de diferenciación B2B/B2C.
 

package/i18n/es/references/rules-change-propagation.md

@@ -42,6 +42,15 @@ North Star / Métricas      → Plan de Validación de Hipótesis, Resumen de Sp
 Resumen de Spec de Producto      → Reporte HTML, PRD (si ya se generó)
 ```
 
+### Dependencia de Extensión de Funcionalidad:
+```
+Dependencia de Extensión de Funcionalidad:
+─────────────────────────────────────────────────────
+S1 (Problema + Contexto)      → S2 (Soluciones), S3 (Riesgos), S4 (Alcance de Ejecución)
+S2 (Solución Seleccionada)    → S3 (Riesgos), S4 (Alcance de Ejecución)
+S3 (Evaluación de Riesgos)    → S4 (Alcance de Ejecución)
+```
+
 ## Proceso de Ejecución
 
 1. **Informar al usuario del alcance del impacto**: "Modificaste [paso]. Esto afecta [lista de pasos downstream]. Actualizaré cada uno."

package/i18n/es/references/rules-commands.md

@@ -58,6 +58,10 @@ Cuando el usuario dice "omitir investigación de usuarios," "el problema ya es c
 
 > Recuerda al usuario: "Omitir la fase de investigación de usuarios significa que tu solución está construida sobre suposiciones. Recomendamos realizar Descubrimiento Continuo lo antes posible después de la ejecución para validar."
 
+## Activación del Modo Extensión de Funcionalidad
+
+- "Agregar una funcionalidad" / "Quiero agregar una nueva funcionalidad" / "nueva funcionalidad para producto existente" → activa el Modo Extensión de Funcionalidad (lee `references/rules-build.md` → Ruta Rápida de Extensión de Funcionalidad)
+
 ## Comandos Complementarios
 
 | Comando | Comportamiento |

package/i18n/es/references/rules-context.md

@@ -188,6 +188,8 @@ Cuando el archivo de contexto existe pero algunas secciones están vacías, dete
 | Historial de Decisiones | Puede omitirse | Incluir si disponible, omitir si no | El flujo mismo producirá esto |
 | Insights Acumulados | Puede omitirse | Incluir si disponible, omitir si no | El flujo mismo producirá esto |
 
+| Extensión de Funcionalidad | Identity (solo confirmar), Architecture & Tech Stack (requerido), Core Strategy (se permite omitir) |
+
 **Principio**: Las secciones vacías **no bloquean el flujo**. Solo las secciones que son "requeridas" para el modo actual y están vacías activarán la recopilación.
 
 ---

package/i18n/es/references/rules-end-of-flow.md

@@ -13,6 +13,58 @@ Antes de producir el output final integrado, lo siguiente debe verificarse:
 
 Violaciones a esta regla incluyen: Decidir independientemente que "los pasos restantes no son importantes" y omitirlos, marcar pasos incompletos como completados, o combinar múltiples pasos en un solo output.
 
+## 🔍 Verificación de Consistencia de Decisiones
+
+Antes de generar el output final integrado, escanear TODOS los pasos completados y verificar la consistencia entre pasos:
+
+### Verificaciones por Modo
+
+**🚀 Modo Rápido** (3 pasos — verificar 2 referencias cruzadas):
+1. JTBD ↔ PR-FAQ: ¿El PR-FAQ aborda el mismo problema que la declaración JTBD?
+2. PR-FAQ ↔ North Star: ¿El North Star mide el resultado que el PR-FAQ promete?
+
+**📦 Modo Completo** (20 pasos — verificar las 7):
+1. Usuario Objetivo — ¿se referencia la misma persona en JTBD, Posicionamiento, PR-FAQ y North Star?
+2. Problema Central / JTBD — ¿el PR-FAQ aborda el mismo problema? ¿El MVP lo resuelve?
+3. Posicionamiento — ¿se refleja en el titular del PR-FAQ y la dirección de la solución?
+4. Dirección de la Solución — ¿la solución seleccionada coincide con el alcance del MVP?
+5. Alcance del MVP — ¿es consistente con las promesas del PR-FAQ? ¿Se respetan los elementos "No Hacer"?
+6. North Star Metric — ¿mide el resultado del JTBD? ¿Es alcanzable con el alcance del MVP?
+7. Riesgos Pre-mortem — ¿siguen siendo relevantes dada la solución final y el MVP?
+
+**🔄 Modo Revisión** (12 pasos — verificar 4):
+1. JTBD existente ↔ Puntos de Dolor ↔ Posicionamiento: ¿consistentes después de la reevaluación?
+2. PR-FAQ ↔ Alcance del MVP: ¿el alcance de la revisión coincide con lo que describe el PR-FAQ?
+3. North Star ↔ Antes/Después: ¿la comparación de métricas es lógica?
+4. Riesgos Pre-mortem: ¿siguen siendo relevantes para el producto revisado?
+
+**⚡ Modo Build** (7 pasos — verificar 4):
+1. Declaración del Problema ↔ PR-FAQ: ¿se aborda el mismo problema?
+2. Dirección de la Solución ↔ Alcance del MVP: ¿la solución seleccionada coincide con el MVP?
+3. North Star ↔ MVP: ¿la métrica es alcanzable con el alcance del MVP?
+4. Riesgos Pre-mortem: ¿siguen siendo relevantes para la solución final?
+
+**🔧 Modo Extensión de Feature** (4 pasos — verificar 3):
+1. Problema ↔ Solución Seleccionada: ¿la solución aborda directamente el problema planteado?
+2. Solución ↔ Alcance de Ejecución: ¿el alcance implementa correctamente la solución seleccionada?
+3. Evaluación de Riesgos: ¿los riesgos identificados siguen siendo relevantes para el alcance de ejecución?
+
+**✏️ Modo Personalizado** — solo verificar referencias cruzadas entre los pasos que el usuario realmente ejecutó. Omitir verificaciones de pasos que no formaron parte de la selección personalizada.
+
+### Ejecución
+1. Listar cada decisión clave en una línea (ej., "Usuario Objetivo: Fundadores de startups en etapa temprana")
+2. Verificar si existen contradicciones o referencias desactualizadas entre pasos
+3. Si se encuentran inconsistencias:
+   - Mostrar: "⚠️ La verificación de consistencia encontró [N] problema(s) antes del output final:"
+   - Listar cada problema con los pasos afectados
+   - Preguntar al usuario: "¿Debo corregir estos problemas antes de generar el output final, o proceder tal como está?"
+4. Si todo es consistente:
+   - Mostrar: "✅ Verificación de consistencia de decisiones aprobada — todos los pasos están alineados."
+   - Proceder al output final
+
+### Por Qué Esto Es Importante
+Durante la planificación iterativa, los usuarios pueden modificar decisiones anteriores (ej., cambiar el JTBD) mientras algunos pasos posteriores retienen contenido desactualizado. Esta verificación detecta esas brechas antes de que se produzca el documento final, evitando entregables inconsistentes.
+
 ## 📦 Auto-Extracción de Contexto de Producto
 
 Después de que todos los pasos estén completos y mientras se produce el output final integrado, lee `references/rules-context.md` Sección 8 para realizar la extracción de contexto:
@@ -43,7 +95,7 @@ Puntos de análisis: Problema más valioso a resolver / JTBD Central / Posiciona
 
 | Modo | Output Final Integrado |
 |------|----------------------|
-| ⚡ Extensión de Feature (variante Modo Build) | Especificación de desarrollo de feature: Problema → Solución seleccionada → Alcance de impacto → Alcance de ejecución → Riesgos |
+| 🔧 Modo Extensión de Feature | Especificación de desarrollo de feature: Problema → Solución seleccionada → Alcance de impacto → Alcance de ejecución → Riesgos |
 | 🚀 Modo Rápido | Resumen de dirección de una página: Problema → Solución → Definición de Éxito |
 | 📦 Modo Completo | Análisis del Mejor Punto de Entrada + Resumen de Spec de Producto |
 | 🔄 Modo Revisión | Resumen de spec de producto de revisión: Comparación antes/después + Qué cambiar/Qué no cambiar + Métricas de éxito |

package/i18n/es/references/rules-progress.md

@@ -29,6 +29,16 @@ Después de completar cada paso, crear o actualizar `.product-playbook-progress.
 - ...
 ```
 
+### Ejemplo de Modo Extensión de Funcionalidad
+```markdown
+Modo: Extensión de Funcionalidad
+Paso: S2/S4
+S1: Problema + contexto del sistema existente ✅
+S2: Tres soluciones paralelas + recomendación de IA ▶️
+S3: Evaluación de riesgos ⬜
+S4: Alcance de ejecución ⬜
+```
+
 ## Reglas de Activación
 
 1. **Auto-guardado**: Después de completar cada paso y ser confirmado por el usuario, actualizar inmediatamente el archivo de progreso

package/i18n/ja/SKILL.md

@@ -128,7 +128,7 @@ description: |
 | 🔄 リビジョンモード | `references/rules-revision.md` |
 | ✏️ カスタムモード | `references/rules-custom.md` |
 | ⚡ ビルドモード | `references/rules-build.md` |
-| 🔧 機能拡張モード | `references/rules-build.md`（機能拡張パスセクション） |
+| 🔧 機能拡張モード | `references/rules-build.md` → 「🔧 機能拡張クイックパス」セクションに直接ジャンプ |
 
 プロダクトタイプ確認後、`references/rules-product-type.md`を読み込み、B2B/B2Cの差異調整を適用してください。
 

package/i18n/ja/references/rules-change-propagation.md

@@ -42,6 +42,15 @@ North Star / メトリクス    → 仮説検証プラン、プロダクトス
 プロダクトスペックサマリー → HTMLレポート、PRD（既に生成済みの場合）
 ```
 
+### 機能拡張の依存関係：
+```
+機能拡張の依存関係：
+─────────────────────────────────────────────────────
+S1（問題 + コンテキスト）  → S2（ソリューション）、S3（リスク）、S4（実行スコープ）
+S2（選択したソリューション）→ S3（リスク）、S4（実行スコープ）
+S3（リスク評価）           → S4（実行スコープ）
+```
+
 ## 実行プロセス
 
 1. **影響範囲をユーザーに通知**：「[ステップ]を修正しました。これは[下流ステップのリスト]に影響します。それぞれ更新します。」

package/i18n/ja/references/rules-commands.md

@@ -58,6 +58,10 @@
 
 > ユーザーにリマインド：「ユーザーリサーチフェーズをスキップすることは、ソリューションが仮定に基づいて構築されることを意味します。実行後できるだけ早くContinuous Discoveryを実施して検証することをお勧めします。」
 
+## 機能拡張モードのトリガー
+
+- 「機能を追加」/「新しい機能を追加したい」/「既存プロダクトに新機能」→ 機能拡張モードをトリガー（`references/rules-build.md` → 機能拡張クイックパスを読み込み）
+
 ## 補助コマンド
 
 | コマンド | 動作 |

package/i18n/ja/references/rules-context.md

@@ -188,6 +188,8 @@
 | Decision History | スキップ可能 | あれば含める、なければスキップ | フロー自体がこれを生成 |
 | Accumulated Insights | スキップ可能 | あれば含める、なければスキップ | フロー自体がこれを生成 |
 
+| 機能拡張 | Identity（確認のみ）、Architecture & Tech Stack（必須）、Core Strategy（スキップ可能） |
+
 **原則**：空セクションは**フローをブロックしない**。現在のモードで「必須」のセクションが空の場合のみ、収集をトリガー。
 
 ---

package/i18n/ja/references/rules-end-of-flow.md

@@ -13,6 +13,58 @@
 
 このルールの違反例：「残りのステップは重要ではない」と独自に判断してスキップする、未完了のステップを完了済みとマークする、複数のステップを単一の出力に統合する。
 
+## 🔍 意思決定の一貫性チェック
+
+最終統合出力を生成する前に、完了したすべてのステップをスキャンし、ステップ間の一貫性を検証します：
+
+### モード別チェック項目
+
+**🚀 クイックモード**（3ステップ — 2つの相互参照をチェック）：
+1. JTBD ↔ PR-FAQ：PR-FAQはJTBDステートメントと同じ課題に取り組んでいるか？
+2. PR-FAQ ↔ North Star：North Star MetricはPR-FAQが約束する成果を測定しているか？
+
+**📦 フルモード**（20ステップ — 全7項目をチェック）：
+1. ターゲットユーザー — JTBD、ポジショニング、PR-FAQ、North Starで同一のペルソナを参照しているか？
+2. コア課題 / JTBD — PR-FAQは同じ課題に取り組んでいるか？MVPはそれを解決しているか？
+3. ポジショニング — PR-FAQの見出しとソリューション方向に反映されているか？
+4. ソリューション方向 — 選択されたソリューションはMVPスコープと一致しているか？
+5. MVPスコープ — PR-FAQの約束と一致しているか？「やらないこと」の項目は遵守されているか？
+6. North Star Metric — JTBDの成果を測定しているか？MVPスコープで達成可能か？
+7. Pre-mortemリスク — 最終ソリューションとMVPを踏まえて依然として関連性があるか？
+
+**🔄 リビジョンモード**（12ステップ — 4項目をチェック）：
+1. 既存のJTBD ↔ ペインポイント ↔ ポジショニング：再評価後も一貫しているか？
+2. PR-FAQ ↔ MVPスコープ：リビジョン範囲はPR-FAQの記述と一致しているか？
+3. North Star ↔ Before/After：指標の比較は論理的か？
+4. Pre-mortemリスク：改訂後のプロダクトに対して依然として関連性があるか？
+
+**⚡ ビルドモード**（7ステップ — 4項目をチェック）：
+1. 課題ステートメント ↔ PR-FAQ：同じ課題に取り組んでいるか？
+2. ソリューション方向 ↔ MVPスコープ：選択されたソリューションはMVPと一致しているか？
+3. North Star ↔ MVP：指標はMVPスコープで達成可能か？
+4. Pre-mortemリスク：最終ソリューションに対して依然として関連性があるか？
+
+**🔧 機能拡張モード**（4ステップ — 3項目をチェック）：
+1. 課題 ↔ 選択したソリューション：ソリューションは述べられた課題を直接解決しているか？
+2. ソリューション ↔ 実行スコープ：スコープは選択したソリューションを正しく実装しているか？
+3. リスク評価：特定されたリスクは実行スコープに対して依然として関連性があるか？
+
+**✏️ カスタムモード** — ユーザーが実際に実行したステップ間の相互参照のみをチェックします。カスタム選択に含まれなかったステップのチェックはスキップします。
+
+### 実行方法
+1. 各コア意思決定を1行のサマリーとしてリストアップ（例：「ターゲットユーザー：アーリーステージのスタートアップ創業者」）
+2. ステップ間の矛盾や古くなった参照がないか確認
+3. 不整合が見つかった場合：
+   - 表示：「⚠️ 一貫性チェックにより最終出力前に [N] 件の問題が見つかりました：」
+   - 各問題と影響を受けるステップをリストアップ
+   - ユーザーに質問：「最終出力を生成する前にこれらを修正しますか、それともこのまま進めますか？」
+4. すべて一貫している場合：
+   - 表示：「✅ 意思決定の一貫性チェック合格 — すべてのステップが整合しています。」
+   - 最終出力の生成に進む
+
+### このチェックが重要な理由
+反復的な企画プロセスにおいて、ユーザーは上流の意思決定（例：JTBDの変更）を修正することがありますが、一部の下流ステップには古いコンテンツが残ることがあります。このチェックは、最終ドキュメントが作成される前にそのギャップを検出し、一貫性のない成果物の発生を防ぎます。
+
 ## 📦 プロダクトコンテキスト自動抽出
 
 すべてのステップが完了し最終統合出力を作成する間に、`references/rules-context.md`セクション8を読み込みコンテキスト抽出を実行：
@@ -43,7 +95,7 @@
 
 | モード | 最終統合出力 |
 |------|------------------------|
-| ⚡ 機能拡張（ビルドモード派生） | 機能開発仕様：問題 → 選択したソリューション → 影響範囲 → 実行スコープ → リスク |
+| 🔧 機能拡張モード | 機能開発仕様：問題 → 選択したソリューション → 影響範囲 → 実行スコープ → リスク |
 | 🚀 クイックモード | 1ページの方向性サマリー：問題 → ソリューション → 成功の定義 |
 | 📦 フルモード | 最適エントリーポイント分析 + プロダクトスペックサマリー |
 | 🔄 リビジョンモード | リビジョンプロダクトスペックサマリー：Before/After比較 + 変更すること/変更しないこと + 成功メトリクス |

package/i18n/ja/references/rules-progress.md

@@ -29,6 +29,16 @@
 - ...
 ```
 
+### 機能拡張モードの例
+```markdown
+モード：機能拡張
+ステップ：S2/S4
+S1：問題 + 既存システムのコンテキスト ✅
+S2：3つの並行ソリューション + AI推奨 ▶️
+S3：リスク評価 ⬜
+S4：実行スコープ ⬜
+```
+
 ## トリガールール
 
 1. **自動保存**：各ステップが完了しユーザーに確認された後、即座に進捗ファイルを更新

package/i18n/ko/SKILL.md

@@ -128,7 +128,7 @@ description: |
 | 🔄 리비전 모드 | `references/rules-revision.md` |
 | ✏️ 커스텀 모드 | `references/rules-custom.md` |
 | ⚡ 빌드 모드 | `references/rules-build.md` |
-| 🔧 기능 확장 모드 | `references/rules-build.md` (기능 확장 경로 섹션) |
+| 🔧 기능 확장 모드 | `references/rules-build.md` → 「🔧 기능 확장 빠른 경로」 섹션으로 바로 이동 |
 
 제품 유형을 확인한 후, `references/rules-product-type.md`를 읽어 B2B/B2C 차별화 조정을 적용하세요.
 

package/i18n/ko/references/rules-change-propagation.md

@@ -42,6 +42,15 @@ North Star / 지표          → 가설 검증 계획, 제품 스펙 요약
 제품 스펙 요약              → HTML 보고서, PRD (이미 생성된 경우)
 ```
 
+### 기능 확장 의존 관계:
+```
+기능 확장 의존 관계:
+─────────────────────────────────────────────────────
+S1 (문제 + 컨텍스트)     → S2 (솔루션), S3 (리스크), S4 (실행 범위)
+S2 (선택된 솔루션)       → S3 (리스크), S4 (실행 범위)
+S3 (리스크 평가)         → S4 (실행 범위)
+```
+
 ## 실행 프로세스
 
 1. **사용자에게 영향 범위를 알림**: "당신이 [단계]를 수정했습니다. 이것은 [하위 단계 목록]에 영향을 미칩니다. 각각 업데이트하겠습니다."

package/i18n/ko/references/rules-commands.md

@@ -58,6 +58,10 @@
 
 > 사용자에게 알림: "사용자 리서치 단계를 건너뛰면 솔루션이 가정에 기반하게 됩니다. 실행 후 가능한 빨리 Continuous Discovery를 수행하여 검증하는 것을 권장합니다."
 
+## 기능 확장 모드 트리거
+
+- "기능 추가" / "새 기능을 추가하고 싶어요" / "기존 제품에 새 기능" → 기능 확장 모드를 트리거합니다 (`references/rules-build.md` → 기능 확장 빠른 경로를 읽음)
+
 ## 보조 명령
 
 | 명령 | 동작 |

package/i18n/ko/references/rules-context.md

@@ -188,6 +188,8 @@
 | Decision History | 건너뛸 수 있음 | 있으면 포함, 없으면 건너뛰기 | 플로우 자체가 이를 생성 |
 | Accumulated Insights | 건너뛸 수 있음 | 있으면 포함, 없으면 건너뛰기 | 플로우 자체가 이를 생성 |
 
+| 기능 확장 | Identity（확인만）、Architecture & Tech Stack（필수）、Core Strategy（건너뛰기 가능） |
+
 **원칙**: 빈 섹션은 **플로우를 차단하지 않습니다**. 현재 모드에 "필수"이면서 비어있는 섹션만 수집을 트리거합니다.
 
 ---

package/i18n/ko/references/rules-end-of-flow.md

@@ -13,6 +13,58 @@
 
 이 규칙의 위반 예: 독자적으로 "나머지 단계는 중요하지 않다"고 판단하여 건너뛰기, 불완전한 단계를 완료로 표시, 여러 단계를 단일 산출물로 합치기.
 
+## 🔍 의사결정 일관성 검사
+
+최종 통합 산출물을 생성하기 전에, 완료된 모든 단계를 스캔하고 단계 간 일관성을 검증합니다:
+
+### 모드별 검사 항목
+
+**🚀 퀵 모드** (3 단계 — 2개 교차 참조 검사):
+1. JTBD ↔ PR-FAQ: PR-FAQ가 JTBD 선언문과 동일한 문제를 다루고 있는가?
+2. PR-FAQ ↔ North Star: North Star Metric이 PR-FAQ가 약속한 성과를 측정하고 있는가?
+
+**📦 풀 모드** (20 단계 — 전체 7항목 검사):
+1. 타겟 사용자 — JTBD, 포지셔닝, PR-FAQ, North Star에서 동일한 페르소나를 참조하고 있는가?
+2. 핵심 문제 / JTBD — PR-FAQ가 동일한 문제를 다루는가? MVP가 이를 해결하는가?
+3. 포지셔닝 — PR-FAQ 헤드라인과 솔루션 방향에 반영되어 있는가?
+4. 솔루션 방향 — 선택된 솔루션이 MVP 범위와 일치하는가?
+5. MVP 범위 — PR-FAQ 약속과 일치하는가? "하지 않을 것" 항목이 준수되고 있는가?
+6. North Star Metric — JTBD 성과를 측정하는가? MVP 범위 내에서 달성 가능한가?
+7. Pre-mortem 리스크 — 최종 솔루션과 MVP를 고려할 때 여전히 관련성이 있는가?
+
+**🔄 리비전 모드** (12 단계 — 4항목 검사):
+1. 기존 JTBD ↔ 페인포인트 ↔ 포지셔닝: 재평가 후에도 일관성이 있는가?
+2. PR-FAQ ↔ MVP 범위: 리비전 범위가 PR-FAQ 설명과 일치하는가?
+3. North Star ↔ 전후 비교: 지표 비교가 논리적인가?
+4. Pre-mortem 리스크: 개정된 제품에 대해 여전히 관련성이 있는가?
+
+**⚡ 빌드 모드** (7 단계 — 4항목 검사):
+1. 문제 선언문 ↔ PR-FAQ: 동일한 문제를 다루고 있는가?
+2. 솔루션 방향 ↔ MVP 범위: 선택된 솔루션이 MVP와 일치하는가?
+3. North Star ↔ MVP: 지표가 MVP 범위 내에서 달성 가능한가?
+4. Pre-mortem 리스크: 최종 솔루션에 대해 여전히 관련성이 있는가?
+
+**🔧 기능 확장 모드** (4 단계 — 3항목 검사):
+1. 문제 ↔ 선택된 솔루션: 솔루션이 명시된 문제를 직접 해결하는가?
+2. 솔루션 ↔ 실행 범위: 범위가 선택된 솔루션을 올바르게 구현하는가?
+3. 리스크 평가: 식별된 리스크가 실행 범위에 대해 여전히 관련성이 있는가?
+
+**✏️ 커스텀 모드** — 사용자가 실제로 실행한 단계 간의 교차 참조만 검사합니다. 커스텀 선택에 포함되지 않은 단계의 검사는 건너뜁니다.
+
+### 실행 방법
+1. 각 핵심 의사결정을 한 줄 요약으로 나열 (예: "타겟 사용자: 초기 스타트업 창업자")
+2. 단계 간 모순이나 오래된 참조가 있는지 확인
+3. 불일치가 발견된 경우:
+   - 표시: "⚠️ 일관성 검사에서 최종 산출물 전에 [N]개의 문제를 발견했습니다:"
+   - 각 문제와 영향받는 단계를 나열
+   - 사용자에게 질문: "최종 산출물을 생성하기 전에 이를 수정할까요, 아니면 그대로 진행할까요?"
+4. 모두 일관된 경우:
+   - 표시: "✅ 의사결정 일관성 검사 통과 — 모든 단계가 정렬되었습니다."
+   - 최종 산출물 생성으로 진행
+
+### 이 검사가 중요한 이유
+반복적인 기획 과정에서, 사용자는 상위 의사결정(예: JTBD 변경)을 수정할 수 있지만, 일부 하위 단계에는 오래된 내용이 남아 있을 수 있습니다. 이 검사는 최종 문서가 생성되기 전에 이러한 격차를 포착하여, 일관성 없는 산출물이 만들어지는 것을 방지합니다.
+
 ## 📦 제품 컨텍스트 자동 추출
 
 모든 단계가 완료되고 최종 통합 산출물을 작성하면서, `references/rules-context.md` 섹션 8을 읽어 컨텍스트 추출을 수행하세요:
@@ -43,7 +95,7 @@
 
 | 모드 | 최종 통합 산출물 |
 |------|---------------|
-| ⚡ 기능 확장 (빌드 모드 변형) | 기능 개발 사양: 문제 → 선택한 솔루션 → 영향 범위 → 실행 범위 → 리스크 |
+| 🔧 기능 확장 모드 | 기능 개발 사양: 문제 → 선택한 솔루션 → 영향 범위 → 실행 범위 → 리스크 |
 | 🚀 퀵 모드 | 1페이지 방향 요약: 문제 → 솔루션 → 성공 정의 |
 | 📦 풀 모드 | 최적 진입점 분석 + 제품 스펙 요약 |
 | 🔄 리비전 모드 | 리비전 제품 스펙 요약: 전후 비교 + 변경/유지 + 성공 지표 |

package/i18n/ko/references/rules-progress.md

@@ -29,6 +29,16 @@
 - ...
 ```
 
+### 기능 확장 모드 예시
+```markdown
+모드: 기능 확장
+단계: S2/S4
+S1: 문제 + 기존 시스템 컨텍스트 ✅
+S2: 3가지 병렬 솔루션 + AI 추천 ▶️
+S3: 리스크 평가 ⬜
+S4: 실행 범위 ⬜
+```
+
 ## 트리거 규칙
 
 1. **자동 저장**: 각 단계가 완료되고 사용자가 확인한 후, 즉시 진행 파일을 업데이트

package/i18n/zh-CN/SKILL.md

@@ -128,7 +128,7 @@ description: |
 | 🔄 改版模式 | `references/rules-revision.md` |
 | ✏️ 自订模式 | `references/rules-custom.md` |
 | ⚡ 直接实作模式 | `references/rules-build.md` |
-| 🔧 功能扩充模式 | `references/rules-build.md`（功能扩充路径段落） |
+| 🔧 功能扩充模式 | `references/rules-build.md` → 直接跳到「🔧 功能扩充快速路径」段落 |
 
 确认产品类型后，读取 `references/rules-product-type.md` 取得 B2B/B2C 差异化调整。
 

package/i18n/zh-CN/references/rules-change-propagation.md

@@ -42,6 +42,15 @@ North Star / 指标     → 假设验证计划、产品规格摘要
 产品规格摘要           → HTML 报告、PRD（若已产出）
 ```
 
+### 功能扩充依赖关系：
+```
+功能扩充依赖关系：
+─────────────────────────────────────────────────────
+S1（问题 + 情境）     → S2（解法）、S3（风险）、S4（执行范围）
+S2（选定解法）        → S3（风险）、S4（执行范围）
+S3（风险评估）        → S4（执行范围）
+```
+
 ## 执行方式
 
 1. **告知使用者影响范围**：「你修改了 [步骤]，这会影响到 [下游步骤清单]，我会逐一更新。」

package/i18n/zh-CN/references/rules-commands.md

@@ -58,6 +58,10 @@
 
 > 提醒使用者：「跳过用户研究阶段，代表解法建立在假设上。建议执行后尽快进行 Continuous Discovery 验证。」
 
+## 功能扩充模式触发
+
+- 「新增功能」/「我要在现有产品加一个功能」/「加新功能」→ 触发功能扩充模式（读取 `references/rules-build.md` → 功能扩充快速路径）
+
 ## 补充指令
 
 | 指令 | 行为 |

package/i18n/zh-CN/references/rules-context.md

@@ -188,6 +188,8 @@ Context 文件存在但某些 sections 为空时，依**模式**决定是否可
 | Decision History | 可跳过 | 有则带入，无则跳过 | 流程本身会产出 |
 | Accumulated Insights | 可跳过 | 有则带入，无则跳过 | 流程本身会产出 |
 
+| 功能扩充模式 | Identity（仅确认）、Architecture & Tech Stack（必要）、Core Strategy（可跳过） |
+
 **原则**：空白 section **不阻挡流程**。只有对当前模式「必要」且为空的 section 才触发收集。
 
 ---