Build a Site that becomes part of the work

Outcome

A working Site brings the question, supporting sources, useful tools, and next decision into one place. Someone should quickly understand what it does, where to start, and which information to trust.

Start with work that already matters. A presentation, dashboard, monthly review, or forecast brief needs a different layout and different controls.

When to use it

Build a Site when the work is recurring, interactive, shared, or easier to review in one place. Useful cases include presenting a story, exploring data, reviewing results, tracking decisions, or teaching a workflow.

Keep a document, slide, or spreadsheet when that is all the job needs. A Site should earn the additional work of maintaining navigation, sources, controls, access, and a usable mobile experience.

Operating pattern

Agree on the audience, question, approved sources, owner, and next useful action. Reuse a supplied working Site or template when it fits. Then build a clear layout around that job:

• Header: Identify the Site, use the supplied branding, and show the

reporting period or review state when relevant.

• Tabs: Group the work into useful sections, such as Slides / Notes /

Sources or Summary / Results / Variances / Actions.

• Toolbar: Provide working controls for the current task: slide navigation,

filters, scenario selection, editing, or export.

• Mascot assistant: Offer a collapsible helper that answers from the

Site's content, links to supporting sources, and says when an answer is missing.

Keep sources, dates, units, and owners close to the claims they support. Make downloads return an actual file. A button must perform its stated, authorized action or explain why that action is unavailable. Show a local preview and test the full workflow on desktop, mobile, and with a keyboard.

Two practical ways to collaborate on one Site

Start with the existing owner, approved source material, and tools the team can actually use. Keep contributors' work separate until it is reviewed.

Pattern 1: One human owner, separately approved handoffs

Name one human integration owner. Others can draft copy, check sources, or review navigation and accessibility in distinct files, sections, or handoffs. The owner resolves conflicting recommendations, combines approved changes, and checks the result.

This works without simultaneous editing. A reviewer can supply approved copy, screenshots, or feedback without becoming an editor or accessing unrelated sources. Reading a draft, editing a shared Site, deploying it, and changing its audience remain separate actions with separate approval requirements.

Pattern 2: Isolated Git branches in an approved shared repository

If an approved shared repository is available, assign separate Git branches and exclusive file ownership. Review each change against the same source revision and acceptance checks. One human integration owner still decides what to combine.

GitHub is an optional review service, not a requirement for building a Site. Verify the account, repository, access, branch permissions, and workspace policy before relying on it. A local branch is not pushed, reviewed, merged, deployed, or shared simply because it exists. Pushing, opening a pull request, merging, publishing, deploying, and changing access each need explicit human approval for the intended action.

What same-workspace access actually means

Verify the actual Site's sharing controls and the named person's role before promising access. Viewer access is not editor access; an editor role does not guarantee simultaneous or conflict-free editing. Neither grants permission to publish, widen access, or change another person's work. If support is unclear, use the single-owner handoff pattern.

For a bounded handoff, see team collaboration without losing ownership, the task handoff template, and the human approval matrix. Start the practical exercise with the Sites collaboration prompt.

Copyable implementation

Choose a starting prompt, fill in your job and approved sources, and copy it into your task. The prompts cover slide apps, dashboards, close reviews, and forecast reviews. Keep the controls and review steps that fit the chosen format.

Start with a format

• HTML slides: Tell a story with editable slides,

speaker notes, source references, and presentation mode.

• Interactive dashboard: Explore metrics through

Overview / Detail / Sources tabs. Add Trends only when the sources contain history, and use filters only for available dimensions. Apply each filter to the affected charts, tables, and exports.

• Adapt the editable slide Site: Start with an independent

copy of the slide app. Keep the editor and slides together, then adapt them to your work.

Start with a Finance workflow

• Monthly close review: Compare actuals with plan,

explain supported variances, and track open questions and action owners.

• Forecast brief: Show what changed from the prior

forecast, compare scenarios, and identify decisions. Keep assumptions and exploratory scenarios distinct from the approved forecast.

Use the full prompts in the Sites section rather than maintaining separate copies. Tailor the tabs and controls to the job; a useful reference provides a starting layout, not someone else's content or source data.

Example

A team uses the monthly close prompt with its approved actuals and plan files. The header shows the period and currency. Summary leads with the results; Variances explains the supported changes; Actions tracks unresolved questions and owners. Changing a department filter updates the charts and table together. The mascot links answers to the underlying source and flags an unexplained variance instead of guessing.

The spreadsheet remains the source of truth. The Site makes the review easier to navigate and repeat. The owner checks the source reconciliation and local preview before approving any publication or access change.

Approval boundary

Building locally is not the same as deployment. A deployed Site is not automatically public. A visible draft is not approval to send a message, change data, update a shared artifact, or give someone new access.

ChatGPT Work may prepare the Site, check its routes, and show a local review when the user requests that work. Ask before publishing, deploying, changing access, connecting live systems, or writing to a production source. Report which checks passed, failed, or were not run. Call the requested work complete only when the result and checks support that claim.

Validation

Test the real surface rather than assuming the source looks right:

• The first page explains the job and offers a useful starting point.
• Tabs, toolbar controls, filters, and links do what their labels promise.
• The mascot cites supporting content and identifies unsupported questions.
• Each displayed download returns the actual described file.
• Sources, owners, dates, and review state are visible where needed.
• Contributors have distinct ownership and one human integration owner.
• Claimed editor, repository, and collaboration capabilities were verified.
• The experience works on small screens and with a keyboard.
• Missing data and unavailable services fail clearly.
• Local, hosted, restricted, and published states stay distinct.

Failure modes

Common failures are copying a reference without adapting it to the job, adding decorative controls, losing the source of a number, inventing an explanation, hiding the decision owner, and mistaking a local preview for publication.

Start with the actual workflow. Build the smallest useful surface. Make every claim, button, source, and download real.