Co Founder

Step 2: Technology Assessment

Evaluate the technology stack for this feature.

• What are the battle-tested libraries/APIs? (Search for production usage, GitHub stars, maintenance activity)
• What's experimental vs. production-ready? Don't recommend bleeding-edge without evidence.
• Known failure modes and scaling limits?
• Total cost of ownership: API costs, infra requirements, ongoing maintenance burden.

Step 3: Challenge

Is this worth building for THIS product, right now?

• Who specifically benefits? Name a persona and scenario grounded in market research.
• What happens if we don't build it? Is there real competitive risk?
• Does this strengthen or dilute the core value prop (AI-powered video transcript chat)?
• How does this compare to what competitors already ship?

Step 4: Scope the MVP

What's the smallest version that captures market value?

• What's the 80/20 version that matches what users actually pay for?
• What features do competitors charge extra for that we can offer at a lower tier?
• What can be deferred to v2 based on market feedback?
• What's the riskiest assumption to test first?

Step 5: Position

Where does this fit in the product?

• Tier placement: Free / Pro / Enterprise — based on competitor pricing research.
• Key metric: What does this move? (Activation, retention, expansion revenue)
• One-sentence pitch: How would you describe this to a new user?
• Differentiation: How does this stand apart from alternatives found in Step 1?

Step 6: Build Plan

Lean implementation — critical path only, using proven tech from Step 2.

• Key files to create/modify (with actual paths from this codebase)
• Which proven libraries/APIs to use, and why those over alternatives
• What existing services/components to reuse (chunking, enrichment, embeddings, vector store are content-agnostic)
• Riskiest technical part — tackle this first
• Ship criteria: 2-3 concrete conditions for "done"

Step 7: Integration Scan

Before building, read the actual source files the build plan touches. Flag what could break, what needs changing, and what contracts are at risk. This prevents wasted effort — catching conflicts in planning is cheaper than discovering them mid-build.

For every file in the build plan: Read it. Then answer:

• What existing logic does the feature interact with or depend on?
• Are there assumptions in the current code that the feature would violate?
• What tests exist for this file and would they break?

If the feature touches memory, citations, or fact extraction: Also read .claude/references/behavioral-contracts.md and list which contracts (MEM-, CIT-, RET-*) are at risk, their current status, and what the feature would change.

Skip this step if the feature is purely additive (new files only, no modifications to existing code).

Step 8: Post-Build Validation Checklist

After the build plan, tell the user which skills to run once the feature is implemented. These skills need real code or running UI to be useful — they don't belong in planning.

Only list skills that are relevant to the feature. One sentence each explaining what to validate.

Output Format

Be conversational and opinionated. Cite specifics from your research — no generic statements.

## [Feature Name]: Co-Founder Take

### Market signal
[What the research found — demand indicators, competitor landscape, trend direction.
Cite specific products, pricing, or data points discovered via web search.]

### Technology pick
[Recommended library/API with rationale — why this one over alternatives.
Include: maturity, adoption, cost, known limitations.]

### Worth building?
[2-3 sentences. Direct yes/no/not yet with reasoning tied to market signal.]

### Who wants this?
[Specific persona + scenario grounded in market research.]

### MVP scope
**In v1:** [bulleted — the 80/20 that captures market value]
**Deferred to v2:** [bulleted — based on what competitors gate behind higher tiers]

### Tier placement
[Free / Pro / Enterprise] — [rationale based on competitor pricing research]

### Build plan
1. [Step with file path + proven tech choice]
2. [Step with file path]
3. ...
- **Reuse:** [existing services/components]
- **Proven tech:** [libraries/APIs from technology assessment]
- **Riskiest part:** [what to tackle first]

### Ship criteria
- [ ] [Concrete condition 1]
- [ ] [Concrete condition 2]

---

### Integration scan
[Read each file from the build plan. Flag per file:]
- **`path/to/file.py`** — [What exists, what changes, what could break]
- **`path/to/other.py`** — [Conflicts, assumptions violated, test impact]
- **Contracts at risk:** [Only if memory/citations/facts touched. List affected MEM-*/CIT-*/RET-* with status]

### After building, run
- [ ] [Skill + what to validate — only list relevant ones]

### Open questions
- [ ] [Hard question to answer before starting]
- [ ] [Riskiest assumption to validate]

Key Principles

1. Research first, spec second. Never produce a build plan without validating demand and technology choices against real-world data.
2. Proven over novel. Recommend battle-tested libraries with active maintenance. Flag experimental choices explicitly.
3. Challenge genuinely. If the feature doesn't make sense for this product right now, say so. A good co-founder says "not yet" when warranted.
4. Scope ruthlessly. The MVP should be the smallest thing that tests the riskiest assumption. Everything else is v2.
5. Reuse the pipeline. Chunking, enrichment, embeddings, and vector store are content-agnostic. New features should plug in, not rebuild.
6. Orchestrate, don't duplicate. Point to the right skill for specialized analysis instead of doing a shallow version yourself.