/proposal-writer

name: memstack-business-proposal-writer
description: "Use this skill when the user says 'write proposal', 'create proposal', 'proposal for', 'client proposal', 'project proposal', 'bid on project', 'pitch', or is preparing a project proposal for a client or freelance engagement. Do NOT use for contracts, invoices, or onboarding."
version: 1.0.0
license: "Proprietary, MemStack™ Pro by CW Affiliate Investments LLC. See LICENSE.txt"

📝 Proposal Writer: Drafting project proposal...

*Generates a professional project proposal with executive summary, deliverables, tiered pricing, timeline, and terms, ready to send as PDF or email.*

Activation

When this skill activates, output:

`📝 Proposal Writer: Gathering project details...`

Then execute the protocol below.

| Context | Status | |---------|--------| | User says "write proposal" or "create proposal" | ACTIVE | | User says "pitch" or "bid on project" or "client proposal" | ACTIVE | | Preparing a document to send to a prospective client | ACTIVE | | Writing internal project plans (no client) | DORMANT: use scope-of-work | | Discussing pricing strategy generally | DORMANT |

Anti-patterns

| Trap | Reality Check | |------|---------------| | "Just list what we'll build" | Proposals sell outcomes, not features. Lead with the problem you solve. | | "One price, take it or leave it" | Tiered pricing lets clients choose their budget level. Always offer 2-3 options. | | "We'll figure out scope later" | Vague scope creates disputes. Define deliverables AND exclusions explicitly. | | "Terms can wait until contract" | Payment schedule, revision limits, and IP ownership prevent 80% of freelance conflicts. Include them. | | "The longer the better" | Busy clients skim. Executive summary + pricing first. Details in appendix. |

Protocol

Step 1: Gather Project Requirements

If the user hasn't provided project details, ask:

> I need a few details for the proposal: > 1. **Client name** and company > 2. **Project type** (web app, mobile app, marketing site, API, etc.) > 3. **Core problem**: what does the client need solved? > 4. **Rough scope**: key features or deliverables > 5. **Timeline**: any deadlines or target launch date? > 6. **Budget range**: if known (helps calibrate tier pricing)

If the user provides partial info, ask only for what's missing. Don't ask for information you can infer.

Step 2: Write Executive Summary

The executive summary is what the client reads first (and sometimes only). It must:

1. **Name the problem** the client faces, in their language, not technical jargon 2. **Present the solution** at a high level, what you'll build and why it works 3. **State the outcome**: what the client gets (revenue, time saved, users served) 4. **Establish credibility**: briefly mention relevant experience

**Template:**

## Executive Summary

[Client name] needs [problem statement: what's broken, missing, or inefficient].

We propose [solution summary, what you'll build] using [key technology/approach].
This will [primary outcome, measurable benefit to the client].

Based on our experience with [relevant past work], we estimate [timeline]
for full delivery, with [key milestone] available within [shorter timeframe].

**Rules:**

• Max 150 words, if you can't summarize in 150 words, you don't understand the project
• No technical jargon the client wouldn't use
• Lead with their problem, not your solution
• Include one specific number (timeline, cost savings, user capacity)

Step 3: Break Down Deliverables

List every deliverable with estimated hours per phase:

## Deliverables

### Phase 1: Foundation (Week 1-2)
| Deliverable | Description | Est. Hours |
|-------------|-------------|-----------|
| Project setup | Repository, CI/CD, staging environment | 8 |
| Authentication | User registration, login, password reset | 16 |
| Database design | Schema, migrations, seed data | 12 |
| **Phase subtotal** | | **36** |

### Phase 2: Core Features (Week 3-5)
| Deliverable | Description | Est. Hours |
|-------------|-------------|-----------|
| Dashboard | Admin dashboard with key metrics | 24 |
| User management | CRUD, roles, permissions | 20 |
| API integration | Connect to [external service] | 16 |
| **Phase subtotal** | | **60** |

### Phase 3: Polish & Launch (Week 6-7)
| Deliverable | Description | Est. Hours |
|-------------|-------------|-----------|
| Testing | Unit tests, integration tests, QA | 16 |
| Deployment | Production setup, domain, SSL | 8 |
| Documentation | User guide, API docs | 8 |
| **Phase subtotal** | | **32** |

**Total estimated hours: 128**

**Rules:**

• Group deliverables by phase (foundation, core, polish)
• Each deliverable is specific and verifiable (not "backend work")
• Hours are estimates, include a buffer note ("+/- 15%")
• Include testing, deployment, and documentation: clients forget these exist

Step 4: Tech Stack Recommendation

Justify the technology choices:

## Technical Approach

| Layer | Technology | Why |
|-------|-----------|-----|
| Frontend | Next.js 15 + React | Fast development, SEO-friendly, scales well |
| Styling | Tailwind CSS | Rapid UI development, consistent design system |
| Backend | Next.js API Routes | Unified codebase, simplifies deployment |
| Database | Supabase (Postgres) | Real-time capabilities, built-in auth, RLS |
| Hosting | Railway + Netlify | Reliable, auto-scaling, CI/CD built-in |
| Auth | Supabase Auth | Secure, supports OAuth, handles sessions |

This stack was chosen for [speed of development / scalability / client's existing infrastructure / cost-effectiveness].

**Rules:**

• Only include if the client cares about technical details (some don't)
• Justify each choice in client terms (fast, cheap, reliable: not "it's cool")
• Mention alternatives you considered and why you didn't pick them
• Flag any client-side constraints (existing systems, team expertise)

Step 5: Create Tiered Pricing

Alw