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

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.

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?