A BETTER WAY TO SHARE THE WORK
Turn project notes into a proposal people can confidently approve
A good proposal makes the commitment clear—not just the idea sound exciting.
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 project proposal with an AI agent?
Give your agent the problem, proposed work, known constraints, and the person who can approve it. Ask for a proposal that separates scope from exclusions, estimates from commitments, and deliverables from hoped-for benefits. Review the draft, then share a readable HTML page with a clear request for a decision.
01 / SEE THE DIFFERENCE
Approve the pilot—not an uncosted rollout
A fictional support team proposes a two-week pilot to improve five help articles. The same facts below become a bounded request rather than an implied commitment.
Pilot notes: audit five selected help articles, draft revisions, and run an editorial review. Deliver five revised drafts plus a review log of unresolved issues. Exclude publishing, site redesign, software changes, and the rest of the library. Sam estimates 24 writer hours plus 6 reviewer hours; staff availability is unconfirmed. Proposed duration: two weeks after approval and authorized source access. Neither is approved yet. There is no measured support-demand baseline or agreed reduction target. Ask Lee to approve only the pilot and proposed staff effort, not a full rollout.
- Request
- Approve only the five-article pilot and proposed staff effort. Nothing is approved yet.
- Scope
- Audit, draft revisions, and editorial review. Publishing, site redesign, software changes, and the remaining library are excluded.
- Deliverables
- Five revised drafts and a review log showing unresolved issues—not published articles.
- Estimate
- 24 writer hours plus 6 reviewer hours; availability unconfirmed. Two weeks is a proposed duration after approval and authorized source access.
- Unknown
- No measured support-demand baseline or agreed reduction target. Do not invent savings.
Open a complete fictional HTML example, with its source notes →
Create my project proposal02 / MAKE IT YOURSELF
Start with the evidence. Shape the page around the reader.
Name exactly what you want approved
'Approve a two-week content pilot' is different from 'approve the full redesign.' State the proposed phase, requested resources, decision owner, and any supplied deadline. If these are missing, ask before turning the idea into a commitment.
Draw a boundary around the work
Put included work beside explicit exclusions. For each deliverable, name the evidence someone will use to review it. 'Write five draft articles' describes output; 'reduce support demand' describes an outcome that still needs measurement. Do not promise one because you can deliver the other.
Show what the estimate depends on
Keep the source, units, exclusions, and uncertainty beside each estimate. Explain whether the proposed schedule starts after approval, source access, or another dependency. An available budget does not prove staff availability; a proposed duration is not a booked start date.
Make the decision smaller than the whole project
When the evidence supports only a pilot, propose that pilot and a later review. Show what the reviewer can approve, reject, or ask to revise. Do not quietly bundle a rollout into permission to explore an idea.
Review before asking for commitment
Have your agent create a static HTML page with the approval request first, followed by scope, deliverables, estimates, dependencies, and supporting evidence. Confirm the facts and audience. Keep the actual approval record in the agreed email or project workflow.
Adapt this to your work
Keep the same approach. Change the inputs and review checks for the job you need.
A business case for a bounded pilot
Make the benefit hypothesis, available baseline and next evidence checkpoint explicit. The case should explain why this is a useful learning investment, not manufacture a return-on-investment calculation from staff-hour estimates.
Fictional source notes: Fictional proposal: revise five support articles using 24 writer hours and 6 reviewer hours, both estimates. The intended benefit is clearer answers, but the support-demand baseline is missing. The proposed next checkpoint is a review of article quality and a plan to establish baseline demand before considering a larger rollout. Approval is pending.
A clearer result: Request the bounded 30-hour estimated pilot, not a full rollout. Label clearer answers a hypothesis. Show the missing baseline and proposed quality/evidence checkpoint. Do not monetize hours into savings or claim reduced support demand before measurement; the checkpoint and funding still require approval.
The matching instructions are included in the creation request below; your agent should use them only when relevant.
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 proposal for [decision owner] about [proposed work]. Ask only for missing essentials: the decision requested, scope and exclusions, deliverables and review criteria, resource estimates, dependencies, and approval process. Lead with exactly what I am asking them to authorize. Distinguish proposed work from approved work, estimates from commitments, and deliverables from expected outcomes. Preserve estimate units, sources, exclusions, and uncertainty. Do not invent available staff, savings, return on investment, approvals, dates, or acceptance criteria. If criteria are missing, list them as unresolved rather than making them binding. Explain what must happen before work starts and what would require a separate decision. Create readable static HTML with no scripts, forms, signature fields, or live-data claims. Use my saved artifact style if available. Keep sensitive evidence in my existing authorized tools; include only audience-safe details and links. Show me the draft and unresolved questions for review. Do not publish or change access without separate explicit approval. Keep the approval record in our existing email or project workflow. For a business-case version, state the supplied benefit hypothesis, baseline, evidence gaps and proposed checkpoint before a larger commitment. Keep benefits hypothetical until measured. Do not invent ROI, monetize staff hours without approved assumptions or convert a proposed checkpoint into an agreed approval condition.
04 / BEFORE YOU SEND
A polished page still needs your judgment.
- Is the exact phase and resource commitment being requested visible near the top?
- Are exclusions as clear as included deliverables?
- Are estimated cost, effort, and timing labeled accurately with their dependencies?
- Are acceptance criteria supplied facts or clearly unresolved—not invented commitments?
- Are expected benefits separate from measured outcomes?
- Does the page explain how to respond without pretending to collect approval?
When HTML fits
Use an HTML proposal when someone needs to understand the proposed commitment asynchronously, with a short opening and supporting detail below. Your agent can reuse authorized context without moving the project into another editor.
When another format fits better
Use the required submission template when procurement or a client mandates one. Keep negotiation, signatures, resource allocation, and the authoritative approval record in their established systems. A shared page does not authorize work or enforce contractual terms.
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 the same as a decision brief?
A decision brief helps compare options. A project proposal spells out the work and resources someone would authorize. If your reader only needs to choose between alternatives, use the decision-brief workflow instead.
What if we do not know the budget or schedule yet?
Label them unresolved, preserve any supplied estimate, and say what is needed to confirm it. You may propose a bounded discovery phase if that is genuinely the decision you want; do not turn uncertainty into a confident full-project quote.
Can someone approve the proposal on the page?
No. This is a static reading page, not a signature or approval system. Tell the reader to respond through your agreed email or project workflow.