An AI workspace for formal visual deliverables, keeping source material, drafts, review, revisions, and exported files on one traceable delivery line.
Slides · Xiaohongshu Notes · Posters
When a task moves from "make a few images" to "produce a visual deliverable I can actually use," the hard part is usually the full workflow, not one page:
- Source material, notes, screenshots, reference images, and old drafts are scattered. How do they become one coherent deliverable?
- After many generated versions, which review comments were addressed, and which version should be rerun?
- Slides, Xiaohongshu notes, and posters need different routes. Can the system choose the right creation path for the deliverable type?
- During longer generation, review, and export runs, can the user still understand what is happening?
- At handoff, can exported files, review records, and source material still match each other?
RedCube AI is built around those questions. For knowledge-heavy visual work, it keeps source organization, page generation, review, revision, progress reporting, and export evidence on the same delivery line so a draft can move toward deliverable files.
It does not reduce visual delivery to "generate one image." A usable deliverable often needs several visual directions, layout comparison, missing-material handling, review and repair, and final export checks. RedCube AI keeps those creative decisions and delivery evidence on one line so every revision can explain why it changed and where it landed.
|
Who It Serves Experts, PIs, educators, and professional teams turning structured knowledge into formal visual deliverables |
What It Organizes Source materials, review comments, reruns, progress updates, and exported files on one traceable delivery line |
How To Start Tell it what you want to make, what source material you already have, and what final file you want to deliver |
Continuous Creation Around The Deliverable
It does not stop at a single generated image. It keeps working around a concrete slide deck, note series, or poster, organizing material, generating pages, absorbing review feedback, and preparing final exports.
Source To Deliverable In One Workspace
Lecture notes, project summaries, references, screenshots, old drafts, and review comments stay on one delivery line for inspection and reuse; runtime artifacts live in the task workspace, not in the source checkout.
Traceable Review And Revision
Each review round, rerun, revision target, and export result stays connected, so operators can see why the current version changed.
Routes Match The Output Type
Slides, Xiaohongshu notes, and knowledge posters use different default routes; editable PPTX and HTML routes are explicit selectable routes.
Template Intelligence Before Rendering
When a template or reference deck matters, RedCube profiles layout zones and placeholder capacity before visual direction or native PPTX authoring consumes those constraints.
Progress Stays Visible During Long Jobs
During generation, checking, reruns, and export, RCA progress and review surfaces expose the current step, remaining issues, and the next review focus.
Room For Visual Exploration And Comparison
Formal visual delivery often needs multiple directions, repeated-failure diagnosis, variants, and export checks. RedCube AI does not lock creation into one path; candidates, review, repair, and handoff can continue together.
You can start with prompts like:
- "Turn these lecture notes and references into a polished teaching deck, keep the progress visible, and export the final PPTX/PDF. If I ask for editable slides, use the native PPTX route."
- "Use this source package to draft a Xiaohongshu note series, tell me what is still missing, and keep each review round traceable."
- "Make a poster from this project summary, track the review comments, and export the final delivery files when the content is ready."
- Turning notes, outlines, references, screenshots, and draft fragments into formal slide decks, note series, and poster-style deliverables.
- Keeping multi-round review, reruns, and export checks tied to the same workspace.
- Showing human-readable progress while longer-running jobs continue in the background.
- Delivering exported files that stay connected to their source material and review history; editable PPTX is an explicit route when requested.
- Comparing visual directions, finding repeated failure patterns, generating variants, absorbing review, and completing export checks inside the same delivery stage.
Slidesfor teaching decks, academic talks, internal briefings, and formal reports. The current default PPT route is image-first full-slide authoring; HTML and editable native PPTX are explicit selectable routes.Xiaohongshu notesfor knowledge posts, science communication, and serialized publishing. The default route is GPT-Image-2 full-page 3:4 PNG authoring throughauthor_image_pages; HTML remains an explicit maintenance route.Knowledge postersfor single-page visual delivery.- Academic paper and conference poster lanes continue to be evaluated case by case.
- Experts provide the source material, audience expectations, and final judgment.
- The AI operator handles direction exploration, generation, revision, reruns, export, and progress reporting.
- The workspace keeps sessions, review state, rerun history, artifact refs, and export outputs together for inspection.
RedCube AIis an independent visual-deliverable Foundry Agent. Its first public identity is visual delivery: source intake, staged visual authorship, review, repair, export, and file handoff.- In the OPL family, RCA is the domain agent package: RCA retains visual-deliverable authority, while OPL owns generic runtime, package carrier, generated wrapper, and hosted surfaces.
- The first public surface is the single
redcube-aiapp skill;Codex,OPL, and other general agents can reach stable capabilities through that skill. - It can be used as the Presentation Foundry inside One Person Lab, and it can also be called directly by Codex or another agent through stable capability entries.
- RedCube owns material intake, visual generation, review loops, export, and file handoff.
- Content framing, audience fit, and final acceptance stay with experts.
- External publishing and upload steps stay under human supervision.
Technical OPL / executor boundary
- OPL can host RedCube as an external domain agent, but that hosted path is an internal integration surface, not RedCube's first public identity.
- After task start, OPL/Temporal may own persistent scheduling, wakeup, retry/dead-letter handling, and resume. RCA does not embed a daemon, scheduler, or attempt loop.
Codex CLIis the current first-class executor; Hermes-Agent, Claude Code, and similar executors are explicit opt-in adapters with auditable receipts.- RedCube keeps the visual-deliverable authority: visual-domain truth, review/export gates, canonical artifacts, artifact handoff, and owner receipts.
- The full entry taxonomy, service-safe domain entry, generated-wrapper boundary, contract refs, canary evidence, and no-readiness rules are maintained in the Docs Guide, Status, Architecture, Invariants, Decisions, and Contracts Overview.
- Potential users should start here, then continue to the Docs Guide.
- Technical readers and planners should read Project, Status, Architecture, Invariants, Decisions, and Contracts Overview.
- Developers and maintainers should continue from the Docs Guide into
docs/active/,docs/references/, anddocs/policies/.
Start here if you are handing this repo to Codex or another agent
- Cloning this repo does not install the OPL Framework or hosted runtime. If you need hosted execution, prepare the current
one-person-labcheckout or release bundle first. - Read the Docs Guide first, then Contracts Overview, Project, Status, Architecture, Invariants, and Decisions.
- Treat the public package as
RedCube AI Foundry Agent: one app skill and one service-safe domain entry, with OPL-generated wrapper/projection refs and visual-domain truth kept inside RCA. - Direct RedCube use and OPL-hosted use must converge on the same RedCube-owned route, review, artifact, and export surfaces.
- Use the repo-local commands, command targets, and verification matrix maintained in the Docs Guide, contracts, and
scripts/test-registry.ts; do not reconstruct current execution truth from scattered implementation files. - Use
docs/active/for current baton records,docs/references/for current support references, anddocs/history/for absorbed milestones, proof records, tombstones, and provenance.

