/product-init

name: product-init
description: Use when documenting product decisions inferred from an already-built product (brownfield) via multi-agent feature-area analysis.
disable-model-invocation: true

product-init

What this skill does

Reverse-engineers product decisions from an **existing product** using a **three-phase analysis pipeline**:

1. **Discovery Agent**: Scans each feature-area for raw product signals (code, docs, pricing) 2. **Pattern Agent**: Classifies signals into PDR categories, scores strategic importance 3. **Synthesis Agent**: Cross-feature-area analysis, flags inconsistencies

**Output**: Individual `PDR-{NNN}.md` files (status **Discovered**) in `.adlc/drafts/pdr/` with an auto-generated `pdr.md` index.

When to use

• Existing product with no formal PDRs
• Brownfield codebase needs product documentation
• Team onboarding — walking through product rationale
• Post-acquisition or inherited codebase

When NOT to use

• New product (use `/product-specify` instead)
• Minor PDR updates (use `/product-clarify` instead)

Execution Steps

Phase 0: Environment Setup

**Run setup script** to resolve paths and detect feature-areas:

sh: scripts/bash/setup-product-init.sh [--json]
ps: scripts/powershell/setup-product-init.ps1

**Requires:** the `product-clarify` skill (provides `pdr-lib.sh`): `adlc-cli skills add tikalk/adlc-team-skills --skill product-clarify`

**Setup output** (JSON):

{
  "REPO_ROOT": "/path/to/project",
  "PDR_DRAFTS_DIR": "/path/to/project/.adlc/drafts/pdr",
  "PRD_FILE": "/path/to/project/PRD.md",
  "feature_areas": ["core", "business", "growth"],
  "next_pdr": "001"
}

**Create directories**:

mkdir -p "{REPO_ROOT}/.adlc/drafts/pdr"
mkdir -p "{REPO_ROOT}/.adlc/product"

Phase 1: Feature-Area Detection

Detect feature-areas from **three sources**:

| Source | Detection Pattern | |---|---| | Directory Structure | `src/auth/`, `features/payments/`, `modules/` | | Documentation | README sections, existing PRD, ROADMAP | | Pricing Tiers | Starter/Pro/Enterprise feature mapping |

**Present detected areas**:

## Detected Feature-Areas

| # | Feature-Area | Sources | Evidence |
|---|--------------|---------|----------|
| 1 | **Core** | Directory + Docs | src/users/, README "Core Features" |
| 2 | **Business** | Directory + Pricing | src/billing/, pricing.md tiers |

Reply: Y to confirm, n for monolithic, or suggest changes.

**Threshold Logic**:

• ≤3 areas: Auto-approve
• 4-6 areas: Confirm with user
• >6 areas: Suggest grouping

Phase 2: Discovery Agent (Per Feature-Area)

For each feature-area in order:

1. **Scan directory** for monetization signals, user flows, features 2. **Analyze documentation** (README, PRD, pricing) 3. **Identify pricing tier mappings** 4. **Document evidence**

**Progress report per area**:

Discovery Agent: business feature-area
├── Directory signals: 4
├── Documentation signals: 2
├── Pricing signals: 1
└── Status: ✓ Completed

Phase 3: Pattern Agent (Per Feature-Area)

For each feature-area:

1. **Categorize signals** into PDR categories (Problem, Persona, Scope, Metric, etc.) 2. **Score strategic importance** (0.0-1.0) 3. **Check for duplicates** against existing PDRs 4. **Identify cross-area candidates**

Phase 4: Synthesis Agent (Cross-Feature-Area)

**1. Cross-Area Pattern Detection**:

{
  "pattern_id": "P001",
  "pattern_name": "Admin Persona",
  "feature_area_presence": {"core": true, "business": true},
  "is_cross_area": true
}

**2. Inconsistency Detection**:

• Priority conflicts
• Duplicate problems
• Inconsistent metrics
• Generate flags (embedded in affected PDRs)

**3. PDR Generation**: High-strategic patterns (>0.7) and cross-area patterns (≥2 areas)

Phase 5: Write Individual PDR Files

For each discovered PDR:

1. **Assign ID**: PDR-{NNN} using next available number 2. **Write file**: `{REPO_ROOT}/.adlc/drafts/pdr/PDR-{NNN}.md`

**PDR file format** (individual file, YAML frontmatter — use the shared template):

Use the template at `{REPO_ROOT}/.agents/skills/product/../templates/pdr-template.md` as the canonical PDR format. The template includes YAML frontmatter (status, date, owner, category, feature-area, title) as the single source of truth for index generation, plus the standard PDR body sections.

---
status: discovered
date: YYYY-MM-DD
owner: [Inferred from codebase/authors]
category: [Problem | Persona | Scope | Metric | Prioritization | Business Model | Feature | NFR]
feature-area: [core | business | growth | ...]
title: [Decision Title]
---

# PDR-001: [Decision Title]

### Cross-Feature-Area Metadata
- **Appears in**: [business, growth]
- **Cross-area count**: 2
- **Is cross-area pattern**: ✓

### ⚠️ Inconsistency Flags
*None* (or flag details if detected)

### Context
**Problem/Opportunity:**
[Clear description]

**Market Forces:**
- [Market factor 1]
- [Customer feedback]

### Decision
**Decision Statement:**
[Clear statement]

**Rationale:**
[Why this option]

### Consequences
#### Positive
- [Benefit 1]

#### Negative
- [Trade-off 1]

#### Risks
- [Risk with mitigation]

### Success Metrics
| Metric | Target | Measurement Method |
|--------|--------|-------------------|
| [Metric] | [Target] | [Method] |

### Alternatives Considered
#### Option A: [Alternative Name]
**Description:** [Brief description]
**Trade-offs:** [Neutral comparison]

Phase 6: Regenerate PDR Index

Generate `{REPO_ROOT}/.adlc/drafts/pdr/pdr.md` from all `PDR-*.md` files:

# For each PDR-*.md file, extract ID, title, status, date
# Build index table

**Index format**:

# Product Decision Records

## PDR Index

| ID | Feature-Area | Category | Status | Date | Owner |
|----|--------------|----------|--------|------|-------|
| PDR-001 | business | Business Model | Discovered | 2026-01-20 | [Inferred] |
| PDR-002 | core | Persona | Discovered | 2026-01-20 | [Inferred] |

---

## Cross-Fea