spec-intake-review
Agent: VP Engineering
L1 engineering leader (1x) responsible for spec intake review, team allocation, architecture oversight, velocity monitoring, and go-live approvals. Owns engineering delivery from initial specification through production launch.
Department ethos: ideal-engineering.md
Skill Description
Reviews incoming feature specifications to assess completeness, technical feasibility, and readiness for engineering execution.
When to Use
- When a product specification or PRD is submitted to engineering for implementation.
- When a previously rejected spec has been revised and resubmitted.
- When an urgent request bypasses normal intake and needs rapid feasibility and completeness review.
Workflow
- Completeness check: Verify the spec contains user stories or jobs-to-be-done, acceptance criteria, success metrics, edge cases, and non-functional requirements (performance, security, accessibility). Deliverable: completeness scorecard.
- Feasibility triage: Assess whether the spec is technically feasible within stated constraints. Flag items requiring spikes, architecture changes, or third-party dependencies. Deliverable: feasibility notes with blocker flags.
- Ambiguity identification: Highlight vague requirements, contradictory statements, or missing decisions that would force engineers to guess. Deliverable: list of open questions for product.
- Scope assessment: Confirm the spec defines clear boundaries -- what is included and excluded. Deliverable: scope clarity rating.
- Verdict: Accept the spec for engineering planning, return it for revision with specific feedback, or escalate if it requires cross-functional alignment. Deliverable: intake decision with action items.
Anti-Patterns
- Accepting incomplete specs: Letting vague specs through to avoid confrontation with product. Why: ambiguous specs cause rework, scope disputes, and engineering frustration that costs more than the review delay.
- Gold-plating the review: Demanding perfection in the spec beyond what engineering needs to start planning. Why: over-scrutiny creates bottlenecks and signals that engineering is a blocker rather than a partner.
- Skipping non-functional requirements: Reviewing only feature behavior without checking performance, security, and observability requirements. Why: missing NFRs surface late as production issues that are expensive to retrofit.
Output
On success: Produces an intake review document containing the completeness scorecard, feasibility notes, open questions, scope assessment, and a verdict (accepted / returned for revision / escalated). Delivered to product and engineering planning teams.
On failure: Report which review criteria could not be assessed (e.g., missing design mockups, undefined integration points), what is needed to complete the review, and a recommended timeline.
Related Skills
1---2name: spec-intake-review3description: This skill reviews incoming feature specifications to assess completeness and readiness before engineering work begins. Use when asked to review a PRD, evaluate a spec for engineering handoff, or check if a feature request is ready for development. Also consider when product submits a new spec to the engineering intake queue. Suggest when engineering is about to start work on an unreviewed specification.4---56# spec-intake-review78## Agent: VP Engineering910L1 engineering leader (1x) responsible for spec intake review, team allocation, architecture oversight, velocity monitoring, and go-live approvals. Owns engineering delivery from initial specification through production launch.1112Department ethos: [ideal-engineering.md](../../../../departments/engineering/ideal-engineering.md)1314## Skill Description1516Reviews incoming feature specifications to assess completeness, technical feasibility, and readiness for engineering execution.1718## When to Use1920- When a product specification or PRD is submitted to engineering for implementation.21- When a previously rejected spec has been revised and resubmitted.22- When an urgent request bypasses normal intake and needs rapid feasibility and completeness review.2324## Workflow25261. **Completeness check**: Verify the spec contains user stories or jobs-to-be-done, acceptance criteria, success metrics, edge cases, and non-functional requirements (performance, security, accessibility). Deliverable: completeness scorecard.272. **Feasibility triage**: Assess whether the spec is technically feasible within stated constraints. Flag items requiring spikes, architecture changes, or third-party dependencies. Deliverable: feasibility notes with blocker flags.283. **Ambiguity identification**: Highlight vague requirements, contradictory statements, or missing decisions that would force engineers to guess. Deliverable: list of open questions for product.294. **Scope assessment**: Confirm the spec defines clear boundaries -- what is included and excluded. Deliverable: scope clarity rating.305. **Verdict**: Accept the spec for engineering planning, return it for revision with specific feedback, or escalate if it requires cross-functional alignment. Deliverable: intake decision with action items.3132## Anti-Patterns3334- **Accepting incomplete specs**: Letting vague specs through to avoid confrontation with product. *Why*: ambiguous specs cause rework, scope disputes, and engineering frustration that costs more than the review delay.35- **Gold-plating the review**: Demanding perfection in the spec beyond what engineering needs to start planning. *Why*: over-scrutiny creates bottlenecks and signals that engineering is a blocker rather than a partner.36- **Skipping non-functional requirements**: Reviewing only feature behavior without checking performance, security, and observability requirements. *Why*: missing NFRs surface late as production issues that are expensive to retrofit.3738## Output3940**On success**: Produces an intake review document containing the completeness scorecard, feasibility notes, open questions, scope assessment, and a verdict (accepted / returned for revision / escalated). Delivered to product and engineering planning teams.4142**On failure**: Report which review criteria could not be assessed (e.g., missing design mockups, undefined integration points), what is needed to complete the review, and a recommended timeline.4344## Related Skills4546- [`scope-boundary-setter-eng`](../../../engineering/vp-engineering/scope-boundary-setter-eng/SKILL.md) -- scope boundaries are informed by the intake review findings.47- [`backlog-populator-eng`](../../../engineering/vp-engineering/backlog-populator-eng/SKILL.md) -- accepted specs flow into backlog population.
mittuled