A BETTER WAY TO SHARE THE WORK
Does your reader need to understand something—or do something in an app?
A beautiful page can explain a workflow without being the system that runs it.
New to creating with an agent? The request will guide it through the task. Bring your notes; you don’t need to write HTML.
When should I publish a static artifact instead of building a web app?
Use a static artifact when the job is to read a reviewed report, presentation, brief or snapshot. Use an application when readers must submit information, save changes, query live data, run calculations or carry out authenticated actions. HTML is used in both; the difference is the behavior the task requires.
01 / SEE THE DIFFERENCE
A weekly snapshot fits. An editable request queue does not.
Fictional Cedar operations request. Two reader jobs use the same authorized situation but need different capabilities.
Manager needs to understand August completion: 18 closed of 24 eligible. Operator needs to assign incoming requests, save changes and see current queue state. No approved app URL or authentication requirements supplied.
- Reading job
- A dated HTML snapshot can explain 18 / 24 = 75% completion.
- Operational job
- Assignment, saved changes and current queue state require an application workflow.
- Possible split
- A briefing may link to an approved app when its URL and access are verified. No link is supplied here.
- Not implemented
- This decision brief contains no working assignment controls, login or live queue.
Open a complete fictional HTML example, with its source notes →
Create my static page or app decision brief02 / MAKE IT YOURSELF
Start with the evidence. Shape the page around the reader.
Describe the action in ordinary language
Ask what the reader must accomplish. 'Understand this week's result' differs from 'change a request and save it.' A button-shaped decoration does not deliver the second workflow. Separate explanatory content from the operations the user expects to perform.
Find the active requirements
List live data retrieval, submitted forms, saved state, user accounts, calculations and background work. MDN distinguishes static delivery from server-side processing and data-backed behavior. share/artifacts Safe Static Mode disables scripts, forms and external API calls; it is not a place to implement these operations.
Choose an honest split when both are needed
A reviewed briefing can explain results and link to an approved application for action. Keep source data and operational controls in that application. Do not mimic a working form, login or save button in the static page, and do not imply that a linked tool's state is synchronized with the briefing.
Review the actual output before sharing
Check that every visible affordance matches what the page can do. Show the snapshot date and limitations near changing data. If the primary job needs an app, choose an appropriate application workflow rather than hiding the unsupported behavior in a disclaimer. The agent can still draft a requirements brief for that separate work.
03 / TRY THIS PROMPT
Copy this into your agent. Add your source material.
Use the conversation where you already did the work, or start one with your notes. Replace the placeholders and supply any missing context; only attach information you are allowed to share with your agent.
Get the ready-to-copy creation request for guided questions, this task, and a draft review before anything is published.
Create a static HTML decision brief that qualifies whether my reader task fits a static artifact or needs a web application. Use my authorized requirements and existing context. Separate reading and explanation from submitted inputs, saved state, live queries, calculations, accounts and background work. Recommend a real application workflow when active behavior is essential; suggest a reading-plus-approved-link split only when appropriate. Ask only for missing essentials. Use my saved artifact style if available. This task creates a communication brief only, not an app or a prototype with misleading controls. No scripts, forms, fake login, save buttons or live-data claims. Show the draft for review. Do not publish, deploy an application or change access without separate explicit approval.
04 / BEFORE YOU SEND
A polished page still needs your judgment.
- Is every required reader action classified, not just the page's appearance?
- Does the page avoid controls that imply unsupported submission or saved state?
- Are snapshot freshness and external-app responsibilities explicit?
- If the primary job needs an app, does the recommendation clearly say so?
When HTML fits
A decision brief, explanation, report or reviewed snapshot with ordinary reading navigation and approved links.
When another format fits better
Use an application platform for scripts, forms, APIs, accounts, mutable state, computation or background behavior. Sharing controls around an artifact do not turn submitted HTML into an authenticated application.
FROM DRAFT TO A LINK
Make it clear. Make it yours. Then share it.
Keep creating and revising in the agent you already use. With a compatible connection, share/artifacts publishes the reviewed HTML so you do not have to rebuild it in another editor. Ask your agent to use your saved artifact style for headings, color, and tone; review the result before sending it.
Choose who should be able to open the page and verify the returned link. For corrections to the same deliverable, update the existing artifact without changing its link. Publish a separate artifact when the old edition needs to remain available.
These are static pages, not live apps: no scripts, forms, or automatic data refresh. Source collection and scheduling depend on your agent and its available tools, not on share/artifacts.
Make this with my agentQuestions before you start
Is every HTML page a static artifact?
No. Applications also use HTML. The important distinction is the required behavior and supporting system. A static reading page does not provide a database, saved inputs or live application actions.
Can a static page link to a working tool?
Yes, when the link is approved and appropriate for the audience. The tool performs the action. The briefing does not gain that capability or automatically reflect changes made there.
Can I publish a calculator or signup form here?
Not in this Safe Static workflow. Scripts and forms are disabled. Keep calculations or signup in an appropriate application and use a static page only to explain verified results or instructions.