Build a Site that does the work

Replace the brackets with your task, audience, and approved sources.

Build a responsive HTML slide presentation about [topic] for [audience], using [approved source materials] and [brand or template]. Lead with clear takeaway titles.

First check that the approved inputs are readable and that file-creation and local-preview tools are available. If something is missing, identify the gap and offer a clearly labeled plan or code-only draft; never claim it is a working preview.

Include a branded header with the deck title; Slides / Notes / Sources tabs; a slide list; and a working toolbar for slide navigation, editing, and presentation mode. Keep editing controls out of the presentation view.

Make slide text and speaker notes editable in the browser; make chart data editable when the underlying data is supplied. Save edits locally in that browser and provide a working export/reopen path for the edited deck. Label storage as device-local and verify that edits survive reload and export/reopen.

Trace claims and figures to the supplied sources. Preserve dates, units, and qualifiers; flag missing inputs rather than inventing content. Add a collapsible mascot assistant that answers from the deck and links to the relevant slide or source; say when an answer is unsupported. If chat is not connected, show clearly labeled help and source links instead of a chat box that pretends to answer new questions.

Return the created files and local preview when available. Check desktop, mobile, keyboard navigation, and every control; report checks as passed, failed, or not run. Ask before publishing, deploying, connecting live services, or changing access.

Replace the brackets with your task, audience, and approved sources.

Build an interactive dashboard that helps [team] answer [business question], using [approved data sources] and [brand or style reference].

First check that the approved inputs are readable and that file-creation and local-preview tools are available. If something is missing, identify the gap and offer a clearly labeled plan or code-only draft; never claim it is a working preview.

Include a branded header with the reporting period; Overview / Detail / Sources tabs, adding Trends only when history supports it; and a working toolbar with filters, reset, and CSV export. Use period or category filters only for dimensions present in the sources. Changing a filter must update every affected chart, table, and export; omit unsupported controls.

Show units, metric definitions, source dates, known data owners, and the actual data-import time. Label a snapshot as a snapshot, not a live feed. Reconcile totals to the source data and make empty, missing, and unavailable-data states clear. Never substitute invented data.

Add a collapsible mascot assistant that explains the displayed metrics and links to supporting sources. It should respect selected filters and identify questions the data cannot answer. If chat is not connected, show clearly labeled help and source links instead of a chat box that pretends to answer new questions.

Return the created files and local preview when available. Check desktop, mobile, keyboard navigation, and every control; report checks as passed, failed, or not run. Ask before publishing, deploying, connecting live services, or changing access.

Replace the brackets with your task, audience, and approved sources.

Build a monthly close review Site for [month] and [review audience], using [approved actuals, plan, and supporting files]. Follow [brand or template].

First check that the approved inputs are readable and that file-creation and local-preview tools are available. If something is missing, identify the gap and offer a clearly labeled plan or code-only draft; never claim it is a working preview.

Confirm actuals and plan use comparable reporting periods, currency, units, reporting grain, and inclusions before comparing them. Reconcile each input to its approved source control totals; flag any mismatch or missing control. State the variance formula, sign convention, and materiality rule. Ask for missing rules before labeling a variance material.

Include a header showing period, currency, and review status; Summary / Results / Variances / Actions / Sources tabs; and a working toolbar with reset, filtered export, and period or department filters only where those dimensions exist in the sources. Keep charts, tables, and exports in sync.

Show actuals versus plan, source-backed variance explanations, open questions, and action owners supported by the sources. Mark unknown owners and unexplained variances rather than inventing owners or drivers.

Add a collapsible mascot assistant that answers from the displayed results and approved sources, with links to its evidence. If chat is not connected, show clearly labeled help and source links instead of a chat box that pretends to answer new questions.

Return the created files and local preview when available. Check desktop, mobile, keyboard navigation, and every control; report checks as passed, failed, or not run. Ask before publishing, deploying, connecting live services, or changing access.

Replace the brackets with your task, audience, and approved sources.

Build a forecast review Site for [period] and [decision audience], using [current forecast, prior forecast, actuals, and approved assumptions]. Follow [brand or template].

First check that the approved inputs are readable and that file-creation and local-preview tools are available. If something is missing, identify the gap and offer a clearly labeled plan or code-only draft; never claim it is a working preview.

Use only supplied forecast and scenario values with approved assumptions; never invent forecasts or scenarios. Confirm comparable periods, currency, and reporting grain before comparing versions. Flag missing inputs or incompatible comparisons.

Include a branded header showing period, currency, and forecast version; Executive Brief / Changes / Decisions / Sources tabs, adding Scenarios only for supplied scenario data; and a working toolbar with reset, export, and period or scenario selection only where the sources support it. Apply selections consistently to charts, tables, and exports.

Lead with source-supported changes, drivers, impacts, and decisions needed. Reconcile forecast totals and the bridge from the prior forecast to approved source controls; report any unreconciled gap. Label assumptions, source-backed owners, and dates. Keep supplied exploratory scenarios separate from the approved forecast and flag unsupported explanations.

Add a collapsible mascot assistant that explains the selected forecast or scenario and links to supporting sources. If chat is not connected, show clearly labeled help and source links instead of a chat box that pretends to answer new questions.

Return the created files and local preview when available. Check desktop, mobile, keyboard navigation, and every control; report checks as passed, failed, or not run. Ask before publishing, deploying, connecting live services, or changing access.

Start with the actual HTML starter. The prompt includes its reference link; attach the downloaded file if your agent cannot open it.

Create a separate local working copy of the How to Sites HTML slide app, then help me make it my own. This request is for a local draft only; do not publish or change the shared reference Site.

Use the attached how-to-sites-starter.html if I supplied it. Otherwise retrieve this exact starter:
https://work-guide.openai.chatgpt.site/download/how-to-sites-starter.html
The same editor is demonstrated at:
https://work-guide.openai.chatgpt.site/examples/how-to-sites

Make a faithful independent copy first. Preserve the editable slide app: title, menus, toolbar, slide sidebar, text and object editing, chart examples and data editor, notes, undo/redo, presentation mode, and save/reopen. The file has no company templates, account, cloud sharing, or live connections. It is not a duplicate of the hosted project and does not inherit its permissions.

Inspect the actual file and its embedded slides-app-data, styles, and editor code before editing. Keep existing runtime and asset bytes unless the requested change requires them to change. For content-only edits, prefer the validated deck data. Do not read out long bundled libraries or encoded images. If the file cannot be read, ask me to attach that specific download; do not substitute a generic plan or claim a copy was created.

With file and preview tools available, first create and open the working copy. Check an edit, undo, a chart change, and saving an editable HTML copy. Reopen that saved copy and confirm the editor and changes remain. Use the supplied fictional examples until I provide approved sources. Missing title, logo, or business data does not block this faithful starter copy.

Use context I have already supplied to suggest the next adaptation. If its purpose is unclear, ask one focused question: what job should the slides or tools help with, and who will use them? If I have answered, make the smallest useful local change. HTML can support custom tools around the slides and interactive features inside them; only claim the features you actually built and tested. Do not invent business facts, owners, or numbers.

Return the actual editable HTML file and local preview, a short note on what changed, and checks labeled passed, failed, or not run. Ask before publishing, deploying, connecting live services, or changing access.