A BETTER WAY TO SHARE THE WORK
Make the launch decision clear before you announce the date
A full checklist is not the same as permission to launch. Show the conditions that still stand between the product and its audience.
New to creating with an agent? The request will guide it through the task. Bring your notes; you don’t need to write HTML.
What should an agent-made product launch brief include?
Start with the launch scope, intended audience, required conditions and decision owner. Ask your agent to connect each remaining condition to evidence, an owner and the communication it holds up. Keep proposed dates separate from approved dates. Review the brief before using it to coordinate a launch.
01 / SEE THE DIFFERENCE
Product ready. Launch decision still open.
Fictional Harbor reporting pilot for invited teams. All source details are synthetic.
Export tests passed. Scope is invited teams only, not all customers. Support guide pending. Morgan owns guide review, target September 10. Casey approves launch after guide acceptance. September 14 proposed. Customer announcement held.
- Scope
- Invited-team reporting pilot; broad availability is excluded.
- Completed
- Export tests passed. This does not approve the launch.
- Remaining condition
- Morgan's support-guide review targets September 10; acceptance is still pending.
- Decision and announcement
- Casey decides after guide acceptance. September 14 remains proposed and the customer announcement stays held.
Open a complete fictional HTML example, with its source notes →
Create my product launch brief02 / MAKE IT YOURSELF
Start with the evidence. Shape the page around the reader.
Define the release readers are deciding about
Name what is included and excluded, who receives it, and whether the release is a pilot or broad availability. A feature passing tests does not establish readiness for every customer. Keep this scope beside the opening decision.
Turn checklists into conditions
For each required condition, show its evidence, current state and remaining action. Separate completed engineering work from support readiness and commercial approvals. Do not average those into a misleading readiness percentage: one unresolved mandatory condition may still prevent launch.
Connect readiness to communication
Explain what must happen before the announcement, customer email or help content can be released. Preserve the owner and approval chain from the sources. If a date is only a target, make that visible wherever it appears rather than qualifying it once at the bottom.
Record the decision outside the page
Have the accountable launch owner verify the evidence and record any go/no-go in the established process. The page summarizes that record; it does not issue approval. After a decision, update the brief with the actual state and tell affected teams about important changes.
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.
Using my authorized launch materials, create a static HTML launch brief for the stated audience and release scope. Lead with the exact decision and current approval state. Distinguish required conditions, evidence, remaining actions, confirmed owners and dates. Keep pilot scope, exclusions and dependencies visible. Separate proposed dates from commitments and completed work from launch approval. Do not invent readiness percentages, customer outcomes, owners or approvals. Ask only for missing essentials using existing authorized context. Apply my saved artifact style if available. No scripts, forms, live tracking or automatic announcements. Show the draft and contradictions for review. Do not publish, send announcements or change access without separate explicit approval.
04 / BEFORE YOU SEND
A polished page still needs your judgment.
- Are the release audience and exclusions accurate?
- Does each required condition have source-backed evidence and an honest status?
- Are targets clearly different from approved dates throughout the page?
- Are approval and announcement decisions still controlled by their established owners?
When HTML fits
A cross-functional reading brief around one release decision, with clear dependencies and the current evidence.
When another format fits better
Keep deployment controls, live task tracking, incident response and approval records in their established systems. The brief is not a release console.
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 this just a weekly status report?
A status report tracks change across a period. A launch brief centers on a particular release decision and the conditions required for it. Link to status details rather than repeating every activity.
Can I show a readiness percentage?
Only if an approved method makes that measure meaningful. Never infer readiness from the fraction of checklist items completed. A missing required condition can matter more than several completed optional tasks.
Does publishing the brief approve launch?
No. Approval must come from the authorized owner in the established process. The page can communicate a verified approval afterward, but sharing it does not create one.