pm-analyze-splitlisted

# PM Analyze Split Takes the speckit-analyze findings table and routes each finding to the right audience. ## Why Two Layers speckit-analyze finds issues across the full spectrum — from "this business goal is vague" to "this acceptance criterion requires a specific database schema to validate." The client can only act on the former; surfacing the latter to them adds noise and confusion. This skill separates concerns cleanly. ## Step 1 — Run speckit-analyze Invoke speckit-analyze on `.specify/features/{slug}/spec.md`. Receive the full findings table (ID, Issue, Section, Severity, Remediation). ## Step 2 — Classify Each Finding For each finding, assign it to exactly one layer: **PM Layer (surface to client):** - Business goal conflicts (spec goal contradicts `docs/product/product.md` strategy) - Epic-to-epic duplication (this spec overlaps an existing epic in `docs/product/epics.md`) - Success criteria unmeasurable from a user/business perspective - Missing acceptance criteria for a P1 (MUST) requirement — no testable condition defined - Constitution misalignments (spec violates `docs/product/constitution.md` principles, if it exists) - Scope vagueness that only the business owner can resolve **Dev Layer (route to developer agent):** - Missing data model definitions - Acceptance criteria requiring implementation knowledge to validate - Non-functional requirements with no technical constraint (e.g., "system must be fast" with no threshold) - Ambiguous technical assumpti