Use this skill when writing proposals, responding to RFPs, drafting SOWs, or developing pricing strategies. Triggers on proposal writing, RFP response, statement of work, pricing strategy, win themes, executive summary, and any task requiring business proposal creation or optimization.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
Instruções da origem · Visualização somente leitura
name
proposal-writing
version
0.1.0
description
Use this skill when writing proposals, responding to RFPs, drafting SOWs, or developing pricing strategies. Triggers on proposal writing, RFP response, statement of work, pricing strategy, win themes, executive summary, and any task requiring business proposal creation or optimization.
Lead with their problem, not your solution - The first thing the evaluator
reads must prove you understand their situation. Before a single word about your
capabilities, reflect their pain, their constraints, and their desired outcome
back to them. A proposal that opens with "We are a leading provider of..." loses
immediately.
The executive summary is the whole proposal in miniature - Many decision-makers
read only the executive summary. It must contain: the problem, your solution, the
key differentiators, quantified value, and the call to action. Nothing else belongs
in the executive summary. Treat it as a standalone document that can win the deal alone.
Quantify everything - Claims without numbers are noise. "We reduce costs" is
forgettable. "Clients average 23% reduction in operational costs within 90 days" is
memorable and verifiable. Every benefit claim needs a number, a timeframe, or a
named reference. If you don't have the number yet, find it before submitting.
Tailor, don't template - Evaluators can smell a recycled proposal. Use the
buyer's exact language from their RFP. Mirror their terminology, their priority
order, their section structure. Customize every named example, case study, and
metric to their industry. A proposal that reads like it was written for someone
else is a proposal that loses.
Price to value, not cost - Pricing anchored to your internal cost signals
commodity thinking. Price instead to the value the buyer receives - the problem
solved, the risk removed, the revenue gained. Present pricing in a way that makes
the investment obvious relative to the return, not relative to your delivery cost.
Core concepts
Proposal structure
A winning proposal follows a buyer-centric arc:
Cover letter - One page. Personal, direct, references a specific insight
about the buyer. Signed by a named executive.
Executive summary - 1-2 pages. Problem, solution, value, differentiators,
call to action. Never a table of contents or a company history.
Understanding of requirements - Demonstrate you have read and internalized
the RFP. Restate the buyer's goals in your own words, adding nuance they may not
have articulated.
Technical / solution approach - How you will solve the problem. Organized by
the buyer's priorities, not your delivery methodology.
Management approach - Team, governance, escalation, communication cadence.
Past performance / case studies - Proof that you have done this before for
comparable clients. Each case study should mirror the buyer's situation.
Pricing - Transparent, tied to deliverables, easy to evaluate.
Win themes are the 3-5 central messages that differentiate your proposal from every
competitor. They are not generic strengths ("we are experienced"). They are specific,
verifiable, and tuned to this buyer's stated and unstated priorities.
Example: "Our pre-built integration layer cuts the buyer's go-live risk because all
data migrations complete in under 72 hours - demonstrated in all 14 of our last
implementations."
Every section of the proposal should reinforce at least one win theme. Win themes
should appear in the executive summary, in section headers (as "ghosting"), and in
the conclusion.
Compliance matrix
For formal RFPs, a compliance matrix maps every stated requirement to the section of
your proposal that addresses it. It serves two purposes: it proves you read the entire
RFP, and it makes the evaluator's scoring job easier. Use "Compliant," "Partially
Compliant," or "Exception" for each row. Never leave a row blank.
Format:
RFP Section
Requirement
Compliance
Proposal Location
3.1.2
System uptime >= 99.9%
Compliant
Section 4, p. 12
3.2.1
SOC 2 Type II certification
Compliant
Appendix C
Pricing models
Model
Best for
Risk to seller
Risk to buyer
Fixed price
Well-scoped, low-change projects
Scope creep
Low
Time and materials
Exploratory, R&D, unclear scope
Overrun budget
High
Not-to-exceed (NTE)
T&M with a budget ceiling
Scope creep above ceiling
Medium
Retainer
Ongoing advisory or support
Underutilization
Overpaying
Value-based / outcome
SaaS, results-tied engagements
Delivering without payment
Low
Milestone-based
Long multi-phase projects
Cash flow gaps
Delivery risk
Common tasks
Write an executive summary
Use this template structure (expand each section to 2-4 sentences):
[PROBLEM STATEMENT]
[Buyer name] faces [specific challenge] which is causing [quantified impact].
Without action, [consequence].
[PROPOSED SOLUTION]
[Your company] proposes [solution name], a [brief description] that [primary outcome].
[KEY DIFFERENTIATORS - 2-3 bullets]
- [Win theme 1 with proof]
- [Win theme 2 with proof]
- [Win theme 3 with proof]
[VALUE / ROI]
Based on [reference or assumption], [buyer name] can expect [specific measurable outcome]
within [timeframe], representing [ROI or value statement].
[CALL TO ACTION]
We are prepared to begin [next step] on [date]. [Named contact] is available at
[contact] to discuss any questions before [decision date].
Rules:
Maximum 1 page for deals under $500K; 2 pages for larger engagements
Never start with a sentence about your company's history or size
Every claim must be backed by a number or a named customer
End with a specific next step and a date
Respond to an RFP systematically
Follow this workflow:
Shred the RFP - Read it end-to-end. Highlight every explicit requirement,
every evaluation criterion, and every implicit signal about what the buyer values.
Build the compliance matrix - List every requirement before writing a word.
Identify win themes - Based on evaluation criteria and your differentiators,
choose 3-5 win themes. Write them in one sentence each.
Create the outline - Mirror the RFP's structure exactly unless instructions
say otherwise.
Write section by section - Draft technical approach first (most complex),
then past performance, then management, then executive summary last.
Ghost win themes - Review each section. Every section header and opening
sentence should reinforce a win theme.
Red team review - Read it as the evaluator. Score yourself against the stated
criteria. Fix any section below the threshold.
Final compliance check - Walk the compliance matrix. Confirm every row has a
location in the proposal.
Draft a statement of work
A SOW defines what will be delivered, by when, at what cost, and what is out of scope.
Vague SOWs cause disputes. Every clause should pass the "measurable and observable" test.
Required sections:
Purpose and background - 1 paragraph. Why this work is being done.
Scope of work - Bullet list of deliverables. Each deliverable must be a noun
(a thing), not a verb (an activity).
Out of scope - Explicit list of what is excluded. This is as important as scope.
Deliverables and acceptance criteria - For each deliverable: format, deadline,
and the objective criteria by which the buyer will accept or reject it.
Timeline and milestones - Table of milestone, date, and deliverable.
Roles and responsibilities - RACI or equivalent. Who does what.
Assumptions - List every assumption embedded in the scope or price. Each
assumption that proves false is a change order.
Change management - How scope changes are requested, estimated, and approved.
Payment terms - Tied to milestones or calendar dates.
Develop pricing strategy
Work through these questions before setting a number:
What is the measurable value to the buyer? (revenue gained, cost saved,
risk reduced, time saved)
What would it cost them to build this themselves? (make vs. buy anchor)
What are competitors likely to price? (market anchor)
What is your floor? (cost + minimum margin)
Which pricing model fits the risk profile? (see pricing models above)
Present pricing with three options when possible:
Option
Scope
Price
Best for
Core
[minimum viable scope]
$X
Budget-constrained buyers
Recommended
[full scope]
$Y
Buyers who want the outcome
Premium
[full scope + additions]
$Z
Buyers who want certainty/speed
This structure anchors the buyer to the middle option and prevents lowest-price
anchoring. Always recommend one option explicitly.
Create win themes
Step 1 - Extract evaluation criteria from the RFP. Rank them by weight.
Step 2 - List your 5 strongest discriminators (things you can prove that competitors
cannot easily claim).
Step 3 - Map discriminators to evaluation criteria. The overlaps become win theme candidates.
Step 4 - Write each win theme using the formula:
[Discriminator] + because + [buyer benefit] + [proof point]
Step 5 - Test each theme: Is it specific? Is it provable? Does it address a buyer
priority? If any answer is no, rewrite or discard.
Step 6 - Weave each theme into the proposal: executive summary, section openers,
past performance selection, and conclusion.
Write a technical approach section
Structure:
Restate the technical challenge - Show you understand the complexity.
Solution overview - 1-2 paragraphs. What you will build/do and why this
approach is right for their situation.
Methodology / process - Step-by-step. Use a visual (phased diagram, swim lane)
if allowed. Match phase names to the buyer's own language.
Key technical decisions - Explain 2-3 architectural or methodological choices
and why you made them (not just what they are).
Risk mitigation - Name the top 3 technical risks and your mitigation for each.
This demonstrates maturity and builds trust.
Staffing - Who will do the work. Named leads when possible.
Avoid: generic methodology descriptions that could apply to any project. Every
paragraph should contain something specific to this buyer's environment or requirements.
Build a compliance matrix
For each RFP section, create a row. Columns:
RFP Section
Requirement text (verbatim)
Compliance status
Proposal section
Notes
Compliance status options:
Compliant - Requirement is fully met as stated
Compliant with clarification - Met, but with a noted condition
Partially compliant - Met in part; explain the gap
Exception - Not met; explain why and what you offer instead
Not applicable - Requirement does not apply to your solution
Submit the compliance matrix as an appendix. Reference it from the executive summary.
Anti-patterns / common mistakes
Mistake
Why it loses
What to do instead
Company-first opening
Evaluators skip it; signals seller-focus not buyer-focus
Open with the buyer's problem in their own words
Undifferentiated win themes
"Experienced team" and "proven process" describe everyone
Tie each theme to a specific proof point unique to your firm
Scope without exclusions
Missing out-of-scope clause turns every ambiguity into a dispute
Always include an explicit out-of-scope list in every SOW
Single price option
Creates lowest-price anchoring; leaves budget on the table
Present three tiers; recommend the middle one explicitly
Recycled case studies
Evaluators notice industry and scale mismatches; signals laziness
Use case studies within 2x of the buyer's size and same industry
Vague acceptance criteria
"Deliverable approved by client" is not a criterion
Define acceptance as observable, measurable outcomes with deadlines
Gotchas
Executive summary written last and rushed - Because the executive summary comes first in the document, teams often write it last under time pressure. But evaluators who read only the exec summary decide the proposal's fate. Draft the exec summary early as a forcing function to align the entire proposal narrative, then refine it last.
Win themes that describe you, not the buyer's benefit - "25 years of experience" and "proven methodology" are company-centric claims. A win theme must end with a buyer benefit and a proof point, not stop at the discriminator. Apply the formula explicitly: discriminator + because + buyer benefit + proof.
SOW scope without an explicit out-of-scope list - Every ambiguous item not excluded in the SOW will eventually become a disputed change order. When drafting a SOW, explicitly list what is excluded. The out-of-scope section is as legally important as the scope section.
Compliance matrix built after writing - Building the compliance matrix retroactively means gaps are discovered late and addressed with retrofitted language. Build the matrix first from the RFP, then write to fill every row.
Single pricing option presented - A single price creates a take-it-or-leave-it dynamic and anchors the buyer on your lowest number. Always present three tiers and explicitly recommend the middle one; this shifts the framing from "should we buy?" to "which option fits us?"
References
For detailed templates and worked examples, read the relevant file from references/:
references/proposal-templates.md - SOW template, executive summary template,
pricing table template with worked examples
Only load a references file when the current task requires a complete template or
worked example.
Companion check
On first activation of this skill in a conversation: check which companion skills are installed by running ls ~/.claude/skills/ ~/.agent/skills/ ~/.agents/skills/ .claude/skills/ .agent/skills/ .agents/skills/ 2>/dev/null. Compare the results against the recommended_skills field in this file's frontmatter. For any that are missing, mention them once and offer to install:
