Merge pull request #1 from savvides/feat/ai-native-framework

feat: AI-native framework integration (v1.3.0)

Author: savvides

ARCHITECTURE.md

@@ -49,6 +49,7 @@ The `data/` directory contains markdown files with structured domain knowledge:
 - **Market data:** buyer personas, competitive landscape by segment, funding landscape by stage
 - **Frameworks:** ESSA evidence tiers, procurement guides, pilot benchmarks
 - **Higher ed framework:** 15 validated jobs across 6 student journey phases (from SXSW EDU 2026), 4 structural patterns founders miss
+- **AI-native framework:** 4 AI-native criteria, 5 bolted-on indicators, the removal test, Karpathy hierarchy (for developer-tool founders), architecture patterns, and pricing models. All 10 skills read this file to classify a founder's AI posture and adapt guidance accordingly
 
 Skills read these files at runtime using the AI tool's file reading capability. This means the data is always current (edit the markdown, the skill reads the updated version) and auditable (every fact has a source you can check).
 

CHANGELOG.md

@@ -1,5 +1,25 @@
 # Changelog
 
+## 1.3.0 (2026-04-01)
+
+### AI-native framework integration
+
+Every skill is now AI-native aware. When a founder's product involves AI, skills detect whether the AI is load-bearing (AI-native) or decorative (bolted-on) and adapt guidance accordingly.
+
+- New `data/ai-native-framework.md` reference file: 4 AI-native criteria, 5 bolted-on indicators, the removal test, Karpathy hierarchy (for developer-tool founders), architecture patterns, and AI-native pricing models
+- `/product-review` adds a 6th scoring dimension (AI Architecture) for products with AI components
+- `/idea-validation` evaluates AI Architecture Fit as a validation signal
+- `/go-to-market` provides AI-native pricing strategy (usage-based economics, institutional procurement guidance)
+- `/pitch-review` coaches the "improves with models" investor narrative and adapts investor targeting
+- `/sales-strategy` adds AI-native objection handling ("what if the AI is wrong?") and demo flow guidance
+- `/fundraising-guide` targets AI-focused VCs for AI-native products and traditional edtech VCs for bolted-on
+- `/edtech-landscape` maps AI-native vs bolted-on competitors in competitive analysis
+- `/evidence-check` adds behavior change as an evidence dimension for AI-native products
+- `/accessibility-check` flags AI-specific concerns (bias, transparency, explainability, override capability)
+- `/pilot-design` adds AI-specific pilot metrics (accuracy, hallucination rate, trust calibration, behavior change)
+
+The framework is diagnostic, not prescriptive. Bolted-on AI can be a valid strategy. The skills help founders understand the implications for their pricing, sales, fundraising, and competitive positioning.
+
 ## 1.2.0 (2026-03-31)
 
 ### Tier-1 repo infrastructure

CLAUDE.md

@@ -21,6 +21,10 @@ When the user's request matches an available skill, invoke it using the Skill to
 
 Skills reference markdown files in `data/` for regulatory, market, and evidence information. Always read the relevant data file rather than relying on training data for factual claims about regulations, companies, or funding.
 
+## AI-native framework
+
+`data/ai-native-framework.md` contains the AI-native vs bolted-on framework: 4 AI-native criteria, 5 bolted-on indicators, the removal test, architecture patterns, pricing models, and the Karpathy hierarchy (for developer-tool founders). Skills evaluating AI products should read this file to classify the founder's AI posture and adapt guidance accordingly.
+
 ## Higher ed framework
 
 `data/higher-ed-jobs-atlas.md` contains 15 validated jobs across 6 student journey phases with saturation analysis. `data/founder-traps.md` contains 4 structural patterns founders miss plus the noise vs. signal filter. Both from ScaleU's SXSW EDU 2026 framework. Skills targeting higher ed founders should reference these files.

README.md

@@ -1,6 +1,6 @@
 # EdTech Founder Stack
 
-![Version](https://img.shields.io/badge/version-1.2.0-blue)
+![Version](https://img.shields.io/badge/version-1.3.0-blue)
 ![License](https://img.shields.io/badge/license-MIT-green)
 ![Skills](https://img.shields.io/badge/skills-10-orange)
 ![Research](https://img.shields.io/badge/papers-376-purple)

TODOS.md

@@ -0,0 +1,11 @@
+# TODOs
+
+## P3: AI-native framework consistency check
+
+**What:** Add a CI step that validates all 10 SKILL.md files reference `data/ai-native-framework.md` consistently. Grep for framework criteria references and flag drift when the data file evolves.
+
+**Why:** The AI-native framework is integrated across all 10 skills with duplicated detection logic (each skill asks its own AI posture question). When the framework criteria evolve (and they will, this space moves fast), updating the data file is easy but verifying all 10 skills still align requires manual review.
+
+**Effort:** S (human: ~2 hours / CC: ~15 min)
+
+**Depends on:** v1.3.0 shipped (AI-native framework integration)

VERSION

@@ -1 +1 @@
-1.2.0
+1.3.0

data/ai-native-framework.md

@@ -0,0 +1,118 @@
+# AI-Native vs Bolted-On Framework
+
+How to tell whether an edtech product is genuinely AI-native or whether AI was bolted on after the fact. This distinction shapes pricing, sales, fundraising, competitive positioning, and product architecture.
+
+## The Framework
+
+### 4 AI-Native Criteria
+
+A product is AI-native when:
+
+1. **Token/compute spend scales with usage.** Users can spend $100 or $1,000 via tokens as they use the product. The product's cost of goods sold (COGS) scales with the value delivered, not with the number of seats.
+
+2. **Gets substantially better every 6 months as base models improve.** When GPT-5 or Claude 5 ships, the product automatically improves without engineering effort. The product rides the model improvement curve, it doesn't just wrap a static API call.
+
+3. **Core workflow is impossible without AI, not just enhanced by it.** Remove all the AI and the product stops working. The AI isn't a feature... it's the engine.
+
+4. **Creates behavior change when users try it.** Users don't just use the product, they change how they work. They stop doing things the old way because the AI-powered way is fundamentally different, not just faster.
+
+### 5 Bolted-On Indicators
+
+A product has bolted-on AI when:
+
+1. **The main AI feature is a button with sparkle icons.** The AI is a discrete feature you click, not the underlying engine.
+
+2. **There's a chat pane where you ask LLM questions.** A chatbot sidebar that answers questions about the product. The product existed before the chat pane and works fine without it.
+
+3. **No memory or personalization beyond one chat.** Every interaction starts from scratch. The AI doesn't learn from the user's history, preferences, or behavior patterns.
+
+4. **Users try it once and go back to using the app the "normal" way.** The AI feature gets novelty clicks but doesn't change the core workflow. Usage drops after the first week.
+
+5. **AI is optional, not essential to the product working.** You can turn off every AI feature and the product still does its job. The AI is decorative.
+
+### The Removal Test
+
+The simplest way to classify: **remove all the AI from the product. Does it still work?**
+
+- If yes: the AI is bolted on. The product is a traditional edtech tool with AI features added.
+- If the product breaks or becomes useless: the AI is native. The product was built around AI from the ground up.
+
+This isn't a judgment call. Both can be valid business models. But they have fundamentally different implications for pricing, fundraising, sales, and competitive positioning.
+
+## AI-Native Architecture Patterns
+
+These patterns apply to any AI-native edtech product, regardless of sector or buyer.
+
+### Memory and personalization across sessions
+
+AI-native products remember. An AI tutoring engine that adapts to a student's learning patterns over weeks is native. A chatbot that starts fresh every conversation is bolted on. The memory creates compounding value: the more you use it, the better it gets for you specifically.
+
+### Model-agnostic design
+
+AI-native products work across model providers. They improve with GPT, Claude, Gemini, or open-source models. The product's value isn't locked to one API. When a better model ships, the product gets better automatically. This is the "improves every 6 months" signal.
+
+### Usage-based economics
+
+The product's COGS scales with value delivered. Heavy users cost more to serve but also get more value. This naturally leads to usage-based or outcome-based pricing. Per-seat pricing creates a mismatch: one teacher using AI tutoring for 30 students consumes 10x the compute of a teacher who logs in once a month, but pays the same.
+
+### Feedback loops
+
+User behavior improves the system. Student responses train better recommendations. Teacher corrections improve content generation. Usage data identifies which AI outputs are helpful and which aren't. The product has a data flywheel, not just an API call.
+
+## The Karpathy Hierarchy
+
+*This section applies if you're building tools for developers or AI workflows. If you're building an AI tutoring app, LMS, or student-facing product, skip to "AI-Native Pricing Models" below.*
+
+Andrej Karpathy articulated the hierarchy for connecting tools to AI coding agents: CLI at the top, API in the middle, MCP at the bottom.
+
+**CLI (best):** Zero context cost until the moment you call it. The AI calls a command-line tool directly from the user's machine. No handshake, no persistent connection, no context window overhead.
+
+**API (middle):** Lightweight and stateless. Each call is independent. The overhead is one request/response cycle. Works well for discrete operations.
+
+**MCP (worst for context):** Eats context the moment it connects. Every MCP you load sits in your context window doing nothing until you call it. Five MCPs connected can lose 15-20% of your usable context before a single message is typed.
+
+**The sub-agent pattern:** Dispatch work to sub-agents to preserve main session context. Carl Vellotti demonstrated this: a web research task with 10 tool calls and 30,000 tokens through a sub-agent moved the main session from 16% to 16.5% context used. Without the sub-agent, that same task would have filled to 25%. The difference between a session that lasts 30 messages and one that compacts after 5.
+
+If you're building AI developer tools for education (coding platforms, AI-assisted curriculum for CS, teacher tooling for programming classes), this hierarchy directly affects your product architecture and user experience.
+
+## AI-Native Pricing Models
+
+### Usage-based
+
+Per token, per API call, per computation. The user pays proportional to value consumed. Best for: products where heavy usage directly correlates with heavy value (AI tutoring, content generation, automated grading at scale).
+
+### Outcome-based
+
+Pay per successful tutoring session, per assessment completed, per learning outcome achieved. Best for: products that can measure specific outcomes and tie pricing to results.
+
+### Hybrid
+
+Base subscription for access + usage tier for AI features. Best for: products transitioning from traditional to AI-native, or selling to institutions that need predictable line items.
+
+### Per-seat is structurally challenged for AI-native
+
+AI-native products have variable COGS. A power user consuming 10x the compute pays the same as a casual user under per-seat pricing. At scale, this creates margin compression on your best customers.
+
+**But: institutional procurement reality matters.** K-12 districts and universities often require per-seat or site-license pricing because their procurement systems can't process usage-based invoices. The budget line item needs to be predictable.
+
+**Tactical advice:** Match your pricing to what the buyer can actually purchase.
+- **Direct-to-consumer and enterprise:** Usage-based or outcome-based pricing. Your structural advantage.
+- **Institutional procurement (districts, universities, state systems):** Per-seat or site-license pricing, but structure your margins to account for usage-based COGS. Build in usage tiers or fair-use policies to prevent margin compression from power users.
+- **Both channels:** Hybrid pricing. Base subscription + usage tier. The subscription gives procurement a line item, the usage tier captures AI-native value.
+
+The structural pressure on per-seat SaaS is real (massive valuation corrections in early 2026 hit per-seat AI-bolted companies hardest). But the tactical reality is: sell in the format your buyer can buy. Optimize internally for usage-based economics.
+
+## Bolted-On Is Not Always Wrong
+
+Some products should be bolted-on. Adding AI features to a working edtech product can be the right call when:
+
+- The core product already solves a real problem without AI
+- The AI features genuinely enhance specific workflows (not just sparkle icons)
+- The buyer doesn't care about AI architecture, they care about outcomes
+- The market isn't ready for a pure AI-native approach in that segment
+
+The framework is diagnostic, not prescriptive. It helps founders understand what they've built and the implications for their strategy. Bolted-on products compete on features and distribution. AI-native products compete on improving output quality over time. Both can win. The mistake is not knowing which game you're playing.
+
+---
+
+Last updated: 2026-04-01

skills/accessibility-check/SKILL.md

@@ -60,6 +60,16 @@ Options (multiSelect: true):
 - User-generated content
 - AI-generated content
 
+### AI-Specific Accessibility (if "AI-generated content" selected in Question 4)
+
+If the founder selected "AI-generated content" in Question 4, OR if the product description from earlier questions mentions AI, machine learning, LLM, adaptive, or similar, read `data/ai-native-framework.md` and add these AI-specific accessibility concerns to the Phase 2 assessment:
+
+- **Algorithmic bias:** Does the AI perform equally across demographics? An AI tutoring system that works better for native English speakers than English language learners has an accessibility problem. Test AI output across diverse learner populations.
+- **Transparency:** Can users understand why the AI made a recommendation? If a student gets a learning path and has no idea why, that's a transparency gap.
+- **Explainability:** Can the system explain its reasoning in plain language? Educators need to validate AI recommendations before acting on them.
+- **Override capability:** Can users override AI recommendations? AI that makes decisions without human review creates an accessibility barrier for users whose needs fall outside the model's training data.
+- **Data consent:** Do users understand what data feeds the AI? Informed consent is both an accessibility and privacy requirement.
+
 ## Phase 2: Requirements Assessment
 
 Based on their sector, explain the specific requirements that apply:

skills/edtech-landscape/SKILL.md

@@ -142,7 +142,13 @@ Output:
 - Common failure modes for startups in this segment
 - Where the gaps and opportunities are
 
-**If their product uses AI:** Call out the AI-specific competitive landscape for their sector. The AI landscape is moving fast — note that competitive positions may shift quickly and they should verify current status.
+**If their product uses AI (Question 5: "central" or "enhances"):** Read `data/ai-native-framework.md`. Call out the AI-specific competitive landscape for their sector. The AI landscape is moving fast — note that competitive positions may shift quickly and they should verify current status.
+
+Classify their AI posture based on Question 5:
+- "AI is central" = AI-native. Note: "Most edtech AI products are bolted-on. Being genuinely AI-native is a differentiator — your product improves automatically as base models improve, which most competitors can't match."
+- "AI enhances some features" = Borderline/bolted-on. Flag: "Your AI enhances but isn't essential. Competitors building AI-native in your space will improve faster. Consider whether your AI can become load-bearing, or compete on distribution and evidence instead. Run `/product-review` for a detailed AI architecture assessment."
+
+Map AI-native vs bolted-on competitors in their specific segment when providing the 3-5 key competitors list.
 
 ## Phase 5: Situational Brief
 

skills/evidence-check/SKILL.md

@@ -64,6 +64,22 @@ Options:
 - No, but we're open to it
 - No, and we want to do this ourselves
 
+### AI Posture Detection
+
+After Question 2, if the founder's product context mentions AI, machine learning, LLM, adaptive, or similar, ask via AskUserQuestion:
+
+"How central is AI to your product?"
+
+Options:
+- AI IS the product — the core workflow is impossible without it
+- AI is a significant feature — it enhances the product meaningfully but the product works without it
+- AI is a minor or planned feature — optional, supplementary, or not yet built
+- No AI component
+
+If AI-native or borderline: read `data/ai-native-framework.md` and add "behavior change" as an evidence dimension in Phase 2. AI-native products need to demonstrate they create behavior change (users work fundamentally differently), not just engagement or satisfaction.
+
+If AI posture is obvious from context, skip the question and state the classification.
+
 ## Phase 2: Evidence Classification
 
 Read `data/evidence-tiers.md` for the full ESSA framework.
@@ -102,6 +118,20 @@ Without a comparison group or statistical controls, improvement could be from ma
 **"We compared our schools to other schools and our schools did better" → Depends**
 If you controlled for prior achievement, demographics, and other differences statistically, this could be Tier 3. If you just compared raw scores without controls, the groups might have been different to begin with. That's Tier 4.
 
+### AI-Native Evidence Dimension (if AI posture detected)
+
+**If AI-native or borderline:**
+
+Beyond standard ESSA tier evidence, AI-native products need to demonstrate **behavior change**. This is the 4th AI-native criterion: users work fundamentally differently after trying the product.
+
+How to measure behavior change:
+- **Before/after workflow analysis:** Document how users performed the task before the product, then after 4-8 weeks of usage. Are they working differently, or just slightly faster at the same workflow?
+- **Usage persistence:** Do users continue using the AI-powered workflow after the novelty wears off (week 4+)? If usage drops after week 1, the AI isn't creating behavior change.
+- **Reversion rate:** When the product is temporarily unavailable, do users revert to old methods or wait for it to come back? Waiting = behavior change. Reverting = nice-to-have.
+- **Qualitative indicators:** Users describing their work as "before [product]" and "after [product]." Unprompted advocacy. Expanding usage to new contexts.
+
+Flag: "Engagement metrics (time on task, session counts) are necessary but not sufficient for AI-native evidence. A chatbot can have high engagement without creating any behavior change. Focus on whether users' workflows actually changed."
+
 ## Phase 3: Gap Analysis
 
 Based on the distance between their current tier and their target tier: