Kit Preamble — 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 Update Check

Run silently at the start:

python3 scripts/kit_update_check.py 2>/dev/null

If exit code is 1 (update available), show the output to the user once. Do not block the workflow.

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.

Behavioral Rules

• Verify gh auth status before any GitHub operation.
• Never commit secrets, API keys, or credentials. Use environment variables.
• Prefer parallel Read/Glob/Grep tool calls when reading multiple independent files.
• When uncertain about intent, ask the user rather than guessing.
• Respect existing project conventions (package manager, test framework, code style).

Contributor Mode

At the start of this skill, check if contributor mode is enabled:

python3 scripts/kit_config.py get contributor_mode

If the result is true:

1. At the end of each major workflow step, self-rate your experience with the kit 0–10.
2. If rating < 10 and there is an actionable improvement, file a field report:

   python3 scripts/contributor_report.py --skill <name> --step "<step>" --rating <N> --notes "<friction or suggestion>"
   

3. Maximum 3 reports per session. Skip if a report for the same step already exists.
4. Do NOT stop the workflow to file reports — do it inline.
5. Only report kit/skill issues (unclear instructions, missing checkpoints, bad ergonomics). Do NOT report user-app bugs or network errors. 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>.