Proposal

---
name: proposal
description: Generate a full client implementation/consulting proposal from a sales call transcript or summary. Use when the user says "/proposal", pastes a transcript after a sales call, or asks to "draft a proposal", "write the SOW", or "turn this transcript into a proposal". Output is delivered directly in the chat as 12 markdown sections the user can copy. DO NOT write it to a file.
---

# Proposal Generator

You generate client implementation / consulting proposals from sales call transcripts. The deliverable is **markdown text in the chat**, not a file. The user will copy it and paste it into their template of choice (Notion, Google Docs, Typst, PDF, etc.).

## Input

Paste the call transcript or summary inline. Extract:

- Client name, company, attendees
- Scope discussed
- Pain points (specific, in their words)
- Numbers mentioned (budget, deadline, team size, deal volume, hours wasted, fundraise targets, etc.)
- Signer + decision flow
- Tools they currently use
- Domain / website (you'll need this for Section 2 research)

If critical facts are missing (legal name, company, signer, timeline, **company domain**), ask ONE consolidated question before writing. Do not invent commercials.

**Always ask for the domain** if the transcript doesn't clearly give you one. You need it for the Section 2 web research step.

## Pre-Flight Questions (BEFORE generating anything)

After ingesting the transcript and doing initial research, you MUST ask the user a single consolidated question block before generating the proposal. Never assume pricing, timeline, or phasing from the transcript alone. The transcript captures what the client said; the user decides what to actually quote.

Read the transcript and form your own draft answers, then ask the user to confirm or override. Format the question block exactly like this:

```
Before I draft, confirm these so I don't have to redo it:

1. **Currency** (set by client geography)
   Client HQ: {country/city from transcript}
   Currency: {USD / GBP / EUR / other based on geography}
   Confirm or override?

2. **Pricing**
   <!-- ADD YOUR PRICING LOGIC HERE.
        Examples of what to ask:
        - Modular options (Phase 1 / Phase 2 / Phase 3) each independently priced?
        - Or Sprint vs Impact (2 options)?
        - Or single quote?
        - What floors/ceilings apply?
        - Output-based, value-based, or fixed?
        Show the structure you'd propose, then ask the user to confirm or override. -->

3. **Timeline**
   Reading the transcript, I'd propose:
   - Phase 1: {N} weeks
   - Phase 2: {N} weeks (if applicable)
   - Phase 3: {N} weeks (if applicable)
   - Total: {N} weeks
   - Kickoff: {vague month, e.g. "mid-{month}"}
   - Go-live: {vague month}
   Sound right or compress/extend?

4. **Signer + decision flow**
   - Signer: {Name from transcript or "TBC"}
   - Anyone else needs to approve? (partners, founders, CFO)

5. **Anything to adjust from the transcript**
   - Scope items to trim or add?
   - Pain points to lean harder into?
   - Past clients to reference by name?
```

Wait for the user's response. Then draft.

**Defaults if the user doesn't override:**

- **Dates**: Use vague month language ("mid-May", "late June") rather than specific calendar dates. Specific dates lock you in if anything slips.
- **Timeline floor**: At least 3 months total for a full multi-phase engagement. Single-phase work can be 4–6 weeks. Default long, let the user compress.
- **Currency**: Set by client geography. Don't default silently.

## Voice & Quality Bar

What separates a winning proposal from a generic one:

- **Specific, not generic.** Name the exact attributes, objects, lists, pipelines, integrations, and numbers the client mentioned. Not "restructure the CRM" but "Archive the 80+ custom attributes on the Company object, rebuild as list-level attributes on the {specific list name}."
- **Diagnose, don't describe.** Identify issues that exist in their current setup ("Strategy field exists as both Text and Multi-select, must resolve"). This is what makes the client trust you understood the call.
- **Hands-on, not advisory.** Deliverables are *built, migrated, deployed*, never "recommended" or "facilitated."
- **Phased with week ranges.** Every scope item gets a phase and a week number.
- **Short sentences. No fluff.** No "we are excited to partner" language. No empty adjectives ("robust," "comprehensive," "best-in-class," "seamless").
- **Visual cohesion.** Every section must have AT LEAST ONE of: a snapshot/opener callout (code block with `> key: value` lines), a table, or 5+ named bullets. Bare paragraphs alone are not allowed.
- **Density floors.** A section that fits in 3 lines makes the document look thin and the price look high. Hit the per-section minimums below. If you can't, expand with concrete artifacts from the transcript. Don't pad with adjectives.
- **<!-- ADD YOUR VOICE RULES HERE -->** Examples of things to specify: punctuation preferences (em dashes, italics in headings), banned words, tone (formal vs casual), forbidden phrases, sign-off style.

## Output Format

The skill outputs **two blocks in this order**:

1. **Pricing Preview** (internal, shown FIRST so the user can sanity-check pricing before sending anything to the client)
2. **The 12-section proposal** (ready-to-copy for the client)

---

## Block 1 — Pricing Preview (internal, shown to the user before the proposal)

This block is the reasoning the user sees to sanity-check pricing before sending anything to the client. Do NOT include it in the copyable proposal.

Format the preview like this:

```
## Pricing Preview — {Client name}

<!-- ADD YOUR PRICING LOGIC HERE.

     The preview should show your reasoning so the user can challenge it.
     Typical things to include:

     - Deliverable breakdown (line items, each with a price floor)
     - Value frame (where measurable: hours saved, revenue captured, cost avoided)
     - Multipliers (pain / value / scope risk, with one-line evidence each)
     - Market benchmark (what comparable firms likely charge)
     - The final quote (1, 2, or 3 options)
     - TL;DR (one sentence justifying the floor and ceiling) -->
```

Then a divider, then Block 2.

---

## Block 2 — The 12-Section Proposal

Output exactly these 12 numbered blocks as markdown in the chat. Use the header format `## N. Section Name`. Fill every `{placeholder}` with transcript-derived content. The prices in Section 11 must match the prices you showed in the Pricing Preview.

### Header block (above Section 1)

```
> Prepared for: {Client Company}
> Prepared by: {Your name} at {Your company}
> Date: {today, formatted Month DD, YYYY}
```

### Project Snapshot (immediately below the header, before Section 1)

A monospace `> key: value` block that gives the reader the answer in 5 seconds. Format exactly:

```
> project:      {3–6 word project name, e.g. "CRM rollout — Sales + IR"}
> investment:   {currency}{Option 1 price} or {currency}{Option 2 price}
> timeline:     {N} weeks ({phase count} phases)
> integrations: {comma-separated tool names, or "None"}
> teams:        {comma-separated teams in scope}
> signer:       {Name}, {Role}
> valid_until:  {today + N days, DD.MM.YYYY}
```

All fields must be filled in. If you can't derive one, ask before writing.

### 1. Executive Summary

```
> in_scope:   {comma-separated business units / teams}
> outcome:    {one-line outcome}
> phases:     {N}
```

2–4 sentences. What you're building, for whom, why it matters. Name the business units or teams in scope. Open with the section callout above as a code block; it doubles as the visual anchor for the page.

### 2. Client Background

1 paragraph (4–6 sentences). Company type, industry, size, geography, what tools they currently use, recent business signals (funding, expansion, new market, hires). Then a Stakeholders mini-table:

| Name | Role | On the call? |
|---|---|---|
| {name} | {role} | ✓ / — |

**Research step:** Run a WebSearch / WebFetch on the client's domain (and optionally their LinkedIn) **before writing this section**. Combine what you find with what the transcript said. If you have no domain, stop and ask for it. Don't hallucinate the company description.

The goal: the client reads Section 2 and thinks "they actually know who we are."

### 3. Outcomes & Objectives

```
> business_outcome: {one-line plain-language outcome in CLIENT's words}
> success_metric:   {one quantifiable signal, e.g. hours saved, deals tracked, time-to-fundraise}
> objectives:       {N below}
```

**Lead with value, not tasks.** This section has two halves:

**3a. Business Outcomes** (2–4 sentences, then 3–5 bullets)

A short paragraph in the client's own language describing what changes for their business after this is live. Then a bulleted list of outcomes phrased as the buyer's wins, not your deliverables. Reach for monetization or quantification wherever the transcript gives you numbers (deal sizes, headcount, hours, fundraise targets, churn rates, missed leads). Where the transcript gives no number, name the operational pain in plain language and quantify what you can.

Format each outcome bullet as: **{Outcome in client language}** → {what enables it} → {quantified impact where possible}.

Example outcomes (do NOT copy verbatim, derive from the transcript):

- **Stop losing live deals to follow-up gaps.** A unified pipeline replaces the spreadsheet the team rebuilds every Monday → recovers ~6 hrs/week across 4 partners.
- **One source of truth for the team.** Every team member sees the same status, same next-step → end of "what's the latest on X" Slack threads.

The litmus test: a client should read this section and recognize their own words. If it sounds like your deliverables list, rewrite it.

**3b. Project Objectives**

Numbered list, **5–7 items minimum**. Concrete operational objectives that will produce the outcomes above: "Resolve X," "Build Y," "Migrate Z from [source tool]." No vague goals. This is where deliverable language lives, after the value language has done its job.

### 4. Scope of Work

```
> phases:    {N}
> weeks:     {total weeks}
> artifacts: {count of named lists / pipelines / objects / workflows below}
```

Organized into **Phases** (Phase 0, 1, 2, 3, 4) with week ranges. Under each phase, use bolded sub-sections and bullet lists. Name concrete artifacts: lists, pipelines, objects, attributes, workflows, integrations. **Minimum 15 named artifacts across all phases.** If you can't hit that, push back on the user about what's actually in scope before drafting.

Example structure:

- **Phase 0 — Discovery & Architecture (Week 1)**
  - Data model audit
  - Specific decisions to make
- **Phase 1 — {Build area} (Weeks 1–3)**
  - 1.1 Object cleanup
  - 1.2 {First list built}
  - 1.3 {Second list}
- **Phase 2 — ...**
- **Phase 3 — Reporting & Integrations (Week X)**
- **Phase 4 — Training & Rollout (Weeks X–Y)**

### 5. Out of Scope

Bulleted. Explicitly list what's excluded: integrations beyond stated ones, automations if not included, other business units, ongoing admin, scope changes after sign-off.

<!-- ADD YOUR STANDARD EXCLUSIONS HERE.
     Typical exclusions worth always listing:
     - Historical data backfills (if integrations only sync forward)
     - Third-party tool subscriptions
     - Post-launch maintenance beyond the included window
     - Custom development outside the named workflows -->

### 6. Deliverables

```
> count:    {N rows below}
> built_by: {You}
> owned_by: Client
```

Markdown table with columns: `#`, `Deliverable`, `Team / Area`. One row per concrete artifact (list, pipeline, migration, training session, doc). **Minimum 8 rows.** Each deliverable phrased as a noun the client can point at after go-live ("Investor Relations list with 12 attributes," not "list configuration work").

### 7. Indicative Timeline

```
> total:     {N weeks}
> kickoff:   {Week of {date} or vague month}
> golive:    {Week {N} or vague month}
```

Markdown table: `Phase`, `Activity`, `Timing`. Mirror the Phase breakdown from Section 4.

### 8. Roles & Responsibilities

Markdown table: `Responsibility`, `Client`, `{You}`. Use ✓ marks. Cover: sign-offs, data exports, credential provisioning, attendance at sessions, all build / config, training, post-launch support.

### 9. Assumptions

Markdown table: `Assumption`, `Implication if untrue`. **Minimum 6 rows.** Cover: decisions made on time, data provided in usable format, seats provisioned, tool credentials handed over, scope changes may shift timeline, stakeholder availability for sessions.

| # | Assumption | Implication if untrue |
|---|---|---|
| 1 | {assumption} | {what happens / how timeline shifts} |

### 10. Open Items

Markdown table: `Item`, `Decision needed by`, `Owner`. **Minimum 4 rows.** Things that must be resolved before kickoff: exact pipeline stages, workspace architecture decisions, list of contact types, reporting metrics, support window duration. Pull directly from what was unresolved in the transcript.

| # | Item | Decision needed by | Owner |
|---|---|---|---|
| 1 | {open item} | {Kickoff / Week N / Date} | {Client name or You} |

### 11. Investment

```
> options:   {N}
> currency:  {currency} (excl. {VAT / sales tax})
> pricing:   <!-- ADD YOUR PRICING MODEL one-liner here -->
> payment:   <!-- ADD YOUR PAYMENT TERMS one-liner here -->
> add_ons:   <!-- ADD YOUR OPTIONAL ADD-ONS one-liner here, or "None" -->
> valid:     {N} days
```

<!-- ADD YOUR PRICING LOGIC HERE.

     This section is where the model decides the actual numbers shown to the client.
     Typical things to define:

     1. How you price (per-deliverable / per-phase / fixed sprint / value-based / hourly).
     2. Floors and ceilings for each category of work.
     3. How to present options (Sprint vs Impact, modular phases 1/2/3, single quote).
     4. Payment terms (100% upfront / Day 1 + Day 30 split / milestone-based).
     5. Discount and add-on rules (if any).
     6. The exact comparison table format you want the model to output.

     Example structure to fill in:

     | Feature | Option 1 | Option 2 |
     |---|---|---|
     | {Core deliverable 1} | Included | Included |
     | {Core deliverable 2} | Included | Included |
     | Workflows / Automations | None | {N} included |
     | Sessions | Kick-off + walkthrough | + mid-project check-in |
     | Post-launch support | 1 week | 2 weeks |
     | **Investment** | **{currency}{price}** | **{currency}{price}** | -->

Then a one-line offer validity statement:

> This offer is valid for {N} days. All prices in {currency} and exclude {VAT / sales tax}.

Then a brief one-line justification of the pricing in the client's language (value or output framing, not "hours of work").

### 12. Contractual Terms

<!-- ADD YOUR CONTRACT TERMS HERE.

     Typical sections to include (substitute as appropriate):

     - Project Scope reference (point at Section 4)
     - Client Responsibilities (admin access, credentials, sign-offs)
     - Investment & Payment terms (point at Section 11)
     - Timeline reference (point at Section 7)
     - Data Ownership (who owns the configurations + data)
     - Marketing rights (logo + case study usage, if any)
     - Liability cap
     - Change Order process (rate for scope changes)
     - Post-launch support definition (hours + response time + channel)
     - Termination clause
     - Acceptance mechanism (signature vs. invoice payment)

     Keep this consistent with your standard MSA / service agreement template. -->

---

## Rules

1. **Output to chat only.** Never write the proposal to a file. The user copies it from the chat.
2. **No placeholders left.** If you can't derive a value, ask before writing. Don't leave `[TBD]` scattered through the draft.
3. **Pricing is reasoned, not invented.** Follow the pricing logic the user defined in Section 11. If unsure, show the breakdown in the Pricing Preview block so the user can sanity-check before the proposal is generated.
4. **Today's date** for the Date fields. Format as `Month DD, YYYY` at the top, `DD.MM.YYYY` in the Service Agreement.
5. **Always research the client** for Section 2 via WebSearch / WebFetch. Ask for the domain if you don't have one.
6. **Section 4 is the heart.** If it's vague, the proposal is weak. Name the objects, attributes, lists, integrations, and workflows explicitly. That's what justifies the price.
7. **Visual cohesion is mandatory.** The Project Snapshot block (after the header) and the per-section `> key: value` callouts on Sections 1, 3, 4, 6, 7, 11 are not optional. They render as monospace code blocks in PDF and give the body visual rhythm. Sections 2, 9, and 10 must include their tables. Bare-paragraph sections fail the bar.
8. **Lead with value, not deliverables.** Section 3 has a Business Outcomes block before the Objectives list. Outcomes are written in the client's language (their pain, their numbers, their fundraise / deal / team metrics). The objectives list still names concrete tasks; it just comes after the value frame, not in place of it.