# Creative Brief Room prompt template using the Sites Plugin in Codex > Source: > Published: 2026-06-02 17:19:51+00:00 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. ```