RedCube AI

English | 中文

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

Core Highlights

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.

One-Sentence Quick Start

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."

What It Helps With

• 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.

Current Delivery Focus

• Slides for 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 notes for knowledge posts, science communication, and serialized publishing. The default route is GPT-Image-2 full-page 3:4 PNG authoring through author_image_pages; HTML remains an explicit maintenance route.
• Knowledge posters for single-page visual delivery.
• Academic paper and conference poster lanes continue to be evaluated case by case.

How It Works

• 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.

Current Boundary

• RedCube AI is 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 OPL Package(kind=agent): RCA owns its executor-neutral identity, capabilities, work-item and typed-view semantics, and all visual-deliverable authority.
• The first public surface is the single redcube-ai app skill. It is the current Codex carrier projection, not the Package identity or the complete installed truth; Codex, OPL, and other general agents can reach the same stable RCA capabilities through supported routes.
• 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.
• Package, carrier, and executor are separate. The RCA publication model puts complete first-party Package bytes in its owner channel and advances only its own latest-stable; a shared Release Set is only an offline/QA snapshot.
• Required and optional Package dependencies use identity presence and entrypoint callability, not version/ABI ranges, locks, payloads, digests, or atomic release cohorts.
• Codex CLI is the current preferred and only productized executor route. Codex Plugin is the current carrier projection. Future executor routes must not require reinstalling RCA or losing preferences, work items, Temporal references, or typed views.
• RedCube keeps the visual-deliverable authority: visual-domain truth, review/export gates, canonical artifacts, artifact handoff, and owner receipts.
• Exact refs and digests remain required for one publication's byte integrity and for artifact/evidence lineage; they are not ordinary composition locks.
• The current Package manifest still contains legacy lifecycle fields for migration compatibility. This documentation does not claim that the carrier migration or public latest-stable proof is complete.
• 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.

How To Read This Repository

1. Potential users should start here, then continue to the Docs Guide.
2. Technical readers and planners should read Project, Status, Architecture, Invariants, Decisions, and Contracts Overview.
3. Developers and maintainers should continue from the Docs Guide into docs/active/, docs/references/, and docs/policies/.

For Codex / Agents

Install the Codex plugin carrier or hand this repo to another agent

• The repo marketplace exposes the existing redcube-ai plugin carrier to Codex. In the Codex desktop app, open this repository, restart the app after the first checkout or marketplace change, open Plugins, select RedCube AI, and install RedCube AI. Start a new task before invoking @RedCube AI or $redcube-ai so the installed skill is loaded.

• Codex CLI can configure, install, inspect, and remove the same carrier from the repository root:

  codex plugin marketplace add .
  codex plugin marketplace list --json
  codex plugin add redcube-ai@redcube-ai --json
  codex plugin list --marketplace redcube-ai --available --json
  codex plugin remove redcube-ai@redcube-ai --json
  codex plugin marketplace remove redcube-ai --json

• codex plugin list --marketplace redcube-ai --available --json is the carrier readback. An installed and enabled redcube-ai entry, together with the bundled redcube-ai skill, proves carrier installation and availability; it does not prove OPL Base installation, canonical Package rca currentness, hosted runtime or StageRun availability, artifact readiness, review/export acceptance, or an RCA owner receipt.

• For the complete OPL boundary and current readiness, continue to Status, Contracts Overview, and opl packages status --package-id rca --json in an environment where OPL Base is installed. Cloning this repo or installing the plugin does not install OPL Base or grant the carrier Package/runtime/domain authority.

• 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, and docs/history/ for absorbed milestones, proof records, tombstones, and provenance.

Further Reading

• Docs Guide
• Project
• Status
• Architecture
• Invariants
• Decisions
• Contracts Overview