@rubytech/create-maxy-code 0.1.169 → 0.1.170

package/payload/platform/plugins/venture-studio/skills/zero-to-prototype/references/positioning-statement.md

@@ -1,179 +0,0 @@
-# Positioning Statement
-
-## Purpose
-Create a clear, compelling articulation of who your product is for, what problem it solves, and why it's different—the foundation for all marketing and sales.
-
-## When to Use
-- Refining your value proposition after customer discovery
-- Creating marketing and sales materials
-- When product-market fit feels off (message not resonating)
-- Aligning team on target customer and differentiation
-- Preparing for investor pitches or product launches
-- Evaluating whether to pursue a new market or segment
-
-## Process
-
-### 1. The Positioning Statement Template
-
-**For** [specific target customer]
-**Who** [statement of need or opportunity]
-**The** [product name] **is a** [product category]
-**That** [key benefit / reason to believe]
-**Unlike** [competitive alternative]
-**Our product** [primary differentiation]
-
-### 2. Define Each Element
-
-**Target Customer (For...)**
-- Be specific—not "everyone" or "businesses"
-- Include firmographics (B2B) or demographics (B2C)
-- Describe the role, not just the company
-- Example: "For series-A B2B SaaS founders" not "For startups"
-
-**Statement of Need (Who...)**
-- Describe the problem or opportunity in their words
-- Focus on the situation, not your solution
-- Should resonate immediately with target customer
-- Example: "Who struggle to forecast revenue accurately"
-
-**Product Category (Is a...)**
-- Place yourself in a frame of reference customers understand
-- Create a new category only if necessary
-- Example: "Is a revenue intelligence platform" not "Is an AI thing"
-
-**Key Benefit (That...)**
-- The primary value you deliver
-- Specific and measurable where possible
-- Tied to what target customer cares about
-- Example: "That predicts pipeline with 90%+ accuracy"
-
-**Competitive Alternative (Unlike...)**
-- The thing they'd do instead of using you
-- Could be a competitor, manual process, or doing nothing
-- Example: "Unlike spreadsheet forecasts and gut instinct"
-
-**Primary Differentiation (Our product...)**
-- What makes you uniquely able to deliver the benefit
-- Defensible and hard to copy
-- Example: "Our product analyzes deal signals automatically"
-
-### 3. Pressure Test Your Positioning
-
-**Is your target customer specific enough?**
-- Can you list 10 companies/people who fit this description?
-- Can you find them on LinkedIn/Google?
-- If you can't find them, you can't sell to them
-
-**Is the need real and urgent?**
-- Do customers describe this problem in discovery conversations?
-- Are they actively trying to solve it today?
-- What's the cost of not solving it?
-
-**Is the category clear?**
-- When customers hear it, do they immediately understand?
-- Does it imply the right competitive set?
-- Is it a category they already have budget for?
-
-**Is the benefit compelling?**
-- Does it address the stated need directly?
-- Can you prove it? (Case studies, data, demos)
-- Is it differentiated from alternatives?
-
-**Is the differentiation defensible?**
-- Can competitors copy this easily?
-- Does it create switching costs?
-- Is it meaningful to customers (not just interesting to you)?
-
-### 4. Test with Customers
-
-**The 5-Second Test:**
-Show positioning statement to target customer for 5 seconds. Ask:
-- "What is this product?"
-- "Who is it for?"
-- "Why would someone use it?"
-
-If they can't answer correctly, your positioning isn't clear.
-
-**The "So What?" Test:**
-Read each line. If customer could respond "So what?" it's not compelling enough.
-- "We use AI" → "So what? Everyone uses AI."
-- "We predict revenue with 90% accuracy" → "That's interesting..."
-
-**The Believability Test:**
-Does the customer believe your claims?
-- Too good to be true → skepticism
-- Supported by evidence → credibility
-
-### 5. Evolve Through Stages
-
-**Early Stage (Pre-PMF):**
-- Focus on problem and specific customer
-- Benefit may be aspirational (not yet proven)
-- Category may be borrowed from adjacent space
-
-**Growth Stage (Post-PMF):**
-- Sharpen based on customer feedback
-- Add proof points and social proof
-- Consider category creation if dominant
-
-**Mature Stage:**
-- Positioning becomes brand
-- Defend against new entrants
-- Expand to adjacent segments
-
-### 6. Synthesis
-
-After completing your positioning statement:
-- Does it clearly differentiate you from alternatives?
-- Would your target customer recognize themselves?
-- Is every element based on validated customer insights?
-- Can you deliver on the promise?
-- What would need to change if you're wrong about the customer or need?
-
-## Example
-
-**Idea**: "AI tool that writes code documentation"
-
-### Discovery Insights
-
-From 20 customer conversations:
-- Engineering managers at 50-500 person companies
-- Documentation is always out of date
-- Engineers hate writing docs but need them for onboarding
-- Current alternatives: Manual writing, hoping engineers document as they go
-- Pain point: New hire onboarding takes 3x longer than it should
-
-### Draft Positioning Statement
-
-**For** engineering managers at mid-size SaaS companies (50-500 employees)
-**Who** waste weeks onboarding new engineers due to outdated or missing documentation
-**The** DocBot **is a** code documentation platform
-**That** automatically generates and updates documentation from your codebase
-**Unlike** manual documentation or hoping engineers write it themselves
-**Our product** integrates with your IDE and CI/CD pipeline to keep docs perpetually current
-
-### Pressure Test
-
-**Target customer specific?** ✓ Engineering managers, 50-500 employees
-**Need real and urgent?** ✓ Mentioned in 18/20 conversations
-**Category clear?** ✓ Documentation platform is understood
-**Benefit compelling?** ✓ Automatic generation + staying current
-**Differentiation defensible?** ~ IDE/CI/CD integration is somewhat defensible
-
-### Refinement
-
-Differentiation weak—"automatic generation" is becoming commoditized. What's truly different?
-
-**Updated differentiation:**
-"Our product learns your team's terminology and architecture patterns, so docs read like your senior engineers wrote them."
-
-### Final Statement
-
-**For** engineering managers at growing SaaS companies (50-500 employees)
-**Who** lose weeks onboarding each new hire because documentation is outdated or nonexistent
-**DocBot is a** code documentation platform
-**That** automatically generates and maintains human-quality documentation from your codebase
-**Unlike** manual documentation or generic AI generators
-**DocBot** learns your team's terminology and patterns, creating docs that read like your senior engineers wrote them
-
-**Insight:** The positioning evolution shows how generic benefits ("automatic generation") are strengthened by specific, differentiated value ("reads like your senior engineers wrote them"). This makes the offering harder to compare and commoditize.

package/payload/platform/plugins/venture-studio/skills/zero-to-prototype/references/prd.md

@@ -1,363 +0,0 @@
-# Product Requirements Document (PRD)
-
-## Purpose
-Transform PMF analysis into a structured product specification that guides development, aligns stakeholders, and maintains focus on validated customer needs.
-
-## When to Use
-- After PMF analysis validates the opportunity
-- Before beginning development
-- When aligning team on what to build
-- When scoping MVP vs. future phases
-- When communicating product vision to stakeholders
-
-## Prerequisites
-
-**Required PMF artifacts:**
-- Validated customer interviews (minimum 5-10)
-- JTBD or problem validation analysis
-- Persona or earlyvangelist profile
-- Pareto analysis (if feature prioritization done)
-- Competitive/alternative analysis
-
-## Process
-
-### 1. PRD Structure
-
-A complete PRD contains these sections:
-
-| Section | Purpose | Length |
-|---------|---------|--------|
-| **Vision** | Why this exists | 2-3 sentences |
-| **Target Customer** | Who it's for | 1 page |
-| **Problem Statement** | What pain we solve | 0.5 pages |
-| **Solution** | How we solve it | 1-2 pages |
-| **User Stories/Jobs** | What users can do | Varies |
-| **Requirements** | What we must build | Varies |
-| **Out of Scope** | What we're NOT building | 0.5 pages |
-| **Success Metrics** | How we measure | 0.5 pages |
-| **Risks & Assumptions** | What could go wrong | 0.5 pages |
-| **Timeline & Phases** | When we build what | 0.5-1 page |
-
-### 2. Write Each Section
-
-#### Vision (The "Why")
-
-**Formula:**
-> [Product name] is a [category] that helps [target customer] [achieve outcome] by [how it works].
-
-**Guidelines:**
-- One to three sentences maximum
-- Aspirational but grounded
-- Should inspire the team
-- References the validated job-to-be-done
-
-**Example:**
-> Task Agent is an AI business assistant that helps tradespeople capture every customer enquiry by handling messages, scheduling, and quotes through WhatsApp—so they can focus on the job, not the admin.
-
-#### Target Customer (The "Who")
-
-**Include:**
-
-**Primary Persona:**
-- Demographics (job title, company size, location)
-- Psychographics (values, motivations, frustrations)
-- Current behavior (tools used, workflows, pain points)
-- Quote from customer interview
-
-**Why This Customer:**
-- Market size (TAM, SAM, SOM if known)
-- Why they're underserved
-- Why they'll adopt your solution
-- What makes them ideal early adopters
-
-**Validation:**
-- Number of interviews conducted
-- Key patterns observed
-- Confidence level in targeting
-
-#### Problem Statement (The "What Hurts")
-
-**Formula:**
-> [Target customers] spend [time/money] on [problem] because [root cause]. This results in [negative outcomes].
-
-**Include:**
-- Customer quotes that describe the pain
-- Quantified impact (hours lost, revenue missed, stress caused)
-- Current alternatives and why they fail
-- Trigger moments when the pain is most acute
-
-**Example:**
-> Small tradespeople spend ~16 hours/week on admin tasks because customer messages arrive through 10+ channels and require immediate response or the customer calls a competitor. This results in lost revenue (missed enquiries), burnout (evening admin), and relationship strain (partner doing unpaid work).
->
-> In Sarah's words: *"Our main thing is getting back to people quickly because all they've got to do is put down the phone because we're all emergencies."*
-
-#### Solution (The "How")
-
-**Include:**
-
-**Value Proposition:**
-- One-line summary of what you offer
-- How it addresses the validated pain points
-- Key differentiators from alternatives
-
-**How It Works:**
-- User journey (step by step)
-- Key interactions
-- What the user sees/does
-
-**Key Capabilities:**
-- Core features (must-haves for value delivery)
-- Supporting features (enhance core value)
-- Future features (out of scope for now)
-
-**Technical Approach** (if relevant):
-- Architecture overview
-- Key technology decisions
-- Integration requirements
-
-#### User Stories / Jobs to Be Done
-
-**Format:**
-> As a [user type], I want to [action] so that [outcome].
-
-Or JTBD format:
-> When [situation], I want to [motivation] so I can [outcome].
-
-**Prioritization:**
-- **Must Have:** Required for MVP, without this the product doesn't work
-- **Should Have:** High value, include if possible
-- **Could Have:** Nice to have, defer if needed
-- **Won't Have:** Explicitly out of scope (this version)
-
-**Example:**
-
-| Priority | Story | Acceptance Criteria |
-|----------|-------|---------------------|
-| Must Have | As a tradesperson, I want the agent to reply to WhatsApp enquiries so I never miss a customer | Agent responds within 60 seconds, 24/7 |
-| Must Have | As a tradesperson, I want to approve messages before they send so I stay in control | Approval mode available, agent waits for confirmation |
-| Should Have | As a tradesperson, I want the agent to remember customers so conversations feel personal | Agent recalls name, previous jobs, preferences |
-| Could Have | As a tradesperson, I want quotes sent via email so they look professional | Email integration with quote templates |
-| Won't Have | As a tradesperson, I want the agent to order parts for me | Deferred to Phase 3 |
-
-#### Requirements
-
-**Functional Requirements:**
-What the system must DO (features, capabilities).
-
-| ID | Requirement | Priority | Source |
-|----|-------------|----------|--------|
-| FR-1 | Receive WhatsApp messages in real-time | Must | JTBD: instant response |
-| FR-2 | Generate contextual AI responses | Must | Core value prop |
-| FR-3 | Store customer information | Must | Persona analysis |
-| FR-4 | Schedule reminders and follow-ups | Should | Interview: "chase invoices" |
-
-**Non-Functional Requirements:**
-How the system must PERFORM (quality attributes).
-
-| Category | Requirement | Target |
-|----------|-------------|--------|
-| Performance | Response time to customer | < 60 seconds |
-| Availability | System uptime | 99.5% |
-| Scalability | Concurrent users | 100+ |
-| Security | Data protection | GDPR compliant |
-| Usability | Setup time | < 30 minutes |
-
-#### Out of Scope
-
-**Explicitly state what you're NOT building:**
-
-This prevents scope creep and aligns expectations.
-
-| Feature | Why Out of Scope | When to Revisit |
-|---------|------------------|-----------------|
-| Multi-channel (Facebook, email) | Focus on WhatsApp first | Phase 2 |
-| Bookkeeping integration | Different problem space | Phase 3 |
-| Multi-user accounts | Starting with sole traders | Post-PMF |
-
-#### Success Metrics
-
-**Lagging Indicators (Outcomes):**
-| Metric | Target | Measurement |
-|--------|--------|-------------|
-| Customer retention | >80% at 3 months | Cohort analysis |
-| NPS | >40 | Monthly survey |
-| Time saved | >5 hours/week | User survey |
-
-**Leading Indicators (Behaviors):**
-| Metric | Target | Measurement |
-|--------|--------|-------------|
-| Daily active usage | >60% of users | Analytics |
-| Messages handled/day | >10 per user | Agent logs |
-| Response time | <60 seconds | Agent logs |
-
-#### Risks & Assumptions
-
-**Assumptions (things we believe but haven't fully validated):**
-| Assumption | Confidence | Validation Plan |
-|------------|------------|-----------------|
-| Tradespeople will trust AI to reply | Medium | Approval mode, watch adoption |
-| WhatsApp is the primary channel | High | 8/10 interviews confirmed |
-| Partners make purchase decisions | Medium | Track who signs up |
-
-**Risks (things that could go wrong):**
-| Risk | Likelihood | Impact | Mitigation |
-|------|------------|--------|------------|
-| WhatsApp API changes | Medium | High | Build Telegram fallback |
-| AI makes embarrassing mistakes | Medium | High | Approval mode, monitoring |
-| Tradespeople can't install | Low | High | Done-for-you onboarding |
-
-#### Timeline & Phases
-
-**Phase Structure:**
-
-| Phase | Focus | Duration | Success Criteria |
-|-------|-------|----------|------------------|
-| Phase 1 (MVP) | Core messaging + scheduling | 4 weeks | 5 paying users |
-| Phase 2 | Email, quotes, memory | 6 weeks | 50 users, <5% churn |
-| Phase 3 | Multi-channel, geo-routing | 8 weeks | 200 users, word-of-mouth |
-
-**Phase 1 Scope (MVP):**
-- WhatsApp message handling ✓
-- AI response generation ✓
-- Basic scheduling ✓
-- Customer memory ✓
-- Approval mode ✓
-
-**Deferred to Phase 2:**
-- Email integration
-- Quote templates
-- Invoice reminders
-- Home PC file access
-
-### 3. Review Checklist
-
-Before finalizing PRD:
-
-- [ ] Every feature traces to a validated customer need
-- [ ] Customer quotes support key decisions
-- [ ] Scope is realistic for timeline
-- [ ] Success metrics are measurable
-- [ ] Risks have mitigation plans
-- [ ] Out of scope is explicit
-- [ ] Non-functional requirements defined
-- [ ] Stakeholders have reviewed
-
-### 4. Keep It Alive
-
-**PRD is a living document:**
-- Update as you learn from users
-- Add features to future phases (not current)
-- Document pivots and why
-- Link to related artifacts (interview notes, analytics)
-
-### 5. Synthesis
-
-After completing the PRD:
-- Does the MVP scope deliver the core JTBD?
-- Are we building the smallest thing that tests our hypothesis?
-- What would we cut if we had half the time?
-- What assumption, if wrong, would kill this product?
-- Who needs to approve this before we start?
-
-## Example
-
-**Product**: Task Agent (AI assistant for tradespeople)
-
-### PRD Excerpt
-
----
-
-**1. Vision**
-
-Task Agent is an AI business assistant that helps tradespeople capture every customer enquiry by handling messages, scheduling, and quotes through WhatsApp—so they can focus on the job, not the admin.
-
-**2. Target Customer**
-
-**Primary Persona: Neil the Plumber** (validated via interview with his wife Sarah)
-- Age 56, runs own plumbing business, specialises in boilers
-- Technophobic: can fix an aircraft but can't send an email
-- Wife Sarah handles ALL admin: bookings, quotes, scheduling
-- Gets emergency calls throughout the day
-- Customers contact via 10+ channels (WhatsApp, Facebook, email, phone)
-
-**Why This Customer:**
-- ~2M sole trader tradespeople in UK
-- Viscerally hate admin after physical work
-- Live on WhatsApp already
-- Underserved: enterprise tools (HubSpot) are overkill
-- Built-in viral loop: trade mates at the pub
-
-**Validation:**
-- 20+ customer conversations
-- 8/10 confirmed WhatsApp as primary channel
-- Sarah interview provided deep pain validation
-
-**3. Problem Statement**
-
-Small tradespeople spend ~16 hours/week on admin because customer messages arrive through 10+ channels requiring immediate response.
-
-> *"Our main thing is getting back to people quickly because all they've got to do is put down the phone because we're all emergencies."* — Sarah
-
-> *"Sometimes I have to check 10 different routes."* — Sarah
-
-**Impact:**
-- Lost revenue: Enquiries unanswered = competitor wins
-- Burnout: Evening admin after physical work
-- Relationship strain: Partner doing unpaid admin
-- Quote delays: Handwritten → typed takes days
-
-**4. Solution Overview**
-
-Task Agent lives in WhatsApp. It:
-- Replies to enquiries in seconds (even at 3am)
-- Books appointments and handles back-and-forth
-- Sends quotes the same day
-- Remembers every customer and job
-
-**User Journey:**
-1. Customer WhatsApps Neil
-2. Agent replies within seconds, gathers details
-3. Agent notifies Neil with summary
-4. Neil approves or dictates response
-5. Agent handles the rest
-
-**5. MVP Requirements (Phase 1)**
-
-| ID | Requirement | Priority | Validation Source |
-|----|-------------|----------|-------------------|
-| FR-1 | Real-time WhatsApp messaging | Must | Core value prop |
-| FR-2 | AI contextual responses | Must | Core value prop |
-| FR-3 | Approval mode (draft before send) | Must | Trust barrier from interview |
-| FR-4 | Customer memory (names, jobs) | Must | "Remember people" from JTBD |
-| FR-5 | Daily summary notification | Should | "Know what's happening" |
-| FR-6 | Basic scheduling ("Tuesday 2pm?") | Should | "Book jobs" from interview |
-
-**6. Out of Scope (This Phase)**
-
-| Feature | Reason | Revisit |
-|---------|--------|---------|
-| Facebook/Instagram | WhatsApp-first validation | Phase 2 |
-| Email quotes/invoices | Adds complexity | Phase 2 |
-| Voice IVR (phone) | Separate capability | Phase 3 |
-| Geographic routing | Advanced feature | Phase 3 |
-
-**7. Success Metrics**
-
-| Metric | Target | Rationale |
-|--------|--------|-----------|
-| Response time | <60s | "Quick response" from interview |
-| Messages/user/day | >10 | Active usage signal |
-| 30-day retention | >60% | Product-market fit indicator |
-| "Very disappointed" | >40% | Sean Ellis test |
-
-**8. Key Risk**
-
-| Risk | Impact | Mitigation |
-|------|--------|------------|
-| Trust barrier: Neil won't let AI reply | High | Approval mode for Week 1 |
-| WhatsApp ToS change | High | Telegram fallback ready |
-| AI mistakes | Medium | Human review mode, monitoring |
-
----
-
-**Insight:** This PRD excerpt shows how every section connects back to validated PMF insights. The features aren't invented—they're the minimum required to solve the validated problem. The risks are real (from interviews), not theoretical. The metrics measure what customers said matters.

package/payload/platform/plugins/venture-studio/skills/zero-to-prototype/references/pre-mortem.md

@@ -1,74 +0,0 @@
-# Pre-mortem Analysis
-
-## Purpose
-Imagine the idea has failed spectacularly. Work backward to identify what went wrong, surfacing risks and blind spots before they become reality.
-
-## When to Use
-- Identifying blind spots and hidden risks
-- Validating high-stakes business ideas or GTM strategies
-- When team/stakeholders are overly optimistic
-- Before committing significant resources
-
-## Process
-
-1. **Set the scene**
-   - "It's 12 months from now. We launched this idea and it failed completely. What happened?"
-
-2. **Generate failure scenarios** (aim for 5-10)
-   - Brainstorm every plausible reason for failure
-   - Encourage worst-case thinking
-   - Consider: market, execution, timing, competition, resources, team, assumptions
-
-3. **Prioritize by likelihood + impact**
-   - Which failures are most likely?
-   - Which would be most damaging?
-   - Focus on high-likelihood OR high-impact scenarios
-
-4. **Root cause analysis for top failures**
-   - For each priority failure: What would cause this?
-   - Trace back to decisions, assumptions, or conditions
-
-5. **Identify early warning signals**
-   - How would you know this failure is beginning?
-   - What metrics or indicators would show trouble?
-
-6. **Build mitigation strategies**
-   - How could you prevent this failure?
-   - How could you detect it early?
-   - What's your contingency plan?
-
-7. **Synthesis**
-   - Which risks can you eliminate by redesigning the idea?
-   - Which risks require monitoring and contingency plans?
-   - Is the idea still worth pursuing given the risks?
-
-## Example
-
-**Idea**: "Launch a premium AI automation consulting service for SMBs"
-
-**Failure scenario (12 months later)**: "We shut down after 8 months with only 2 clients."
-
-**What went wrong** (working backward):
-- SMBs couldn't afford premium pricing
-- Decision-makers didn't understand AI value proposition
-- Sales cycles were 6+ months (unsustainable)
-- We lacked case studies to prove ROI
-- Competition from cheaper overseas providers
-
-**Root causes**:
-- Assumed SMBs had enterprise budgets
-- Didn't validate price sensitivity
-- Underestimated education required
-
-**Early warnings**:
-- High interest but low conversions
-- Requests for payment plans
-- "Can you just build it for us?" instead of consulting
-
-**Mitigations**:
-- Create a productized starter package at lower price
-- Build 2-3 pilot projects first (case studies)
-- Target SMBs in specific high-value industries
-- Consider hybrid model: consulting + implementation
-
-**Insight**: Premium consulting alone is high-risk for SMBs. Build productized entry point first.