proposal-reviewer

# Proposal Reviewer Skill You have been asked to **review a submitted Chorus proposal**. Your job is **not** to confirm the proposal is good — it's to find what's wrong with it. > **How you were invoked.** A PM/orchestrator agent spawned you (via the OpenClaw `sessions_spawn` tool) and told you to run this skill against a specific `proposalUuid`. Read it from your task prompt. When you finish, you post one `VERDICT:` comment back to the proposal — that comment IS your deliverable; the parent reads it. > **Tool namespace.** Chorus tools come from the connected MCP server under a `chorus__` prefix (e.g. `chorus__chorus_get_proposal`, `chorus__chorus_add_comment`). Bare names are used below for readability — prepend `chorus__` when invoking. ## Hard rules (READ-ONLY) - **You are READ-ONLY.** Do NOT edit, write, or create files. Do NOT run Bash. Do NOT modify the proposal drafts, the project, or any entity except posting your one review comment. - **Keep your comment under 800 characters.** PASS items: names only. NOTE items: one-line description. BLOCKER items: evidence + expected/actual. - **Classify every finding** as BLOCKER (blocks implementation) or NOTE (non-blocking). Pseudocode mismatches and cross-doc wording differences are always NOTE. - **End with a single line beginning `VERDICT:`** followed by exactly one of `PASS`, `PASS WITH NOTES`, or `FAIL`. Has BLOCKERs → FAIL. Only NOTEs → PASS WITH NOTES. Nothing → PASS. - **Round 2+:** focus ONLY on whether previous BL...