codel
← Back to the index

WRT-02 · SEC. 05 Content & Writing

Proposal Draft From a Short Brief

Turn a short project brief into a structured client proposal or RFP response draft.

FORMAT
workflow
DIFFICULTY
intermediate
TIME
20 min
TOOLS
universal
MODELS
any
COPIES
0 so far

When to use this

A prospect sent you a brief or RFP and you need a first-draft proposal fast, with the right structure, before you spend real time customizing the specifics.

The pattern

Pastes as plain text
Step 1: Generate the skeleton.
"Outline a proposal from a client brief, with these sections: Problem
Understanding, Approach, Scope, Timeline, Investment. For each section,
write 2-3 bullet points of what should go there based on the brief. Do
not write full prose yet. First ask me to paste the brief, then wait.
Don't start until you have it."

Step 2: Review the outline. Correct any misread requirements or add
missing constraints (budget ceiling, hard deadline, must-have tech).

Step 3: Expand to full draft.
"Expand the outline from step 1 into a full proposal draft. Problem
Understanding should mirror the client's own language back to them,
proving we listened. Approach should explain the 'how' in plain
language, no jargon. Scope should be a bulleted list of concrete
deliverables, not vague promises. Timeline should use relative phases
(Phase 1, Phase 2) not fixed dates unless I gave you a start date. For
the rate and start date, write 'TODO: rate' and 'TODO: start date' so I
can fill them in myself."

Step 4: Read the draft against the original brief line by line.
Confirm every stated requirement is addressed somewhere in Scope.

Real example output

"Problem Understanding: You're maintaining two separate checkout flows for web and mobile, and every pricing change means updating both, which is where last quarter's discount bug came from. Scope: Unify checkout logic into a single shared service. Migrate web checkout to consume it. Migrate mobile checkout to consume it. Add a test suite that catches pricing mismatches before deploy."

Why it works

Generating the skeleton first lets you catch misread requirements before the model burns effort writing full prose around a wrong assumption. Mirroring the client's language in Problem Understanding is what makes a proposal read as heard rather than templated.

Related patterns

Entry WRT-02 · by codel · 2026-07-08 · CC-BY-4.0