I’m Matheus, the maker of Mosaic.
While building products with agents, I wanted the planning work to leave behind more than a useful chat transcript. Product decisions should remain inspectable, revisable, and explicit before implementation begins.
Mosaic is my attempt at that workflow. Its current Plan Studio alpha runs locally on Apple Silicon Macs and works with a compatible Codex installation.
A Plan can contain:
- durable Brief, Requirements, Architecture, UX, Test Scenario, and Delivery Plan documents
- self-contained interactive HTML prototypes
- comments anchored to documents or individual prototype elements
- candidate diffs and validation results
- immutable revisions after explicit approval
The core loop is: ask Codex to revise a Plan, inspect the candidate changes, comment or discard them, and approve only the version worth preserving.
Plan-scoped Codex chat, product documents, and a working HTML design in one workspace.
This is a deliberately limited alpha. It is free to evaluate, unsigned and not notarized, has no cloud sync, and does not yet implement code or handle deployment. Generated artifacts still require human review.
https://mosaic-site-wine.vercel.app/
If you tried this on a real feature, which review checkpoint would matter most before implementation: document diffs, prototype comments, validation results, or approval history?
Top comments (2)
Anchoring comments to individual prototype elements, then preserving immutable revisions only after explicit approval, gives the planning phase a much stronger audit trail than a chat transcript can. The combination of candidate document diffs and validation results is especially useful, but the real product challenge will be keeping the Brief, Requirements, Architecture, and HTML prototype semantically aligned as each changes. Without that linkage, reviewers may approve locally sensible edits that quietly contradict another artifact; with it, Mosaic becomes a genuine decision system rather than a polished collection of files.
@marcusykim I appreciate your thoughts! This is something I’ve considered carefully and am working to address in future releases. I envision a way to define design languages, themes, and layout and bind them to specific project directories (feature TBD).