proposal

name	proposal
description	Generates a closing proposal from demo meeting notes + the actual PoC + account brief. Business-value first; technical specs in appendix. Run after a demo meeting, before contract negotiation.
argument-hint	<demo_meeting_notes_path> [proposal_output_path, default docs/proposal.md]
disable-model-invocation	false
allowed-tools	Read, Glob, Grep, Write, Edit, Task

Kit Preamble — proposal

Kit Script Root

Kit root: ${CLAUDE_PLUGIN_ROOT}

• Absolute path above → plugin install (substituted at load time; no project scripts/ dir): prefix every kit script command with it, e.g. bash <kit-root>/scripts/checkpoint.sh …. Absolute paths also work from worktrees.
• Literal ${…} placeholder above → standalone layout: run commands as written.

Project Context Detection

Run these checks silently at the start. Use results to adapt behavior:

• [ -f issues.md ] — if true, this project uses the sprint system. Respect issue numbering and STATUS.md.
• [ -f docs/sprint_state.md ] — if true and Status shows running, a sprint is active. Be aware of parallel work in worktrees.
• [ -f docs/prd_digest.md ] — if true, read it for quick project context before starting.

Kit Rules

• Verify gh auth status before any GitHub operation. Steps:

1. Parse arguments:
   • $1 (required): demo meeting notes file path. Must exist.
   • $2 (optional): proposal output path, default docs/proposal.md.
2. Validate the meeting notes file exists.
3. Read the meeting notes and confirm meeting_type is demo or closing.
   • If discovery: stop. Tell the user to run /meeting-capture instead (proposal is generated after demo, not after discovery).
   • If missing or unclear: ask the user.
4. Validate demo_feedback section has content (if meeting type is demo). If empty, warn the user — proposal quality depends on knowing how the demo landed.
5. REQUIRED input — check docs/poc_results.md:
   • If missing: STOP. Tell the user to copy templates/poc_results.md to docs/poc_results.md and fill it in (sales + engineer together). Without this, proposal metrics (per-unit cost, ROI, success criteria pass/fail) become unverifiable.
   • If exists but Success Criteria pass-rate < 50%: warn — proposal will need to honestly acknowledge gaps and may recommend revised approach over closing.
6. Check other optional inputs:
   • docs/account_brief.md (highly recommended)
   • docs/prd_draft.md (what we said the PoC would do — for cross-checking against poc_results)
   • prototype/ directory (sanity check what was actually built)
   • prior docs/proposal.md (if updating) 6.5) Resolve shared file paths via walk-up (supports multi-account repo structure):

     LESSONS_PATH="$(bash scripts/find_shared.sh sales_lessons.md 2>/dev/null || true)"
     

     • If non-empty, pass the absolute path to the agent.
     • If empty, proceed without lessons context.

If proposal does NOT exist (New Proposal):

7a) Invoke the proposal-writer agent via the Task tool, passing all available input paths (including the required docs/poc_results.md and the resolved LESSONS_PATH from step 6.5). 8a) The agent will: - Read all inputs + templates/proposal.md for structure - Use poc_results.md as the single source of truth for all metrics (per-unit cost, processing time, evaluation scores, success criteria) - Optionally read the resolved sales_lessons.md path (passed in) for cross-account patterns - Aggregate pain points from all prior meeting notes for this account - Build the requirement → PoC demo mapping table sourcing ✅ from poc_results.md "시연 시 작동한 것" only (no fabrication) - Generate ROI section by copying assumptions from poc_results.md "운영 단계 ROI 가정" verbatim - Propose 2–3 pricing options with recommendation - List 3–5 real risks (from poc_results.md "Productionalization Gap" + meeting feedback) with concrete mitigations - Save proposal to output path 8a) Present to the user: - Executive Summary preview - Sections marked TBD (especially pricing inputs) - Honest read on demo reception and whether to recommend closing or revising approach

If proposal DOES exist (Update Proposal):

7b) Read existing proposal and present a brief summary. 8b) Ask what changed (new meeting feedback, revised pricing, new risk, updated poc_results.md). 9b) Invoke proposal-writer in update mode. 10b) Highlight what changed.

Common (both modes):

9. After the proposal is finalized, inform the user the next step is:

   /followup <demo_meeting_notes_path>
   

   to generate the customer follow-up email, CRM updates, and account_brief updates.

Error Handling

• If meeting notes file does not exist: stop and ask for correct path.
• If meeting type is discovery: redirect to /meeting-capture.
• If docs/poc_results.md does not exist: STOP. Tell the user to copy templates/poc_results.md to docs/poc_results.md and fill it in.
• If demo_feedback is empty: warn but proceed (proposal will be weaker).
• If prototype/ directory is missing: proceed using poc_results.md as source of truth.

Quality Criteria

NEVER:

• Proceed without docs/poc_results.md — claims become unverifiable
• Fabricate ROI numbers — every metric traces to poc_results.md or meeting_notes
• Overstate what the PoC demonstrated — only check ✅ for items in poc_results.md "시연 시 작동한 것"
• Bury price in the appendix — Economic Buyers want price visible up top
• Use marketing fluff ("best-in-class") — concrete claims only
• Skip addressing demo feedback — if customer flagged gaps, the proposal must explicitly address them

INSTEAD:

• Quote the customer's own pain statements with date attribution
• For each customer requirement, show exactly where it was demonstrated (or schedule when it will be)
• Make pricing transparent and recommend one option with reasoning
• For each risk, name the concrete mitigation with the responsible party
• End with a single, unambiguous next step ("Sign by [date] to start kickoff on [date]")

Guidelines

• If demo feedback was largely negative, do NOT pretend it landed well. Acknowledge gaps in "Risks" and propose a revised approach — preserves trust.
• Pricing: if pricing inputs are missing, mark with <!-- needs pricing team input --> and proceed.
• After saving, suggest next step: /followup <demo_meeting_notes_path>.