Cowork RFP Response
Respond to an RFP the way a seasoned proposal manager does: decompose every requirement first, decide bid/no-bid honestly, reuse the best prior language, and never claim a capability the source documents do not support. Inputs: the RFP document and a folder of company material (past proposals, case studies, bios, certifications, pricing sheets).
Workflow
- Shred the RFP. Extract every numbered and implied requirement into a matrix: ID, requirement text (verbatim), type (mandatory/scored/informational), section owner, and any disqualifier ("must have X certification", "minimum N years"). Extract the logistics separately: due date, format, page limits, submission method, Q&A deadline, evaluation criteria and weights.
- Bid/no-bid check. Before drafting anything, report disqualifiers you cannot document from the company folder and requirements with weak evidence. Ask whether to proceed. This is the most valuable five minutes of the skill.
- Mine the folder. For each requirement, find the strongest supporting material: prior proposal sections, case studies with named results, team bios, certifications. Record source file and section in the matrix. Mark each requirement
STRONG(direct evidence),PARTIAL(adjacent evidence, needs framing), orGAP(nothing found). - Draft. Write the response following the RFP's mandated structure exactly. For
STRONGitems, adapt the best prior language to this client's context. ForPARTIAL, draft honest framing and flag it for review. ForGAP, insert a clearly marked[GAP: needs input -- suggested approach]block rather than fiction. - Compliance pass. Verify every mandatory requirement is addressed where the RFP says it must be, page/format limits hold, and required attachments are listed. Output
compliance-matrix.md(the full matrix with response locations) andrfp-response-draft.md. - Executive summary last. Write it after the body, leading with the client's stated problem in their own vocabulary and the 2-3 discriminators the evidence actually supports.
Rules
- Never invent capabilities, clients, metrics, or certifications. Every claim traces to a source file;
GAPblocks are the honest alternative. - Use the client's terminology from the RFP, not internal jargon. Evaluators score against their own words.
- Answer the requirement asked, not the adjacent one you have better material for -- then add the better material.
- Respect page limits from the first draft; cutting 40% at the end butchers the good sections.
- Boilerplate is a starting point, not a deliverable. Any reused paragraph must name this client and this context or it gets rewritten.
- Track questions for the Q&A window: ambiguous requirements go in a
questions-to-submit.mdlist, drafted in submission-ready form.
Quick Commands
- "Shred [RFP file]" -- requirements matrix and logistics only
- "Should we bid?" -- steps 1-3, the honest gap report
- "Full response with [folder]" -- complete workflow
- "Compliance check my draft" -- step 5 against an existing draft