Mechanism
One answer becomes a small review room before it becomes a decision.
Round Table Workspace is built for the moment when an AI coding agent sounds confident, but you still need product, engineering, risk, and user-facing review before you trust the output.
- Create reviewer candidates. The workflow starts from the question or generated change and prepares reviewer angles that could catch different failure modes.
- Keep the useful reviewers. The review panel should include roles with signal for this decision, such as product, engineering, risk, or user advocate.
- Bring them into the round table. The selected reviewers debate the decision instead of letting one confident answer stand alone.
- Return a decision gate. The result is a practical `ship`, `revise`, or `reject` decision with missing evidence and next steps.
Why create reviewers?
Different roles catch different blind spots. A product reviewer may question the user value; a risk reviewer may question public claims.
Why select them?
The point is not to add noise. The point is to keep reviewers that add useful pressure to the specific decision in front of you.
Why decide at the end?
The useful output is not a long debate transcript. It is a decision you can act on before merging, launching, or trusting generated work.
$ ./rtw ship-check "Should we merge this AI-generated feature?"
Decision: revise
Panel: product, engineering, risk, user-advocate
Why: useful direction, but public claims and evidence need tightening
Next: run tests, add a visible demo, keep claims local-first unless validated
Use It When
- an AI-generated change sounds ready but has not been reviewed from multiple angles
- a launch claim needs current evidence before it goes public
- you want a repeatable pause between agent output and human trust
Do Not Treat It As
- a replacement for tests, security review, or human ownership
- a claim of universal host-live support
- a claim of provider-live support without fresh validation evidence