A proposal that reads itself as the buyer

A render-verify receipt tells you a document is well made. Every sheet fits, no footer moved, the PDF has as many pages as there are sheets. It says nothing about whether the person receiving it will believe a word of it.

So a proposal came back from a human review last week with a list that no renderer could have produced. A closing line that invited a no. A projected saving nobody could source. A dashboard full of invented numbers. A roadmap sheet that read like a scope commitment. A second buyer at the same client sent a -v2 of a document the first buyer had already seen.

Every one of those is a rule. None of them is a rendering bug.

The red team

red_team_document reads a rendered document sheet by sheet as the sceptical operations lead who has to carry it into an internal business case without you in the room. It returns numbered findings — the sheet, the rule broken, what they actually read, the fix — graded three ways:

• block — this does not get sent.
• fix — it costs trust.
• consider — a judgement call, left to a person.

The house rubric asks the questions a buyer asks. Does every number, name, date and quote trace to a decision log or a starred source, or did the model produce it? Is there a promised outcome anywhere, when what we commit is a capability and a measurement? Are the unknowns visible as placeholders, or quietly guessed? Is the scope unmistakable, is the commercial shape clear, does any line argue against the offer? And the register: no constructed contrasts, no consultant jargon for the client's own world, no aphorisms.

The rubric is text, so a workspace replaces it with its own. The banned phrases come from voice.yaml automatically, because a workspace already declared them there.

A document is ready when the verify receipt is clean and the red team has no blocks.

The spine

The other half of the problem is that the writer had a framework but no shape. The skill now carries the twelve sheets that have closed: the cover, what you are buying, one product per sheet, measurement, the month-by-month plan, what the service means, investment, what the client brings and what this does not touch, the questions their colleagues will ask, and the appendix of what comes later marked out of scope. Each entry says what that sheet must carry and which components it uses. Fewer sheets when one has nothing to say; never two ideas on one.

Beside it, a rule for visuals. A sheet earns one when the reader has to picture something they have never seen or hold several things at once. Otherwise it is a sentence. Every interface mock carries a caption saying it is illustrative, and no dashboard in a proposal shows a performance number, because we do not publish projected results.

And one rule that does more work than the rest: nothing on a sheet is invented. Before the first sheet, the room's newest call is filed with a numbered decision log — what a person actually said, in their words — and every sheet traces to a line in it. A claim with no line behind it is a placeholder and an open item, not a sentence.

It learns from every correction

Feedback on a proposal generalises more often than most feedback. A cut phrase, a rejected commercial shape, a finding that comes back on a second document — those are almost never about one client.

So the Proposal Writer now declares its own learning step, proposal-feedback. Every review decision on a proposal and every correction someone makes in chat files a candidate there. A person adopts or rejects it, as always. Adopted rules mount into the writer's context before the first sheet of the next proposal, and they win where they disagree with the skill.

The test the writer applies to a correction is one line: would this apply to the next client's proposal? Then it is a rule, not an edit.

The step ships seeded with four rules that came out of a real document's red team, including the two that a renderer will never catch: a proposal assumes the yes, and the email carrying it names no dollar figure.

What stays out of the plugin

Everything true of one seller. The name of your offer, your pricing shape, what happens at the end of the term, the concession you will make and what earns it, your ownership paragraph, how you name a file, who signs. That is a playbook on your own writer, in your own workspace — a page of markdown, patched on with extends: core.

The plugin ships the framework, the spine and the critic. The workspace ships the house.

Turn it on with plugins: [proposals], or from the Marketplace. It depends on data rooms, and turning it on turns that on.