send a proposal, not an attachment.
a proposal as a pdf is a dead end: it is stale the moment the scope shifts, it opens badly on a phone, and you cannot tell whether anyone read it.
a proposal as a page is a link. the agent writes the scope, outcomes, timeline, and pricing from your notes; htmlshare gives it a url you can send, update after the call, and point at again when it is time to sign.
same content, one less round of "here is v3 final revised.pdf".
what you are making.
01 / what it iswrite a branded client proposal with claude or chatgpt and publish it to a shareable url. no pdf attachment, no template subscription — one link you can update after the call.
see one in action.
02 / exampleentirely invented client and numbers, labeled as such. the structure is the part to copy.
copy this, then make it yours.
03 / starting prompta starting point, not a template — the point of an agent is that the result is yours. change the sections to match what you want, and remove anything you don’t need.
Create a polished, responsive client proposal for [CLIENT NAME] from [YOUR NAME / COMPANY].
Goal:
A proposal the client can read on a phone in three minutes and act on.
Content and requirements:
- Header: client name, project title, date, proposal validity period
- "The problem" — the client's situation in their own words, not yours. Two short paragraphs
- "What we'll do" — scope as concrete deliverables, each one a thing that either exists or
doesn't when the project ends
- "Out of scope" — say it explicitly; this section prevents more arguments than any other
- "Timeline" — phases with dates or durations, and what the client owes you at each one
- "Pricing" — [FIXED FEE / TIERS / RATE]. If tiers, three at most, with a recommended one
- "Terms" — payment schedule, revisions included, cancellation
- "Next step" — one specific action with a contact link
Design direction:
- [YOUR BRAND COLORS AND TONE]; confident and plain, not corporate filler
- Pricing legible without scrolling past it
- Mobile-first and accessible
- Clear hierarchy and fast loading
Delivery requirements:
- Produce one self-contained HTML file.
- Include CSS and JavaScript in the file where practical.
- Do not require a build step or server.
- Use placeholders where information is missing; do not invent facts — especially not
prices, dates, client details, or past results.
PUBLISHING
Publish the finished page to HTMLShare and give me the link.
Use exactly one of the two paths below, preferring the first. Make the call
directly. Do not route it through a code sandbox, container, or computer-use
session — that is where the request gets blocked, and it is never necessary.
1. An HTMLShare integration or connector, if you have one configured.
The page is permanent and owned by my account. Report the url and the
siteId. There is no claimUrl or manageToken on this path — do not go
looking for one, and do not switch paths in order to produce one.
2. Otherwise, publish anonymously over REST. No account, key, or signup is
needed:
POST https://api.htmlshare.net/v1/publish
content-type: application/json
{"html": "<!doctype html> ... "}
The reference is https://htmlshare.net/docs and, for the full schema,
https://api.htmlshare.net/openapi.json
Report these from the response, in your reply and never inside the page:
url the public page
claimUrl a private link that is mine alone. opening it is how I keep
the page past its 24-hour expiry, or set an email reminder
before it goes. it carries the manage token, so it must
never appear in the published HTML or anywhere a visitor
could see it.
manageToken the only thing that can edit or delete this page later. it is
returned once and never again, so tell me what it is.
Tell me which of the two you used. If the path you reach for first is
unavailable in your environment, say so and tell me what you are switching to
before you publish — a permanent page on my account and a 24-hour anonymous
page are different things, and which one I get is my decision, not a detail.
If I ask for a change afterwards, update the existing page instead of
publishing again, so the URL I have already shared keeps working — through the
same integration on path 1, or with the manage token as an X-Manage-Token
header on path 2.give it a url.
04 / publishing ithow you publish depends on how you’re working.
- claude
- paste your notes, let claude draft, then iterate in the same conversation — "make the pricing table three tiers", "cut the intro in half". with the mcp connector on, the final version publishes straight to a url and update_html keeps that url current through revisions.
- chatgpt
- ask for one self-contained html file, download it, and drop it on the htmlshare home page. re-uploading makes a new url, so if you expect revisions, publish with an account and update in place instead.
- cursor
- useful when the proposal is one of many: keep a proposals folder, let the agent copy the last accepted one as a starting point, and publish each with an api key.
- grok
- writes the page and publishes it over rest with no signup, which is the shortest path from notes to a url. expect it to tell you no htmlshare connector is available in its environment and publish anonymously — that works, but the page expires in 24 hours and the reply carries a claimUrl. keep that link and claim the page before you send the url to anyone: a proposal sitting in a client's inbox should not go dark overnight. if it says publishing is blocked, it is usually trying to make the call from a sandbox rather than directly.
temporary is fine for trying it.
05 / keeping it aroundfine for trying the idea out. anonymous pages stop serving after 24 hours, and are recoverable by their creator for 7 days after that before deletion.
if you are going to use it past this week, publish it from your htmlshare account so it stays at one url you can keep.
- stable updates
- the scope changes after the call. the client should re-open the same link and see the new version, not hunt for a newer attachment.
- custom slug
- yourname.htmlshare.net/acme-proposal reads like your work. a random id reads like a file host.
- password
- pricing is the one part of your business you would rather not have indexed.
- analytics
- knowing the proposal was opened twice on a monday morning is worth more than the follow-up email you would otherwise send blind.
questions.
06 / questionscan the client sign it?
not on the page — htmlshare publishes documents, it does not do signatures. the usual pattern is a proposal link plus whatever you already use to sign.
what if i need it as a pdf too?
print to pdf from the browser. ask the agent for print styles in the prompt and it will come out cleanly.
is it private?
a published page is reachable by anyone with the url, and htmlshare noindexes uploaded pages so they stay out of search. for a proposal with real pricing, use a password.