# The Six-AI Collaborative Feature Remake **Status:** standing tool, feature-agnostic, reusable. Never "used up" — re-aim it at a new feature whenever the owner wants one. This is a prompt-generation template, not a one-time report. **Owner's job: copy, paste, paste back. Nothing else.** Dispatch prepares both briefs, the owner pastes Block 1 into Gemini and Block 2 into ChatGPT, then pastes each reply straight back to Dispatch unedited. Dispatch runs the Claude models and does the synthesis. --- ## Purpose Take ONE existing feature of RobCo U.O.S. and remake it from the ground up, using all six available models together — **not** six models each throwing out four ideas. Six models × four ideas = twenty-four mediocre answers. This template instead gives **six models, one feature, six different roles**, so each model's actual strength is pointed at the part of the problem it's best at. Every idea produced under this template must be a ground-up **remake of a feature that already exists** in RobCo U.O.S. — never a net-new invention pitched as a remake. (A prior run got this wrong and had to be redone. Restate this constraint explicitly in both briefs every time.) --- ## The roles | Model | Role | Why this model does this job | | --- | --- | --- | | **Gemini** (Pro, extended thinking, huge context) | **Go wide.** The most ambitious possible reimagining of the feature. | Reach is its strength — give it the full brief and the full budget to explore. | | **ChatGPT** (free tier) | **The adversary.** Attack the current version first, then attack every other model's proposal. | Its proven edge is finding what's wrong, not producing volume — a short, sharp critique ask fits its free-tier limits. | | **Fable** | **The design answer.** The most beautiful, most diegetically RobCo-native version. | Design/creative model — house voice, ceremony, materiality. | | **Opus** | **The architect.** What is actually buildable, what it really costs, what breaks. | Deepest reasoning for feasibility, risk, and architectural fit against this codebase's real constraints. | | **Sonnet** | The implementation reality check, and later the build. | Efficient, concrete — turns a spec into working code once one is chosen. | | **Dispatch** | Synthesis, and the payoff question: **what did only the outsiders see?** | Gemini and ChatGPT have no RobCo-specific priors — anything they surface that all three Claude models missed is the whole point of paying for outside models at all. | --- ## The sequence — independent first, blind **Round 1 is cold.** Every model proposes from the same brief, having seen nothing from any other model. If Gemini sees ChatGPT's answer before proposing, it anchors on it — and the entire reason for asking a different model evaporates. **Round 2 is cross-fire.** Once every Round-1 proposal is in hand, each model critiques the others' proposals (Dispatch relays the proposals; the models don't talk to each other directly). The cross-fire round is worth more than any single Round-1 proposal — this is where the adversarial (ChatGPT) and architect (Opus) roles earn their keep, and where blind spots in the ambitious Gemini proposal or the diegetic Fable proposal get caught before anyone commits to them. Do not compress this into one round to save time. The whole value of the template is in the two-round structure. --- ## Two portable briefs, different sizes on purpose Both briefs are generated **fresh** from `library/BRAIN_DUMP.md` at run time, using the brain dump's own portable-brief generator spec (see its "Generating a portable brief for an external model" section — §25 as of this writing). Never store a static copy of either brief; a stored brief goes stale the moment the brain dump next changes. Regenerate every time this template runs. - **Gemini gets the LONG brief.** Full architecture, hard constraints, design philosophy, feature inventory, roadmap. Gemini has the context window for it — use it. Skimping on Gemini's brief wastes its actual advantage. - **ChatGPT gets a SHORT brief.** The free tier has a small context window and short outputs — a long paste gets truncated into mush and the reply comes back thin. Condense to exactly three things: what the app is, the hard constraints (below), and the ONE feature under remake. Nothing else. --- ## Hard constraints — carried into every brief, for every model, every run State these plainly in both briefs, every time. They do not change per-feature. - Vanilla global-scope JS/CSS. **No build step, no framework, no bundler.** - Offline-first PWA. **No new image assets** (inline SVG is markup, not an asset — that's fine). Justify any added precache cost. - Must stay free. AI usage is bring-your-own-key. - Mobile-primary (360–412px), and landscape orientation matters too — not just portrait. - Popup-only auth. No redirect sign-in, ever (Protocol 30). - Game-agnostic: per-game behavior is DATA (`GAME_DEFS`), never a hardcoded literal (Protocol 38). - **Clarity outranks flavor.** A themed name only ships if it's instantly understandable without a legend. - **The player owns the truth.** Anything editable today stays editable, in no more taps than it currently takes. - **Every idea must be a ground-up remake of a feature that already exists** — not a net-new invention. Say this explicitly; it has been gotten wrong before. --- ## The honest-boundary rule — the most important thing in this template **Before running this template for any feature, Dispatch must state plainly — to the owner, up front — what the six models CANNOT do for that particular feature.** Skipping this step is how you get a beautiful, confidently wrong deliverable that the owner has to catch by hand after the fact. ### Worked example: the New Vegas world map Six models will nail the LOOK and the SYSTEM — phosphor line-work, terrain hatching, icon design, fog-of-war, fast travel, zoom behavior, the underlying data structure, the per-game hook into `GAME_DEFS`. **But they cannot invent the Mojave.** No model actually knows that map's true geometry — where the Colorado river bends, how the roads really run between Primm and Novac. Asked to draw it from a text prompt, every one of them will produce something **confidently wrong**, and the owner will spot it instantly because he knows the game. The fix is to draw the DESIGN/DATA line up front: the geometry is **DATA, not design** — coordinates sourced from fallout.wiki (the sanctioned source per Protocol 3), terrain and roads hand-drawn as original vector art against real reference. **The models build the machine. A human (or a dedicated sourcing pass) authors the artefact that goes inside it.** ### The general rule For every feature this template is aimed at, name up front: - What is **DESIGN** — the models can genuinely do this well (visual language, interaction model, data structures, code architecture, per-game hooks). - What is **DATA / AUTHORSHIP** — a human or a dedicated sourcing pass has to do this, because it requires ground-truth knowledge no model actually has (real-world geometry, exact game text, canonical values, licensed assets). Failing to draw this line before running the models is exactly how a confidently-wrong deliverable happens. --- ## What Dispatch hands the owner In this exact order, every block ready to paste with zero editing required: 1. **Block 1 → Gemini.** The long brief, followed by the expansive "go wide" ask for this feature, followed by an explicit instruction to turn on extended thinking. 2. **Block 2 → ChatGPT.** The short brief, followed by the sharp-critique ask. **The ChatGPT thread is named `GPT - Claude Data`** — tell the owner to paste into that thread specifically, not a fresh one. 3. **One line** telling the owner: paste each model's reply straight back to Dispatch, unedited, no summarizing. 4. Dispatch then runs the three Claude models (Fable, Opus, Sonnet) through the same two-round structure, folds in the Gemini and ChatGPT replies for the cross-fire round, and synthesizes. --- ## Output aim This is analysis-first, but it aims at **a spec good enough to build** — so that if the owner likes it, shipping is a live option with zero rework, not a second design pass. The owner reads the synthesis and decides whether to build, revise, or shelve. Dispatch does not pre-commit to building; that decision is the owner's. The synthesis should explicitly answer: what did only the outside models (Gemini, ChatGPT) see that all three Claude models missed? That question is the actual payoff of paying six models instead of three. --- ## How to re-aim this at a new feature 1. Swap the feature name and its current-implementation summary everywhere the template references "the feature under remake." 2. Regenerate both briefs fresh from `library/BRAIN_DUMP.md` — never reuse a stored brief from a prior run. 3. Restate the honest-boundary rule for the NEW feature specifically — do not reuse the Mojave-geometry example verbatim; find the real DESIGN/DATA line for the new target. Every feature has a different line; assuming it's the same one is itself a version of the mistake this rule exists to prevent. 4. Run the two-round sequence (independent-blind, then cross-fire) exactly as above. 5. Add the feature to the "already aimed at" list below in the same run, so it doesn't get silently re-run on the same target later. --- ## Features already aimed at - **New Vegas world map** — first target, chosen by the owner. (Run pending as of this template's creation.)