Pm Tech Spec Review

---
name: pm-tech-spec-review
description: "Review an engineering technical spec through a PM lens — does it cover every PRD requirement, does it preserve user/UX intent, does it quietly add or drop scope, what are the product risks, what's missing for launch. Produces a priority-tagged findings list + clarifying questions for engineering. Use after eng drafts a tech spec / design doc / architecture proposal and before code lands."
---

## Codex host binding

- Treat references to Claude slash workflows as the equivalently named Codex skill.
- Before delegating to any specialist, read the `great-pm-runtime` skill and the selected packaged role file.
- Treat "invoke", "assign", "delegate", "spawn", and source Agent-tool instructions as a required Codex `spawn_agent` call with that role and a bounded assignment.
- For the spawn tool's `task_name` or `agent_name` identifier, replace canonical role-name hyphens with underscores (`query-refiner-pm` → `query_refiner_pm`). Keep canonical names unchanged in prompts, filenames, verdict logs, and user-facing output; this is an internal identifier mapping, not a role rename.
- Store every returned agent identifier. Never call a wait tool until a spawn has returned an identifier, and wait only on identifiers returned by successful spawns.
- If `spawn_agent` is unavailable or a spawn fails, report BLOCKED; do not impersonate the specialist or wait on an empty agent set.
- Resolve bundled paths from the installed GreatPM plugin root.
- Ignore Claude-only model aliases, colors, turn limits, and tool allowlists.
- Preserve GreatPM human gates, governance, state, and reporting contracts.


# PM-lens Technical Spec Review

Engineers write specs to answer "how do we build it?" A PM-lens review answers a
different question the spec rarely asks itself: **"does this build still deliver
what we promised the user, all of it, and nothing we didn't agree to?"** This sits
between PRD sign-off and implementation — the cheapest place to catch a scope
drift or a lost requirement.

This is distinct from:
- **Code review** (does the code work / is it well-built) — that's `code-reviewer`.
- **PRD clarity check** (is the PRD itself complete/testable) — that's `prd-authoring` / spec-reviewer's mechanical pass.
- This skill: **does the engineering plan honour the PRD's product intent.**

## Inputs

- The technical spec / design doc / architecture proposal / API shape.
- The original PRD or requirements it claims to implement.
- The success metrics the feature is meant to move (if defined).

## The review lenses

Run the spec against each lens. Every finding gets a **priority tag**:
`P0` (blocks build — a requirement is lost or intent is broken), `P1` (must
resolve before launch), `P2` (worth raising, not blocking).

**1. Requirements coverage matrix**
Walk every PRD requirement / acceptance criterion. For each, mark:
`covered` / `partially covered` / `missing` / `can't tell from spec`. Missing or
partial coverage of a stated requirement is a P0. Produce the matrix explicitly —
this is the heart of the review.

**2. Scope drift — additions**
Does the spec build things the PRD didn't ask for? "Scope creep" disguised as
engineering thoroughness. Each addition is at least P1 — it costs time the launch
may not have. Name it and ask whether it's in or out.

**3. Scope drift — silent reductions**
Does the spec quietly narrow a requirement? ("PRD says all banks; spec handles 3.")
The most dangerous finding because it's invisible until a user hits it. P0 if it
breaks a stated acceptance criterion.

**4. UX / product-intent preservation**
Does the technical approach degrade the experience the PRD specified? E.g. a sync
flow the PRD wanted made async without a loading state; an instant action made
multi-step; an error path that dead-ends. Map each to the affected PRD flow.

**5. Edge cases & failure modes**
Does the spec handle the failure modes the PRD's user would hit — empty states,
errors, partial data, the unhappy paths? Missing failure handling for a primary
flow is P1.

**6. Data / privacy / trust implications**
Does the spec introduce data handling, retention, or third-party calls the PRD's
privacy posture didn't account for? For a privacy-positioned product this is P0.

**7. Metric instrumentation**
Can the success metrics actually be measured given this design? If the spec
doesn't emit the events the metrics need, the feature ships blind. P1.

**8. Launch-readiness flags**
Dependencies, migrations, rollout/rollback story, review/submission timelines
(e.g. app-store review) implied by the spec that the PM needs to plan around.

## Output shape

```
SUMMARY: [one paragraph — does this spec deliver the PRD's intent? overall verdict]

COVERAGE MATRIX:
| PRD requirement | Spec coverage | Note |
|---|---|---|
| … | covered / partial / missing | … |

FINDINGS (priority-tagged):
- [P0] [lens] [finding] → [what to change / decide]
- [P1] …
- [P2] …

QUESTIONS FOR ENGINEERING:
- [the things the spec doesn't let you judge — ask, don't assume]

SCOPE LEDGER:
- Added vs PRD: [list] → [keep / cut decision needed]
- Reduced vs PRD: [list] → [accept / restore decision needed]
```

## Governance

This skill PROPOSES findings; it does not approve or block on its own authority.
The findings go to the human + engineering to resolve. Frame findings as
questions and trade-offs, not verdicts — the engineer often has context the spec
didn't capture (see `receiving-code-review` discipline: verify, don't assume the
spec is wrong).

## Relationship to other great-pm skills

- Reads the PRD produced via `prd-authoring`.
- Hands launch-readiness flags to `launch-readiness`.
- Trade-off framing borrows from `tradeoff-arbiter`.