jumpstart-mode 1.1.13 → 1.1.14

package/.github/skills/gtm-ai-gtm/SKILL.md

@@ -0,0 +1,324 @@
+---
+name: gtm-ai-gtm
+description: |
+   Go-to-market strategy for AI products, AI teammate offerings, and AI Innovation Pod style services. Use this skill whenever the user needs client-safe positioning, seller talk tracks, objection handling, packaging, pricing guidance, Jump Start to Pod recommendation logic, or competitive differentiation for AI solutions. Trigger even when the user asks indirectly for proposal language, workshop follow-up, buyer messaging, executive framing, "who owns it when it breaks?", or whether an AI offer should be framed as a copilot, teammate, agent, Jump Start, Pod, or hybrid motion.
+license: MIT
+metadata:
+   author: Smit Patel (https://linkedin.com/in/smitkpatel)
+   source: https://github.com/beingsmit/technical-product-gtm
+---
+
+# AI GTM
+
+Use this skill to turn rough AI offering ideas into practical go-to-market artifacts that fit this repo's Jump Start and AI Innovation Pod motions.
+
+## What good output looks like
+
+Produce consulting-grade output, not generic startup advice. In most cases the answer should:
+
+1. Clarify the offer motion: product, service, Jump Start, Pod, or hybrid.
+2. Make the enterprise buying risk explicit: ownership, controls, adoption, and operational readiness.
+3. Recommend positioning language that matches the buyer and the actual autonomy of the solution.
+4. Separate confirmed facts, assumptions, risks, dependencies, and next-step recommendations.
+5. Give the user a reusable artifact such as a messaging brief, objection matrix, recommendation memo, or seller talk track.
+
+## Workflow
+
+### 1. Classify the motion
+
+Quickly identify which motion the user actually needs:
+
+- `AI product GTM`: messaging, packaging, pricing, category framing, differentiation.
+- `Jump Start entry motion`: discovery-first recommendation when clarity is low or multiple use cases compete.
+- `AI Innovation Pod motion`: subscription or capability-based positioning for validated work that needs speed and execution.
+- `Hybrid motion`: Pod leads the AI layer while adjacent teams or the client own app, data, testing, or run scope.
+
+If the request is vague, bias toward a recommendation with rationale rather than pretending the motion is already settled.
+
+### 2. Ground the answer in enterprise buying reality
+
+Do not treat trust as a generic brand problem. For AI offers, trust usually means operational accountability.
+
+- Who monitors the solution?
+- Who investigates failures?
+- Who approves rollout, rollback, or customer communication?
+- What evidence proves the team can operate the solution safely?
+
+Use [references/enterprise-ai-objections.md](references/enterprise-ai-objections.md) when the user needs objection handling, trust framing, demo guidance, or enterprise readiness language.
+
+### 3. Choose the positioning frame
+
+Default to the least alarming framing that is still honest about capability:
+
+- `Copilot`: the AI suggests and a human decides each time.
+- `Teammate`: the AI handles meaningful work but the human stays in control.
+- `Agent`: the AI acts with meaningful autonomy and the audience is ready for that language.
+
+For enterprise buyers, `teammate` is usually the safest default for action-taking AI unless the audience explicitly wants autonomy-forward language.
+
+### 4. Choose the commercial and engagement path
+
+When the request touches Jump Starts or Pods, recommend the entry point that matches maturity:
+
+- Use `Jump Start` when the client needs discovery, prioritization, feasibility, or stakeholder alignment.
+- Use `Pod` when the use case is validated and the client needs a cohesive build-and-iterate capability.
+- Use `Hybrid` when the AI layer must integrate with broader application, data, testing, or operations teams.
+
+Use [references/jumpstart-and-pod-alignment.md](references/jumpstart-and-pod-alignment.md) when the answer should align to repo language, tiering, and handoff patterns.
+
+### 5. Make packaging and pricing defensible
+
+Prefer practical pricing and packaging logic over token-level imitation:
+
+- Seat-based when value scales mostly with users.
+- Hybrid base-plus-variable when usage or outcome volume varies materially.
+- Subscription or tiered capability framing for Pod-style services.
+
+Do not overcommit on outcomes that depend on client data quality, change management, or run-state ownership. Use [references/pricing-and-packaging.md](references/pricing-and-packaging.md) when the user needs a pricing recommendation or commercial narrative.
+
+### 6. Produce a reusable artifact
+
+Unless the user asks for a different format, deliver one of these:
+
+- a client-ready GTM brief
+- a Jump Start versus Pod recommendation
+- an objection-response matrix
+- a seller talk track
+- a positioning comparison table
+- a proposal-ready background and scope narrative
+
+Start from bundled templates when possible:
+
+- [templates/client-gtm-brief.md](templates/client-gtm-brief.md)
+- [templates/jumpstart-to-pod-recommendation-matrix.md](templates/jumpstart-to-pod-recommendation-matrix.md)
+
+## Default response structures
+
+### For positioning or messaging asks
+
+Use this section order unless the user requests something else:
+
+## Executive summary
+## Buyer problem and context
+## Recommended positioning
+## Why this framing works
+## Objections and responses
+## Risks and assumptions
+## Next best action
+
+### For Jump Start or Pod recommendation asks
+
+Use this section order unless the user requests something else:
+
+## Objective
+## Current situation
+## Recommended entry motion
+## Why Jump Start, Pod, or Hybrid
+## Proposed scope and boundaries
+## Dependencies and client responsibilities
+## Risks and open questions
+## Suggested next step
+
+## Heuristics
+
+- Position on business value and operational fit before feature novelty.
+- If the buyer fears replacement, shift from autonomy language to control and augmentation language.
+- If the work is ambiguous, recommend discovery before implementation.
+- If the offer spans multiple teams, name explicit handoffs instead of implying the Pod owns everything.
+- For AI service motions, focus reporting on validated assumptions, backlog progress, working outputs, and decisions made, not hours.
+- When differentiating, prefer structural advantage over temporary model performance claims.
+
+## Anti-patterns
+
+Avoid these common mistakes:
+
+- promising production certainty for systems that still need discovery
+- using `autonomous` as default language for enterprise audiences
+- answering accountability objections with only accuracy metrics
+- hiding failure modes in demos or proposal language
+- presenting Pod work as a replacement for every adjacent delivery capability
+- using pricing logic copied from model vendors without tying it to buyer value
+
+## Resource map
+
+- [references/jumpstart-and-pod-alignment.md](references/jumpstart-and-pod-alignment.md): Jump Start, Pod, and hybrid recommendation logic aligned to this repo.
+- [references/enterprise-ai-objections.md](references/enterprise-ai-objections.md): trust, accountability, demo, and objection-handling patterns.
+- [references/pricing-and-packaging.md](references/pricing-and-packaging.md): pricing models and commercial guardrails.
+- [templates/client-gtm-brief.md](templates/client-gtm-brief.md): baseline client-ready output structure.
+- [templates/jumpstart-to-pod-recommendation-matrix.md](templates/jumpstart-to-pod-recommendation-matrix.md): decision matrix for entry motion and next step.
+- [examples/jumpstart-to-pod-recommendation.md](examples/jumpstart-to-pod-recommendation.md): example recommendation memo for a Jump Start to Pod path.
+- [examples/enterprise-ai-teammate-positioning.md](examples/enterprise-ai-teammate-positioning.md): example positioning brief for an AI teammate offer.
+- [evals/evals.json](evals/evals.json): starter evaluation prompts for iterative skill improvement.
+
+## Working style
+
+Stay direct, practical, and client-safe. Tie messaging to workflows, decisions, owners, controls, and measurable outcomes. When information is incomplete, use hypothesis-driven recommendation language instead of pretending certainty.
+2. Identify shared claims (these are commoditized — you can't win here)
+3. Map where you have structural advantage (not just product features)
+4. Find the position competitors can't easily copy
+
+**Structural advantages that work for AI positioning:**
+- Unique data or workflow ownership (you control something competitors can't replicate)
+- Deployment flexibility (on-prem, private cloud, customer-controlled infrastructure)
+- Pricing model innovation (outcome-based, usage-based when competitors are seat-based)
+- Community or ecosystem (network effects that compound over time)
+
+Feature advantages that don't last:
+- "Better accuracy" (competitors catch up in one sprint)
+- "Faster inference" (infrastructure commoditizes)
+- "More integrations" (easy to copy)
+
+**The Test:**
+
+For every positioning claim, ask: Can a competitor copy this with a single product sprint? If yes, it's not defensible. Don't build your GTM on it.
+
+**Common Mistake:**
+
+Claiming you're "better" at what everyone does. In AI, benchmarks change monthly. Position on what's structurally different about your approach, not what's temporarily better about your model.
+
+---
+
+### 8. Ceiling Moment Qualification (Finding High-Intent AI Buyers)
+
+**The Pattern:**
+
+The highest-intent enterprise buyers for AI agents are people who've already adopted a comparable tool and hit its limits. They've invested in learning, they understand the problem space, and they have a clear business case for the upgrade.
+
+**How to Identify Ceiling Moments:**
+
+The prospect has:
+- Used a copilot/assistant tool for 6+ months
+- Hit its limitations (can't handle complex tasks, doesn't work with their stack, not autonomous enough)
+- Low switching costs (the mental model transfers)
+- Clear business case ("we're spending X hours on this manually even with the current tool")
+
+**How to Target Them:**
+
+1. Identify the tool(s) your AI product complements or displaces
+2. Build target lists of companies known to use those tools
+3. Craft outreach around the limitation, not your features:
+   - "Teams using [incumbent] often hit a ceiling when they need [capability your product provides]"
+   - Acknowledge the incumbent has value (don't trash-talk)
+   - Position as "next level," not replacement
+
+**Why This Converts Better:**
+
+Ceiling-moment conversations convert 3-5x vs cold outreach because:
+- Prospect already understands the problem
+- They've already invested in the category
+- They have internal budget allocated
+- They can articulate what's missing
+
+**The Qualification Question:**
+
+"What's the most complex task you've tried to automate with your current tool, and where did it break down?"
+
+If they have a specific answer with specific pain, they're a ceiling-moment buyer. If they say "it works fine," they're not ready.
+
+**Common Mistake:**
+
+Trying to convince tool-naive prospects to adopt AI agents. Bad conversion rates, long education cycles, and they'll compare you to "doing nothing" instead of "doing it better." Target buyers who already believe in the category.
+
+---
+
+## Decision Trees
+
+### Which Positioning Should I Use?
+
+```
+Does your AI act autonomously (no approval per action)?
+├─ Yes → Who are you selling to?
+│   ├─ Developers → "Agent" framing
+│   └─ Enterprises → "Teammate" framing
+└─ No → "Copilot" framing
+```
+
+### Which Pricing Model Should I Use?
+
+```
+Can you measure customer outcomes reliably?
+├─ Yes → Outcome-based (or hybrid with outcome component)
+└─ No → Continue...
+    │
+    Does usage vary 5x+ by customer?
+    ├─ Yes → Hybrid (base + usage)
+    └─ No → Seat-based
+```
+
+### Is This Buyer Ready for AI Agents?
+
+```
+Do they have incident response processes for tool failures?
+├─ Yes → Continue...
+│   │
+│   Do they have on-call rotations for production systems?
+│   ├─ Yes → Qualified buyer
+│   └─ No → Help them build it first
+└─ No → Not ready (come back in 6 months)
+```
+
+---
+
+## Common Mistakes
+
+**1. Using "autonomous" because it sounds impressive**
+   - I've watched this slow deals. "Autonomous" scares enterprises. "Teammate" progresses faster.
+
+**2. Hiding AI failure modes**
+   - Buyers know real-world data is messy. If you don't show failures, they assume you're hiding them.
+
+**3. Treating "will it break production?" as the objection**
+   - Real objection: "who's responsible when it does?" Organizational readiness, not accuracy.
+
+**4. Pricing usage-based AI like OpenAI**
+   - Your cost structure isn't theirs. Price for 20-30% of customer's alternative cost.
+
+**5. Skipping transparency docs before demo**
+   - Order matters. Transparency → Control → Performance → Scale. Don't skip steps.
+
+**6. Demoing perfect AI**
+   - Show mistakes + recovery. Builds more trust than fake perfection.
+
+**7. Selling to buyers who demand 100% accuracy**
+   - They're not ready. Filter for mature buyers with incident response processes.
+
+---
+
+## Quick Reference
+
+**Enterprise objection checklist:**
+- [ ] "Who gets paged when AI breaks production?" → Map to their on-call rotation
+- [ ] "Who debugs AI failures?" → Map to their incident response
+- [ ] "Who owns customer communication?" → Map to their escalation path
+
+**Positioning word choices:**
+- ✅ Teammate, augments, accelerates, you stay in control
+- ❌ Autonomous, replaces, fully automated, AI-first
+
+**Demo structure:**
+1. Problem with quantified cost (30s)
+2. AI attempt including failure/uncertainty (60s)
+3. Human review and override (30s)
+4. Outcome with ROI (30s)
+
+**Trust ladder:**
+1. Transparency (model card, security, explainability)
+2. Control (approval workflows, kill switches, confidence scores)
+3. Performance (benchmarks, case studies, live demo)
+4. Scale (enterprise deployments, compliance, SLAs)
+
+**Pricing hybrid formula:**
+- Base: $X/month (covers fixed costs)
+- Variable: $Y per unit (20-30% of customer's alternative cost)
+
+---
+
+## Related Skills
+
+- **positioning-strategy**: General positioning frameworks and testing
+- **technical-product-pricing**: Pricing models including AI-specific patterns
+- **enterprise-account-planning**: Enterprise AI deal management
+
+---
+
+*Based on enterprise AI agent GTM across developer tools and infrastructure. Patterns drawn from working enterprise deal cycles selling autonomous AI products — some carried directly, others supported alongside sales leadership — including the positioning trap diagnosis that shifted from feature competition to structural differentiation, the ceiling-moment qualification that improved outbound conversion significantly, and frameworks tested across security, operations, and engineering buyer personas. Not theory — lessons from deals where "autonomous" killed conversations and "teammate" converted.*

package/.github/skills/gtm-ai-gtm/evals/evals.json

@@ -0,0 +1,42 @@
+{
+  "skill_name": "gtm-ai-gtm",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "I need a client-facing recommendation for whether we should start this manufacturing client with a Jump Start or go straight into the AI Innovation Pod. They have three possible use cases, no agreed priority, and the CIO wants something concrete to take to the steering committee next month.",
+      "expected_output": "A clear recommendation memo that favors the right entry motion, explains why, and makes scope boundaries and next steps explicit.",
+      "files": [],
+      "expectations": [
+        "The response explicitly recommends Jump Start, Pod, or Hybrid and explains why that motion fits the client's maturity.",
+        "The response includes a steering-committee-ready decision package or named outputs such as prioritized use case, success metrics, ownership, or a gated path into Pod execution.",
+        "The response includes explicit scope boundaries, client responsibilities, or dependencies rather than only messaging.",
+        "The response handles uncertainty explicitly and conditions implementation on discovery outcomes when clarity is low."
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "Help me position our AI code modernization offer for enterprise buyers. The current draft keeps calling it an autonomous agent and buyers keep asking who owns it when it changes production code. I need sharper messaging and objection handling for an executive follow-up email.",
+      "expected_output": "A positioning brief or email-ready response that reframes the offer, handles accountability objections, and avoids autonomy-heavy language where it hurts trust.",
+      "files": [],
+      "expectations": [
+        "The response recommends a safer positioning frame such as teammate or copilot when appropriate for enterprise buyers.",
+        "The response addresses ownership or operational accountability, not just accuracy or ROI.",
+        "The response gives language that could be used in an executive or seller follow-up rather than only abstract analysis.",
+        "The response proposes a controlled next step such as an assessment, pilot, or bounded rollout rather than broad autonomy claims."
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "We are trying to package a new AI operations accelerator. Usage could vary a lot by client, and sales wants to price it like model consumption. I need a practical pricing recommendation and the commercial story we should use in proposals so we do not overpromise.",
+      "expected_output": "A pricing recommendation with rationale, commercial guardrails, and proposal-safe language tied to buyer value and scope boundaries.",
+      "files": [],
+      "expectations": [
+        "The response recommends a pricing model with a rationale tied to buyer value or usage variability.",
+        "The response warns against overcommitting on outcomes that depend on client conditions or adoption.",
+        "The response warns against copying raw model-vendor pricing without translating it into buyer-understood commercial units.",
+        "The response includes proposal-safe commercial language or packaging guidance rather than only naming pricing models.",
+        "The response defines scope boundaries such as included usage bands, overage rules, approval ownership, or run-state responsibilities."
+      ]
+    }
+  ]
+}

package/.github/skills/gtm-ai-gtm/examples/enterprise-ai-teammate-positioning.md

@@ -0,0 +1,31 @@
+# Example: Enterprise AI Teammate Positioning
+
+## Executive Summary
+
+Position the offer as an AI teammate for procurement analysts rather than an autonomous sourcing agent. The buyer is receptive to acceleration, but sensitive to control, auditability, and accountability if a recommendation is wrong.
+
+## Buyer Problem And Context
+
+Procurement teams spend too much time summarizing vendor responses, checking policy fit, and routing exceptions. They want faster cycle time, but they do not want to introduce a tool that appears to replace judgment or create invisible decision risk.
+
+## Recommended Positioning
+
+- Framing: AI teammate for procurement operations
+- Value proposition: accelerates repetitive review and exception triage while keeping analysts in control of supplier and policy decisions
+- Proof points: draft summaries, policy checks, confidence signals, human review step, audit trail
+
+## Why This Framing Works
+
+- "Teammate" reduces replacement anxiety while preserving meaningful value.
+- It matches the actual operating model: the AI handles preparation and triage, but humans still own final decisions.
+- It creates room to discuss controls, approvals, and phased rollout without sounding defensive.
+
+## Objections And Responses
+| Objection | Recommended response |
+| --- | --- |
+| "What happens if it makes the wrong recommendation?" | Start with a low-risk workflow, require analyst approval, and map investigation and rollback to the existing procurement operations process. |
+| "Are you trying to automate our team away?" | No. The goal is to reduce repetitive review work so analysts can spend more time on negotiation, exceptions, and supplier decisions. |
+
+## Suggested Next Step
+
+Propose a short discovery and pilot design session to define one review-heavy workflow, success metrics, approval rules, and the evidence package required for a controlled pilot.

package/.github/skills/gtm-ai-gtm/examples/jumpstart-to-pod-recommendation.md

@@ -0,0 +1,33 @@
+# Example: Jump Start To Pod Recommendation
+
+## Objective
+
+Recommend the right entry motion for a regional insurer that wants AI-enabled claims intake but has not aligned on the first use case, the target workflow, or the operational owner.
+
+## Current Situation
+
+The client believes AI can reduce manual claims intake effort, but the discovery notes show three competing use cases, inconsistent views on data quality, and no shared answer on who would own production support. They want momentum, but they are still deciding what success should look like.
+
+## Recommended Entry Motion
+
+Start with a Jump Start focused on claims intake, document triage, and escalation design. The main risk is not engineering speed; it is selecting the right workflow, defining measurable value, and confirming where automation is operationally safe.
+
+## Why This Motion Fits
+
+- The client has multiple candidate workflows and no agreed first priority.
+- Operations ownership is unclear, which makes a direct autonomy-heavy pitch risky.
+- A Jump Start can convert the current ambiguity into a prioritized roadmap, target-state workflow, architecture view, and recommendation on whether a Pod-led MVP should follow.
+
+## Proposed Follow-On Path
+
+If the workshop confirms a narrow intake workflow with safe rollback points and usable data, recommend a Pod-led MVP focused on one intake segment. Position the Pod as the AI innovation layer that designs and builds the workflow while the client's existing platform team continues to own the surrounding claims system.
+
+## Risks And Dependencies
+
+- Claims taxonomy and source data quality may block scope confidence.
+- The client must identify an operations owner before any autonomous action is proposed.
+- Broader production rollout may require adjacent testing and operational support scope.
+
+## Suggested Next Step
+
+Offer a two-day Jump Start with named outputs: prioritized use case, target workflow, risk register, architecture direction, and go/no-go recommendation for a Pod-led MVP.

package/.github/skills/gtm-ai-gtm/references/enterprise-ai-objections.md

@@ -0,0 +1,80 @@
+# Enterprise AI Objections
+
+Use this reference when the user needs objection handling, messaging for enterprise AI buyers, or guidance on how to demo action-taking AI without creating unnecessary fear.
+
+## The core objection
+
+The real enterprise objection is often not "will the AI ever fail?" It is "who owns the failure when it does?"
+
+Frame trust around operational accountability:
+
+1. `L1 response`: who monitors and gets paged?
+2. `L2 escalation`: who investigates and fixes?
+3. `L3 ownership`: who decides rollback, communication, and commercial response?
+
+If those answers are weak, recommend a lower-risk entry path and a tighter scope.
+
+## Safer framing choices
+
+Use these phrases more often:
+
+- AI teammate
+- augment the team
+- accelerate repetitive work
+- human stays in control
+- start with lower-risk workflows
+
+Use these phrases carefully:
+
+- autonomous
+- fully automated
+- replaces analysts or engineers
+- set it and forget it
+
+## Positioning heuristic
+
+| Capability reality | Best default framing |
+| --- | --- |
+| AI suggests and user decides every time | Copilot |
+| AI performs meaningful work but user still governs the outcome | Teammate |
+| AI acts with meaningful autonomy and the audience is autonomy-friendly | Agent |
+
+## Demo pattern
+
+Do not show only the perfect path. A stronger enterprise demo usually shows:
+
+1. the current manual problem and cost
+2. the AI attempt on realistic data
+3. uncertainty, failure, or a needed correction
+4. the human review and control point
+5. the quantified improvement
+
+This builds more trust than a polished "everything worked" demo.
+
+## Objection response moves
+
+### "What happens when it breaks?"
+
+Respond with a failure-handling scenario, not an accuracy boast. Walk the buyer through alerts, triage, rollback, and scope control.
+
+### "How do we trust this in production?"
+
+Answer with evidence in this order:
+
+1. transparency: what it does, what data it touches, what controls exist
+2. control: approval points, fallbacks, kill switches, audit trail
+3. performance: baseline comparison, case studies, pilot outcomes
+4. scale: enterprise readiness, operational model, support boundaries
+
+### "Are you replacing our team?"
+
+Reframe to augmentation and capacity. Focus on repetitive work, decision support, and throughput rather than headcount elimination.
+
+## Qualification questions
+
+Ask these when the buyer sounds excited but operationally unready:
+
+- What happens today when a tool or automation causes a production issue?
+- Who would own investigation if this workflow failed at 2 a.m.?
+- Which environments or workflows are safe enough for a phased rollout?
+- What evidence would your operations or risk team need before they approve broader deployment?

package/.github/skills/gtm-ai-gtm/references/jumpstart-and-pod-alignment.md

@@ -0,0 +1,72 @@
+# Jump Start And Pod Alignment
+
+Use this reference when the user needs guidance on whether to lead with a Jump Start, move directly to the AI Innovation Pod, or recommend a hybrid motion.
+
+## Decision logic
+
+| Situation | Recommended motion | Why |
+| --- | --- | --- |
+| The client has multiple candidate use cases, low clarity, or weak stakeholder alignment | Jump Start | Discovery and prioritization are the highest-value next step |
+| The use case is already validated and the client needs working capability quickly | Pod | A pre-integrated team accelerates architecture, build, and iteration |
+| The AI layer is only one part of a broader application or transformation program | Hybrid | The Pod can lead the AI workstream while adjacent teams own the surrounding scope |
+| The client expects long-term run-state ownership, enterprise platform modernization, and broad app delivery from one small team | Reframe | Position a broader Sogeti solution, not a Pod-only motion |
+
+## Buyer signals
+
+Jump Start signals:
+
+- "We know AI matters but we are not sure where to start."
+- "We have several use cases and need help choosing."
+- "We need an executive-ready roadmap before we ask for funding."
+- "We want to see what is feasible in our environment."
+
+Pod signals:
+
+- "We have a specific use case and need to build fast."
+- "We need architecture plus hands-on implementation."
+- "We want a working MVP or pilot in users' hands in weeks, not quarters."
+- "We need a cohesive team, not a few disconnected specialists."
+
+Hybrid signals:
+
+- "Our platform or app team will stay in place, but we need AI specialists."
+- "We need the Pod to define the AI layer while another team owns app engineering or data engineering."
+- "We want the Pod to establish the scaffold and then hand off industrialization."
+
+## Scope boundaries to state explicitly
+
+Always name what the Pod does not automatically own:
+
+- enterprise platform ownership
+- privileged release approvals
+- long-term run and support
+- broad application engineering outside the AI use case
+- enterprise data platform modernization unless that scope is explicitly included
+
+## Delivery pattern guidance
+
+Recommend one of these patterns explicitly:
+
+1. `Pod-led innovation sprint`: use when the primary risk is discovery, feasibility, or proving value quickly.
+2. `Embedded co-delivery`: use when the client already has adjacent app, data, QA, or operations teams.
+3. `Accelerate and handoff`: use when the Pod should establish architecture, first release scaffolding, and working patterns before transition.
+
+## Suggested recommendation language
+
+### When recommending Jump Start first
+
+Recommend a Jump Start when the main risk is choosing the right use case, aligning stakeholders, and defining a realistic path to value. Position the workshop as the shortest route to a scoped backlog, architecture direction, and decision-ready next step rather than as a generic training event.
+
+### When recommending direct Pod entry
+
+Recommend direct Pod entry when the client has enough clarity to start building and the main need is speed, multidisciplinary execution, and a rapid feedback loop. Position the Pod as a specialized AI innovation layer that can lead the AI workstream, not as a replacement for every adjacent delivery function.
+
+### When recommending a hybrid
+
+Recommend a hybrid motion when the client already has strong delivery muscles in app engineering, data, QA, or operations but lacks specialized AI design and execution capacity. Make the handoffs explicit so the proposal does not hide ownership risk.
+
+## Handoff language
+
+Use language like this when the answer needs to connect Jump Start to Pod work:
+
+"The Jump Start should produce the prioritized use case, target workflow, success metrics, architecture direction, risk register, and recommendation on whether to continue into a Pod-led MVP. If the outputs confirm value and feasibility, the Pod becomes the execution layer that converts the validated concept into a working release path."

package/.github/skills/gtm-ai-gtm/references/pricing-and-packaging.md

@@ -0,0 +1,41 @@
+# Pricing And Packaging
+
+Use this reference when the user needs pricing guidance, offer packaging, or a commercial story for AI products or Pod-style services.
+
+## Pricing models
+
+| Model | Best fit | Main risk | Guidance |
+| --- | --- | --- | --- |
+| Seat-based | Predictable user-level augmentation | Heavy users may be underpriced | Use when usage variance is modest and value scales with adoption |
+| Usage-based | Variable machine work with clear units | Customers optimize to use less | Use only when the buyer understands the unit and the value per unit is clear |
+| Outcome-based | Outcomes can be measured and attributed cleanly | Vendor absorbs too much risk if outcomes are noisy | Use carefully and avoid when many dependencies sit outside the offer |
+| Hybrid | Usage varies materially but some base capability is fixed | Overcomplex pricing if poorly explained | Often the safest default for AI offers with variable demand |
+
+## Packaging rules of thumb
+
+- Price against customer alternative cost, not model-provider list price.
+- For AI product motions, align variable pricing to a meaningful unit of value, not raw tokens unless the user explicitly needs that level of detail.
+- For Pod motions, frame the offer as subscription access to integrated capability, velocity, and outcome-oriented execution rather than hours.
+- Separate discovery, prototype, productionization, and run-state economics. Do not blur them.
+
+## Jump Start and Pod commercial guardrails
+
+When the ask involves Jump Starts or Pods:
+
+- Treat the Jump Start as a fixed-scope discovery and design motion.
+- Treat the Pod as a flexible capability model whose tier should match maturity, urgency, and depth of execution.
+- State that scaled build, platform ownership, or managed run services may require adjacent teams or follow-on scope.
+
+## Commercial language patterns
+
+Use language like:
+
+- "subscription access to a pre-integrated AI innovation capability"
+- "shared focus on validated assumptions, working outputs, and decision velocity"
+- "the right entry point depends on clarity, urgency, and execution readiness"
+
+Avoid language like:
+
+- "guaranteed business outcome" when the client controls key dependencies
+- "all-in-one replacement" when multiple delivery functions are clearly needed
+- "priced just like model consumption" when the offer includes delivery, governance, or change work

package/.github/skills/gtm-ai-gtm/templates/client-gtm-brief.md

@@ -0,0 +1,40 @@
+# [Client Or Offer Name]
+
+## Executive Summary
+[2-4 sentences on the buyer situation, the recommended GTM motion, and why it matters now.]
+
+## Buyer Problem And Context
+- Buyer type:
+- Current pain or trigger:
+- Why existing approaches fall short:
+- Urgency or business driver:
+
+## Recommended Positioning
+- Recommended framing:
+- One-sentence value proposition:
+- Supporting proof points:
+- What not to imply:
+
+## Recommended Entry Motion
+- Jump Start, Pod, product, or hybrid:
+- Why this is the right starting point:
+- What should happen next:
+
+## Commercial And Packaging Guidance
+- Pricing or packaging model:
+- Scope boundary:
+- Key assumption:
+
+## Likely Objections And Responses
+| Objection | Recommended response |
+| --- | --- |
+| [Objection] | [Response] |
+
+## Risks, Assumptions, And Dependencies
+- Confirmed facts:
+- Assumptions:
+- Risks:
+- Client responsibilities:
+
+## Recommended Next Step
+[Specific next meeting, workshop, or proposal action.]