Creative Brief Room prompt template using the Sites Plugin in Codex

OpenAI's Codex platform now supports a "Creative Brief Room" template that uses the Sites Plugin to build and deploy interactive internal creative briefing applications. The template generates a working app that integrates with Google Drive, Slack, and Notion to pull source documents, production status, and creative direction, replacing static docs with a collaborative workspace for tracking assets, decisions, and timelines. The system includes privacy-safe screenshot capabilities and deploys via the Sites Plugin with local preview fallback.

Prompt: Creative Brief Room Using the Sites Plugin in Codex @sites plugin://sites@openai-bundled & @build-web-apps plugin://build-web-apps@openai-curated Build an internal creative briefing app called APP NAME for PRODUCT OR CAMPAIGN NAME launching on LAUNCH DATE OR WINDOW . This app is for PRIMARY AUDIENCE who need to brief and collaborate with creative partners on assets such as videos, web pages, campaign containers, social content, and other launch materials. The app should be more useful than a static doc or slide deck because it is interactive, easy to scan, source-linked, screenshot-friendly, and able to track decisions, notes, assets, asset-specific timelines, and visual inspiration in one working surface. Use @google-drive plugin://google-drive@openai-curated to find source docs, campaign briefs, launch plans, landing-page drafts, video briefs, creative reviews, feedback docs, and slide decks related to PRODUCT OR CAMPAIGN NAME . Use @slack plugin://slack@openai-curated to find current production status, open decisions, creative direction, launch constraints, and review feedback in channels like CHANNEL NAME 1 , CHANNEL NAME 2 , CHANNEL NAME 3 , CHANNEL NAME 4 , and CHANNEL NAME 5 . Use @notion plugin://notion@openai-curated if there are relevant launch trackers, planning pages, creative notes, production pages, or source-of-truth briefs. Use $imagegen to generate one high-fidelity desktop concept before implementation. Use the Browser plugin to render the app locally, inspect desktop and mobile layouts, test the interactive flows, and apply browser review comments before finalizing. Use Git/GitHub if available to create a dedicated repo, commit the final app, and report the commit hash. Use @sites plugin://sites@openai-bundled to deploy the verified app. Do not stop at a mockup, static screenshot, or design proposal. Build and deploy the working app. Base the app content on the discovered resources. Prefer approved PMM, comms, creative, web, video, and launch-facing sources over informal Slack discussion. Use Slack mainly to identify current status, unresolved questions, review feedback, asset needs, rollout caveats, and useful context. If Slack conflicts with approved source material, preserve the uncertainty and mark the relevant item as needing review. Use these source names as search targets. Replace these placeholders with the actual doc, deck, page, or thread names: - PRIMARY CAMPAIGN BRIEF NAME - MESSAGING BRIEF NAME - PRODUCT OR LAUNCH BRIEF NAME - LAUNCH BLOG OR ANNOUNCEMENT NAME - LANDING PAGE COPY DOC NAME - VIDEO BRIEF NAME - VIDEO FEEDBACK DOC NAME - SOCIAL PLAN NAME - VISUAL MOCKS OR DEMOS NAME - CONTENT RADAR OR TRACKER NAME - XFN LAUNCH GUIDE NAME - DOCS UPDATE OR RELEASE NOTES NAME Create a new folder and git repo named REPO NAME . Use the visible application-shell brand APP NAME . Use the hero title SHORT CAMPAIGN NAME . App Goal Build a practical internal creative workspace, not a public marketing page. It should help PRIMARY AUDIENCE understand the assignment quickly, track requested deliverables, resolve decisions, manage production timelines, and collect creative references in one place. The final app should include: - A screenshot-friendly overview - Compact launch and ownership status pills - A Room settings editor for visible campaign metadata and fictionalized names - A full-width decisions and room-notes component - A global asset-request workflow - A separate editable production timeline for each asset - A chronological full-width inspiration wall - Source-grounded target-audience and key-message sections - Dedicated brief sections for each seeded asset - A lower provenance section with source links - Deployed persistence with a graceful local-preview fallback Privacy Requirement The app must be safe to screenshot and share without exposing real coworker names. - Replace all visible coworker names with tasteful fictional names. - Use fictional DRIs such as FICTIONAL PMM OWNERS , FICTIONAL VIDEO OWNERS , and FICTIONAL WEB OWNERS . - Do not surface email addresses, Slack handles, profile photos, or private names in the visible UI. - Source links may remain available in the lower provenance section. - Make every visible fictionalized name editable directly in the UI. A user should not need to modify code to change a PMM owner, asset DRI, milestone owner, or other visible collaborator label before taking a screenshot. - Treat placeholders as initial seeded values, not hard-coded presentation copy. Provide clear edit actions for visible seeded brief content. Moodboard Direction Before implementation, use $imagegen to create a high-fidelity desktop concept with this direction: Create a premium internal creative-workspace UI that combines an editorial brief room with a practical moodboard. Use a restrained white canvas, subtle borders, sage green status accents, warm pale-yellow review states, serif display typography for the campaign title, and compact sans-serif operational UI. Include a persistent left navigation rail, a screenshot-friendly launch overview, asset cards, a decisions list, production timelines, and a full-width Inspiration Wall lower on the page. Avoid marketing-page hero treatments, decorative gradients, oversized rounded cards, and fabricated employee photography. Use the generated visual as a directional artifact. Build an actual usable app rather than copying decorative details blindly. Layout And Navigation Use a persistent internal-tool layout. Desktop: - Persistent left navigation rail - Main content surface - No secondary top header - No global search bar Mobile: - Collapse the rail into a Jump to section disclosure - Keep the primary actions usable inside the disclosure and section headers Add a compact Room settings action at the bottom of the desktop rail and inside the mobile disclosure. The desktop left-rail brand should say only: APP NAME Use these navigation items in this order: - Overview - Timeline - Inspiration - Target audience - Key messages - ASSET 1 SHORT NAME - ASSET 2 SHORT NAME Do not include review questions as a standalone navigation item. The page should flow in this order: - Overview hero - Key updates & decisions - Assets requested - Production timelines nested directly under Assets requested - Inspiration Wall - Target Audience - Key Messages - ASSET 1 SHORT NAME brief - ASSET 2 SHORT NAME brief - Sources Overview Hero Create a concise, screenshot-friendly opening area. The hero title should say only: SHORT CAMPAIGN NAME Include: - Launch date or window: LAUNCH DATE OR WINDOW - Primary message: PRIMARY MESSAGE - Compact status pills: - OVERALL STATUS - LAUNCH DATE PILL - A dynamic pill showing the number of requested assets - FICTIONAL PMM OWNER PILL Do not show risk-detail pills in the hero. Keep rollout uncertainty, legal review, or timing caveats in the decisions list or source notes instead. Key Updates & Decisions Create a full-width horizontal component directly below the hero and above Assets requested. Use a single-column list. Do not arrange decision items across multiple columns. Seed the example with source-grounded open items such as: - OPEN DECISION 1 - OPEN DECISION 2 - OPEN DECISION 3 - OPEN DECISION 4 - OPEN DECISION 5 Each item should show: - Checkbox - Decision or question - Due date Behavior: - When checked, dim and strike through the item text. - Add an Add entry action in the component header. - Clicking Add entry opens a modal with: - Entry - Due date - Newly added entries should appear immediately. Below the decisions, show Room notes when notes exist. Notes Add a functional New note action at the bottom of the desktop rail. Include the same action inside the mobile navigation disclosure. Clicking New note should open a modal with: - Note text area - Save note action New notes should appear under Room notes in the Key updates & decisions component. Room Settings And Brief Editing Add a functional Room settings action so non-technical users can edit the visible seeded values directly in the UI without modifying code. Clicking Room settings should open a modal or side panel with: - Application-shell brand - Campaign title - Launch date or window - Primary message - Overall status - PMM owner label - Screenshot-safe collaborator aliases Saving should immediately update the hero, status pills, and any visible owner labels that use those values. Add restrained Edit actions to source-backed sections so placeholder content can be adapted directly in the app: - Target Audience cards - Key Messages - Asset brief content - Asset cards and their DRIs - Timeline milestone labels and owners Use clear, low-noise edit controls such as a small pencil icon or text action in each section header. Keep the default reading view clean and screenshot-friendly. Do not allow users to overwrite original provenance. Source links, source titles, and source excerpts should remain read-only. Assets Requested Create an Assets requested section below Key updates & decisions. Include: - Section title: Assets requested - Supporting copy: Current delivery state and directly responsible owners. - A global Add asset action in the Assets requested heading - An Edit asset action on each asset card so users can change the asset name, description, status, icon, and DRI directly in the UI Seed the app with at least two asset cards. ASSET 1 NAME - Description: ASSET 1 DESCRIPTION - Status: ASSET 1 STATUS - DRI: FICTIONAL ASSET 1 DRI - Icon: ASSET 1 ICON ASSET 2 NAME - Description: ASSET 2 DESCRIPTION - Status: ASSET 2 STATUS - DRI: FICTIONAL ASSET 2 DRI - Icon: ASSET 2 ICON Render asset cards in an auto-fitting grid so additional assets remain usable. The overview asset-count status pill must update dynamically when assets are added. Add Asset Clicking Add asset should open a modal with: - Asset name - DRI - Status - Status tone: Green or Yellow - Icon: Web page, Video, or Message - Description - Timeline rows Use a simple structured timeline-row format: date | milestone | owner | state Use one row per milestone. Supported states: - done - current - next - launch Provide five useful default milestone rows for a newly added asset. When an asset is added: - Add its card to Assets requested. - Update the dynamic asset-count pill. - Add its timeline under Production timelines. - Persist the asset. Production Timelines Nest Production timelines directly inside the Assets requested section, below the asset cards. Use a subtle internal divider so the timelines read as detail for requested assets rather than as a separate unrelated page band. Keep the Timeline navigation anchor working. Each asset timeline should show: - Asset title - Status pill - Edit timeline action - Five milestone points - Date - Milestone title - Owner or team - Visual state: done, current, next, or launch Seed the ASSET 1 NAME timeline with: - ASSET 1 MILESTONE 1 DATE | ASSET 1 MILESTONE 1 NAME | ASSET 1 MILESTONE 1 OWNER | done - ASSET 1 MILESTONE 2 DATE | ASSET 1 MILESTONE 2 NAME | ASSET 1 MILESTONE 2 OWNER | done - ASSET 1 MILESTONE 3 DATE | ASSET 1 MILESTONE 3 NAME | ASSET 1 MILESTONE 3 OWNER | current - ASSET 1 MILESTONE 4 DATE | ASSET 1 MILESTONE 4 NAME | ASSET 1 MILESTONE 4 OWNER | next - ASSET 1 MILESTONE 5 DATE | ASSET 1 MILESTONE 5 NAME | ASSET 1 MILESTONE 5 OWNER | launch Seed the ASSET 2 NAME timeline with: - ASSET 2 MILESTONE 1 DATE | ASSET 2 MILESTONE 1 NAME | ASSET 2 MILESTONE 1 OWNER | done - ASSET 2 MILESTONE 2 DATE | ASSET 2 MILESTONE 2 NAME | ASSET 2 MILESTONE 2 OWNER | done - ASSET 2 MILESTONE 3 DATE | ASSET 2 MILESTONE 3 NAME | ASSET 2 MILESTONE 3 OWNER | current - ASSET 2 MILESTONE 4 DATE | ASSET 2 MILESTONE 4 NAME | ASSET 2 MILESTONE 4 OWNER | next - ASSET 2 MILESTONE 5 DATE | ASSET 2 MILESTONE 5 NAME | ASSET 2 MILESTONE 5 OWNER | launch Edit Timeline Each asset timeline should include an Edit timeline action. The editor should use the same asset form as Add asset , populated with the selected asset's data. Saving should update both: - The overview asset card - The production timeline card Make milestone owners editable in this form. This includes any visible fictionalized collaborator names. Inspiration Wall Create a full-width Inspiration Wall after Assets requested and its nested timelines. This should be a practical link viewer and moodboard, not a manually curated decorative gallery. The section header should include the only Add reference action in the app. Include filters: - All - ASSET 1 SHORT NAME - ASSET 2 SHORT NAME - Shared When a reference link is added: - Fetch Open Graph metadata where available. - Store page title, description, preview image, site or domain, URL, asset relevance, tags, and creator note. - If Open Graph metadata is unavailable, store the URL and show a patterned fallback tile. Each tile should show: - Preview image or patterned fallback - Tag - Domain - Page title - Creator note or description - Asset relevance - Link to open the source - Remove action for creator-added references Seed the board with references that demonstrate: - REFERENCE THEME 1 - REFERENCE THEME 2 - REFERENCE THEME 3 - REFERENCE THEME 4 - REFERENCE THEME 5 - REFERENCE THEME 6 Target Audience Create a Target Audience section with source-grounded audience cards. Seed cards for: - TARGET AUDIENCE SEGMENT 1 - TARGET AUDIENCE SEGMENT 2 - TARGET AUDIENCE SEGMENT 3 Each card should include: - Audience name - What they need - Desired takeaway - Source link Add an Edit action so users can update the visible audience name, need, and takeaway without editing code. Key Messages Create a Key Messages section. Include: - Primary message: PRIMARY MESSAGE - Supporting pillar: SUPPORTING MESSAGE 1 - Supporting pillar: SUPPORTING MESSAGE 2 - Supporting pillar: SUPPORTING MESSAGE 3 Use a restrained editorial layout with one primary message and three supporting pillars. Add an Edit action so users can update the primary message and supporting pillars without editing code. Asset Briefs Create a dedicated brief section for every seeded asset. For two initial assets, use: ASSET 1 NAME Include: - Asset purpose - Core story - Key moments to show - Distribution channels: ASSET 1 DISTRIBUTION CHANNELS - Formats: ASSET 1 FORMATS - Status: ASSET 1 STATUS - Source links Use three story cards: - ASSET 1 STORY CARD 1 - ASSET 1 STORY CARD 2 - ASSET 1 STORY CARD 3 ASSET 2 NAME Include: - Asset purpose - Audience - Status: ASSET 2 STATUS - Source links - Outline Use outline cards for: - ASSET 2 OUTLINE CARD 1 - ASSET 2 OUTLINE CARD 2 - ASSET 2 OUTLINE CARD 3 - ASSET 2 OUTLINE CARD 4 - ASSET 2 OUTLINE CARD 5 Add an Edit brief action to each asset-brief section so users can update visible purpose, story, audience, channels, formats, outline, and status without editing code. Sources Create a lower Sources section with live links to the discovered source documents and relevant docs pages. Keep provenance available without adding source-link noise to the screenshot-friendly overview or timeline headers. Include a concise source note if an older tracker conflicts with the latest approved launch brief. Data And Source Rules Every major content block should either: - Link to a discovered source, or - Be clearly marked as needing review by REVIEW OWNER OR TEAM Do not fabricate: - Metrics - Customer claims - Competitor claims - Personas or audiences - Approved messaging - FAQs or open decisions - Launch dates - Owners - Feature scope - Roadmap commitments If a source is missing, create a visible placeholder such as: Needs approved source Treat launch facts as live data. If sources disagree, identify the freshest approved source and clearly note the conflict in a source note. Persistence Use D1 for deployed persistence. Persist: - Inspiration references and Open Graph metadata - Notes - Decisions - Requested assets - Timeline milestones - Room settings and screenshot-safe collaborator aliases - User-edited target-audience cards, key messages, and asset-brief content Provide a graceful browser-local fallback when D1 is unavailable during local preview. The app should remain fully usable for local design QA. Do not make original source links, source titles, or source excerpts editable. Creator edits should complement the source-backed brief rather than overwrite provenance. Visual Design Design this as an internal operational workspace, not a marketing landing page. Use: - White background - Thin neutral borders - Sage green for complete and active states - Pale yellow for review states - Terracotta outline for launch milestones - Serif typography for the SHORT CAMPAIGN NAME title and major editorial section headings - Compact sans-serif typography for operational content - Cards with restrained 6-8px radii - Dense but readable spacing - Persistent left rail on desktop - Collapsed Jump to section disclosure on mobile Avoid: - Search bar - Secondary top header - Large decorative gradients - Decorative orbs or bokeh - Oversized pill-heavy UI - Nested floating card sections - Fabricated product screenshots where patterned fallbacks are more honest - Real coworker names Responsive Behavior Verify at: - Desktop: approximately 1421 x 968 - Mobile: approximately 390 x 844 On mobile: - Replace the desktop rail with a Jump to section disclosure. - Keep New note accessible inside the disclosure. - Stack cards. - Keep Add entry and Add asset visible and usable. - Ensure the document width does not exceed the viewport. Implementation Notes Recommended implementation: - React or Next-style app compatible with Sites hosting. - Keep source-grounded data in a structured file. - Keep the main page focused on rendering and local UI state. - Use an API route or server-side action for Open Graph metadata retrieval. - Use D1 for deployed persistence. - Use browser-local storage as a local-preview fallback. Suggested scripts: - npm run dev - npm run lint - npm run build Local Review Render locally before finalizing. Use the Browser plugin to verify: - Sidebar brand says APP NAME . - Hero title says SHORT CAMPAIGN NAME . - No top header or global search bar appears. - Decisions use one column. - Checked decisions dim and strike through. - Add entry opens, saves, and immediately appends a decision. - New note opens, saves, and appears under Room notes . - Room settings opens, saves, and immediately updates the hero metadata and PMM owner label. - Every visible fictionalized coworker name can be changed through the UI without editing code. - Add asset opens, saves, increments the asset-count pill, adds an asset card, and adds a production timeline. - Edit asset updates an asset card's DRI and visible content. - Edit timeline opens with populated fields and milestone rows. - Saving a timeline edit updates both the asset card and production timeline. - Target Audience, Key Messages, and each asset brief expose restrained edit actions and persist updated visible copy. - Timeline navigation lands on the nested Production timelines block. - Inspiration navigation lands on the full-width Inspiration Wall. - Add reference appears only in the Inspiration Wall. - Inspiration filters work. - Real coworker names do not appear in visible UI. - Mobile layout does not overlap, clip, or exceed the viewport width. Run: - lint - production build Deployment Deploy the completed app with Sites when the approved source-push path is available. Create the Sites project, save its project ID in .openai/hosting.json , build the deploy archive, push the committed source revision to the generated Sites repository, create a Sites version from the exact commit SHA and archive, then deploy it. Default the deployed access mode to admins only unless explicitly instructed otherwise. After deployment, report: - local URL used for review - deployed site URL, if deployment succeeds - access mode - commit hash - missing source materials - sections marked as needing review If deployment is blocked by a source-push or security control, do not bypass the control. Report the blocker and what approved path is needed.