sales-proposal-drafter

What problem does it solve?

Draft professional client proposals using vault context, past proposals for tone matching, and client history. Creates proposal documents ready for review and customization before sending.

Core Features & Use Cases

• Extract parameters — Parse from user input:

  • Client name
  • Project scope (what will be delivered)
  • Deliverables (list of outputs)
  • Timeline (project duration, milestones)
  • Pricing (if provided; if not, note as TBD)

• Load client context — Run:

  cat ~/.second-brain/vault/clients/<client-slug>.md
  

  Extract: company, contact info, past engagements, relationship strength, budget awareness

• Pull product details — From PRODUCTS.md (in session context), extract the relevant product's description, key features, pricing model, and competitive edge to include in the proposal.

• Search similar past proposals — Run:

  Use the `search_memory` MCP tool with query: "proposal template scope deliverables"
  

  Find similar past proposals to match tone, structure, and language patterns

• Search past client emails — Run:

  Use the `search_emails` MCP tool with gmail_query: "from:<client-email>"
  

  Extract communication style, terminology they use, concerns they've raised

• Generate structured proposal with sections:

  • Executive Summary
  • About [Client]
  • Proposed Scope
  • Deliverables
  • Timeline
  • Investment
  • What's Included vs. Out of Scope
  • Next Steps
  • Terms

• Match tone and style — Use language from past emails and similar proposals to match your communication style with this client

• Save proposal to:

  ~/.second-brain/vault/sales/proposals/YYYY-MM-DD-<client-slug>-proposal.md
  

• Optionally create Gmail draft — Run:

  Use the `draft_email` MCP tool with to, subject, and body
  

  Draft email never sends — user reviews and clicks send manually

• Log to daily log:

  • HH:MM — [SALES] Proposal drafted: <client-name> — $<value> (<timeline>)

Rules

• Always mark pricing as "Estimated" or "TBD" if not finalized — never guess
• Include explicit "Out of Scope" section to prevent scope creep
• Keep proposal to 1-2 pages (with optional appendices for detailed T&Cs)
• Match writing style to client email tone (formal vs. casual)
• If client has rejected proposals before, research why and address concerns
• Never include proprietary competitor names unless necessary for differentiation
• Use client's own language and terminology from their emails
• Pricing: if multi-phase, show per-phase breakdown and total
• Cross-reference to client file using [[wiki-links]]
• Product details in proposals must match PRODUCTS.md — never invent features or pricing.

Templates

Use this structure for proposal file:

[template content]

• Cloud memory: After completing this workflow, call the log_note MCP tool with a one-line summary of what was done. Example: log_note("Completed eng-plan for School Cab — 9 phases, 22 days")

• Cloud memory: After completing this workflow, call the log_note MCP tool with a one-line summary of what was done. Example: log_note("Completed eng-plan for School Cab — 9 phases, 22 days")

Quick Start

Provide the client name and project scope to generate the initial proposal draft.