proposal-writer

---
name: proposal-writer
description: >
  Write a consulting or service proposal. Trigger on "write a proposal", "create a quote", "draft a SOW", "scope of work", "put together a proposal", "pricing for", "engagement letter", or any variation of creating business proposals, quotes, scoping documents, or service agreements. Also fires when the user describes a potential client engagement and needs it formalized. Reads `core/voice-profile.yml`, `core/brand-profile.yml`, and any relevant company context (operator path `companies/<slug>-business.md` first, prospect path `companies/prospects/<slug>.md` second).
why: "Builds proposals that reflect the specific prospect's situation rather than a generic template - a proposal that mirrors the client's own words wins more than one that describes the service."
enhance: "Fill context/clients.md with scoping notes before running - the more prospect-specific context you provide, the stronger the Situation section, which is where most proposals lose."
allowed-tools: ["Read", "Write", "Edit", "Bash"]
mcp_requirements: []
---

# Proposal Writer

Runs on: reasoning - reads your files and reasons; any capable agent can run this.

The proposal must reflect the founder's voice, brand, and the specifics of the prospect. It must not sound like a template.

## Voice routing (operator or brand?)

Apply the routing rules in `skills/your-voice/SKILL.md`. Default to operator voice for personal proposals. If the proposal is FROM a brand the operator runs (e.g. an agency, a productized service), use brand voice from `brands/<slug>/voice.yml` and brand visual from `brands/<slug>/visual.yml` if present.

## Before producing output

**Every number in a proposal is a claim the buyer can check.** A wrong one costs more than a weak sentence, because it reads as carelessness about their money. `rules/research-integrity.md` governs them: any figure that did not come from the client's own mouth or a document you hold carries a tier tag in the working draft - `[MEASURED]`, `[SOURCED: url + date]`, or `[ESTIMATE: assumption]`. Benchmarks and "businesses like yours typically see X" are the dangerous class: either the claim carries a live source, or it gets rewritten using the client's own numbers. Never quote a person or a publication without a retrievable link and date.

The finished proposal resolves those tags into plain prose ("our estimate, assuming X"), but only after the tagged draft has passed `python scripts/claims_check.py <draft>`.

If using operator voice, run: `python scripts/check-voice-ready.py`
If using brand voice, run: `python scripts/check-brand-voice-ready.py --brand <slug>`

If exit code is 1, read the output line and surface it to the user verbatim. Do not produce any draft. Stop.

If the user explicitly chooses to proceed with defaults after seeing that message, write with the universal anti-AI baseline and clearly label that the voice profile was not applied.

Then read in this order:

1. The chosen voice profile (operator: `core/voice-profile.yml`. Brand: `brands/<slug>/voice.yml` + `brands/<slug>/positioning.yml`).
2. The chosen visual brand (operator default: `core/brand-profile.yml`. Brand: `brands/<slug>/visual.yml` if present). Governs any branded version of this proposal (PDF, DOCX). For plain-text proposals, this is optional.
3. **Company-specific context (two-path check).** Look for the prospect or client at:
   1. `companies/<slug>-business.md` (operator path - the company you run, if this proposal is going out from a brand you operate to a related entity)
   2. `companies/prospects/<slug>.md` (prospect path - the company you are selling to)

   Prefer the operator file if both exist. If neither exists and the engagement is with a tracked prospect, surface a one-line note offering to run the `prospect-init` flow to capture the minimum context before drafting. Proceed with generic output if the user declines.
4. Any prior scoping notes the user points you at.
5. `brain/knowledge/` - topic notes relevant to the deal type, buyer pain, industry, proof points, or prior wins. Read frontmatter and top headings first. Do not hard-parse full bodies unless the user asks.

If a `your-deliverable-template` skill is available and this proposal is going out as a branded document, route through it for consistent visual identity.

If the user wants a plain-text proposal (email, Google Doc, plaintext), skip the brand step.

After producing a draft and before returning it, run the anti-examples filter:

1. Read the `anti_examples.pairs` block in `core/voice-profile.yml`.
2. For each line in your draft, scan for matches against any `bad:` pattern (literal substrings, structural markers like negation-contrast, or rule-of-three lists).
3. If a line matches, rewrite it using the `good:` pattern as the model and the `rule:` line as the constraint.
4. Also reject any line that uses an `aesthetic_crimes` phrase or a `red_flags` pattern.
5. Return the cleaned draft.

Do not surface this filter to the user as a separate step. The user sees only the cleaned draft.

Before drafting, read `brain/.snapshot.md`. If it is missing, or its `date:` line is more than 3 days old, run `python scripts/brain-snapshot.py --write` first and read the fresh one - a stale snapshot read as current presents last week's flags and must-dos as today's, which is worse than no memory at all. If Python is unavailable, proceed without it and say so. Use the open-flags block to avoid topics that contradict current operator stance. Use the must-do block to lean the draft toward what the operator is actively working on. Use the voice and brand blocks (if present) to set tone. The freshness check above is not optional: skipping the regeneration and reading a week-old snapshot is the one way this block makes output worse.

## Core Philosophy

- **Show the problem before the solution.** The prospect should see their situation reflected back accurately before you propose anything.
- **Translate symptoms to money.** Don't leave a pain point as a feeling. Connect it to a P&L line item, a hiring cost, a delay, a missed sale, a churned client. If a symptom appears in the proposal without a financial or operational translation, the proposal is incomplete.
- **Specificity builds trust.** Vague proposals lose. Name the roles, the processes, the timelines, the deliverables.
- **Price with confidence.** No apologetic pricing. No "we can discuss." State the investment clearly. If the founder genuinely needs to gather more information before pricing, scope the diagnostic phase and price that, not the full engagement.
- **Don't quote what you haven't diagnosed.** If the engagement has multiple phases, quote the first phase only. Subsequent-phase pricing comes after the first phase reveals what's actually needed.
- **Information ownership is the prospect's.** Add a line: "This document is yours regardless of whether we work together." It signals that the value is in the execution, not in the document.

## Currency Rule

Read the founder's identity or business context for their default currency. Use the currency that matches the engagement geography: EUR for Europe, GBP for UK, INR for India, USD for international, AED for UAE/GCC - or whatever the client's country uses. If unclear, ask the user before writing the price.

## Proposal Structure

```
PROPOSAL: [Engagement Title]
Prepared for: [Client Name, Company]
Prepared by: [Founder Name, Title - Company]
Date: [Date]

---

1. SITUATION
[2-3 paragraphs reflecting the prospect's current state. Show you understand the problem. Every symptom mentioned must connect to a financial or operational consequence. Mirror, not critique.]

2. WHY THIS COSTS MORE THAN IT LOOKS
[Translate 2-3 key symptoms into financial terms. Make the cost of inaction visible.]

3. PAST WINS TO REFERENCE
[Relevant prior notes from `brain/knowledge/`, if any. Name the topic, not private details. If none matched, write "No knowledge notes matched the terms searched (<terms>). If notes on this topic exist under another name, say the topic and I will read it directly, or run /founder-os:brain-pass."]

4. WHAT WE'LL DO
Phase 1: [Phase name and duration]
-> [Deliverable 1]
-> [Deliverable 2]

[Subsequent phases described in scope terms only, not quoted. "Pricing for subsequent phases will be based on Phase 1 findings."]

5. WHAT YOU'LL HAVE WHEN WE'RE DONE
[Tangible outputs. Things they can hold, use, share with their team.]

6. TIMELINE
[Week-by-week or phase-by-phase breakdown.]

7. INVESTMENT
[Phase 1 pricing only. Clear amount. No "starting at" or ranges unless that's genuinely how the founder prices.]

8. WHAT WE NEED FROM YOU
[Client responsibilities. Time commitment. Access requirements.]

9. ENGAGEMENT TERMS
[Standard terms - see Engagement Terms section below.]

10. NEXT STEPS
[Initiation flow.]

---
Valid for 14 days from date of issue.

This document is yours regardless of whether we work together.
```

## Pricing Patterns

The founder may use different pricing approaches. Help them pick one that fits the engagement. Three common patterns:

**Fixed-fee phase pricing.** A clear number for the first phase. No hourly billing surprises. Best for diagnostic-style engagements or well-scoped work. Pair with a money-back-on-no-findings guarantee where appropriate.

**Reverse pricing (faster = higher).** Two or three options where shorter timelines cost more. Signals confidence and rewards urgency. Example: 1-week intensive at premium, 2-week standard at base. Use only if the founder can genuinely deliver faster with more focused attention.

**Retainer or part-time embedded.** Committed hours per week or month at a fixed rate. Best for ongoing advisory or fractional engagements. Be specific about what hours include and what counts as out-of-scope.

If the user hasn't told you which pattern to use, ask.

## Risk Reversal (Recommended)

If the engagement model supports it, include a guarantee tied to a measurable outcome - not a generic satisfaction guarantee. Examples:

- "No P&L outcomes identified in Phase 1? Full refund."
- "No working prototype delivered by week 4? You pay 50%."
- "If we don't hit [specific metric], we work to fix it on our time, not yours."

Tie the guarantee to something the prospect can verify. Avoid vague satisfaction promises.

## Engagement Terms (Recommended Standard Block)

Adapt to the founder's positioning. A common pattern:

### NDA Framing
The CLIENT initiates the NDA / NCC / NCA. Frame it as protecting THEIR data, not as the founder's requirement:

"During this engagement, you'll be sharing sensitive information about your suppliers, pricing, customers, and internal operations. We ask that you initiate a mutual NDA to safeguard your proprietary information."

This positions the founder as professional and the prospect as the party with information to protect.

### Information Ownership
"This document is yours regardless of whether we work together."

Include on every proposal. The value is in the execution, not in the proposal.

### Founder-specific clauses
The founder may have non-negotiable values they want surfaced in every engagement (no headcount-reduction clauses, ethical-sourcing clauses, exclusivity terms, etc.). If `core/identity.md` or `rules/operating-rules.md` calls these out, include them. If unclear, ask the founder which standard clauses they always include.

## Initiation Flow

Include in Next Steps. A typical flow:

1. Email intent to proceed to [founder's email]
2. Client sends mutual NDA / NCC / NCA
3. Both parties sign
4. Account details shared
5. Payment within 48 hours
6. Engagement begins the following week

Adjust based on the founder's actual operating cadence.

## Writing Rules

- Simple hyphens (-) not em or en dashes
- Arrows (->) for deliverable lists
- No jargon unless the client speaks that language
- No superlatives ("best-in-class", "world-class")
- No filler paragraphs about the founder's history - the proposal is about the prospect
- Numbers and specifics wherever possible
- Follow `your-voice` and the universal anti-AI baseline for all written content

## Challenge the scope before you write it

The expensive failure in a proposal is not a weak sentence. It is a scope that
was never questioned, priced, agreed, and then found to be the wrong work in
week three. Before drafting, stress-test what you were handed.

1. Say the engagement back in one sentence: who, what changes for them, by when.
   If you cannot, you do not have enough to write a proposal yet.
2. Name the one thing this client will push back on hardest. The price, the
   timeline, the assumption that their team has capacity, the dependency on data
   they have not shown you. Name the real one, not the safe one.
3. Name what is missing that would change the shape of the work if it turned out
   differently.
4. Ask exactly one question. The one whose answer changes the proposal most.
5. Wait. Then write.

This is not a delay. A proposal written on a premise the client rejects in the
first meeting costs a week; a question costs a minute. Skip it only when the
founder has already answered that question in the brief.

## What to Ask the User

If context is thin, ask:
1. Who is this for? (Name, company, size, industry)
2. What problem are you solving for them?
3. What's the scope? Phase 1 only, or full engagement?
4. Any specific timeline discussed?
5. What pricing pattern - fixed phase, reverse, retainer?
6. Currency?
7. Has a discovery or scoping conversation already happened? Where are those notes?

If the founder hasn't specified pricing, propose one number based on the work involved and ask them to confirm before producing the final document. Never quietly invent prices.

**No money ask before permission.** A proposal with a price asks the buyer for money. If the founder's files and this conversation do not show they may take money for this activity where they sell (a licence or permit that covers it), ask once before putting a price in, and write the proposal without one meanwhile. Earlier sales to friends are not that permission. This repeats the founder safety rule in `CLAUDE.md` for surfaces where that file is not loaded.

## Self-check before delivery

1. Does the SITUATION section sound like the prospect could read it and say "yes, that's us"?
2. Are the costs of inaction quantified, not implied?
3. Are deliverables specific and tangible?
4. Is the price stated clearly without softening language?
5. Did you apply the founder's voice? (No corporate-AI tone.)
6. Did you scan `brain/knowledge/` for relevant prior notes or wins?
7. No banned words, no em dashes, no rule of three?
8. Does the proposal close with a clear next step the prospect can take in under 5 minutes?