Review Proposal Auto

Read a proposal artifact READ-ONLY and emit a findings-first review report to the active thread's inbox/open/ folder. This skill reads the proposal, drafts the report end-to-end, and writes one record per review run. It does not ask clarifying questions, it does not walk findings with the user one-at-a-time, and it does not commit.

The LIGHTWEIGHT framing matters: a proposal is an early sketch, not a downstream handoff document. The review checks for the three things a proposal can plausibly miss at its stage — gaps, risks, ambiguities — and stops there. Do NOT treat a proposal review like a spec review; missing semantic-contract elements (intended outcome, scope/non-scope, acceptance guidance) are not findings against a proposal because a proposal does not promise to carry them. Those are findings a downstream spec review surfaces against the spec that comes after the proposal.

Inputs

This skill accepts ONE input: a proposal artifact path under docs/threads/<thread>/proposals/<UTC>-<kebab-desc>-proposal.md.

If the path is not supplied, ASK the user which proposal to review — do not pick by recency. If multiple plausible proposal artifacts exist in docs/threads/<thread>/proposals/ and the user's reference is vague ("the proposal", "the latest proposal", "the auth one"), ASK the user which artifact is intended. There is NO global "latest proposal" algorithm. Silently picking the most recent file would hide a real decision — which proposal won, which variant survived discussion — behind a sort order.

The literal folder docs/threads/<thread>/proposals/ is the only location proposal artifacts land in. If the path passed is not under that folder, refuse and ASK the user to confirm — a proposal not in proposals/ is either a misplaced draft (still in .wip/, not yet emitted) or not actually a proposal artifact.

What This Skill Reviews

A proposal-review pass surfaces three categories of finding: