auto-eng-review

name	auto-eng-review
description	Optional engineering go/no-go on a plan. Use when execution safety needs review before implementation.
metadata	{"stage":"plan"}

auto-eng-review

Optional engineering-safety review. Validates that a plan is safe to execute before implementation begins.

First action: run node .agent/.automaton/scripts/get-context.mjs from the project root.

Preamble

Execution safety review. Architecture, data flow, edge cases, test strategy, not product vision. It does not modify the plan or reopen product scope. Identifies risks that could cause failure, stalling, or rework.

A good review names the riskiest slice, the most likely failure mode, and whether the test strategy catches it. A bad review lists generic concerns.

Loading discipline: one PLAN.md read, optional DESIGN.md when canonical_design exists, one risk matrix, one verdict. Read source files when assessing technical risk: slice boundaries, dependency assumptions, and blast radius claims are only verifiable against the actual code.

Quality Gate

Before appending the engineering review:

• Ground concerns in slices, file areas, commands, or missing artifacts.
• Separate blockers from follow-up cleanup.
• Avoid reopening product scope unless the plan is unbuildable.
• Read references/quality.md when findings are generic or unactionable.

Do

Do NOT proceed unless:

• canonical_plan is set and PLAN.md is readable.

If the plan is missing or unreadable, set verdict to needs_correction and stop.

Load State

Read the canonical PLAN.md. Read DESIGN.md only when canonical_design is set and resolves to a file; otherwise continue without it and note that the plan intentionally has no design artifact.

Restate the Plan

In engineering terms: what is being built, what systems does it touch, and what is the critical path?

Evaluate Risks

Use this matrix as an internal checklist. In chat, summarize only the verdict-driving dimensions unless the user asks for the full matrix. Apply standards from references/prime-directives.md while evaluating.

Risk Matrix

Read references/risk-examples.md for sample matrix scoring.

Dimension	Rating (0–10)	What a 10 looks like
Architecture fit		Clean integration, no hacks, follows existing patterns
Data flow clarity		Every input, transform, and output is traceable
Edge case coverage		Failure modes are enumerated and handled
Test strategy		Tests are specified before code, not after
Rollback safety		Can revert without data loss or downtime
Dependency risk		No new critical dependencies; existing ones are stable

A score ≤ 3 in any dimension is a blocking concern. Surface it explicitly. Read references/engineering-sections.md only when the plan carries non-trivial engineering risk.

Render Verdict

Use exactly one of the three approved values. Read references/implementation-alternatives.md only when PLAN.md lacks an approach rationale, the user asks for alternatives, or the verdict depends on comparing safer execution paths.

Verdict Values

Use strict vocabulary. No synonyms.

Verdict	Meaning	Next Action
approved	Implementation is safe to proceed.	auto-execute
approved_with_risks	Implementation is safe but carries known risks. Document them.	auto-execute
needs_correction	Plan is flawed or unsafe. Return to planning.	auto-plan

Append Review

Add a ## Review: Engineering section to PLAN.md using the exact template in references/review-template.md.

Update State

Run node .agent/.automaton/scripts/sync-status.mjs --engineering-review "<verdict>" from the project root.

Recommend

State the next skill based on the verdict.

Output

• PLAN.md with appended ## Review: Engineering section
• .agent/.automaton/state/current.json updated through sync-status.mjs with engineering_review; stage is unchanged by this skill
• Handoff (verdict-mapped, always stops): approved/approved_with_risks → Next: auto-execute; needs_correction → Next: auto-plan.

Rules

• Focus on execution safety, not product vision.
• Prefer specific engineering objections over generic caution.
• Do not broaden scope just to feel thorough.
• Do not emit the full risk matrix when all dimensions are acceptable; keep the durable review to the 5-field template.
• Verdict vocabulary is strict. Use only the three approved values.
• Missing DESIGN.md is not a blocker when canonical_design is null, absent, or intentionally skipped by the plan.