Launch Center prompt template using the Sites Plugin in Codex

A developer created a prompt template for a "Launch Center" app using the Sites Plugin in Codex, designed to build and deploy internal launch operations tools. The template integrates multiple plugins—including Sites, Build Web Apps, Google Drive, Slack, and Notion—to coordinate launch readiness, track deliverables, and publish daily updates for fast-moving teams. The resulting app features an editable dashboard, deliverables tracker, decision log, and blockers board, with persistence and source linking for privacy-safe collaboration.

Launch Center prompt template using the Sites Plugin in Codex Prompt: Launch Center Using the Sites Plugin in Codex Use @sites plugin://sites@openai-bundled and @build-web-apps plugin://build-web-apps@openai-curated to build and deploy an internal launch operations app called APP NAME for PRODUCT OR LAUNCH NAME on LAUNCH DATE OR WINDOW . This app is for PRIMARY AUDIENCE who need to coordinate launch readiness, track deliverables, resolve blockers, capture decisions, and publish daily updates. The app should be more useful than a static launch doc because it is editable, filterable, source-linked, privacy-safe, and designed for fast-moving launch teams. Use @google-drive plugin://google-drive@openai-curated to find source docs, briefs, launch plans, messaging docs, checklists, blog drafts, landing-page copy, enablement materials, FAQs, approved launch guidance, and release notes related to PRODUCT OR LAUNCH NAME . Use @slack plugin://slack@openai-curated to find relevant launch, GTM, PMM, product, support, partner, and communications threads in channels like CHANNEL NAME 1 , CHANNEL NAME 2 , CHANNEL NAME 3 , and CHANNEL NAME 4 . Use @notion plugin://notion@openai-curated if there are relevant launch pages, planning docs, checklists, or source-of-truth project notes. Use the Build Web Apps plugin for frontend structure, responsive rigor, interaction states, and browser-based QA. Use the design-taste-frontend skill to refine the existing product surface without turning it into a marketing page: consolidate the palette, improve hierarchy, keep the information density useful, reduce generic card-heavy styling, and preserve the practical launch-operations workflow. Use the Browser plugin, specifically the in-app browser, to render the app locally, inspect it visually, apply browser review comments, and verify desktop and mobile behavior before finalizing. Use the GitHub plugin and local Git to create a dedicated repo, commit the final app, and report the commit hash. Use the Sites plugin to configure hosting, save a version, deploy it, inspect deployment status, and report the production URL and access mode. Base the app content on the discovered resources. Prefer approved launch briefs, PMM docs, product guidance, and enablement materials over informal Slack discussion. Use Slack threads mainly to identify blockers, open questions, ownership gaps, rollout caveats, and launch-day updates. 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 - LAUNCH PLAN DOC NAME - MESSAGING BRIEF NAME - BLOG DRAFT OR ANNOUNCEMENT NAME - LANDING PAGE COPY DOC NAME - GTM ENABLEMENT DOC NAME - LAUNCH CHECKLIST DOC NAME - FAQ OR OBJECTIONS DOC NAME - DOCS UPDATE OR RELEASE NOTES NAME - XFN LAUNCH GUIDE NAME - LAUNCH STATUS THREAD OR CHANNEL NAME Create a new folder and git repo named REPO NAME . Use the product/site name APP NAME prominently in the sidebar brand block. App Goal Build a practical internal launch operations tool, not a public marketing page. The app should help PRIMARY AUDIENCE understand launch readiness in under one minute, update the source of truth without editing code, and assemble a daily launch note from live tracker state. The final app should include: - A compact overview dashboard - Editable launch title and status - A clear in-app editing surface for privacy-sensitive labels, names, links, and placeholder values - Deliverables tracker with filters and inline editing - Editable launch checklist - Decision log and open questions - Blockers board - History-first daily updates - Working add and edit flows - Local or Sites-backed persistence - Source links where available - Clear empty states Layout And Navigation Use a persistent internal-tool layout: - Left sidebar with: - compact cobalt app mark - title: APP NAME - subtitle: Launch operations - navigation: Overview, Deliverables, Decisions, Blockers, Daily Update - an icon, label, and short helper caption for each navigation item - Main content area with: - compact sticky top header - editable launch name, default: LAUNCH DISPLAY NAME - small Edit action next to the launch name - green STATUS LABEL chip below the launch name - date-range control: DATE RANGE - working Share button that copies the current URL and changes to Copied Add an unobtrusive Edit launch details control that opens a compact drawer, modal, or panel. This panel should make it easy for a non-developer to replace privacy-sensitive values, names, source labels, links, and placeholders directly in the UI without editing source code. Important UI requirements: - Do not add a marketing hero. - Do not add an inert Launch settings item. - Do not add a fake profile footer such as PMM Team / Synced database . - Do not add an overflow menu. - Do not render dropdown carets on controls that do not open menus. - Do not use decorative gradients, glassmorphism, dark mode, or decorative imagery. - Give side panels enough padding to avoid cramped content. - Desktop and mobile layouts must not clip, overlap, or introduce horizontal page overflow. Overview Create a concise overview dashboard. Design this page so PRIMARY AUDIENCE can understand launch readiness in under one minute. Use a responsive row of six compact metric cards: - Overall status - Days to launch - Deliverables readiness - Decisions readiness - Active blockers - Team updates Use screenshot-ready seed values: - Overall status: On Track - Days to launch: 1 - Deliverables: around 89% - Decisions: around 100% - Blockers: 1 - Team updates: around 96% Below the metrics, use a wide main column and a narrower right rail. Main column: - Deliverables table showing: - Deliverable - Workstream or channel - Owner - Due date - Status - Priority - Recent decisions table showing: - Decision - Status - Decided by - Date - Impact area Right rail: - Editable launch checklist - Active blockers panel - Latest daily update panel Launch Checklist Create an editable checklist panel on the overview page. Checklist fields: - Item label - Checked or unchecked - Position or order Checklist requirements: - Checkbox toggles must work. - Inline label editing must work. - Add checklist item must work. - Persist checklist items. - Default checklist should be 4 / 5 complete. Seed checklist: - Finalize messaging and positioning - Approve launch blog - Publish docs and help-center updates - Run sales enablement session - Update GTM FAQ and objections Deliverables Tracker Create a dedicated Deliverables page. Fields: - Deliverable name - Channel or type: - blog - landing page - social - video - docs - enablement - internal comms - partner comms - DRI - Due date - Status: - Not started - In progress - Needs review - Approved - Shipped - Blocked - Launch-critical boolean - Latest update - Source link Requirements: - Add deliverable must work. - Editing every deliverable field must work. - Filters must work by status, DRI, channel, and launch-critical status. - Include a useful empty state when filters return no rows. - Seed enough deliverables so the app is useful on first load. - Most seeded deliverables should be Approved or Shipped. - One launch-critical item can remain Needs review. Seed realistic workstreams: - Launch blog - Landing page - Social launch plan - Launch video - Docs updates - GTM enablement - Internal comms - Partner comms - Admin or customer email Use fictional DRIs only. Decisions And Open Questions Create a dedicated Decisions page. Decision log fields: - Date - Owner - Decision - Rationale Open-question fields: - Question - Owner - Deadline - Status: - Open - In review - Answered - Blocked Requirements: - Keep the decision log easy to scan. - Make decision date, owner, decision text, and rationale editable in the UI. - Make open questions editable. - Editing question text, owner, deadline, and status must work. - Add question must work. - Seed decisions and questions so readiness looks high. - Flag uncertain decisions as needing review when source material is unclear. Do not invent real decisions from private sources. If sources are unavailable, create realistic fictional examples. Blockers Board Create a dedicated Blockers page. Fields: - Blocker - Severity: - High - Medium - Low - Owner - Needed resolution - Status: - Open - Watching - Resolved Requirements: - Add blocker must work. - Editing blocker text, severity, owner, needed resolution, and status must work. - Overview should show only one or two active blockers. - Seed should include no high-severity active blockers for screenshot readiness. - Older blocker examples should be marked Resolved or archived. Daily Update Create a dedicated Daily Update page. Make the page history-first. Top section: - Heading: Latest history - Prominent list of saved updates - Each update shows: - Date - Author - Progress - Next steps - Blockers - Results Saved-update requirements: - Make saved-update authors editable in the UI. - Make saved-update content editable so the team can correct a name, link, or sensitive detail after posting. - Persist saved-update edits. Add-update flow: - Add an Add daily update button. - The button opens an accordion-style composer below the history list. - Composer fields: - Date - Author - Progress - Next steps - Blockers - Results - Include a Rebuild from tracker button. - Rebuild should populate the composer from current deliverables, next actions, active blockers, and Approved or Shipped results. - Save update must work. - A saved update should immediately appear at the top of history. Do not include: - A Slack-ready daily update preview - A large side-preview panel - A small hidden update-history list Seed at least two daily updates using fictional or role-based authors. 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: - Numeric success metrics - Customer claims - Competitor claims - Launch dates - Real owners - Feature scope - Roadmap commitments - Pricing - Limits - Security or compliance claims If a source is missing, create a visible placeholder such as: Needs approved source If Slack and approved docs conflict: - Prefer approved docs. - Preserve uncertainty. - Mark the item Needs review . Privacy And In-App Editing Do not include real colleague names, private Slack channel names, private document titles, private customer names, or internal URLs in seeded content unless explicitly approved. Use fictional names for seeded owners and DRIs, such as: - Maya Chen - Avery Brooks - Priya Shah - Nina Patel - Sam Rivera - Elena Torres - Quinn Blake - Riley Brooks - Harper Quinn - Taylor Stone - Nora Lee - Dev Patel - Casey Moore - Theo Lane - Luca Reed Use placeholders for internal references: - PRIMARY CAMPAIGN BRIEF NAME - LAUNCH SLACK CHANNEL - SOURCE DOC URL - OWNER TEAM - REVIEW OWNER OR TEAM Treat names, labels, source display names, URLs, and other context-specific values as editable app content, not hard-coded UI copy. The Edit launch details panel must allow a non-developer to update: - Launch display name - Launch status - Launch date range - Launch goal - Audience - Key messages - Key links - Source display names - Source URLs - Review owner or team Make names and ownership directly editable wherever they appear: - Deliverable DRIs - Decision owners - Open-question owners - Blocker owners - Daily-update authors - Checklist labels Editing requirements: - Use clear labeled inputs, selects, and textareas. - Show bracketed placeholder values clearly until they are replaced. - Provide Save changes , Cancel , and Reset to defaults actions in the launch-details editor. - Keep secrets out of this editor. - Do not expose internal URLs, names, or channel labels unless intentionally entered by the user. - Update rendered UI immediately after saving. - Persist edits using the shared Sites storage layer when available. For a static local prototype, document any browser-local fallback clearly. - Do not require a code change to replace a name, link, source label, owner, or placeholder. Persistence And Data Model Use the storage pattern already available in the Sites project. If using D1, include migrations for: - Launch settings - Checklist items - Deliverables - Decisions - Open questions - Blockers - Daily updates Persistence requirements: - Launch details, key links, and privacy-related placeholder edits persist. - Launch-title edits persist. - Checklist edits persist. - Deliverable adds and edits persist. - Decision edits persist. - Question adds and edits persist. - Blocker adds and edits persist. - Daily-update saves persist. - Saved-update edits persist. - PATCH handlers preserve empty strings and other falsy edited values where relevant. If local development lacks D1 bindings, the app may fall back to privacy-safe preview seed data locally. The deployed Sites app should use the configured shared storage layer. Visual Design Design the app as a compact, screenshot-ready B2B product surface with Linear-style clarity. This is a preserve-mode redesign of a dense operational dashboard, not a marketing site. Prioritize: - Dense, scannable content with clear hierarchy - Tables, filters, forms, status chips, checklists, and useful empty states - White surfaces with hairline borders - Minimal elevation - Compact controls - Enough padding in the right-rail panels - Fast access to the next launch action Use a cool neutral visual language with Geist typography, one coherent cobalt-blue accent, and subtle green semantic success states. Use this visual system: - App background: f6f7f9 - Primary text: 182230 - Muted text: 667085 - Primary accent: 155eef - Accent hover: 004eeb - Standard border: e3e8ef - Strong border: d0d5dd - Subtle surface: f9fafb - White content surfaces: ffffff - Success background: ecfdf3 - Success border: abefc6 - Success text: 067647 - Restrained amber only for semantic warnings - Restrained red only for active blocker severity - One consistent 8px card, control, and input radius - Pill shapes only for compact semantic tags where useful - No gradients, decorative imagery, oversized hero, or visual clutter Typography and hierarchy: - Geist or an equivalent neutral product sans through next/font when available - Metric labels around 11px to 12px , uppercase, muted, and compact - Metric values around 28px - Panel titles around 15px to 18px - Body and control text around 14px to 15px - Do not use hero-scale headings. Container rules: - Avoid nested decorative cards. - Use cards only when a border helps group a real unit. - Use extremely subtle tinted shadows, roughly 0 1px 2px rgba 16, 24, 40, 0.035 . - Use light table-header backgrounds and subtle row hover states. - Give right-rail panel bodies approximately 20px padding. - Keep filter controls compact and aligned. Desktop: - 252px sticky left sidebar with a subtle f9fafb background and right border - compact cobalt app mark, app name, and Launch operations subtitle - active navigation item uses a white surface, cobalt text, pale-blue border, and extremely light shadow - inactive navigation items remain transparent with neutral text and white hover surfaces - integrated sticky top header around 80px tall with white or 95% white background and subtle backdrop blur - green On Track chip below the launch title with a small green dot - main content centered with a wide max width around 1840px - six-card metric row on wide screens - main content grid with wide tables and a 420px right rail Mobile: - sidebar becomes stacked and non-sticky - navigation remains horizontally scrollable - metric grid collapses from six columns to two columns and then one column as needed - main content and right rail stack cleanly - wide editable tables scroll horizontally instead of compressing fields until they clip - no clipping, overlapping, or horizontal page overflow Interaction and accessibility: - Add clear cobalt :focus-visible rings. - Use subtle hover states for buttons and table rows. - Use 1px active-button movement only. - Keep placeholder and helper text readable against white surfaces. - Keep status-chip contrast accessible. - Respect reduced-motion preferences. Implementation Notes Recommended implementation: - React / Next-style app compatible with Sites hosting. - Keep privacy-safe seed data in a structured file such as app/launch-data.ts . - Keep the shared storage API in a route such as app/api/launch/route.ts . - Keep the main page focused on rendering and local UI state. - Keep editable launch settings in a structured schema separate from secrets and server-only configuration. - Use shared reusable components for metric cards, panels, progress bars, status chips, filter controls, form controls, and empty states. - Preserve empty-string edits in PATCH handlers instead of dropping falsy values. - Keep .openai/hosting.json in the repo and use the Sites plugin's source-repository, version, and deployment workflow. Suggested scripts: - npm run dev - npm run lint - npm run build Local Review Render locally before finalizing. Use the Browser plugin, specifically the in-app browser, to verify: - Sidebar brand says APP NAME and includes the Launch operations subtitle. - Sticky header shows the editable launch name, green status chip, date range, and working Share button. - Share copies the current URL and changes to Copied . - Launch-title editing works. - Edit launch details works without source-code changes. - Names, links, source labels, owners, and placeholders can be replaced in the UI. - Privacy-related edits persist after refresh. - Overview metrics use the screenshot-ready state. - Checklist toggle, add, and edit work. - Add deliverable works. - Every deliverable field remains editable. - Deliverable filters work and have a useful empty state. - Decision edits work. - Add question works. - Blocker edits work. - Daily Update is history-first. - Add daily update opens an accordion-style composer. - Rebuild from tracker populates the composer. - Save daily update works. - Editing a saved update works. - No real colleague names appear in seeded content. - Side-panel padding is sufficient. - No inert dropdown carets or menus appear. - Mobile layout does not overlap or clip. - Wide editable tables scroll horizontally on mobile. - There is no horizontal page overflow at desktop or mobile widths. Run: - lint - production build Deployment Deploy the completed app with the Sites plugin when the approved source-push path is available. Sites deployment workflow: - Read or create .openai/hosting.json . - Reuse an existing project id instead of provisioning a duplicate project. - Capture a representative public/screenshot.jpeg from the in-app browser at 1200x750 . - Run the production build. - Push the exact reviewed commit to the Sites source repository using a short-lived Sites credential. - Never bypass source-push or security controls. - Create a Sites project version from that commit and matching build archive. - Deploy the saved version and poll deployment status to a terminal state. - Verify the live URL in the in-app browser when access allows. - Use the safest access mode for a new internal site and report the configured access mode. 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 - any persistence limitations 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.