@veyralabs/skills 0.5.0 → 0.5.2

package/skills/venture-suite/venture-analyst/references/execution-roadmap.md

@@ -0,0 +1,187 @@
+# Execution Roadmap Framework
+
+The analysis means nothing if the founder doesn't know what to do on Monday morning.
+
+This framework converts a venture-analyst verdict into a concrete 30-day action plan. The output is not generic advice - it is specific actions based on the evidence collected in Phases 1-5.
+
+---
+
+## The core principle
+
+Most validators end with BUILD or AVOID. That is not enough.
+
+The right output is:
+- What to do this week (not "validate the idea" - specific tasks)
+- What NOT to build yet (and why)
+- When to stop and reassess (specific trigger conditions)
+
+The roadmap changes based on the verdict:
+- **BUILD** → 30-day sprint to first paying customer
+- **VALIDATE FIRST** → 30-day experiment plan
+- **AVOID** → pivot path or stop criteria
+
+---
+
+## BUILD path - 30-day roadmap
+
+The goal is one paying customer in 30 days. Not an MVP. Not a waitlist. One customer who pays.
+
+### Week 1 - Find the customer before building
+
+Actions:
+1. Identify 50 people who have the problem (from the research: which subreddits, which GitHub repos, which communities had the most signal?)
+2. Reach out to 20 with a Mom Test message - not a pitch, a question about their current workflow
+3. Book 5 discovery calls
+4. Run all 5 calls using Mom Test structure from `references/mom-test.md`
+5. By end of week: can you describe the customer's pain in their exact words?
+
+Do NOT build anything this week.
+
+Decision gate: if you cannot find 5 people willing to talk, the ICP is wrong. Stop and reassess before continuing.
+
+### Week 2 - Build only what closes the first sale
+
+Based on the 5 conversations:
+1. Identify the one outcome the customer cares most about
+2. Can you deliver that outcome manually? (Concierge MVP)
+3. If yes: offer to do it for free or at a steep discount for 2-3 people
+4. If the outcome requires software: build only the path from input to that outcome. Nothing else.
+
+Scope rule: if it takes more than 5 days to build, you are building too much.
+
+Decision gate: if you cannot articulate what the customer is paying for in one sentence, do not build yet.
+
+### Week 3 - Deliver and charge
+
+1. Deliver the concierge MVP or minimal software to the 2-3 people from Week 2
+2. At delivery: ask "would you pay [price] per month for this if it continued?"
+3. If yes: send them a payment link (Stripe, Gumroad, bank transfer - whatever works)
+4. If no: ask what would have to be different for them to pay
+
+First payment is the signal. Not a letter of intent. Not "I would pay". An actual transaction.
+
+Decision gate: if nobody pays after Week 3, you have a problem with price, value, or ICP. Identify which one before continuing.
+
+### Week 4 - Stabilize and find customer 2-3
+
+1. Deliver reliably to paying customer 1
+2. Ask for referral: "who else do you know with this problem?"
+3. Run outreach to 10 more people from the original 50 list
+4. Goal: 2-3 paying customers by end of month
+
+---
+
+## VALIDATE FIRST path - 30-day experiment plan
+
+The goal is to answer the one critical unknown identified in Phase 5.
+
+### Week 1 - Define the question precisely
+
+Write this sentence: "We do not know if [specific assumption]. If we knew [assumption] is true, we would build. If false, we would not build."
+
+Examples:
+- "We do not know if freelancers will pay for automated invoicing when free tools exist."
+- "We do not know if HR teams have budget for this outside their annual planning cycle."
+
+Everything in the next 3 weeks answers this one question.
+
+### Week 2 - Run the cheapest test that could falsify it
+
+Based on the assumption type:
+
+| Assumption type | Best test | Cost | Time |
+|----------------|-----------|------|------|
+| Does the problem exist? | 10 Mom Test interviews | 0 | 1 week |
+| Will they pay? | Concierge MVP with payment ask | 0 | 2 weeks |
+| Does the message resonate? | Fake door landing page | 0-30€ | 1 week |
+| Is the ICP right? | Cold outreach to 3 different segments | 0 | 1 week |
+
+Do not run more than one test at a time. You need clean signal.
+
+### Week 3 - Collect and evaluate data
+
+By end of week 3 you need a number against a threshold:
+- Interviews: at least 7 out of 10 describe the same problem unprompted
+- Payment ask: at least 2 out of 5 say yes and follow through
+- Fake door: CTR above 5% from cold traffic
+- ICP test: one segment responds 3x better than others
+
+### Week 4 - Decision
+
+Three possible outcomes:
+
+**Assumption confirmed:** move to BUILD path. Start Week 1 of the BUILD roadmap.
+
+**Assumption partially confirmed:** the test worked but raised a new question. Run a second 2-week experiment targeting the new unknown.
+
+**Assumption falsified:** the critical assumption is wrong. Before stopping:
+- Is there a pivot? (different customer, different problem, different solution)
+- If yes: restart from Phase 1 with the new hypothesis
+- If no: stop. Time is the most valuable resource.
+
+---
+
+## AVOID path - what to do instead
+
+If the verdict is AVOID, the roadmap is not "do nothing." It is:
+
+### Option A - Pivot investigation (2 weeks)
+
+The research surfaced something. What was the most interesting unexpected signal?
+- A different customer segment with stronger pain
+- A related problem that nobody is solving
+- A gap in the competitor landscape that the original idea missed
+
+Spend 2 weeks doing Phase 1 research on the pivot hypothesis before committing.
+
+### Option B - Clean stop criteria
+
+If no pivot is visible, document:
+- What was learned (specific, honest)
+- What would have to change in the market for this to be worth revisiting
+- Time horizon: reassess in [6/12/24] months if [specific trigger] occurs
+
+This is not failure. It is validated learning. The next idea starts from a better place.
+
+---
+
+## Roadmap anti-patterns
+
+**Anti-pattern 1: Building before selling**
+The roadmap assumes zero code until someone has committed to paying. Build only what closes the next sale.
+
+**Anti-pattern 2: Optimizing before validating**
+Do not improve the landing page conversion rate before you have 100 cold visitors. Do not A/B test before you have a working baseline.
+
+**Anti-pattern 3: Scaling before repeating**
+Do not invest in marketing before you have 3 customers who came through the same process. One customer is an anecdote. Three is a pattern.
+
+**Anti-pattern 4: Measuring vanity metrics**
+The only metric that matters in week 1-4 is: did someone pay? Every other metric is a proxy.
+
+**Anti-pattern 5: Moving the goalposts**
+Define success criteria before starting each week. Do not redefine "success" after seeing results.
+
+---
+
+## Output format for roadmap
+
+```
+## 30-Day Execution Roadmap
+
+Path: [BUILD / VALIDATE FIRST / AVOID]
+
+Critical constraint: [the one thing that must be true for this plan to work]
+
+Week 1: [specific tasks + decision gate]
+Week 2: [specific tasks + decision gate]
+Week 3: [specific tasks + decision gate]
+Week 4: [goal + decision]
+
+Do NOT build yet:
+- [specific feature or system to avoid]
+- [reason]
+
+Reassess if:
+- [specific trigger that means the plan is failing]
+```

package/skills/venture-suite/venture-analyst/references/founder-traps.md

@@ -0,0 +1,191 @@
+# Founder Trap Patterns
+
+Common patterns where founders convince themselves they have a good idea when the evidence says otherwise. Detect these from the research data - not from what the founder says, but from what the data shows.
+
+## How to detect traps
+
+These are signal patterns, not opinions. Each trap has specific evidence criteria. If the criteria match, flag it. If they don't, don't flag it.
+
+---
+
+## Trap 1: Solution Looking for a Problem
+
+**What it looks like:**
+Founder describes a sophisticated technical solution. When asked about the problem, they describe the solution again in different words.
+
+**Evidence signals:**
+- High feature complexity in the idea description
+- Low Reddit/HN pain evidence (people aren't complaining about this)
+- GitHub issues about the problem: near zero
+- Trend data: flat or no data
+- When searching for the problem, results are mostly product announcements, not complaints
+
+**Example:**
+"An AI-powered semantic graph database for distributed knowledge management" - but nobody is searching for this, and no Reddit threads show people struggling with their current knowledge management.
+
+**Output flag:**
+```
+Founder Trap: Solution looking for a problem
+Signal: High technical complexity, low organic pain evidence
+Evidence score on the problem: [X] -- below threshold for this complexity level
+```
+
+---
+
+## Trap 2: Building for Yourself
+
+**What it looks like:**
+The founder is the only person in the world with this exact problem configuration. The idea solves a very specific workflow that only power users in one niche experience.
+
+**Evidence signals:**
+- The subreddits where this pain appears have under 10k subscribers
+- HN discussions exist but are 5+ years old and never got traction
+- GitHub issues exist in one very specific repo from one very specific maintainer
+- No mainstream discussion anywhere
+- Trend data: zero or declining
+
+**Output flag:**
+```
+Founder Trap: Building for yourself
+Signal: Pain exists but only in a very narrow segment
+Estimated addressable users: [small] -- may not support a business
+```
+
+---
+
+## Trap 3: Vitamin, Not Painkiller
+
+**What it looks like:**
+The problem exists. People acknowledge it. But nobody is urgently trying to solve it right now. It's a "nice to have."
+
+**Evidence signals:**
+- Reddit posts about the problem get upvotes but few comments
+- No "is there a tool that does X" posts
+- Competitors exist but have low engagement / slow growth
+- People describe the problem but their current workaround is "good enough"
+- No one is spending money on bad solutions currently
+
+**Output flag:**
+```
+Founder Trap: Vitamin, not painkiller
+Signal: Problem acknowledged, urgency low
+No evidence of active spending on imperfect solutions
+```
+
+---
+
+## Trap 4: Red Ocean Obsession
+
+**What it looks like:**
+Founder wants to compete directly with a dominant player using the same positioning and features. "We're like X but better."
+
+**Evidence signals:**
+- 1+ competitor with over 100k users
+- Competitor has a free tier
+- No clear positioning gap in the competitor map
+- Founder's description relies on feature parity + marginal improvements
+- No ERRC analysis shows a meaningfully different value curve
+
+**Output flag:**
+```
+Founder Trap: Red ocean entry
+Signal: Dominant player exists with free tier and no clear structural weakness
+"Better" is not a strategy
+```
+
+---
+
+## Trap 5: Market Timing Mismatch
+
+**What it looks like:**
+The idea was good 3-5 years ago (or will be good in 3-5 years) but is poorly timed for now.
+
+**Evidence signals:**
+- Trend data: declining
+- Related GitHub repos: abandoned or archived
+- HN discussions: lots of interest 3+ years ago, silence now
+- OR: Trend rising fast but infrastructure/regulation not ready yet (too early)
+
+**Output flag:**
+```
+Founder Trap: Market timing mismatch
+Signal: [declining interest over X period] or [infrastructure gap for early timing]
+```
+
+---
+
+## Trap 6: Complexity Moat Illusion
+
+**What it looks like:**
+Founder believes the product's complexity is the moat. "Nobody else will build this because it's hard." This is almost never true.
+
+**Evidence signals:**
+- The problem space has well-funded competitors (they can hire the engineers)
+- The technical complexity doesn't translate to switching costs for users
+- No network effects in the model
+- No proprietary data advantage
+
+**Output flag:**
+```
+Founder Trap: Complexity moat illusion
+Signal: Technical difficulty does not equal defensibility
+Better-resourced competitors can and will replicate
+```
+
+---
+
+## Trap 7: Proxy Metric Validation
+
+**What it looks like:**
+Founder validated the wrong thing. Got 500 waitlist signups but none converted. Got 50 "great idea" replies to a cold email but nobody booked a call.
+
+**Evidence signals (use when reviewing experiment design):**
+- Success criteria were defined by vanity metrics
+- No willingness-to-pay experiment was ever run
+- Conversion from interest to commitment was never tested
+
+**Output flag:**
+```
+Founder Trap: Proxy metric validation
+Signal: Interest validated, commitment not validated
+Waitlist signups are not customers
+```
+
+---
+
+## Trap 8: ICP Drift
+
+**What it looks like:**
+Founder started with one customer type, got rejected, and gradually expanded their ICP until "everyone" is the customer.
+
+**Evidence signals:**
+- Target customer description is vague ("any business", "any developer")
+- Multiple contradictory customer types mentioned in the idea description
+- Pain signals come from very different subreddits with no overlap
+
+**Output flag:**
+```
+Founder Trap: ICP drift
+Signal: Expanding ICP is a sign of failed validation, not a bigger market
+Narrow the target before expanding
+```
+
+---
+
+## How to apply in analysis
+
+During Phase 5 (Decision Intelligence):
+
+1. Match evidence patterns against each trap above
+2. Flag any trap where at least 3 of the listed signals are present
+3. Never flag based on one signal alone
+4. If a trap is flagged, it does NOT automatically change the verdict - it goes into Decision Intelligence for the judge to weigh
+5. A BUILD verdict can coexist with a detected trap if the other evidence is strong enough
+
+Priority order (most damaging first):
+1. Solution looking for problem
+2. Red ocean obsession
+3. Vitamin not painkiller
+4. Building for yourself
+5. Market timing mismatch
+6. All others

package/skills/venture-suite/venture-analyst/references/moat-patterns.md

@@ -0,0 +1,176 @@
+# Moat Patterns
+
+A moat is why you keep customers after a competitor copies your features. Without a moat, you build a product, not a business.
+
+Most startup validators say "competitive advantage" and leave it there. This reference gives scoring criteria for 5 real moat types so the analysis can score each one and identify which is most realistic for a given idea.
+
+---
+
+## The 5 moat types
+
+### 1. Distribution Moat
+
+You control a channel others cannot easily access.
+
+**What it looks like:**
+- Exclusive partnership with a platform (e.g. pre-installed on hardware)
+- Large owned audience (email list, YouTube, community)
+- SEO dominance in a niche that takes years to replicate
+- Embedded in a workflow that creates daily habit (Slack, Notion)
+
+**Evidence signals (score higher for each present):**
+- Founder already has relevant audience or network
+- Product embeds into existing workflow daily
+- Partnership or distribution deal possible that others can't easily get
+- SEO moat: high-intent keywords with low competition
+
+**Score 1-10:**
+- 1-3: No distribution advantage, same channels as competitors
+- 4-6: Some channel advantage but replicable with money
+- 7-10: Structural distribution advantage that compounds over time
+
+**Most realistic for:** content businesses, platforms with network effects, tools that embed into a daily workflow
+
+---
+
+### 2. Data Moat
+
+You accumulate proprietary data that makes your product better over time and is impossible to replicate from scratch.
+
+**What it looks like:**
+- Each user interaction improves the model/output for all users
+- Unique dataset nobody else has (e.g. proprietary industry data)
+- Network of data contributors locked in by switching cost
+- Longitudinal data that takes years to accumulate
+
+**Evidence signals:**
+- Product gets meaningfully better with more users or usage
+- Data collected is not available from public sources
+- Users contribute data as part of normal use (not just consume)
+- The gap between early data and mature data is the moat
+
+**Score 1-10:**
+- 1-3: Uses same public data sources as everyone else
+- 4-6: Collects user data but competitors could replicate with time
+- 7-10: Proprietary data flywheel that widens with scale
+
+**Most realistic for:** AI products, marketplaces, analytics platforms, any product where N+1 users make the product better for all N users
+
+---
+
+### 3. Community Moat
+
+Users identify with the product and each other. Leaving means leaving the community.
+
+**What it looks like:**
+- Strong brand identity (users say "I'm a [product] user" as part of identity)
+- Active user community that is product-adjacent (Slack, Discord, events)
+- User-generated content that attracts more users
+- Power users who become advocates and contributors
+
+**Evidence signals:**
+- Reddit or HN discussions about the product are enthusiastic, not just transactional
+- Users refer others without being asked
+- Community exists or could exist around the problem space
+- Identity signal: does the target customer identify strongly with a community?
+
+**Score 1-10:**
+- 1-3: No community signal, purely transactional product
+- 4-6: Some user loyalty but no real community
+- 7-10: Product is central to a user identity or community
+
+**Most realistic for:** developer tools, creator tools, niche B2B, products solving problems with strong in-group identity
+
+---
+
+### 4. Switching Cost Moat
+
+Leaving is painful because of data, integrations, learned behavior, or sunk cost.
+
+**What it looks like:**
+- Data locked in proprietary format
+- Deep integration into other tools (replacing means replacing the whole stack)
+- Trained behavior - users have built muscle memory around the product
+- Team adoption - everyone on the team uses it, coordination cost to switch
+
+**Evidence signals:**
+- Product stores user data that is hard to export
+- Integration depth: does it connect to 5+ other tools in the workflow?
+- Time-to-value is long (users invest time before they get value)
+- Team product vs individual product (team switching cost >> individual switching cost)
+
+**Score 1-10:**
+- 1-3: Easy to replace, data fully portable, no integrations
+- 4-6: Some friction to switch but not prohibitive
+- 7-10: Switching requires significant time, data migration, or retraining
+
+**Most realistic for:** B2B SaaS, CRMs, project management, any product that stores meaningful user data or integrates deeply
+
+---
+
+### 5. Execution Moat
+
+The team can build and ship faster or better than others. Not a durable moat alone, but can be decisive in a fast-moving market.
+
+**What it looks like:**
+- Unique domain expertise that takes years to acquire
+- Technical complexity that requires rare skills
+- Speed advantage from existing infrastructure or team
+- Regulatory or compliance knowledge that creates a barrier
+
+**Evidence signals:**
+- Founder has 5+ years of domain expertise
+- Technical stack requires rare specialization
+- Regulatory approval process exists (creates time barrier for followers)
+- Existing codebase or infrastructure gives head start
+
+**Score 1-10:**
+- 1-3: Anyone with enough money can hire the team to replicate this
+- 4-6: Some execution advantage but not structural
+- 7-10: Rare expertise or regulatory barrier that cannot be bought quickly
+
+**Most realistic for:** deep tech, regulated industries, products where domain expertise is genuinely scarce
+
+---
+
+## Moat Scoring Guide
+
+Score each moat 1-10 using the criteria above. Then:
+
+**Moat Score = weighted average:**
+- Take the top 2 moat scores
+- The highest becomes the primary moat
+- The second becomes the secondary moat
+- Overall Moat Score = (primary * 0.6) + (secondary * 0.4)
+
+**Interpretation:**
+| Score | Meaning |
+|-------|---------|
+| 1-3 | No real moat. Features will be copied. Compete on speed only. |
+| 4-5 | Weak moat. Some defensibility but competitors can close the gap. |
+| 6-7 | Moderate moat. Viable business, but needs to strengthen before scaling. |
+| 8-10 | Strong moat. Structural advantage that compounds with growth. |
+
+**Critical output:**
+After scoring, answer: "What is the most realistic moat for this idea, and what specific actions build it?"
+
+Do not just name the moat. Give the action. Example:
+- Data moat: "Every analysis run should store anonymized patterns. At 1,000 analyses, the pattern database becomes a proprietary asset."
+- Community moat: "Build in public. Ship a free tool that attracts the exact ICP and turns them into advocates before monetizing."
+- Distribution moat: "Identify the one community where the ICP concentrates and become the go-to contributor before launching."
+
+---
+
+## Common moat mistakes
+
+**Mistake 1: Confusing features with moats**
+"We have AI" is not a moat. Every competitor will have AI. The question is what the AI produces that is unique and hard to replicate.
+
+**Mistake 2: Assuming complexity = moat**
+Hard to build does not mean hard to copy. Once you show it works, a well-funded competitor can hire the engineers.
+
+**Mistake 3: Planning a moat that requires scale you don't have yet**
+Data moats require data. Network effects require network. These are goals, not current advantages. Score them based on realistic trajectory, not end state.
+
+**Mistake 4: Relying on execution moat alone**
+Speed is not a business. It buys time to build a real moat. Always pair execution moat with a second structural moat.