--- name: parked-recreation-funprompt description: "⭐ THE SIX-MODEL COLLABORATIVE REMAKE — a REUSABLE template, not a one-shot: the roles, why independent-and-blind comes first, the honest boundary on what models cannot invent, and the verbatim base prompt. First target picked by the owner: the NV map." metadata: node_type: memory type: project originSessionId: 0b7c5f41-bb34-4ab4-93be-fdb363f5eb40 --- Originally parked 2026-06-28 as a "for fun" prompt. Per [[parked-task-workflow]]: keep the prompt verbatim; do not run until the owner says go. *Correction 2026-07-20: the sequencing this file used to assert (absolute-last position, gated behind a specific release) is stale and has been removed — the owner later said a strong result could make it a real unit. Live ordering lives in `QUEUE.md`.* **FRAMING CORRECTION (owner 2026-06-30 — this is the TRUE intent of the prompt, and the first run got it wrong):** every idea must be a **ground-up REMAKE of a feature that ALREADY EXISTS on the site** — *"pick an existing feature; if you rebuilt it from scratch, how would you make it the best / most-improved version possible?"* This is **NOT** about inventing new or standalone features. The first run proposed net-new things (an ambient engine) and missed the point entirely. Each tier = a from-the-ground-up reimagining of a DIFFERENT existing feature; the MEGA tier = the most ambitious remake of an existing system, still **not** a net-new feature. **SCOPE ADDITION (owner 2026-06-30):** a FOURTH, **MEGA** tier beyond Quick / Medium / Ambitious. All four get the same full 8-point treatment under the same hard constraints. --- ## ⭐⭐⭐ IT IS NOW A REUSABLE TEMPLATE — NOT A ONE-SHOT Owner 2026-07-12: **"keep the vague prompt for future use on other features."** **THE SIX-AI COLLABORATIVE REMAKE is a STANDING TOOL.** The generic, feature-agnostic version lives in the Library ([[prompt-library-campaign-framings]]) and is **re-aimed at a different feature whenever the owner wants one.** It is never "used up." ### FIRST TARGET, PICKED BY THE OWNER: **the NV MAP (the Cartography Table).** ⭐ Owner: *"the map with the current plans is a crazy good idea. we need to make sure the map looks exactly like it does in NV."* It is **NV-specific** (owner: *"let's also add it's for NV specifically"*) and it feeds directly into the planned geographic map ([[parked-2-9-0-update]]) rather than being a side quest. ### ⚠⚠ THE HONEST BOUNDARY — SAY THIS OUT LOUD OR THE EXERCISE IS WASTED Dispatch told the owner this and he accepted it: - **What six models WILL nail:** the LOOK and the SYSTEM — phosphor line-work, terrain hatching, location icons, fog-of-war, fast-travel, zoom, the feel of moving around it, the data structure, and the per-game integration hook (so the next game's map is later a DATA FILE, not a rewrite). - **What they CANNOT do: invent the Mojave.** No model knows that map's real geometry — where the Colorado bends, how the roads run between towns, true relative positions. Asked to draw it, they will produce something **confidently wrong** — a Mojave-*flavoured* map that isn't the Mojave — **and the owner will spot it instantly.** - ⇒ **THE GEOMETRY IS DATA, NOT DESIGN.** It must be AUTHORED: location coordinates from the sanctioned wiki source, terrain and road paths hand-drawn as vector against real reference. - ⇒ **It must be an ORIGINAL DRAWING, not a ripped image** — same rule as the Vault Boy figure. Zero image assets, and a traced screenshot is someone else's artwork. **Geographically faithful, originally drawn.** - This is the owner's own earlier ruling: *the labour of authoring a map is expected and fine — what must NOT be hard is dropping it in.* **The six models build the machine; the map itself gets drawn.** ### SHIP INTENT Owner: *"this is just for fun but I'm hoping to get a ship worthy result so idk until I get the results."* ⇒ Run it as analysis, but **aim the output at a spec good enough to BUILD**, so shipping stays an option with no rework. He decides after reading it. --- ## ⭐⭐ IT IS A SIX-MODEL EXERCISE (Claude ×3 + Gemini + ChatGPT + Dispatch) Owner 2026-07-12: **"adjust it so somehow we also use ChatGPT (free) and Gemini (Pro, extended) to help with the recreation prompt. instructions should be included (copy paste blocks for prompts as well) on what to send to each AI (including the portable brain dump(s)) to make it as automated on me as possible."** **The point:** Claude reviewing work produced inside its own ecosystem is a blind spot. For a *creative* exercise, an outside model may reach ideas Claude structurally cannot. Several models ideate INDEPENDENTLY from the same facts; Claude then synthesizes and — the real payoff — **identifies what only an outsider saw.** ### Dispatch's job: make it ZERO-effort for the owner. He copies, pastes, and brings answers back. Nothing else. **Two portable briefs are generated FRESH from the brain dump at run time** (never stored, so never stale). ⚠ **They are DIFFERENT SIZES on purpose:** - **GEMINI brief — LONG.** Extended thinking plus a huge window: give it the full brief — architecture, hard constraints, design philosophy, feature inventory, roadmap. It can hold all of it. - **CHATGPT brief — SHORT.** The free tier has a small window and short outputs. A condensed brief only — what the app is, the hard constraints, and the named features it must remake. **A long paste gets truncated and produces mush.** ### ⭐ THEY ALL REMAKE **ONE** FEATURE, TOGETHER — not four ideas each Six models each proposing four ideas gives you twenty-four mediocre answers. **All six work the SAME feature, in different ROLES.** ⚠ **INDEPENDENT FIRST, BLIND TO EACH OTHER.** If one model sees another's answer it anchors on it and you lose the entire point of asking a different model. Everyone proposes COLD from the same brief. **Then** cross-pollinate — a second round where each critiques the others. ***The cross-fire is worth more than any single proposal.*** **The roles:** - **GEMINI** (huge context, extended thinking) → **go wide.** The most ambitious possible reimagining. Reach is its strength. - **CHATGPT** (free) → **the adversary.** Attack the current version, then attack everyone else's proposal. Proven edge — it found the audit gap in the 2026-07-11 review. - **FABLE** → **the design answer.** The most beautiful, most diegetic version. - **OPUS** → **the architect.** What is actually buildable, what it really costs, what breaks. - **SONNET** → the implementation reality check, and then the build. - **DISPATCH** → synthesis, and the report that matters: ⭐ **what did only the OUTSIDERS see?** ### Different asks, so they don't duplicate each other - **GEMINI = EXPANSIVE IDEATION.** *"Go wide. What is the most ambitious ground-up remake of this feature?"* Extended thinking on. - **CHATGPT = SHARP CRITIQUE + ONE IDEA.** *"Pick the ONE you think is weakest and tell me how you'd rebuild it — and be harsh about why the current one is bad."* Its strength is **attacking assumptions**, not volume. Play to it. - **CLAUDE** produces its own set, **then synthesizes all of them** and reports what only the outsiders saw. ### The deliverable Dispatch hands the owner (in this exact order, all ready-to-paste) 1. **Block 1 — paste into Gemini** (full brief + expansive ask + "turn on extended thinking"). 2. **Block 2 — paste into ChatGPT** (short brief + the sharp-critique ask). ⚠ Tell him the ChatGPT thread is **`GPT - Claude Data`** — the same convention as the workflow review. 3. **A one-line instruction on what to bring back** — just paste each reply back to Dispatch, no editing, no formatting. 4. Then Dispatch synthesizes. **Constraints carry over unchanged for every model:** vanilla no-build global-scope JS · never bump the app version without owner approval · popup-only auth · justify any precached asset · **every idea is a ground-up REMAKE of an EXISTING feature.** Related: [[engineering-metrics-log]] (the external-evidence-review convention and the `GPT - Claude Data` thread name), [[fo3-pipboy-program]], [[prompt-library-campaign-framings]], [[external-ai-prompt-delivery]]. --- ## The base prompt, verbatim — re-aim it at whichever feature the owner picks ``` You're working on RobCo U.O.S. — my Fallout-themed PWA terminal (live at https://zerckzzyhd.github.io/Robco-UOS/). It's a vanilla HTML/CSS/JS PWA: global-scope scripts (no modules/frameworks), service-worker caching, Firebase (anon + Google auth, Firestore, App Check), and the Gemini API. The whole thing leans into the green-phosphor CRT terminal aesthetic. HARD CONSTRAINTS — do not propose anything that requires: - a framework rewrite (it stays vanilla, global-scope, no build) - an APP_VERSION bump - changes that break popup-only auth (no redirect-based sign-in) - new precached assets, unless you explicitly justify the cache cost Explore the site thoroughly — its screens, components, controls, boot/render flow, and how the terminal "feel" is built. Ground your ideas in what you actually find: reference specific files, functions, screens, or controls you saw, not assumptions. Then give me THREE distinct things you'd want to recreate — three separate, fully developed ideas, not one. Make them genuinely different from each other (e.g. different screens, systems, or layers of the site), not three flavors of the same thing. Spread them across effort levels: - ONE small/quick win — a focused change you could ship fast. - ONE medium-scope idea. - ONE ambitious idea — a bigger rework or new system. This one may be a genuine wildcard: something new rather than a recreation of an existing element, if that's the stronger idea. Label each idea with its tier (Quick / Medium / Ambitious). For EACH of the three, walk me through all of these in full: 1. WHAT — The specific element, component, feature, or screen. Name it precisely. 2. WHY — What makes it worth redoing? What's interesting, weak, or underused about the current version? 3. HOW — Your technical approach, IN KEEPING WITH THE STACK: vanilla JS in global scope, no module system, loaded the way the rest of the site is. If you'd reach for anything heavier, justify why it earns its place on a no-build PWA. 4. BETTER — How your version improves on the original: performance, accessibility, the CRT/terminal authenticity, offline/cache behavior, data safety, or maintainability. Be concrete. 5. FIT — How it fits BOTH ways. Visually: name the actual terminal mechanics it uses or respects (scanlines, phosphor glow, boot-text cadence, keyboard-driven nav, etc.), not just "fits the vibe." Architecturally: cache policy, the gate/tests, popup-only auth, kill-switch + fallback for any new network/IO, additive cloud writes. It should feel native, not bolted on. 6. TRADEOFF — What gets worse or what you'd sacrifice. Every idea has a cost; name it honestly instead of hiding it. 7. EFFORT / RISK — A rough size (files touched, new tests needed) and a risk flag (low / medium / high), so I can triage. 8. PIPELINE — Whether it's trivial enough to ship directly, or needs the full Opus-plans → Sonnet-builds → Opus-audits workflow. Treat all three as serious, standalone proposals — give each the same depth, don't rank or pick a favorite, and don't collapse them into a single recommendation. This is analysis only; don't write or push code yet. ``` ⚠ When reusing: apply the ground-up-remake framing correction above (the base prompt's "wildcard" allowance in the Ambitious tier was what the first run over-read), and add the MEGA tier.