Review a spec for implementation risk before it enters the build queue

Most rework isn't from bad code — it's from a spec that was technically naive. The outcome was clear, the evidence was solid, but nobody flagged the race condition, the missing migration, or the third-party rate limit until the work was half-built. Engineering review is where that gets caught. Pathmode gives you the spec in a form you can actually review: evidence, outcomes, and verification criteria, not a wall of prose.

The input

A draft IntentSpec the product side has authored — objective, outcomes anchored to evidence, and a first pass at edge cases. It's ready for a second set of eyes, specifically yours.

The flow

1. Read the outcomes against the system you'll build in. Each outcome carries its verification criteria. Ask: can this actually be verified the way it's written? If "the list loads instantly" really means "p95 under 200ms with 10k rows," say so — and add it as the criterion.

2. Add the edge cases only engineering can see. Concurrent edits, empty states, the migration that has to run first, the API that paginates at 100. These become explicit "must handle" requirements the agent can't skip.

3. Name the constraints and the out-of-scope lines. The implicit "we don't support multi-tenant yet" assumptions are invisible to an agent. Write them into the spec so they survive the handoff. Out-of-scope is as load-bearing as in-scope.

4. Check the readiness signals, then send it on. Pathmode surfaces what's still soft — an outcome with no verification, an edge case with no evidence. Clear those, and the spec is ready for the build queue.

The output

A spec that's been pressure-tested from the build side before any agent touches it:

• Verification criteria that are actually checkable — not "works well" but a condition that passes or fails
• Edge cases enumerated, so the agent handles them instead of inventing behavior
• Constraints made explicit, so scope doesn't quietly expand mid-build
• Risk surfaced early, when it costs a comment instead of a sprint

Why this beats reviewing a PR cold

Reviewing the spec is reviewing intent; reviewing the PR is reviewing a guess at intent that's already been coded. The first costs six minutes. The second costs a rewrite. Spec review moves the cheapest correction point — the comment thread — to before the work exists, where it belongs.

Try it yourself

1. Open a draft spec the product side handed you
2. Add two edge cases and one constraint only you would know
3. Tighten one vague verification criterion into a pass/fail condition
4. Clear the readiness signals and move it to the build queue

Related

• Use case: Audit a draft spec for missing edge cases
• Use case: Sequence the build queue so agents work in the right order
• Playbook: The Anatomy of an Agent-Ready Spec