/product-implement

name: product-implement
description: Use when accepted PDRs exist and PRD.md must be generated or updated.
disable-model-invocation: true

product-implement

What this skill does

Transforms **accepted PDRs** into a comprehensive, self-contained `PRD.md` using a **three-phase DAG**:

1. **Plan Agent**: Analyze PDRs, detect feature-areas, generate customized DAG, get user approval 2. **Execute Agent**: Generate sections per feature-area with **mandatory checkpoint after Requirements** 3. **Summarize Agent**: Aggregate sections, resolve conflicts, produce unified `PRD.md`

**Output**:

• `docs/adlc/product/PRD.md` — self-contained product requirements (the shared layout; legacy repo-root `PRD.md` stays read-compatible)
• `{REPO_ROOT}/.adlc/product/sections/{feature-area}/{section}.md` — intermediate section files
• Accepted PDRs **moved** to `{REPO_ROOT}/docs/adlc/memory/pdr/` (the shared layout canonical memory root)

When to use

• After `/product-clarify` has approved PDRs
• After `/product-init` to document existing product
• PDR updates requiring PRD regeneration

When NOT to use

• No Accepted PDRs (run `/product-clarify` first)
• Minor PRD edits (edit `PRD.md` directly)

Pre-Flight Validation

**Before starting, verify prerequisites:**

1. **Check PDRs exist**: `{REPO_ROOT}/.adlc/drafts/pdr/PDR-*.md` 2. **Check for Accepted PDRs**: Count files with status "Accepted"

• If **zero**: STOP and output:

     Cannot proceed: No Accepted PDRs found.
     Run /product-clarify to review and approve PDRs first.

• If ≥1: Proceed

Three-Phase DAG Workflow

┌─────────────────────────────────────────────────────────┐
│ PHASE 1: PLAN (Plan Agent)                              │
│ Load PDRs → Detect Feature-Areas → Generate DAG → Approve│
└─────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────┐
│ PHASE 2: EXECUTE (Execute Agent)                        │
│ Overview → Problem → Goals → Metrics → Personas         │
│ → [REQUIREMENTS CHECKPOINT] ← MANDATORY USER APPROVAL   │
│ → NFRs → Out-of-Scope → Risks → Roadmap → PDR-Summary   │
└─────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────┐
│ PHASE 3: SUMMARIZE (Summarize Agent)                    │
│ Read sections → Detect conflicts → Resolve → PRD.md     │
└─────────────────────────────────────────────────────────┘

Execution Steps

Phase 1: Plan

**Step 1.1: Load and Analyze PDRs**

1. Read all `PDR-*.md` files from `.adlc/drafts/pdr/` 2. Filter to **Accepted** status only 3. Parse feature-area from each PDR 4. Group PDRs by feature-area

**Step 1.2: Detect Feature-Area Characteristics**

| Characteristic | Detection Pattern | DAG Customization | |---------------|-------------------|-------------------| | B2B SaaS | Enterprise, admin, SSO | Include compliance sections | | Consumer App | Mobile, freemium, social | Simplify requirements | | Platform | API, integrations, developer | Expand NFRs | | Marketplace | Multi-sided, transaction | Add business model sections |

**Step 1.3: Generate Customized DAG**

**Default DAG** (all 15 sections):

Document Information → Executive Summary → Overview → Problem
→ Market Opportunity → Goals → Metrics → Personas
→ [CHECKPOINT: Requirements]
→ NFRs → Out-of-Scope → Risks → Investment
→ Roadmap → Go-to-Market → PDR-Summary

**Section numbering** (fixed):

• 1. Document Information
• 1.5 Executive Summary
• 2. Overview
• 3. The Problem
• 3.5 Market Opportunity
• 4. Goals & Objectives
• 5. Success Metrics
• 6. Personas
• 7. Functional Requirements
• 8. Non-Functional Requirements
• 9. Out of Scope
• 10. Risks & Mitigation
• 10.5 Investment & Resources
• 11. Roadmap & Milestones
• 11.5 Go-to-Market Strategy
• 12. PDR Summary

**Step 1.4: Present Plan for Approval**

## DAG Execution Plan

**Feature-Areas detected**: 3
**Total sections**: 15

**Feature-Area: Core**
**PDRs**: PDR-001, PDR-005, PDR-008
**DAG**: Document Info → Executive Summary → Overview → Problem
→ Market Opportunity → Goals → Metrics → Personas
→ [Requirements Checkpoint] → NFRs → Out-of-Scope → Risks
→ Investment → Roadmap → GTM → PDR-Summary

**Approve this plan?** [Yes/Modify/Cancel]

**Step 1.5: Write state.json**

{
  "version": "1.0",
  "phase": "plan_approved",
  "feature_areas": [
    {
      "id": "core",
      "name": "Core",
      "pdrs": ["PDR-001", "PDR-005"],
      "dag": ["document-info", "executive-summary", "overview", "problem", ...],
      "progress": {}
    }
  ],
  "checkpoint": {
    "enabled": true,
    "after_section": "requirements",
    "status": "pending"
  }
}

Phase 2: Execute

For each section in the DAG:

1. **Check dependencies** — ensure all prerequisites completed 2. **Load section template** — `../templates/sections/{section}.md` 3. **Generate content** — fill template with PDR-derived content 4. **Write section file** — `.adlc/product/sections/{feature-area}/{section}.md` 5. **Validate** — run `scripts/bash/validate-prd.sh {section}.md` 6. **Update state.json** — mark section as "completed"

**Section template usage** (MANDATORY):

• Read template FIRST
• Fill ALL [PLACEHOLDERS]
• NEVER generate from scratch

**In-section diagrams** (MANDATORY):

• Use ` ```mermaid ` code blocks
• Use `flowchart` keyword (NOT deprecated `graph`)
• ASCII box-drawing characters are PROHIBITED
• Diagrams embedded in their home sections

| Section | Diagram Type | Subsection | |---------|-------------|------------| | 2. Overview | Feature Hierarchy (`flowchart TD`) | 2.4 | | 2. Overview | Architecture (`flowchart TB`) | 2.5 | | 6. Personas | User Journey (`journey`) | 6.4 | | 7. Requirements | Req Dependencies (`flowchart LR`) | 7.4 | | 7. Requirements | Feature Dependencies (`flowchart LR`) | 7.5 | | 11. Roadmap | Gantt Chart (`gantt`) | 11.1 |

**Requiremen