The SprintProposal developmentPursuit memoryCaptureGraphicsGraduationCompareAboutResultsLearnDoPricingWorkbenchSecurityFAQBook a call →
‹ Learn

A prompt is not a wish.

It’s a set of instructions, and the output is only as good as they are. A great prompt won’t save bad inputs or a skipped review. A thin one guarantees a thin draft. Here’s the structure that fixes it.

You are the expert. AI is the tool.

You bring the strategy, the customer knowledge, the competitive context. The model brings speed and pattern-matching across long documents. A proposal pulls together capture intel, past performance, compliance, the technical approach, and pricing, written under a clock and judged by people you can’t talk to. No model has that context on its own. You do. Treat it like the fastest intern you’ve ever hired: brief it well, read every line, never let it sign the cover letter.

The five components

Every effective prompt has five parts, and they’re diagnostic. When a draft comes back generic, hallucinated, the wrong length, or the wrong voice, one of them was thin. Role: the perspective, tone, and assumptions. Context: everything relevant — the RFP text, the criteria, a tone sample. Task: what exactly you want, and how long. Format: your structure, which the model can’t guess. Constraints: the guardrails, like active voice, no invented facts, and flagging uncertainty with [VERIFY].

Default to conversation

A proposal is too complex for one prompt. The model does its best work the way a good writer does, after you’ve walked it through the RFP, the capture, and the tone you want. Do it across a few messages. Set the stage (“don’t draft yet, just confirm you understand each piece”). Feed the requirements, pasting the full RFP section with no paraphrasing. Provide your strategy. Then ask for the draft.

The context window is a workbench, not a dumping ground. Lay things out in order and the model can reason over how they relate. It also makes follow-ups cheap: “revise paragraph 2 to address sub-req (c)” costs ten seconds, not another full brief.

Build a prompt

For batch work and the templates you reuse weekly, a single-shot prompt is the fallback: same five parts, filled in. Load a proposal preset and edit it, or fill the parts yourself. {CAPS_IN_BRACES}are yours to replace. This assembles the instruction; it doesn’t run anything. Then run the output through PARC before it touches the draft.

Your prompt
Fill a field or load a preset — your prompt assembles here.
Same request, two ways.“Write a technical approach for a cloud migration for the VA” gets generic filler. “Write a 400-word technical approach for Section L.4.2, claims-processing modernization, for the VA; differentiator is production VistA experience; mirror RFP terminology; open with customer understanding; include a three-phase plan” gets something you can edit. The difference is context, task, format, and constraints.
Now go do

Take your worst recent prompt and rebuild it with all five parts. The thin one is almost always context (paste the full RFP, not your summary) or format (tell it your structure).

Sources & further reading
  • frwrd field notes — “The Prompting Guide for Proposal Teams” (APMP)the Role/Context/Task/Format/Constraints formula and the conversation method
  • NIST AI Risk Management Frameworkhuman-in-the-loop as the governing default

Or hand the whole thing to us.

Good prompting is a skill. If you’d rather not build it, we run the bid end to end: humans first, the tooling under our hand.

Book a call