Proposal
Skill stanislavnianko/product-discovery-claude-skills/plugins/discovery-phase/skills/proposal
Curated Claude skill pack for structured product discovery
npx -y skills add stanislavnianko/product-discovery-claude-skills --skill proposalAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
[discovery-phase pack · deliverables] Generates a client-facing proposal document consolidating problem understanding, recommended approach, scope, assumptions, dependencies, team, timeline, and headline pricing guidance. Designed for pre-sale or paid-discovery conclusion. Produces proposal.md. Reads discovery-context.md and most upstream artifacts.
SKILL.md
5.8 KB, as published. Nobody here has run it
Proposal
Part of the discovery-phase skill pack ·
deliverablesgroup · readsdiscovery-context.md(runprofile-builderfirst if missing).
Agency-to-client proposal document. The output the client reads, signs (or doesn't), and budgets against.
Step 1 — Read context + prerequisites
Read discovery-context.md (sections 3. Engagement → Mode — if mode is staff aug or internal, suggest discovery-handoff instead, but allow override; 5. Expected deliverable).
Prerequisite artifacts — the proposal's substance:
scope-doc.md— scope languageestimation.md— effort + assumption listrisk-assumption-map.md— risk register- Recommended:
problem-canvas.md,opportunity-tree.md
If discovery-context.md is missing, ask the BA inline: "(a) engagement mode (pre-sale / paid discovery / other); (b) client name + sector?" — tag [ASSUMED]. If 1–2 prerequisite artifacts are missing, ask for 3–5 stand-in bullets per artifact. If 3+ are missing, strongly recommend running the prerequisite skills first; otherwise proceed with [ASSUMED <artifact>] placeholders and a non-removable DRAFT-ONLY banner at the top of proposal.md (NOT for client send). Never block.
Step 2 — Pick proposal style
| Style | When | Length |
|---|---|---|
| Executive brief | Senior client decision-maker, pre-sale, time-pressured | 2-3 pages |
| Detailed proposal | Procurement / RFP response, larger engagement | 8-12 pages |
| Pitch deck | Initial conversation; supplements verbal pitch | Doc + companion deck |
Default to executive brief unless context section 3 (Mode) implies RFP.
Step 3 — Required sections (in this order)
- Cover — engagement title, client name, agency name, date, version, primary contact
- TL;DR — 3-4 bullets max. The client should be able to forward just this.
- Problem we'd solve — one paragraph from
problem-canvas.md, in client-language. NOT in agency-language. - What we learned (if discovery happened already) — 3-5 bullets from
insight-matrix.mdtop-3 with one quote each. Supports the recommendation. - Recommended approach — what we'd build, why this and not alternatives. Pull from
opportunity-tree.mdchosen-direction. If client pre-proposed a different solution and our recommendation differs, handle this section carefully — see step 4. - Scope — pull "in" column from
scope-doc.md. Include the success metrics. - Out of scope — pull "out" column + "explicitly deferred". Crucial — prevents post-contract scope wars.
- Approach / phases — high-level timeline aligned to discipline matrix from
estimation.md. Show milestones, not all tasks. - Team — who from agency works on what. Pull discipline columns from estimation.
- Timeline — calendar weeks, key milestones, decision points
- Effort and pricing guidance — from
estimation.mdadjusted total. Range, not a number. Specify whether fixed-fee, T&M, or phased. - What we need from you — the client-side assumptions and dependencies (from
scope-doc.mdoutsourcing extras +risk-assumption-map.md[client]/[shared]rows) - Risks and how we'll handle them — from
risk-assumption-map.mdregister, prioritized - Assumptions — verbatim from
estimation.md"Assumptions that invalidate the estimate" - Next steps — concrete, signable: "we'll send a SoW within 5 business days of your verbal yes" or similar
Step 4 — Handle "we recommend something different than client asked"
If opportunity-tree.md was Validate-mode and chose against client's pre-proposed solution:
- Section 5 leads with empathy: "You came to us with
<client's idea>. Here's what we learned and where it took us." - Section 5 shows the alternatives — including client's idea — with honest scoring.
- Don't pretend the client's idea was never on the table; that breaks trust.
- Pre-draft the BA-to-client conversation script as an appendix the BA can rehearse.
Step 5 — Voice and tone
- Client-language, not agency-language. "We'll do X" → "We'll help you do Y for users".
- No internal jargon ("MVP", "v1", "story points"). Translate to client terms ("first release", "subsequent release", "effort estimate").
- Active voice. Short sentences. The client is busy.
- No buzzwords ("synergy", "leverage", "best-in-class"). They lower trust.
Step 6 — Output
./discovery/proposal.md per ./template.md.
Append to _log.md: [proposal | YYYY-MM-DD] style: <executive/detailed/pitch>; total: <X-Y>; sent_to: <client contact>.
Anti-patterns
- Buried scope. Scope (and out-of-scope) are the two most-read sections. Don't hide them in section 11.
- Single-number price. Always range. Single number = commitment.
- Hiding "what we need from you". This is where the engagement actually lives or dies. Be explicit.
- Including discovery's open questions as "we'll figure this out". Either resolve them before proposal or surface them as risks.
- Agency-internal language. "Sprint 1, 2, 3" → "First 3 weeks". "Deliverable D1" → describe it in plain terms.
- No alternatives in Validate-mode handling. If you recommend differently than client asked, show your work. Hiding it = lost trust.