Windsurf + Aider targets, MCP server, and demo placement (#33)
Broadens both reach (more tools) and content types (an MCP server), continuing the multi-platform story. Windsurf + Aider: - build-exports.mjs gains two platforms: exports/windsurf/*.md (workspace rules, trigger: model_decision) and exports/aider/*.md (conventions for `aider --read`). Now 5 platforms (ChatGPT, Gemini, Cursor, Windsurf, Aider). - install.sh + bin/cli.mjs install both (windsurf -> .windsurf/rules, aider -> .aider/skills with a --read hint); generated README index is excluded from copies. - One-line windsurf-install.sh / aider-install.sh wrappers for parity. MCP server (new content type): - mcp/server.mjs — zero-dependency stdio MCP server exposing list_skills, search_skills, get_skill. Published as a second bin (pm-claude-skills-mcp). Logs to stderr; reads bundled skills/ at startup. mcp/README.md documents client config. Also: README hero "See it in action" demo placement (ready to swap in a GIF; recording guide in web/docs-assets/README.md), Works-With table + exports + install docs updated, CHANGELOG Unreleased. package.json files/bin updated. Claude-Session: https://claude.ai/code/session_016JWn5jRD5tcEFKrubjQ6Px Co-authored-by: Claude <noreply@anthropic.com>
This commit is contained in:
mohitagw15856
GitHub
@@ -0,0 +1,99 @@
|
||||
# Account Plan Skill
|
||||
|
||||
Produces a structured account plan — the document that separates account managers who grow accounts from those who just service them.
|
||||
|
||||
## Required Inputs
|
||||
- **Account name**
|
||||
- **Current ARR / revenue**
|
||||
- **Contract renewal date**
|
||||
- **Key contacts** (names, roles, relationship strength)
|
||||
- **Products/services currently in use**
|
||||
- **Known opportunities or expansion areas**
|
||||
- **Known risks**
|
||||
- **Planning horizon** (6 / 12 / 24 months)
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
|
||||
# Account Plan: [Account Name]
|
||||
**Account Manager:** [Name] | **Period:** [Date range]
|
||||
|
||||
---
|
||||
|
||||
### Account Snapshot
|
||||
|
||||
| Metric | Current | Target (EOY) |
|
||||
|---|---|---|
|
||||
| ARR / Revenue | £[amount] | £[target] |
|
||||
| NPS / Health score | [Score] | [Target] |
|
||||
| Products in use | [List] | [Expansion targets] |
|
||||
| Renewal date | [Date] | — |
|
||||
| Risk level | Low / Medium / High | — |
|
||||
|
||||
---
|
||||
|
||||
### Relationship Map
|
||||
|
||||
| Name | Title | Influence | Relationship | Notes |
|
||||
|---|---|---|---|---|
|
||||
| [Name] | [Role] | Decision maker / Influencer / User | Strong / Neutral / Weak | [Insight] |
|
||||
|
||||
**Relationship gaps:** [Who we do not have access to that we should]
|
||||
**Executive sponsor:** [Do we have one? If not — who could become one?]
|
||||
|
||||
---
|
||||
|
||||
### Why They Stay (Retention Anchors)
|
||||
[2-3 specific reasons this account renews. If the list is short, that is the risk signal.]
|
||||
|
||||
---
|
||||
|
||||
### Growth Opportunities
|
||||
|
||||
| Opportunity | Product | Est. Value | Timeline | Next Action |
|
||||
|---|---|---|---|---|
|
||||
| [Opportunity] | [Product] | £[value] | [Q/Year] | [Specific action] |
|
||||
|
||||
**Whitespace:** What products do we have that this account does not use, and why?
|
||||
|
||||
---
|
||||
|
||||
### Risks and Mitigation
|
||||
|
||||
| Risk | Likelihood | Impact | Mitigation | Owner |
|
||||
|---|---|---|---|---|
|
||||
| [Risk] | H/M/L | H/M/L | [Action] | [Name] |
|
||||
|
||||
---
|
||||
|
||||
### 90-Day Action Plan
|
||||
|
||||
| Action | Why | Owner | Due |
|
||||
|---|---|---|---|
|
||||
| [Specific action] | [Why it matters] | [Name] | [Date] |
|
||||
|
||||
**Next QBR / EBR:** [Date — if no EBR cadence, flag as a risk]
|
||||
|
||||
---
|
||||
|
||||
### Success Criteria
|
||||
At end of [period]:
|
||||
- Renewed at or above current ARR
|
||||
- [Expansion opportunity] progressed to [stage]
|
||||
- Health score moved from [current] to [target]
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not list only executive contacts in the relationship map — champions and day-to-day users are often more influential on renewal decisions
|
||||
- [ ] Do not set growth opportunity estimates without a basis — even rough ARR values prevent the plan from being treated seriously
|
||||
- [ ] Do not treat "no known risks" as acceptable — if no risks are identified, the plan hasn't been scrutinised honestly
|
||||
- [ ] Do not write 90-day actions as vague aspirations ("strengthen the relationship") — each action must specify a call, meeting, or deliverable with a named owner
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Relationship map identifies decision-makers, influencers, and any relationship gaps
|
||||
- [ ] Risks all have mitigation actions and named owners
|
||||
- [ ] Growth opportunities include estimated value (even roughly)
|
||||
- [ ] 90-day actions are specific (not "have a call" — what call, with whom, to achieve what)
|
||||
- [ ] Success criteria are measurable at the end of the planning period
|
||||
@@ -0,0 +1,108 @@
|
||||
# Discovery Call Prep Skill
|
||||
|
||||
Produces a complete discovery call brief — research summary, call hypothesis, structured questions, and success criteria — so every call starts with context and ends with a clear next step.
|
||||
|
||||
## Required Inputs
|
||||
- **Prospect company name**
|
||||
- **Contact name and role**
|
||||
- **Any known context** (how they found you, prior interaction)
|
||||
- **Your product/solution** (one line)
|
||||
- **Call duration** (15 / 30 / 45 / 60 min)
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
|
||||
# Discovery Call Brief
|
||||
**Prospect:** [Company] | **Contact:** [Name, Title] | **Duration:** [X min]
|
||||
|
||||
---
|
||||
|
||||
### Research Summary
|
||||
- What they do: [Product/service, customer, business model]
|
||||
- Size: [Headcount, revenue if public]
|
||||
- Stage: [Startup / Scaleup / Enterprise]
|
||||
- Recent news: [Funding, launches, leadership changes — last 90 days]
|
||||
- Contact background: [Role tenure, previous companies, LinkedIn activity]
|
||||
- Likely priorities for someone in this role: [Based on title and stage]
|
||||
|
||||
---
|
||||
|
||||
### Call Hypothesis
|
||||
Before the call write your best guess:
|
||||
- **Their most likely pain:** [What someone in this role at this company probably has]
|
||||
- **Why they would care about us:** [Specific connection to your value]
|
||||
- **Biggest risk to the deal:** [What might make this not a fit]
|
||||
|
||||
Write it down — then test it on the call.
|
||||
|
||||
---
|
||||
|
||||
### Call Agenda
|
||||
"Here is what I was thinking for our [X] minutes:
|
||||
- 2 min: Quick intros
|
||||
- [X] min: Learn more about your situation
|
||||
- [X] min: Share how we have helped similar companies
|
||||
- 5 min: Next steps
|
||||
Does that work? Anything specific you would like to cover?"
|
||||
|
||||
---
|
||||
|
||||
### Discovery Questions
|
||||
|
||||
Open with context (not a pitch):
|
||||
- "What prompted you to take this call today?"
|
||||
- "What does [relevant area] look like for you at the moment?"
|
||||
|
||||
Go deeper on pain:
|
||||
- "How long has [problem] been an issue?"
|
||||
- "What have you tried to solve it?"
|
||||
- "What is the impact of not solving this?"
|
||||
|
||||
Understand buying context:
|
||||
- "Who else would be involved in a decision like this?"
|
||||
- "Have you looked at other solutions?"
|
||||
- "Is there a reason you are exploring this now?"
|
||||
|
||||
Qualify on budget:
|
||||
- "Have you set aside budget for this kind of initiative?"
|
||||
|
||||
Close discovery:
|
||||
- "Based on what you have told me, it sounds like [summary]. Is that right?"
|
||||
|
||||
---
|
||||
|
||||
### Success Criteria
|
||||
This call is successful if we leave with:
|
||||
- Understanding of specific pain and business impact
|
||||
- Knowledge of buying process and key stakeholders
|
||||
- A clear agreed next step (demo / proposal / intro)
|
||||
- Sense of timeline
|
||||
|
||||
This call is NOT successful if we only pitched and got "sounds interesting, send me some info."
|
||||
|
||||
---
|
||||
|
||||
### Suggested Next Step
|
||||
"Based on what we discussed, the logical next step would be [specific]. Does [day/time] work?"
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Research summary includes recent news (last 90 days) — not just LinkedIn bio
|
||||
- [ ] Call hypothesis is written before the call (not post-rationalised after)
|
||||
- [ ] Discovery questions progress from context → pain → business impact → buying process
|
||||
- [ ] Success criteria define what "not successful" looks like (not just the ideal outcome)
|
||||
- [ ] A specific next step is proposed (not "let's stay in touch")
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not write the call hypothesis after the call — hypotheses written post-hoc are rationalisations, not testable predictions
|
||||
- [ ] Do not open with a product pitch before establishing the prospect's problem — leading with pitch signals you are not there to learn, which closes discovery conversations
|
||||
- [ ] Do not use closed questions in the discovery phase ("Do you have this problem?") — they produce yes/no answers that confirm bias rather than reveal pain
|
||||
- [ ] Do not skip the "not successful" definition in success criteria — a call that ends with "send me more info" feels like progress but is not a qualified next step
|
||||
- [ ] Do not treat all prospect research equally — recent news (last 90 days) is more relevant to call context than static company facts from LinkedIn
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Prepare me for a discovery call with [company/contact]"
|
||||
- "Build a call brief for my meeting with [name] at [company]"
|
||||
- "What questions should I ask in a discovery call for [use case]?"
|
||||
@@ -0,0 +1,231 @@
|
||||
# Partnership Proposal Skill
|
||||
|
||||
This skill produces a complete B2B partnership proposal covering the partnership rationale, mutual value, partnership model, commercial terms, governance, and a joint go-to-market plan. Output is ready to share with a prospective partner or use as the basis for a business case to internal stakeholders.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Your company** — name, what you do, and the audience you serve
|
||||
- **Prospective partner** — name, what they do, and their audience
|
||||
- **Partnership type** — technology integration / co-marketing / reseller / referral / strategic alliance / OEM
|
||||
- **Partnership goal** — what does each party get? (new customers / revenue / product capability / market reach)
|
||||
- **Proposed commercial model** — revenue share, referral fee, licensing, co-investment?
|
||||
- **Urgency or context** — is there a specific event, product launch, or competitive reason for this partnership?
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
|
||||
# Partnership Proposal: [Your Company] × [Partner Company]
|
||||
|
||||
**Prepared by:** [Name, Role at Your Company]
|
||||
**Date:** [Date]
|
||||
**Partnership type:** [Technology / Co-marketing / Reseller / Referral / Strategic Alliance]
|
||||
**Proposal status:** [Initial proposal / For negotiation / Final]
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
[3–5 sentences. Answer: what are we proposing, why now, and what does each party stand to gain? Write this so a busy executive can understand the proposal in 60 seconds without reading further.]
|
||||
|
||||
**Headline value for [Partner]:**
|
||||
> [One sentence — the most compelling thing this partnership does for them]
|
||||
|
||||
**Headline value for [Your Company]:**
|
||||
> [One sentence — the most compelling thing this partnership does for you]
|
||||
|
||||
---
|
||||
|
||||
## 1. The Opportunity
|
||||
|
||||
**Market context:** [Why does this partnership make sense now? What's happening in the market that creates a window for this to work?]
|
||||
|
||||
**Shared customer:** [Describe the customer both organisations serve — the overlap that makes this logical. Include size of the shared addressable market if you have it.]
|
||||
|
||||
**Problem neither of us solves alone:** [What can't either party do for the shared customer independently that the partnership would enable?]
|
||||
|
||||
---
|
||||
|
||||
## 2. What We're Proposing
|
||||
|
||||
**Partnership model:**
|
||||
|
||||
| Element | Description |
|
||||
|---|---|
|
||||
| **Type** | [Technology integration / Co-marketing / Reseller / Referral / OEM] |
|
||||
| **Scope** | [What specifically are we partnering on? — product features, joint campaigns, distribution, etc.] |
|
||||
| **Exclusivity** | [Exclusive in [region/segment] / Non-exclusive / Right of first refusal] |
|
||||
| **Duration** | [Initial term — e.g. 12 months, renewable] |
|
||||
| **Geographic scope** | [UK / EMEA / Global / Specific markets] |
|
||||
|
||||
**What this looks like in practice:**
|
||||
|
||||
[3–5 bullet points describing what the partnership actually means day-to-day. Make it concrete and operational — not abstract. e.g.:]
|
||||
- [Our product will natively integrate with [Partner's product] — the integration will be live in [timeframe]]
|
||||
- [We will co-market to each other's customer bases — joint webinar, co-authored content, shared newsletter placement]
|
||||
- [Each company will train a dedicated partnership contact who manages the relationship]
|
||||
- [[Partner] will list [Your product] in their marketplace / app directory / referral programme]
|
||||
|
||||
---
|
||||
|
||||
## 3. Value Proposition — What Each Party Gets
|
||||
|
||||
### For [Partner]
|
||||
|
||||
| Value | Evidence / Basis |
|
||||
|---|---|
|
||||
| **[New customer reach]** | [e.g. Access to [Your Company]'s [X,000] [role] customers — [X%] of whom have expressed interest in [Partner's category]] |
|
||||
| **[Product capability]** | [e.g. [Partner]'s product gains [capability] that [X%] of their customers have requested — based on [source]] |
|
||||
| **[Revenue opportunity]** | [e.g. Estimated [£/$/€ X] in referral revenue in Year 1 based on [X%] conversion from shared pipeline] |
|
||||
| **[Market differentiation]** | [e.g. The integration creates a meaningful competitive moat vs [Competitor] who lacks this capability] |
|
||||
|
||||
### For [Your Company]
|
||||
|
||||
| Value | Evidence / Basis |
|
||||
|---|---|
|
||||
| **[Distribution]** | [e.g. Access to [Partner]'s [X,000] customers in [segment] — a segment where we currently have [X] customers] |
|
||||
| **[Credibility]** | [e.g. Association with [Partner]'s brand accelerates enterprise sales cycles — [Partner] is trusted by [X] of the Fortune 500] |
|
||||
| **[Revenue]** | [e.g. Target [X] referral customers in Year 1 at average ACV of [£X] = [£X ARR]] |
|
||||
| **[Product]** | [e.g. [Partner]'s data / capability enhances [specific part of our product] — improving [user outcome]] |
|
||||
|
||||
---
|
||||
|
||||
## 4. Commercial Model
|
||||
|
||||
**Proposed commercial terms:**
|
||||
|
||||
| Term | Proposal | Notes |
|
||||
|---|---|---|
|
||||
| **Revenue share** | [e.g. [X%] of ARR from customers referred by [Partner]] | [Standard in this category: [X–Y%] range] |
|
||||
| **Referral fee** | [e.g. £[X] per qualified lead that converts] | [Or: flat fee per introduction vs % of closed deal] |
|
||||
| **Licensing / access** | [e.g. [Partner] provides API access at no cost in exchange for integration and co-marketing] | [...] |
|
||||
| **Co-marketing investment** | [e.g. Each party commits [£X] to joint marketing activities per quarter] | [...] |
|
||||
| **Minimum commitment** | [e.g. [X] qualified referrals per quarter / [£X] GMV per year] | [Optional — only if there's a meaningful minimum that makes sense] |
|
||||
|
||||
**Payment terms:** [Monthly / Quarterly in arrears / Annual true-up]
|
||||
|
||||
**What we're not proposing:** [Be explicit about what's off the table — e.g. equity / exclusivity in all markets / upfront payment]
|
||||
|
||||
---
|
||||
|
||||
## 5. Joint Go-to-Market Plan
|
||||
|
||||
**Phase 1: Foundation (Months 1–2)**
|
||||
|
||||
| Activity | Owner | Timeline |
|
||||
|---|---|---|
|
||||
| Technical integration scoped and resourced | [Engineering at both companies] | [Month 1] |
|
||||
| Partnership launch announcement drafted | [Marketing at both companies] | [Month 1] |
|
||||
| Joint customer case study identified | [CSM at both companies] | [Month 2] |
|
||||
| Partner enablement — each team trained on the other's product | [Partnership lead, both sides] | [Month 2] |
|
||||
|
||||
**Phase 2: Launch (Month 3)**
|
||||
|
||||
| Activity | Owner | Timeline |
|
||||
|---|---|---|
|
||||
| Integration live in both products / marketplace | [Engineering] | [Month 3] |
|
||||
| Joint press release / blog post / email announcement | [Marketing] | [Month 3] |
|
||||
| First joint webinar | [Both companies] | [Month 3] |
|
||||
| First joint pipeline reviewed | [Partnership leads] | [Month 3] |
|
||||
|
||||
**Phase 3: Scale (Months 4–12)**
|
||||
|
||||
| Activity | Owner | Cadence |
|
||||
|---|---|---|
|
||||
| Co-sell on named accounts | [AE at both companies] | [Monthly] |
|
||||
| Joint content (blog, webinar, case study) | [Marketing] | [Quarterly] |
|
||||
| Pipeline and revenue review | [Partnership leads] | [Monthly] |
|
||||
| Partnership QBR | [VP level, both companies] | [Quarterly] |
|
||||
|
||||
---
|
||||
|
||||
## 6. Success Metrics
|
||||
|
||||
How we'll know the partnership is working:
|
||||
|
||||
| Metric | Year 1 target | Measurement |
|
||||
|---|---|---|
|
||||
| Customers referred (each direction) | [X] | [CRM tracking — tagged as partner-sourced] |
|
||||
| Revenue from partnership | [£/$/€ X ARR] | [CRM + finance reporting] |
|
||||
| Integration adoption | [X% of mutual customers using integration] | [Product analytics] |
|
||||
| Customer satisfaction with integration | [NPS ≥ X] | [Post-integration survey] |
|
||||
| Joint pipeline generated | [£X] | [Quarterly pipeline review] |
|
||||
|
||||
**Review cadence:** Monthly partnership lead check-in + Quarterly business review at VP level
|
||||
|
||||
---
|
||||
|
||||
## 7. Governance & Operations
|
||||
|
||||
**Partnership contacts:**
|
||||
|
||||
| Role | [Your Company] | [Partner] |
|
||||
|---|---|---|
|
||||
| Partnership lead (day-to-day) | [Name, email] | [TBC] |
|
||||
| Executive sponsor | [Name, title] | [TBC] |
|
||||
| Technical lead | [Name] | [TBC] |
|
||||
| Marketing lead | [Name] | [TBC] |
|
||||
|
||||
**Decision-making:**
|
||||
- Day-to-day partnership operations: partnership leads
|
||||
- Commercial term changes: VP-level approval from both parties
|
||||
- Partnership termination: CEO/MD sign-off + [X days] written notice
|
||||
|
||||
**Legal framework:**
|
||||
- [ ] Partnership agreement / MOU to be drafted by [Company]'s legal team
|
||||
- [ ] Data processing agreement (if personal data is shared)
|
||||
- [ ] NDAs: [already in place / to be signed before detailed discussions]
|
||||
- [ ] IP ownership: [Clarify who owns jointly developed materials, integrations, content]
|
||||
|
||||
---
|
||||
|
||||
## 8. Risks & Mitigations
|
||||
|
||||
| Risk | Likelihood | Mitigation |
|
||||
|---|---|---|
|
||||
| Partnership champion leaves [Partner] | M | Ensure VP-level sponsorship; build multiple relationships |
|
||||
| Integration takes longer than planned | M | Scope technical work in Phase 1; set realistic launch commitment |
|
||||
| Low adoption of the integration | M | Include in onboarding for both products; co-market to existing customers not just new |
|
||||
| Partner signs with our competitor | L | Discuss exclusivity options; prioritise quick launch to create switching costs |
|
||||
| Commercial model becomes imbalanced | L | Quarterly review with clear exit terms if targets are consistently missed |
|
||||
|
||||
---
|
||||
|
||||
## 9. Proposed Next Steps
|
||||
|
||||
| # | Action | Owner | By when |
|
||||
|---|---|---|---|
|
||||
| 1 | [Partner] reviews this proposal and provides feedback | [[Partner name]] | [Date] |
|
||||
| 2 | Both parties sign NDA (if not already in place) | [Legal, both sides] | [Before next meeting] |
|
||||
| 3 | Technical discovery call — assess integration feasibility | [Engineering leads] | [Date] |
|
||||
| 4 | Commercial terms negotiation | [Partnership leads / VP] | [Date] |
|
||||
| 5 | MOU / partnership agreement drafted and signed | [Legal] | [Date] |
|
||||
| 6 | Integration and launch planning begins | [Both teams] | [Date] |
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Value proposition for the partner is written from their perspective — not yours
|
||||
- [ ] Commercial model includes specific numbers, not just structure
|
||||
- [ ] "What we're not proposing" section prevents misaligned expectations
|
||||
- [ ] Go-to-market plan has named owners and dates, not "TBD"
|
||||
- [ ] Success metrics are agreed bilaterally — not set unilaterally
|
||||
- [ ] Risks section includes the most uncomfortable risk (partner signs with a competitor)
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Write a partnership proposal for [Company] to partner with [Partner]"
|
||||
- "Draft a co-marketing partnership brief between us and [Partner]"
|
||||
- "Create a reseller partnership proposal for [Company]"
|
||||
- "Build the business case for a strategic partnership with [Partner]"
|
||||
- "Structure a technology integration partnership proposal"
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not write the value proposition from your own perspective — the "For Partner" section must be written from the partner's point of view, in the language of their goals and their customers
|
||||
- [ ] Do not leave commercial terms as structure without numbers — a proposal that says "revenue share" without stating the percentage is not a proposal, it is a conversation opener
|
||||
- [ ] Do not omit the "What we're not proposing" section — leaving unstated assumptions creates misaligned expectations that derail negotiations later
|
||||
- [ ] Do not set success metrics unilaterally — metrics that only your company controls or cares about will not earn partner commitment
|
||||
- [ ] Do not write a go-to-market plan with "TBD" owners — every activity must have a named owner on at least one side before the proposal goes out
|
||||
@@ -0,0 +1,103 @@
|
||||
# Proposal Writer Skill
|
||||
|
||||
Writes commercial proposals that win business — structured around the prospect problem, not the product.
|
||||
|
||||
## Required Inputs
|
||||
- **Prospect company and contact**
|
||||
- **Their problem or goal** (from discovery — be specific)
|
||||
- **Your proposed solution**
|
||||
- **Commercial terms** (pricing, payment terms, contract length)
|
||||
- **Timeline**
|
||||
- **Key stakeholders** who will read this
|
||||
- **Tone** (formal / conversational / technical)
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
|
||||
# Proposal: [Brief description of what you are solving]
|
||||
**Prepared for:** [Contact, Title] | [Company]
|
||||
**Prepared by:** [Name] | [Your Company]
|
||||
**Date:** [Date] | **Valid until:** [Date]
|
||||
|
||||
---
|
||||
|
||||
### Understanding Your Situation
|
||||
[2-3 paragraphs. Demonstrate you listened. Describe their situation, problem, and impact of not solving it in their words. This section should make them think "yes, exactly." Generic boilerplate here = proposal goes in the bin.]
|
||||
|
||||
**The key challenge:** [One sentence — the core problem]
|
||||
**The impact:** [What this costs them]
|
||||
**What you have tried:** [Acknowledge prior attempts]
|
||||
|
||||
---
|
||||
|
||||
### Our Proposed Approach
|
||||
|
||||
**What we will do** (3-5 deliverables or phases)
|
||||
|
||||
**Phase 1: [Name]** (Timeline: [Weeks 1-2])
|
||||
[What happens, what is delivered, what customer input is needed]
|
||||
|
||||
**Phase 2: [Name]** (Timeline: [Weeks 3-6])
|
||||
|
||||
**What you will get** (outcomes, not features)
|
||||
- [Outcome 1]
|
||||
- [Outcome 2]
|
||||
|
||||
**What success looks like**
|
||||
[How both parties know this worked]
|
||||
|
||||
---
|
||||
|
||||
### Why [Your Company]
|
||||
[3-4 sentences. Specific to their situation. Reference similar customers. Generic "why us" sections are skipped.]
|
||||
|
||||
---
|
||||
|
||||
### Investment
|
||||
|
||||
| Item | Description | Investment |
|
||||
|---|---|---|
|
||||
| [Component 1] | [Description] | £[amount] |
|
||||
| **Total** | | **£[total]** |
|
||||
|
||||
**Payment terms:** [Terms]
|
||||
**Included:** [What is in]
|
||||
**Not included:** [What is out — prevents scope disputes]
|
||||
|
||||
---
|
||||
|
||||
### Timeline
|
||||
| Milestone | Date |
|
||||
|---|---|
|
||||
| Contract signed | [Date] |
|
||||
| Kickoff | [Date] |
|
||||
| Delivery | [Date] |
|
||||
|
||||
---
|
||||
|
||||
### Next Steps
|
||||
1. [Sign / reply / schedule] by [date]
|
||||
2. We will send contract and confirm kickoff
|
||||
3. [Any immediate action]
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] "Understanding Your Situation" reflects what was learned in discovery (not generic)
|
||||
- [ ] Outcomes are listed (not just deliverables or features)
|
||||
- [ ] "Not included" section is explicit to prevent scope disputes later
|
||||
- [ ] Next steps include a specific date and named action
|
||||
- [ ] "Valid until" date is included to create urgency
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not lead with the solution before establishing that the problem is understood — the proposal must demonstrate problem comprehension first
|
||||
- [ ] Do not use vague investment language like "competitive pricing" — every proposal must state a specific price or range
|
||||
- [ ] Do not omit a "not included" section — undefined scope leads to disputes after the proposal is accepted
|
||||
- [ ] Do not forget a "valid until" date — proposals without expiry create awkward situations and stale pricing
|
||||
- [ ] Do not list next steps without naming who is responsible for each and what the expected timeline is
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Write a proposal for [prospect] to [solve their problem]"
|
||||
- "Draft a statement of work for [project]"
|
||||
- "Turn my discovery notes into a proposal"
|
||||
@@ -0,0 +1,91 @@
|
||||
# Sales Battlecard Skill
|
||||
|
||||
Produces a practical one-page competitive battlecard that sales reps can use in calls — not a theoretical analysis.
|
||||
|
||||
## Required Inputs
|
||||
- **Your product/company**
|
||||
- **Competitor name**
|
||||
- **Your target customer** (ICP)
|
||||
- **Your top 3 differentiators** vs this competitor
|
||||
- **Common objections** when competing against them
|
||||
- **Known competitor weaknesses**
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
|
||||
# Battlecard: [Your Product] vs [Competitor]
|
||||
Updated: [Date] — Review quarterly
|
||||
|
||||
---
|
||||
|
||||
### In One Sentence
|
||||
When a prospect mentions [Competitor], say: "[Your positioning in one sentence]"
|
||||
|
||||
---
|
||||
|
||||
### Why Customers Choose [Competitor]
|
||||
(Be honest about their genuine strengths)
|
||||
- [Strength 1]
|
||||
- [Strength 2]
|
||||
|
||||
---
|
||||
|
||||
### Why Customers Choose Us
|
||||
(Specific differentiators with proof points)
|
||||
- **[Differentiator 1]:** [Proof point — customer outcome or capability]
|
||||
- **[Differentiator 2]:** [Proof point]
|
||||
|
||||
---
|
||||
|
||||
### Objection Responses
|
||||
|
||||
**"[Competitor] is cheaper"**
|
||||
"You are right their list price is lower. What our customers find is [specific TCO difference]. [Customer] saw [result]. Should we explore total cost of ownership?"
|
||||
|
||||
**"We already use [Competitor]"**
|
||||
"That is helpful. What is working well? [Listen] And what is one thing you wish was better?"
|
||||
|
||||
**"[Competitor] has [feature] you do not"**
|
||||
"You are right. What problem are you solving with that feature? [Listen] Here is how our customers solve that..."
|
||||
|
||||
---
|
||||
|
||||
### Landmines to Plant
|
||||
- "How do you currently handle [area where competitor is weak]?"
|
||||
- "What happens when you need to [scenario competitor struggles with]?"
|
||||
|
||||
---
|
||||
|
||||
### Traps to Avoid
|
||||
- Never badmouth [Competitor] directly
|
||||
- Do not lead with features — lead with the prospect problem
|
||||
- Do not claim you do everything better — be specific about where you win
|
||||
|
||||
---
|
||||
|
||||
### When We Win / When We Lose
|
||||
We win when: [Scenario — e.g. customer prioritises outcome over price]
|
||||
We lose when: [Honest scenario — e.g. primary driver is lowest upfront cost]
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Competitor strengths are listed honestly (not minimised)
|
||||
- [ ] Differentiators have proof points (not just claims)
|
||||
- [ ] Objection responses are conversational (not scripted-sounding)
|
||||
- [ ] Landmine questions are natural and non-confrontational
|
||||
- [ ] "When we lose" is included and honest
|
||||
- [ ] Battlecard has a review date
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Build a battlecard against [competitor]"
|
||||
- "Create a competitive cheat sheet for [competitor]"
|
||||
- "Write objection handling for [competitor] comparisons"
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not minimise or ignore genuine competitor strengths — sales reps who encounter them unprepared lose credibility
|
||||
- [ ] Do not write differentiators without proof points — a claim without evidence is marketing, not a battlecard
|
||||
- [ ] Do not make the battlecard exhaustive — it is a one-page cheat sheet, not a full competitive analysis
|
||||
- [ ] Do not include a "When we lose" section that is dishonestly optimistic — honest loss scenarios build rep trust
|
||||
- [ ] Do not skip the review date — an outdated battlecard with wrong information is worse than no battlecard
|
||||
@@ -0,0 +1,133 @@
|
||||
# Sales Forecasting Model Skill
|
||||
|
||||
Produces a structured sales forecast framework — from pipeline conversion modelling to scenario analysis. Built for revenue and sales leaders who need a defensible forecast, not a spreadsheet guess.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Business type** (SaaS / Transactional / Services / Marketplace)
|
||||
- **Forecast period** (monthly / quarterly / annual)
|
||||
- **Sales motion** (inbound / outbound / channel / PLG / mixed)
|
||||
- **Current pipeline data** (number of deals, stages, values — rough is fine)
|
||||
- **Historical conversion rates** (if available — otherwise model will flag as assumption)
|
||||
- **Average deal size and sales cycle length**
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
|
||||
# Sales Forecast: [Team / Business] — [Period]
|
||||
|
||||
**Forecast type:** [Bottom-up pipeline / Top-down quota / Capacity-based / Hybrid]
|
||||
**Period:** [Month / Quarter / Year]
|
||||
**Created:** [Date]
|
||||
**Forecast owner:** [Name]
|
||||
|
||||
---
|
||||
|
||||
## 1. Forecast Methodology
|
||||
|
||||
**Chosen approach:** [Bottom-up / Top-down / Hybrid] — and why for this context.
|
||||
|
||||
Bottom-up (recommended when pipeline data exists):
|
||||
> Start from real deals in the pipeline. Apply stage-by-stage conversion rates. Sum to a revenue number.
|
||||
|
||||
Top-down (useful for planning, not for calling a number):
|
||||
> Start from market or quota. Work backwards to activity targets.
|
||||
|
||||
---
|
||||
|
||||
## 2. Pipeline Stage Model
|
||||
|
||||
Define the sales stages and the expected conversion rate between each:
|
||||
|
||||
| Stage | Description | % of deals that advance | Avg time in stage |
|
||||
|---|---|---|---|
|
||||
| Prospect | Identified, not contacted | — | — |
|
||||
| Qualified | Discovery done, confirmed fit | [X%] | [N days] |
|
||||
| Proposal | Proposal sent | [X%] | [N days] |
|
||||
| Negotiation | Commercial terms being agreed | [X%] | [N days] |
|
||||
| Closed Won | Contract signed | [X%] | — |
|
||||
|
||||
**Overall pipeline conversion rate:** [X%] (Qualified → Closed Won)
|
||||
**Average sales cycle:** [N days from Qualified to Close]
|
||||
|
||||
---
|
||||
|
||||
## 3. Current Pipeline Snapshot
|
||||
|
||||
| Stage | Number of deals | Total value | Expected close (weighted) |
|
||||
|---|---|---|---|
|
||||
| Qualified | [N] | £[X] | £[X × conversion %] |
|
||||
| Proposal | [N] | £[X] | £[X × conversion %] |
|
||||
| Negotiation | [N] | £[X] | £[X × conversion %] |
|
||||
| **Total** | | **£[X]** | **£[weighted total]** |
|
||||
|
||||
**Coverage ratio:** [Weighted pipeline ÷ target = X×]
|
||||
*Rule of thumb: 3× pipeline coverage is needed for confident forecast; 2× is tight; below 1.5× is at risk.*
|
||||
|
||||
---
|
||||
|
||||
## 4. Scenario Analysis
|
||||
|
||||
| Scenario | Assumption | Revenue | Probability |
|
||||
|---|---|---|---|
|
||||
| Upside | All Negotiation + top 50% of Proposal close | £[X] | [%] |
|
||||
| Base | Weighted pipeline conversion at historical rates | £[X] | [%] |
|
||||
| Downside | Conversion rates drop 20% from historical | £[X] | [%] |
|
||||
|
||||
**Committed forecast:** £[X] — [The number the forecast owner is willing to call. Between base and downside.]
|
||||
|
||||
---
|
||||
|
||||
## 5. Key Assumptions Log
|
||||
|
||||
Every forecast is a set of assumptions. Name them explicitly so they can be updated:
|
||||
|
||||
| Assumption | Value | Confidence | Source | Last updated |
|
||||
|---|---|---|---|---|
|
||||
| Avg deal size | £[X] | High/Med/Low | [Last N deals] | [Date] |
|
||||
| Sales cycle | [N days] | | | |
|
||||
| Close rate from Proposal | [X%] | | | |
|
||||
| Seasonal factor | [e.g. Q4 +20%] | | | |
|
||||
| Churn/contraction | [X% of ARR at risk] | | | |
|
||||
|
||||
---
|
||||
|
||||
## 6. Activity-Based Sanity Check
|
||||
|
||||
Work backwards from the forecast to check if the required activity is achievable:
|
||||
|
||||
To hit £[target]:
|
||||
- Deals needed to close: [N] (target ÷ avg deal size)
|
||||
- Qualified pipeline needed (at current conversion): [N deals or £value]
|
||||
- Discovery calls needed per week to build that pipeline: [N]
|
||||
- Outreach needed per week (at [X%] meeting rate): [N]
|
||||
|
||||
**Does the team have capacity to generate this?** [Yes / No — flag if not]
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Forecast methodology is stated (not just a number)
|
||||
- [ ] Stage conversion rates are based on historical data or flagged as assumptions
|
||||
- [ ] Coverage ratio is calculated
|
||||
- [ ] Three scenarios are modelled (not just one number)
|
||||
- [ ] Assumption log is explicit and dated
|
||||
- [ ] Activity sanity check confirms the forecast is achievable with current capacity
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Build a sales forecast for [period]"
|
||||
- "Create a pipeline model for [team/business]"
|
||||
- "Help me build a bottom-up revenue forecast"
|
||||
- "What is our forecast for Q[N] based on current pipeline?"
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not present a single forecast number without scenario analysis — a forecast without upside and downside cases hides risk
|
||||
- [ ] Do not use 100% confidence on conversion rates that are not backed by historical data — flag them as assumptions
|
||||
- [ ] Do not skip the activity sanity check — a forecast number that requires unreachable activity levels is not credible
|
||||
- [ ] Do not use top-down quota as the only forecast method when pipeline data exists — bottom-up is more accurate and defensible
|
||||
- [ ] Do not omit the coverage ratio — without it, stakeholders cannot assess whether the pipeline is sufficient to hit target
|
||||
Reference in New Issue
Block a user