Why I built it
A meeting ends with a transcript, research, and decisions. Then someone rebuilds the same thinking as a deck, a graphic, an audio briefing, and sometimes a video. Context gets lost at each handoff. The style drifts. A few revisions later, nobody can tell which sentence came from which source.
I built WorkshopLM so one conversation could become finished work while the source trail stayed intact.
What it does
WorkshopLM is a local-first workspace with four steps: Capture, Map, Brief, and Create.
Start by talking, pasting notes, adding a website, or importing a document. GPT-5.6 turns that material into a visual Map that separates evidence, synthesis, and direction. Every grounded idea links back to the exact source excerpt.
After you approve the Brief and choose a Style, WorkshopLM can create a presentation, infographic, image set, Audio Overview, Storyboard, and narrated Video from the same knowledge base. Presentations export as editable PowerPoint files. Storyboards stay editable panel by panel. Video renders locally with HyperFrames.
Two sign-offs keep a person in control. The Brief must be approved before downstream work is created, and the Storyboard must be approved before Video renders. If a source or decision changes, affected work moves to Needs update instead of passing stale material forward.
Open a source link beside a claim, graphic, or Storyboard panel to see the supporting excerpt. Add another meeting later and the Map can grow without erasing the earlier version.
The hard part
Generating files was straightforward. Keeping every output tied to the same decisions, Style, and evidence was harder.
WorkshopLM uses one semantic graph for the Map and every downstream artifact. Versioned approvals and provenance checks sit at the two points where a person needs to stay in control. State is stored locally in SQLite. Normalized source chunks are retrieved with FTS5/BM25. Each rendered Video gets a provenance sidecar.
The judge fixture runs the same path with sanitized data. It needs no account, connector, API key, or paid request.
How I used Codex
I used Codex to build, test, and review WorkshopLM. GOAL.md held the product decisions and completion gates. AGENTS.md required evidence before work could be marked done. log.md became the append-only build record.
Codex implemented the domain contracts, local persistence, graph engine, visual Map, Style system, renderers, job queue, and HyperFrames worker. It also tested approval bypass, stale rendering, broken citations, and interrupted jobs.
During the UI rebuild, one Codex task reported the work complete. Another inspected the rendered styles, disproved that claim, and reopened the work. I kept that correction in the log because it shows the build and review loop I actually used.
How I used GPT-5.6
I used GPT-5.6 Sol at medium and high reasoning for orchestration and review in Codex. Inside WorkshopLM, gpt-5.6-terra turns grounded source material into the semantic Map shown in the demo.
I benchmarked Sol, Terra, and Luna on the real graph, brief, and triage operations. All three passed the deterministic quality bar. Terra became the Map default after producing a valid structure in 2.8 seconds, compared with Sol's 6.8 seconds in the final comparable run.
The repository preserves the live Map request ID, response hash, and model route. The recorded judge fixture replays sanitized outputs, so judges can inspect the full experience without credentials or spend.
Try it
pnpm install --frozen-lockfile
pnpm judge:start
This rebuilds the sanitized Workshop and serves the Capture, Map, Brief, and Create flow at the printed local URL. The verified platform is macOS. The README includes the optional live-provider path.
Built With
- codex
- excalidraw
- gpt-5.6
- gpt-image-2
- gpt-realtime-2.1
- hyperframes
- mcp
- next.js
- node.js
- openai-responses-api
- openai-tts
- playwright
- pnpm
- react
- sqlite
- turborepo
- typescript


Log in or sign up for Devpost to join the conversation.