Menu
Optional product go/no-go on a framed spec. Use when product direction needs review before planning.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Optional engineering go/no-go on a plan. Use when execution safety needs review before implementation.
Implement approved plan slices. Use as the execute-stage entry point.
Bound and de-risk a request into SPEC.md. Use when the objective is clear but scope needs constraining.
Sharpen a vague idea into a bounded objective. Use before framing when scope is undefined.
Build project truth from repo evidence. Use when steering is missing or stale.
Turn an approved spec into ordered slices. Use when framing is accepted and planning begins.
| name | auto-ceo-review |
| description | Optional product go/no-go on a framed spec. Use when product direction needs review before planning. |
| metadata | {"stage":"frame"} |
Optional product-direction review. Decides whether a spec is worth building before planning begins.
First action: run node .agent/.automaton/scripts/get-context.mjs from the project root.
Product bet review. Restates the objective as one crisp bet, identifies differentiation, calls out generic or mis-scoped direction. Does not design implementation or write code.
A good review names the bet in one sentence, identifies the weakest assumption, and renders a verdict in under 150 words. A bad review restates the spec.
Loading discipline: one SPEC.md read, one review paragraph, one verdict. Read project files when understanding the codebase helps ground the review. Verify that spec claims reflect what actually exists before approving or rejecting.
Before appending the product review:
references/quality.md when the review sounds like polite validation.Do NOT proceed unless:
canonical_spec is set and SPEC.md is readable.If the spec is missing or unreadable, set verdict to needs_clarification and stop.
Read the canonical SPEC.md.
In one sentence: "We are betting that [specific user] will [specific action] because [specific reason], and the risk is [specific risk]." Read references/bet-framing.md for crisp-vs-vague bet examples.
Choose a review posture per references/review-modes.md. Assess differentiation, user value, generic or mis-scoped elements, and shippability. Ground each in evidence from the spec. Read references/product-checklist.md for structured checks and references/cognitive-patterns.md for thinking patterns that surface blind spots.
Use exactly one of the four approved values.
Use strict vocabulary. No synonyms.
| Verdict | Meaning | Next Action |
|---|---|---|
approved | Direction is sound. Proceed to planning. | auto-plan |
approved_with_risks | Direction is sound but carries known risks. Document them in the review. | auto-plan |
needs_clarification | Direction cannot be evaluated. Return to framing. | auto-frame or auto-office-hours |
descoped | Direction is out of scope or low-leverage. Do not pursue. | auto-office-hours or stop |
Add a ## Review: Product section to SPEC.md using the exact template in references/review-template.md.
Run node .agent/.automaton/scripts/sync-status.mjs --product-review "<verdict>" from the project root.
Continue inline on a non-blocking verdict; stop and hand off on a blocking one. The verdict→skill map is in Output.
SPEC.md with appended ## Review: Product section.agent/.automaton/state/current.json updated through sync-status.mjs with product_review; stage is unchanged by this skillapproved/approved_with_risks → continue inline into auto-plan; needs_clarification → Next: auto-frame (or auto-office-hours); descoped → Next: auto-office-hours, or halt.