@booklib/core 2.0.0

package/skills/kotlin-in-action/scripts/setup_detekt.py

@@ -0,0 +1,224 @@
+#!/usr/bin/env python3
+"""
+setup_detekt.py - Set up Detekt with Kotlin-in-Action aligned rules.
+
+Usage:
+    python setup_detekt.py [--output-dir ./]
+
+Generates:
+    detekt.yml      - Detekt config with rules mapped to Kotlin in Action chapters
+    run_detekt.sh   - Shell script to run Detekt with this config
+
+Each rule includes a comment referencing the relevant chapter from
+"Kotlin in Action" by Dmitry Jemerov and Svetlana Isakova.
+"""
+
+import argparse
+import pathlib
+import stat
+
+DETEKT_YML = """\
+# detekt.yml
+# Detekt configuration aligned with "Kotlin in Action" by Jemerov & Isakova.
+# Each rule references the chapter that motivates it.
+
+build:
+  maxIssues: 0
+  excludeCorrectable: false
+
+config:
+  validation: true
+  warningsAsErrors: false
+
+complexity:
+  active: true
+
+  # Chapter 5 - Lambdas: keep lambdas and functions concise and readable.
+  LongMethod:
+    active: true
+    threshold: 20
+
+  # Chapter 3 - Functions: prefer functions with few, well-named parameters.
+  # Many parameters suggest the need for a data class or builder pattern.
+  LongParameterList:
+    active: true
+    functionThreshold: 4
+    constructorThreshold: 6
+    ignoreDefaultParameters: true
+
+  # Chapter 10 - Higher-order functions: avoid deep nesting; flatten with
+  # higher-order functions (map, filter, let, run) instead.
+  NestedBlockDepth:
+    active: true
+    threshold: 3
+
+  # Chapter 4 - Classes: classes should be focused and not overly complex.
+  TooManyFunctions:
+    active: true
+    thresholdInFiles: 20
+    thresholdInClasses: 15
+    thresholdInInterfaces: 10
+    thresholdInObjects: 10
+    thresholdInEnums: 5
+
+naming:
+  active: true
+
+  # Chapter 3 - Functions: Kotlin convention is camelCase for function names.
+  FunctionNaming:
+    active: true
+    functionPattern: '[a-z][a-zA-Z0-9]*'
+    excludes: ['**/test/**']
+
+  # Chapter 2 - Basics: variables follow camelCase; properties are idiomatic Kotlin.
+  VariableNaming:
+    active: true
+    variablePattern: '[a-z][a-zA-Z0-9]*'
+    privateVariablePattern: '(_)?[a-z][a-zA-Z0-9]*'
+
+  # Chapter 4 - Classes: class names are PascalCase per Kotlin convention.
+  ClassNaming:
+    active: true
+    classPattern: '[A-Z][a-zA-Z0-9]*'
+
+  # Chapter 8 - Generics: type parameter names should be single uppercase letters
+  # or descriptive PascalCase names.
+  TypeParameterNaming:
+    active: true
+    typeParameterPattern: '[A-Z][A-Za-z]*'
+
+style:
+  active: true
+
+  # Chapter 4 - Classes, Objects, Interfaces: abstract classes without abstract
+  # members should be interfaces or open classes instead.
+  UnnecessaryAbstractClass:
+    active: true
+
+  # Chapter 3 - Functions: Unit return type is implicit; declaring it is redundant.
+  OptionalUnit:
+    active: true
+
+  # Chapter 2 - Basics: val properties that can be const should be const
+  # for compile-time optimisation.
+  MayBeConst:
+    active: true
+
+  # Chapter 4 - Objects: use object declarations instead of classes with only
+  # static members.
+  UseDataClass:
+    active: true
+    allowVars: false
+
+  # Chapter 11 - DSL: trailing lambdas should be outside parentheses per convention.
+  UnnecessaryParentheses:
+    active: true
+
+potential-bugs:
+  active: true
+
+  # Chapter 6 - Null Safety: lateinit signals deferred initialisation, which
+  # makes nullability guarantees harder to reason about. Prefer constructor injection.
+  LateinitUsage:
+    active: true
+    excludes: ['**/test/**']
+    ignoreOnClassesPattern: ''
+
+  # Chapter 6 - Null Safety: the !! operator bypasses null safety and will
+  # throw NPE at runtime. Use safe calls (?.) or Elvis operator (?:) instead.
+  UnsafeCallOnNullableType:
+    active: true
+    excludes: ['**/test/**']
+
+  # Chapter 6 - Null Safety: explicit null checks with == null should be
+  # replaced with safe-call or let idioms.
+  NullableToStringCall:
+    active: true
+
+coroutines:
+  active: true
+
+  # Chapter 12 (Appendix) - Coroutines: GlobalScope couples coroutines to
+  # application lifetime and makes cancellation impossible. Use structured
+  # concurrency with a scoped CoroutineScope instead.
+  GlobalCoroutineUsage:
+    active: true
+
+  # Chapter 12 - Coroutines: suspend modifier on a function that contains no
+  # suspension points is misleading and adds unnecessary overhead.
+  RedundantSuspendModifier:
+    active: true
+
+  # Chapter 12 - Coroutines: use withContext for blocking calls rather than
+  # running them on the default dispatcher.
+  BlockingMethodInNonBlockingContext:
+    active: true
+"""
+
+RUN_SCRIPT = """\
+#!/usr/bin/env bash
+# run_detekt.sh
+# Runs Detekt with the Kotlin-in-Action aligned configuration.
+# Generated by setup_detekt.py
+
+set -euo pipefail
+
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+CONFIG="${SCRIPT_DIR}/detekt.yml"
+SRC_DIR="${1:-src}"
+
+if ! command -v detekt &>/dev/null && ! command -v detekt-cli &>/dev/null; then
+  echo "ERROR: detekt not found on PATH."
+  echo ""
+  echo "Install options:"
+  echo "  brew install detekt          # macOS"
+  echo "  sdk install detekt           # SDKMAN"
+  echo "  # Or run via Gradle plugin - add to build.gradle.kts:"
+  echo "  #   plugins { id(\\"io.gitlab.arturbosch.detekt\\") version \\"1.23.5\\" }"
+  exit 1
+fi
+
+CMD="detekt"
+command -v detekt-cli &>/dev/null && CMD="detekt-cli"
+
+echo "Running Detekt on $SRC_DIR ..."
+$CMD --config "$CONFIG" --input "$SRC_DIR"
+echo "Done."
+"""
+
+
+def write_file(path: pathlib.Path, content: str, executable: bool = False) -> None:
+    path.write_text(content, encoding="utf-8")
+    if executable:
+        path.chmod(path.stat().st_mode | stat.S_IXUSR | stat.S_IXGRP | stat.S_IXOTH)
+    print(f"Wrote: {path}")
+
+
+def main() -> None:
+    parser = argparse.ArgumentParser(
+        description="Set up Detekt with Kotlin-in-Action aligned rules."
+    )
+    parser.add_argument(
+        "--output-dir",
+        default=".",
+        help="Directory to write config files (default: ./)",
+    )
+    args = parser.parse_args()
+
+    output_dir = pathlib.Path(args.output_dir).resolve()
+    output_dir.mkdir(parents=True, exist_ok=True)
+
+    write_file(output_dir / "detekt.yml", DETEKT_YML)
+    write_file(output_dir / "run_detekt.sh", RUN_SCRIPT, executable=True)
+
+    print()
+    print("Setup complete.")
+    print(f"  Config : {output_dir / 'detekt.yml'}")
+    print(f"  Runner : {output_dir / 'run_detekt.sh'}")
+    print()
+    print("Run Detekt:")
+    print(f"  cd {output_dir} && ./run_detekt.sh [src-dir]")
+
+
+if __name__ == "__main__":
+    main()

package/skills/lean-startup/SKILL.md

@@ -0,0 +1,160 @@
+---
+name: lean-startup
+version: "1.0"
+license: MIT
+tags: [product, strategy, entrepreneurship]
+description: >
+  Apply The Lean Startup practices (Eric Ries). Covers Vision (Ch 1-4: Start,
+  Define, Learn, Experiment — validated learning, Build-Measure-Learn loop),
+  Steer (Ch 5-8: Leap of faith assumptions, MVP testing, innovation accounting,
+  pivot or persevere decisions), Accelerate (Ch 9-14: small batches, engines of
+  growth — sticky/viral/paid, adaptive organization, Five Whys, innovation
+  sandbox, startup within enterprise). Trigger on "lean startup", "MVP",
+  "minimum viable product", "validated learning", "pivot", "Build-Measure-Learn",
+  "innovation accounting", "product-market fit", "startup strategy",
+  "lean methodology", "growth engine", "Five Whys".
+---
+
+# The Lean Startup Skill
+
+You are an expert startup strategy advisor grounded in the 14 chapters from
+*The Lean Startup* (How Today's Entrepreneurs Use Continuous Innovation to
+Create Radically Successful Businesses) by Eric Ries. You help in two modes:
+
+1. **Strategy Application** — Apply Lean Startup principles to design experiments, build MVPs, and make pivot/persevere decisions
+2. **Strategy Review** — Analyze existing startup/product strategies against the book's practices and recommend improvements
+
+## How to Decide Which Mode
+
+- If the user asks to *plan*, *design*, *build*, *launch*, *test*, or *validate* a product/startup idea → **Strategy Application**
+- If the user asks to *review*, *evaluate*, *audit*, *assess*, or *improve* an existing strategy/approach → **Strategy Review**
+- If ambiguous, ask briefly which mode they'd prefer
+
+---
+
+## Mode 1: Strategy Application
+
+When helping design or apply Lean Startup methodology, follow this decision flow:
+
+### Step 1 — Understand the Context
+
+Ask (or infer from context):
+
+- **What stage?** — Idea, pre-MVP, MVP built, post-launch, scaling?
+- **What type?** — New startup, new product in existing company, internal innovation?
+- **What uncertainty?** — Which assumptions are riskiest? What do you know vs. believe?
+- **What resources?** — Team size, budget, timeline constraints?
+
+### Step 2 — Apply the Right Practices
+
+Read `references/api_reference.md` for the full chapter-by-chapter catalog. Quick decision guide:
+
+| Concern | Chapters to Apply |
+|---------|-------------------|
+| Starting a new venture | Ch 1: Entrepreneurship is management; startups need a different kind of management |
+| Defining the startup | Ch 2: Institution, product, conditions of extreme uncertainty — the lean startup definition |
+| Learning what customers want | Ch 3: Validated learning, value vs. waste, empirical evidence over opinions |
+| Running first experiments | Ch 4: Strategic planning through experimentation, Zappos-style MVP tests |
+| Identifying risky assumptions | Ch 5: Leap-of-faith assumptions, value hypothesis, growth hypothesis, genchi gembutsu |
+| Building the first product | Ch 6: MVP types (video, concierge, Wizard of Oz, fake-door/smoke-test), quality in MVP context |
+| Measuring progress | Ch 7: Innovation accounting, actionable vs. vanity metrics, cohort analysis, funnel metrics |
+| Deciding pivot vs. persevere | Ch 8: Pivot catalog (zoom-in, zoom-out, customer segment, platform, etc.), runway as pivots remaining |
+| Optimizing development speed | Ch 9: Small batches, continuous deployment, single-piece flow, IMVU pull model |
+| Scaling sustainably | Ch 10: Engines of growth (sticky, viral, paid), product/market fit, sustainable growth |
+| Building adaptive organizations | Ch 11: Five Whys root cause analysis, proportional investment, adaptive process |
+| Innovating within large companies | Ch 12: Innovation sandbox, internal startup teams, protecting the parent organization |
+| Eliminating waste | Ch 13: Lean manufacturing roots, what waste looks like in startups |
+| Building a movement | Ch 14: Lean Startup as organizational capability, long-term thinking |
+
+<framework>
+1. **Entrepreneurs are everywhere** — Any person creating products under conditions of extreme uncertainty is an entrepreneur.
+2. **Entrepreneurship is management** — Startups need management suited to their context, not "just do it".
+3. **Validated learning** — Learn what customers actually want through empirical experiments, not opinions.
+4. **Build-Measure-Learn** — Turn ideas into products, measure customer response, learn whether to pivot or persevere.
+5. **Innovation accounting** — Hold entrepreneurs accountable with metrics that matter, not vanity metrics.
+6. **Test the riskiest assumption first** — Identify and test leap-of-faith assumptions before building more.
+7. **MVP is for learning, not launching** — The MVP tests a hypothesis; it's the fastest way to get through the Build-Measure-Learn loop.
+8. **Actionable metrics over vanity metrics** — Use cohort analysis and split tests, not total signups or page views.
+9. **Pivot or persevere is a structured decision** — Use innovation accounting data to make this call, not gut feeling.
+10. **Sustainable growth comes from engines** — Identify which engine of growth (sticky, viral, paid) drives your business.
+</framework>
+
+---
+
+## Mode 2: Strategy Review
+
+When reviewing startup/product strategies, read `references/review-checklist.md` for the full checklist.
+
+### Review Process
+
+1. **Vision scan** — Check Ch 1-2: Is the venture operating as a startup? Is the right management approach used?
+2. **Learning scan** — Check Ch 3-4: Is validated learning happening? Are experiments structured?
+3. **Assumption scan** — Check Ch 5-6: Are leap-of-faith assumptions identified? Is the MVP testing them?
+4. **Metrics scan** — Check Ch 7: Are metrics actionable? Is innovation accounting in place?
+5. **Decision scan** — Check Ch 8: Are pivot/persevere decisions structured and data-driven?
+6. **Execution scan** — Check Ch 9-10: Are batches small? Is a growth engine identified?
+7. **Organization scan** — Check Ch 11-12: Is Five Whys used? Is innovation protected?
+
+### Review Output Format
+
+Structure your review as:
+
+```
+## Summary
+One paragraph: overall strategy quality, Lean Startup alignment, key strengths and main concerns.
+
+## What's Working Well
+For each correctly applied practice:
+- **Practice**: what the strategy does correctly
+- **Book reference**: chapter and concept this exemplifies
+
+## Issues Found
+For each genuine issue (omit this section if there are none):
+- **Topic**: chapter and concept
+- **Problem**: what's wrong
+- **Fix**: recommended change
+
+## Recommendations
+Priority-ordered from most critical to nice-to-have.
+If the strategy is well-structured, frame suggestions as optional enhancements.
+Each recommendation references the specific chapter/concept.
+```
+
+<pitfalls>
+- **Building without testing assumptions** → Ch 5: Identify and test leap-of-faith assumptions before building.
+- **Vanity metrics as success indicators** → Ch 7: Replace total signups/pageviews with cohort analysis and actionable metrics.
+- **MVP as "version 1.0"** → Ch 6: MVP is an experiment, not a product launch; it tests a hypothesis.
+- **Theater of success** → Ch 3: Launching features is not learning; measure actual customer behavior.
+- **Premature scaling** → Ch 10: Don't scale before product/market fit; growth engine must be working first.
+- **Not talking to customers** → Ch 5: Genchi gembutsu — go and see for yourself; customer development.
+- **Blaming team instead of process** → Ch 11: Use Five Whys to find root causes.
+- **Confusing efficiency with learning** → Ch 13: In startups, the biggest waste is building something nobody wants.
+</pitfalls>
+
+---
+
+<case_studies>
+**Example 1 — New Startup Idea (Concierge MVP):**
+- Value hypothesis: "Busy parents will use a meal planning tool weekly"
+- Growth hypothesis: "Parents will share meal plans with other parents"
+- Design: Manually create plans for 10 families before building software.
+
+**Example 2 — Marketplace (Wizard of Oz MVP):**
+- Design: Manually match first 20 tutor-student pairs behind a basic landing page.
+- Goal: Measure match quality and rebooking rate before automating.
+</case_studies>
+
+---
+
+## General Guidelines
+
+- **Lean Startup is scientific method for business** — Hypothesize, experiment, measure, learn
+- **Speed of learning is the competitive advantage** — Not speed of building
+- **Every assumption is testable** — Frame assumptions as falsifiable hypotheses
+- **Metrics must be actionable, accessible, and auditable** — The three A's of good metrics
+- **Pivots are not failures** — They are structured course corrections based on learning
+- **The goal is sustainable business, not just product** — Business model validation matters
+- **Calibrate feedback to the quality of the work** — A well-designed experiment deserves explicit praise; do not manufacture issues to appear thorough. If a strategy correctly applies Lean Startup principles, do NOT add "Priority 1" or "Priority 2" labels to minor observations — frame them as optional enhancements or leave the Issues section empty.
+- **Praise correct application explicitly** — When a hypothesis is falsifiable, say so. When a riskiest assumption is named separately (even if worded differently than you would choose), praise the identification. When an MVP type is correctly chosen, say so. When pivot/persevere criteria are pre-defined, say so. When metrics have specific numerical thresholds, praise the quantification. Naming what is correct is as important as naming what is wrong.
+- For deeper practice details, read `references/api_reference.md` before applying strategy.
+- For review checklists, read `references/review-checklist.md` before reviewing strategy.

package/skills/lean-startup/assets/example_asset.txt

@@ -0,0 +1 @@
+

package/skills/lean-startup/evals/evals.json

@@ -0,0 +1,43 @@
+{
+  "evals": [
+    {
+      "id": "eval-01-six-month-build-before-user-testing",
+      "prompt": "Review this product development plan:\n\n```\nProduct: TaskFlow — AI-powered project management for remote teams\nTeam: 4 engineers, 1 designer, 1 product manager\nTimeline: 6-month build before any user testing\n\nMonth 1-2: Core task management (create, assign, due dates, status)\nMonth 3: AI features (auto-prioritization, workload balancing)\nMonth 4: Integrations (Slack, GitHub, Jira, Google Calendar)\nMonth 5: Mobile apps (iOS and Android)\nMonth 6: Analytics dashboard and reporting\n\nSuccess criteria: Ship to beta users after 6 months\nMarketing plan: Product Hunt launch in month 7\n\nAssumptions we're making:\n- Remote teams struggle with task prioritization\n- AI suggestions will be trusted and acted on\n- Teams are willing to switch from their current PM tool\n- Integration with existing tools is a must-have on day one\n```",
+      "expectations": [
+        "Identifies the 6-month build before any user testing as a direct violation of the Build-Measure-Learn loop: validated learning cannot happen without users (Ch 3-4: validated learning, experimentation over planning)",
+        "Flags the listed assumptions ('remote teams struggle', 'AI suggestions will be trusted', 'willing to switch') as leap-of-faith assumptions that should be tested first, not assumed (Ch 5: identify and test leap-of-faith assumptions before building)",
+        "Flags the absence of any hypothesis or success metric beyond 'ship to beta': recommends defining a value hypothesis and growth hypothesis with measurable success criteria (Ch 5: value hypothesis and growth hypothesis)",
+        "Flags the absence of an MVP: 6 months of features is not an MVP — it is a v1.0 product launch; recommends identifying the single riskiest assumption and testing it with the minimum viable experiment (Ch 6: MVP is for learning, not launching)",
+        "Flags that integrations, mobile apps, and analytics are included before validating whether users even want the core task management and AI features; recommends cutting scope to the riskiest assumption (Ch 6: smallest experiment to test the riskiest assumption)",
+        "Flags the absence of innovation accounting: there are no cohort metrics, funnel metrics, or baseline measurements planned (Ch 7: innovation accounting)",
+        "Recommends concrete alternatives such as a concierge MVP (manually prioritize tasks for 5 teams for 2 weeks) or a Wizard of Oz test (fake AI powered by a human) to validate the AI trust assumption before building it"
+      ]
+    },
+    {
+      "id": "eval-02-feature-request-without-validated-learning",
+      "prompt": "Review this feature request and justification:\n\n```\nFeature Request: Advanced Filtering and Saved Views\n\nSubmitted by: Product Manager\nPriority: High\n\nRequest:\nAdd advanced filtering to the task list — filter by assignee, due date range,\ntag, project, and custom fields. Users should be able to save filter combinations\nas named views (e.g., \"My overdue tasks\", \"Sprint backlog\").\n\nJustification:\n- 3 customers mentioned filtering in support tickets last quarter\n- Our top competitor, Asana, has this feature\n- The engineering team estimates 3 sprints (6 weeks) to build\n- A customer on a discovery call said \"filtering would be great\"\n\nExpected outcome:\nImprove user retention and increase upsell conversion to Pro tier.\n\nApproval requested: Start sprint planning next week\n```",
+      "expectations": [
+        "Flags that 'customers mentioned in support tickets' and 'a customer said it would be great' are anecdotal, not validated learning — these are opinions, not measured behavior (Ch 3: validated learning requires empirical evidence, not opinions)",
+        "Flags competitor benchmarking ('Asana has this feature') as a reason to build without testing whether this feature drives retention or conversion for this specific user base (Ch 5: test your own value hypothesis, not competitors')",
+        "Flags that the expected outcome 'improve retention and increase upsell' is stated without a hypothesis, baseline metric, or success threshold; recommends defining a testable hypothesis before committing 6 weeks of engineering (Ch 7: innovation accounting — establish baseline, define success threshold)",
+        "Flags no mention of which leap-of-faith assumption is being tested: is the assumption that users can't find what they need, that they churn because of missing filters, or that Pro upsell is blocked by this feature? (Ch 5: identify the specific assumption)",
+        "Recommends a smaller experiment to validate before building: add a prominent 'Filter tasks' button that shows a 'Coming soon — join waitlist' modal and measure click rate to quantify demand (Ch 6: smallest experiment to validate the assumption)",
+        "Flags the absence of a pivot/persevere decision framework: what happens if the feature ships and retention does not improve? (Ch 8: define pivot/persevere criteria before building)"
+      ]
+    },
+    {
+      "id": "eval-03-well-structured-mvp-experiment",
+      "prompt": "Review this product experiment plan:\n\n```\nExperiment: Validate demand for AI-assisted code review summaries\n\nHypothesis:\nWe believe that engineering managers at companies with 10-50 engineers\nspend more than 2 hours per week reading through pull request diffs to\nstay informed. We believe they will pay for an automated daily digest\nthat summarizes what changed, why, and any risks flagged.\n\nRiskiest assumption: Managers will read and act on AI-generated summaries\nrather than skimming or ignoring them.\n\nMVP Design (Wizard of Oz — 3-week test):\n- Recruit 8 engineering managers via LinkedIn outreach\n- Each connects their GitHub repo (OAuth)\n- Every weekday morning, a human analyst (us) reads the day's PRs\n  and writes a 200-word summary email manually\n- We send it from a branded email: digest@codebrief.io\n- Participants do not know summaries are human-written\n\nSuccess metrics (measured after 3 weeks):\n- Primary: Open rate >= 70% across all 5 weekday sends\n- Secondary: At least 5 of 8 managers respond to exit survey saying\n  they found summaries 'useful' or 'very useful'\n- Conversion signal: At least 3 managers ask 'how do I keep this?'\n\nPivot/persevere criteria:\n- If primary AND secondary metrics are met: build v1 with real AI\n- If only one is met: run a second 2-week test with adjusted format\n- If neither is met: pivot to a different user segment or problem\n\nTimeline: Recruiting this week, experiment runs weeks 2-4, decision week 5\n```",
+      "expectations": [
+        "Recognizes this is a well-structured Lean Startup experiment and says so explicitly",
+        "Praises the falsifiable hypothesis that names a specific user segment, problem, and measurable behavior (Ch 3: validated learning with empirical evidence)",
+        "Praises identifying the riskiest assumption ('managers will act on summaries') separately from the general hypothesis — this is the correct application of leap-of-faith assumption identification (Ch 5: leap-of-faith assumptions)",
+        "Praises the Wizard of Oz MVP design that tests the value hypothesis without building any AI infrastructure (Ch 6: MVP is for learning, not launching — concierge/Wizard of Oz types)",
+        "Praises the quantified success metrics with specific thresholds (70% open rate, 5/8 satisfaction, 3 conversion signals) rather than vague goals (Ch 7: actionable metrics, not vanity metrics)",
+        "Praises the explicit pivot/persevere criteria defined before the experiment runs, making the decision data-driven rather than gut-driven (Ch 8: structured pivot/persevere decision)",
+        "Praises the tight 5-week timeline keeping the Build-Measure-Learn loop short (Ch 9: small batches, fast learning cycles)",
+        "Does NOT manufacture issues to appear thorough; any suggestions are explicitly framed as minor optional improvements"
+      ]
+    }
+  ]
+}

package/skills/lean-startup/evals/results.json

@@ -0,0 +1,13 @@
+{
+  "pass_rate": 1,
+  "passed": 21,
+  "total": 21,
+  "baseline_pass_rate": 0.524,
+  "baseline_passed": 11,
+  "baseline_total": 21,
+  "delta": 0.476,
+  "model": "default",
+  "evals_run": 3,
+  "date": "2026-03-28",
+  "non_standard_provider": true
+}

package/skills/lean-startup/examples/after.md

@@ -0,0 +1,80 @@
+# After
+
+An MVP experiment document that identifies the riskiest assumption, defines the smallest test, specifies actionable metrics, and sets explicit pivot/persevere criteria before any code is written.
+
+```markdown
+## MVP Experiment: AI Expense Management — Concierge Test
+
+### The Big Idea
+SMB finance managers spend 3+ hours per week manually reconciling receipts.
+We believe they will pay for a tool that eliminates that work — but we have
+not yet validated that they will change their workflow to use it.
+
+### Leap-of-Faith Assumptions to Test
+
+**Value hypothesis (riskiest):**
+> "Finance managers at 10–50 person companies will submit receipts through
+> a new tool at least 3× per week if the categorisation is accurate."
+
+**Growth hypothesis (secondary):**
+> "Satisfied users will refer at least one colleague within 30 days."
+
+### Why NOT build the full product yet
+Building OCR + AI categorisation + ERP integrations takes 6 months and $400K.
+If users don't form the habit of submitting receipts, none of those features
+matter. We must validate the value hypothesis first.
+
+### MVP Design: Concierge (Manual Behind the Scenes)
+
+**What users experience:**
+- Sign up form → they receive a dedicated WhatsApp number
+- They photograph receipts and send to WhatsApp
+- We manually categorise and respond with a structured summary within 2 hours
+- Weekly: we email a formatted expense report (manually compiled in Google Sheets)
+
+**What we actually build:**
+- Landing page with sign-up form (1 day)
+- WhatsApp Business number (1 hour)
+- Google Sheets report template (2 hours)
+- Total build time: ~2 days
+
+**Participants:** 15 finance managers recruited from our network
+
+**Duration:** 6 weeks
+
+### Innovation Accounting — Metrics
+
+| Metric | Baseline | Target (persevere) | Source |
+|--------|----------|--------------------|--------|
+| Weekly receipt submission rate | 0 | ≥ 3 receipts/user/week by week 4 | WhatsApp logs |
+| Categorisation acceptance rate | — | ≥ 85% accepted without correction | User replies |
+| User retention (still active week 6) | — | ≥ 70% of participants | WhatsApp logs |
+| Referral rate | 0 | ≥ 1 referral per 5 users | Sign-up source field |
+| Willingness to pay | 0 | ≥ 60% say "yes" at $29/mo | End-of-pilot survey |
+
+**Vanity metrics we will NOT track:** total sign-ups, page views, social shares.
+
+### Pivot/Persevere Decision — Week 6 Review
+
+**Persevere** (move to automated MVP) if ALL of:
+- Submission rate ≥ 3/week by week 4
+- Retention ≥ 70% at week 6
+- Willingness to pay ≥ 60%
+
+**Pivot** (reconsider problem or segment) if ANY of:
+- Submission rate < 1/week by week 3 (habit not forming)
+- Retention < 40% at week 4 (users not finding value)
+
+**Pivot options to consider:**
+- Zoom-in: focus only on one vertical (e.g., restaurant industry) where receipt volume is higher
+- Customer segment: target bookkeepers who file for multiple clients, not the SMB themselves
+- Problem: pivot to approval workflows if users engage more with that step than receipt capture
+```
+
+Key improvements:
+- Leap-of-faith assumptions are named explicitly before any engineering begins — value hypothesis and growth hypothesis are the riskiest bets, not product features (Ch 5: Leap-of-faith assumptions)
+- Concierge MVP — two days of manual work — tests the core habit loop without six months of engineering (Ch 6: MVP is for learning, not launching)
+- Innovation accounting table defines baseline, target, and data source for each metric before the experiment runs (Ch 7: Innovation accounting)
+- All metrics are cohort-based and behavioural ("submission rate", "retention") — vanity metrics like total sign-ups are explicitly excluded (Ch 7: Actionable vs. vanity metrics)
+- Explicit pivot/persevere decision criteria with a named decision date eliminate gut-feel delays (Ch 8: Pivot or persevere)
+- Pivot catalog is pre-populated — the team has thought through options in advance rather than scrambling at the decision point (Ch 8: Pivot types)

package/skills/lean-startup/examples/before.md

@@ -0,0 +1,34 @@
+# Before
+
+A product specification for a 6-month build with no validated learning step, no hypothesis to test, and no criteria for deciding whether to continue.
+
+```markdown
+## Product Spec: AI-Powered Expense Management Platform
+
+### Overview
+We will build a comprehensive AI-powered expense management platform for SMBs.
+The platform will replace manual receipt tracking with automatic categorization,
+OCR scanning, policy enforcement, and CFO-level reporting.
+
+### Features (all required for launch)
+- Mobile app (iOS + Android) with camera OCR for receipt scanning
+- AI categorization engine trained on 50k expense categories
+- Multi-currency support with live FX rates
+- Approval workflow engine with configurable multi-level sign-off
+- Integration with QuickBooks, Xero, NetSuite, SAP
+- Admin dashboard with 25 pre-built CFO reports
+- SSO/SAML integration
+- Audit log and compliance export (SOC 2 ready)
+
+### Timeline
+- Month 1-2: Backend API + database schema
+- Month 3-4: Mobile app development
+- Month 5: Integrations + admin dashboard
+- Month 6: QA, security review, launch
+
+### Success metric
+5,000 paying customers within 3 months of launch.
+
+### Next step
+Kick off engineering sprint planning on Monday.
+```