Architecture decisions
Weigh two designs, draw the module boundaries, and settle the rollback plan before you commit to one of them.
Use cases
Most prompts don't need a council. This is for the ones where a confident, wrong answer costs you a rollback, a migration, or a bug your users hit first.
Weigh two designs, draw the module boundaries, and settle the rollback plan before you commit to one of them.
Hand it a patch and ask what breaks: regressions, missing tests, the edge case that pages you at 3am.
Let Leonardo tear into the UX, then have Bob drive the browser before anyone says "it works".
Seymour goes after latency, memory, and database load — and the question everyone skips: how will you measure it?
Skill-review mode checks whether people will find your tool, use it, and not trip over rules you already wrote.
Trade "I think it's fine" for a list: blockers, open disagreements, what's tested, what's still unknown.
Frontend review
UI bugs hide in behavior, not screenshots — the focus trap that won't release, the background that stays clickable, the modal that falls apart on a phone. So frontend runs get a stricter path.
Mode selection
| Situation | Mode | Why |
|---|---|---|
| Small, reversible decision | fast |
A quick Chairman pass, none of the full-council cost. |
| Implementation or architecture choice | standard |
Six reviewers and a scoring pass. Enough for most calls. |
| Security, migration, data loss, a close tie | deep |
When the downside is real, the extra scrutiny pays for itself. |
| Frontend, UX, modals, forms, navigation | standard --frontend-review |
Leonardo on the experience, Bob on the browser when there's something to click. |
| Skill or plugin usability | --type skill --skill-review |
Compact lenses for how the tool is built and whether anyone can use it. |
Don't overuse it