/product-analyze

name: product-analyze
description: Use when checking PDR↔PRD consistency after /product-implement or periodically to detect drift, PDR quality issues, cross-PDR conflicts, and staleness.
disable-model-invocation: true

product-analyze

What this skill does

Performs **read-only** product consistency analysis:

1. **PDR Quality** — completeness, clarity, standards compliance 2. **PDR→PRD Drift** — decisions not reflected in PRD 3. **PRD→PDR Drift** — PRD elements without supporting PDRs 4. **Cross-PDR Consistency** — conflicts between PDRs 5. **Staleness** — outdated references, placeholders, deprecated PDRs still referenced 6. **Mermaid Syntax** — invalid diagram blocks flagged with location + suggested patch (the mermaid detection pass)

**Output**: Structured markdown analysis report (no files modified)

When to use

• After `/product-implement` to validate generated PRD
• After `/product-clarify` to verify refinements
• Before feature development to ensure product is solid
• Periodically to detect drift as product evolves

When NOT to use

• No product artifacts exist (use `/product-init` or `/product-specify` first)
• You want to modify files (this is analysis-only)

Execution Steps

Phase 1: Load Artifacts

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

**Read**:

• `docs/adlc/product/PRD.md` (legacy repo-root `PRD.md` fallback — dual-read)
• `{REPO_ROOT}/.adlc/drafts/pdr/PDR-*.md` (individual PDR files)
• `{REPO_ROOT}/docs/adlc/memory/constitution.md`, falling back to legacy `{REPO_ROOT}/.adlc/memory/constitution.md` (dual-read; if either exists)

**Build inventory**:

| Artifact | Path | Status |
|----------|------|--------|
| Product PRD | docs/adlc/product/PRD.md (legacy PRD.md fallback) | Found/Missing |
| Product PDRs | .adlc/drafts/pdr/ | [N] files |
| Constitution | docs/adlc/memory/constitution.md (legacy .adlc/memory fallback) | Found/Missing |

Phase 2: PDR Quality Analysis

For each PDR file, check:

| Dimension | Check | Severity | |-----------|-------|----------| | Context | Problem clearly stated | MEDIUM | | Decision | Actionable, testable | HIGH | | Consequences | Positive AND negative | HIGH | | Success Metrics | Defined with targets | HIGH | | Alternatives | At least 2 with neutral trade-offs | HIGH | | Constitution | Aligns with vision | CRITICAL |

Phase 3: Inter-PDR Consistency

1. **Conflicting Decisions**: PDRs that contradict (e.g., B2B vs B2C) 2. **Missing Dependencies**: PDRs that should reference each other 3. **Terminology Drift**: Same concept named differently 4. **Strategy Coherence**: Problem/persona/metric alignment

Phase 4: PDR→PRD Drift (Forward Sync)

For each PDR, check if decision appears in PRD:

| PDR Element | Expected in PRD | Section | |-------------|-----------------|---------| | Problem decision | Problem statement | 3 | | Persona decision | Personas | 6 | | Scope decision | Requirements / Out of Scope | 7 / 9 | | Metric decision | Success Metrics | 5 | | Business Model | Overview | 2 | | NFR decision | Non-Functional Requirements | 8 |

Phase 5: PRD→PDR Drift (Backward Sync)

1. **Requirements Without PDRs**: User stories without scope justification 2. **Personas Without PDRs**: Personas with no persona PDR 3. **Metrics Without PDRs**: Success metrics with no metric PDR 4. **Risks Without PDRs**: Risks without consequence documentation

Phase 6: Staleness Detection

1. **Deprecated PDRs Still Referenced**: PRD references status "Deprecated" 2. **Placeholders**: `[TODO]`, `[TBD]`, `[PRODUCT_NAME]`, `[DATE]` 3. **Date Inconsistencies**: PDR dates older than PRD last-updated 4. **Orphaned References**: PDR IDs mentioned but file doesn't exist

Phase 7: Mermaid Syntax Validation (the mermaid detection pass)

**Objective**: flag invalid Mermaid blocks in the PRD with a location and a suggested patch, so a broken diagram never ships unremarked.

**Run the shared validator** — it owns the rule set (canonical in `architect-clarify`; the rules are documented once, in the validator itself). Do not re-derive or restate the thresholds here:

sh: {REPO_ROOT}/.agents/skills/architect-clarify/scripts/bash/mermaid-lint.sh --tsv <artifact>

Requires the `architect-clarify` skill (`adlc-cli skills add tikalk/adlc-team-skills --skill architect-clarify`). Exit code: `0` clean, `1` a HIGH (syntax-break) is present, `2` only MEDIUM (style) findings.

**Rule vocabulary** — the validator's own ids; severity travels with each finding, never inferred here:

| Rule | Meaning | |------|---------| | `M001-fence-not-closed` | the ` ```mermaid ` block is never closed | | `M002-unknown-diagram-type` | the type keyword is outside the known set — review it, never a false HIGH | | `M003-missing-diagram-type` | the block declares no diagram type at all | | `M004-empty-block` | the block carries no diagram content — comments and directives do not count | | `M005-empty-body` | a type is declared but no statement follows — mermaid renders it (an empty chart), so it is a MEDIUM style finding, never a syntax break; the finding sits on the type declaration | | `M006-malformed-gantt-header` | the gantt block's first statement (comments and directives skipped) is neither a gantt key nor a task line — a malformed first statement is a syntax break (HIGH); a task-line-shaped statement is at most MEDIUM, never a false HIGH | | `M007-malformed-sequence-diagram` | the sequenceDiagram's first statement (comments and directives skipped) is neither a participant nor a message — a malformed first statement is a syntax break (HIGH) | | `M008-malformed-entity-diagram` | the erDiagram's first statement (comments and directives skipped) is neither an entity nor a relation — a malformed first statement is a syntax break (HIGH) | | `M009-non-mandated-keyword` | `graph` used where the product mandate requires `flowchart` |

**Rules**:

• Run it over the PR