A BETTER WAY TO SHARE THE WORK
Create a project handoff that makes the next owner's job clear
Sending the files is not the same as handing over the work. Show what is ready, what remains open, and who acts next.
New to creating with an agent? The request will guide it through the task. Bring your notes; you don’t need to write HTML.
How do I create a useful project handoff with my AI agent?
Give your agent the deliverables, review evidence, known issues, and agreed ownership arrangements. Ask for a handoff page that distinguishes received work from accepted work, names who still owns each open item, and explains what the receiving team must confirm. Review it before sharing; the page summarizes a transfer but does not perform one.
01 / SEE THE DIFFERENCE
The files arrived. The transfer is still pending.
A fictional help-center refresh. Delivery, review, and ownership notes describe different states; the handoff preserves all three.
Eight article drafts and a maintenance guide were delivered. Morgan acknowledged receipt of all files. Six articles are accepted; two await terminology review. Casey owns the terminology review, targeting September 10, not a guaranteed completion date. One outdated reference must be removed before the affected articles are published. Casey remains delivery owner until Morgan explicitly accepts maintenance responsibility in the existing project record. Morgan can read the draft folder; publishing permission is unconfirmed. Software changes and the rest of the knowledge base are excluded. The transfer date is unconfirmed.
- Received
- Eight drafts and the maintenance guide reached Morgan. Receipt is not ownership acceptance.
- Review state
- Six articles are accepted; two await terminology review. Remove the outdated reference before the affected articles are published.
- Still with delivery
- Casey owns the terminology review, targeting September 10. Casey remains delivery owner until Morgan explicitly accepts maintenance responsibility in the existing project record.
- Receiver must confirm
- Morgan can read the draft folder; publishing permission and the transfer date are unconfirmed.
- Outside this handoff
- Software changes and the rest of the knowledge base are excluded.
Open a complete fictional HTML example, with its source notes →
Create my project handoff02 / MAKE IT YOURSELF
Start with the evidence. Shape the page around the reader.
Start with what the receiver needs to know
Name the work being handed over, its current state, and the decision or action needed from the receiving owner. Do not begin with the project's entire history. If ownership or readiness is unclear, say that at the top rather than hiding it beneath a completed-deliverables list.
Separate delivery from acceptance
For each deliverable, preserve the supplied version, review evidence, and acceptance state. Files can be received while review is still pending. A successful test is not necessarily customer acceptance, and an acknowledgement is not permission to publish. Ask for missing evidence rather than turning a delivery message into a sign-off.
Give every open issue a next step
Show its consequence, current owner, next action, and target date when supplied. Keep unassigned work visibly unassigned. Explain any restriction on using the affected deliverable. Do not label the whole project ready merely because most items are complete, or quietly move unresolved work to the receiving team.
Check the conditions for taking over
Confirm which responsibilities have actually transferred and which remain with delivery. Put required access and operating references beside the work they support. A readable link does not establish editing permission. Keep access requests in the approved process and keep credentials out of the page.
Walk the handoff with the receiving owner
Ask whether they can identify their first action, find the required references, and explain who handles an unresolved issue. Verify the draft against the sources and record actual acceptance in the established project workflow. Share the reviewed snapshot only with an approved audience; update it when an agreed responsibility or status 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 only materials I provide or have authorized you to access, create a project handoff for [receiving owner] covering [delivered work]. Ask only for missing essentials: deliverables and versions, acceptance evidence, open issues, current owners, transfer conditions, required access, and the next review request. Lead with what is ready to take over and what still needs confirmation. Separate received, reviewed, and accepted work. For each open issue preserve its consequence, current owner, next action, and supplied target date; keep missing information unresolved. Distinguish a target from a commitment. Do not infer acceptance from receipt or silence, invent owners or dates, close issues, grant access, or transfer responsibility. Keep known restrictions beside affected deliverables, and preserve scope exclusions. Include only audience-safe references, not credentials or private source notes. Explain how to record acceptance in our existing project workflow; this page must not collect it. Create readable static HTML with no scripts, forms, signature fields, or live-data claims. Use my saved artifact style if available. Show me the draft and unresolved questions. Do not publish or change access without separate explicit approval.
04 / BEFORE YOU SEND
A polished page still needs your judgment.
- Can the receiving owner see what is ready and what they must confirm without reading the full history?
- Are receipt, acceptance, permission, and ownership transfer distinct and supported by the sources?
- Does each open issue retain its current owner, consequence, and honest target status?
- Are the operating references useful to the recipient at their actual access level, with no credentials exposed?
- Are scope exclusions and conditions for transfer still visible?
- Does the page point to the authoritative acceptance process rather than pretending to complete it?
When HTML fits
An HTML handoff is useful when a receiving team needs a concise reading page assembled from delivery notes, issue records, and approved instructions already available to your agent. It can put the next action first and leave supporting detail below.
When another format fits better
Keep authoritative issues, approvals, access grants, and ownership records in their existing tools. Use a required handover document or signature process when your organization needs one. If your existing project page already answers the receiver's questions, share it rather than maintain a duplicate. This static page does not track acknowledgements or update itself.
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
How is a handoff different from a status report?
A status report explains changes while work continues. A handoff helps someone take responsibility for delivered work: the operating context, unresolved issues, access prerequisites, and conditions for transfer matter most. Link to the status history instead of reproducing it.
What if the receiving owner has not accepted yet?
Mark the transfer as pending and state the confirmed current owner. Ask for the missing decision through the existing approval process. Do not treat an email acknowledging files, a page view, or silence as acceptance.
Can a project be handed over with open issues?
That depends on the agreed criteria and authorized decision-makers. Describe the remaining issues and their ownership accurately. The agent should not decide that they are minor enough to waive, or invent an agreement to transfer them.