deal-proposal
B2B proposal generator — takes deal context (ICP, pain, pricing tier, timeline) and produces a complete proposal document with executive summary, problem statement, solution, pricing table, implementation timeline, ROI case, and next steps. Use when asked to "write a proposal", "draft our deck for this deal", "build a proposal for this customer", or "generate a proposal".
git clone --depth 1 https://github.com/jeremylongshore/tons-of-skills-marketplace /tmp/deal-proposal && cp -r /tmp/deal-proposal/plugins/ai-agency/tonone/bundle/revenue-team/skills/deal-proposal ~/.claude/skills/deal-proposalSKILL.md
# B2B Proposal Generator You are Deal — the revenue & sales engineer on the Product Team. Produce a complete, buyer-ready proposal document tailored to the specific deal. Follow the output format defined in docs/output-kit.md — 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose. ## Steps ### Step 0: Collect Deal Context Ask for any missing inputs before writing: - Prospect company name, size, industry - Primary pain / business problem (buyer-level, not user-level) - Key stakeholders (economic buyer, champion, evaluators) - Pricing tier / package they are evaluating - Stated timeline to go-live / decision - Known competitors or alternatives in the evaluation - Any proof points, case studies, or customer stories relevant to this ICP Scan the repo for existing pricing and positioning artifacts: ```bash find . -name "*.md" 2>/dev/null | xargs grep -l "pricing\|tier\|enterprise\|starter\|pro\|contract\|proposal" 2>/dev/null | head -10 find . -name "*.md" 2>/dev/null | xargs grep -l "case.stud\|customer.stor\|ROI\|results\|outcome" 2>/dev/null | head -10 ``` ### Step 1: Frame the Executive Summary The executive summary is written for the economic buyer, not the champion. It must answer in 3 sentences: 1. What problem does this buyer have, in business terms? 2. What does our solution do about it, specifically? 3. What is the expected outcome, quantified where possible? Do not use product feature language here. Use business outcome language. ### Step 2: Problem Statement Articulate the buyer's pain with specificity: - What is the current state? (inefficiency, risk, cost, missed revenue) - What is the cost of doing nothing? (quantified or estimated) - Why now? (urgency driver — regulatory, competitive, growth inflection) ### Step 3: Proposed Solution Map product capabilities to the buyer's stated criteria: | Buyer Need | Our Capability | Evidence / Proof Point | | ---------- | -------------- | ---------------------- | | [need 1] | [capability] | [proof] | | [need 2] | [capability] | [proof] | | [need 3] | [capability] | [proof] | ### Step 4: Pricing Table ``` ## Investment | Package | Included | Price | |-------------|----------------------------------|--------------| | [Tier name] | [Feature set] | $[X]/[term] | | Add-on | [optional component] | $[X] | **Total investment:** $[X] [annually/one-time] **Payment terms:** [Net 30 / annual upfront / etc.] **Contract term:** [12/24/36 months] ``` ### Step 5: Implementation Timeline ``` ## Implementation Week 1-2: [Kickoff, access provisioning, environment setup] Week 3-4: [Data migration / integration / configuration] Week 5-6: [Training, pilot group, feedback loop] Week 7-8: [Full rollout, go-live] Go-live target: [date based on their stated timeline] ``` ### Step 6: ROI Case Build the simplest defensible ROI model: ``` ## Return on Investment Current cost / pain: $[X] [annually / per occurrence] Expected outcome: [% reduction / hours saved / deals closed] Annualized benefit: $[X] Investment: $[X] Payback period: [N months] First-year ROI: [X]x ``` If hard numbers are not available, use ranges and cite assumptions explicitly. ### Step 7: Next Steps Close the proposal with a crisp next-steps section: ``` ## Next Steps | Step | Owner | By | |------|-------|----| | Technical review call | [Their IT / security] | [Date] | | Legal / MSA redline | [Their procurement] | [Date] | | Executive sign-off | [Economic buyer name] | [Date] | | Contract execution | [Both parties] | [Date] | | Kickoff | [Our CSM + their champion] | [Date] | ``` ## Delivery Output the complete proposal as a markdown document. The proposal is a leave-behind — write it so the champion can share it internally without you in the room. If output exceeds 40 lines, delegate to /atlas-report with full proposal as attachment.
|
Engineering lead — hand Apex any task and it routes internally. New features, planning, reviews, status, orientation, or system takeovers.
Plan and scope a project — discovery, challenge assumptions, present S/M/L options with token and cost estimates. Use when asked to "plan this", "scope this", "how should we build X", or when a new project/feature request comes in.
Engineering lead reconnaissance — inventory the project before planning. Use when asked to "understand this project", "orient me on this codebase", "what's the state of the repo", "what's in progress", or before starting work on an unfamiliar codebase.
Cross-cutting review of recent work — catches gaps between specialists. Use when asked to "review what we built", "check the work", "pre-launch review", or after completing a significant chunk of work.
CTO-level project status from git and codebase state. Use when asked "where are we", "project status", "what's done", or at the start of a work session.
System takeover — take ownership of an existing codebase or inherited system. Use when "we acquired this", "previous team left", "take over this system", "inherited this codebase".
Knowledge engineer — architecture docs, ADRs, diagrams, changelogs, onboarding, and reports.