@booklib/skills 1.0.0

package/lean-startup/references/review-checklist.md

@@ -0,0 +1,137 @@
+# The Lean Startup — Strategy Review Checklist
+
+Systematic checklist for reviewing startup/product strategies against the 14 chapters
+from *The Lean Startup* by Eric Ries.
+
+---
+
+## 1. Vision & Definition (Chapters 1–2)
+
+### Startup Identity
+- [ ] **Ch 1 — Startup management** — Is the venture managed as a startup (experimentation-based) rather than with traditional planning?
+- [ ] **Ch 1 — Five principles awareness** — Are the five Lean Startup principles understood and applied?
+- [ ] **Ch 2 — Uncertainty acknowledgment** — Is extreme uncertainty recognized as the defining condition?
+- [ ] **Ch 2 — Institutional thinking** — Is the startup treated as an institution requiring management, not just a product?
+
+---
+
+## 2. Learning & Experimentation (Chapters 3–4)
+
+### Validated Learning
+- [ ] **Ch 3 — Learning measurement** — Can the team point to specific validated learnings from recent work?
+- [ ] **Ch 3 — Value vs. waste** — Is effort directed toward learning what customers want, or toward untested features?
+- [ ] **Ch 3 — Empirical evidence** — Are decisions based on customer experiment data, not opinions or surveys alone?
+- [ ] **Ch 3 — Learning milestones** — Are learning milestones used instead of (or alongside) traditional milestones?
+
+### Experiment Design
+- [ ] **Ch 4 — Hypothesis-driven** — Are initiatives framed as testable hypotheses with clear success/failure criteria?
+- [ ] **Ch 4 — Minimum experiment** — Is each experiment the smallest possible test of the core assumption?
+- [ ] **Ch 4 — Real customers** — Are experiments run with actual customers, not internal stakeholders?
+- [ ] **Ch 4 — Measurable outcomes** — Are success/failure criteria defined before the experiment runs?
+
+---
+
+## 3. Assumptions & MVP (Chapters 5–6)
+
+### Leap-of-Faith Assumptions
+- [ ] **Ch 5 — Assumptions identified** — Are the riskiest assumptions explicitly listed?
+- [ ] **Ch 5 — Value hypothesis** — Is there a clear value hypothesis (will customers use/pay for this)?
+- [ ] **Ch 5 — Growth hypothesis** — Is there a clear growth hypothesis (how will new customers discover this)?
+- [ ] **Ch 5 — Risk ordering** — Are assumptions tested in order of riskiness (most dangerous first)?
+- [ ] **Ch 5 — Customer contact** — Is the team practicing genchi gembutsu (talking to customers directly)?
+
+### MVP Design
+- [ ] **Ch 6 — MVP purpose** — Is the MVP designed to test a hypothesis, not to be a small product?
+- [ ] **Ch 6 — MVP type** — Is the right MVP type used (video, concierge, Wizard of Oz, landing page, smoke test)?
+- [ ] **Ch 6 — Minimum scope** — Does the MVP contain only what's needed for the learning goal?
+- [ ] **Ch 6 — Quality perspective** — Is MVP quality measured by learning quality, not product polish?
+- [ ] **Ch 6 — Fear management** — Are fears (competitors, brand damage, discouragement) addressed rationally?
+
+---
+
+## 4. Metrics & Accounting (Chapter 7)
+
+### Innovation Accounting
+- [ ] **Ch 7 — Three-step process** — Is innovation accounting followed (baseline → tune → pivot/persevere)?
+- [ ] **Ch 7 — Baseline established** — Has the MVP established a baseline for key metrics?
+- [ ] **Ch 7 — Tuning measured** — Are iterations measured against the baseline to show improvement?
+- [ ] **Ch 7 — Decision readiness** — Is there enough data to make a pivot/persevere decision?
+
+### Metric Quality
+- [ ] **Ch 7 — Actionable metrics** — Are metrics actionable (show cause and effect), not vanity (total signups)?
+- [ ] **Ch 7 — Cohort analysis** — Are customers grouped by cohort, not measured as cumulative totals?
+- [ ] **Ch 7 — Split testing** — Are product changes tested with A/B tests, not "launch and hope"?
+- [ ] **Ch 7 — Three A's** — Are metrics Actionable, Accessible (everyone understands), and Auditable (verifiable)?
+- [ ] **Ch 7 — Kanban with validation** — Are features tracked through a validation stage, not just "done"?
+
+---
+
+## 5. Pivot Decisions (Chapter 8)
+
+### Decision Process
+- [ ] **Ch 8 — Regular meetings** — Are pivot/persevere meetings scheduled regularly (not crisis-driven)?
+- [ ] **Ch 8 — Data-driven** — Are pivot decisions based on innovation accounting data, not gut feelings?
+- [ ] **Ch 8 — Runway awareness** — Is runway measured in pivots remaining, not just cash?
+- [ ] **Ch 8 — Warning signs** — Are telltale signs monitored (diminishing experiment results, unproductive development)?
+
+### Pivot Knowledge
+- [ ] **Ch 8 — Pivot catalog** — Does the team know the full catalog of pivot types?
+- [ ] **Ch 8 — Preserved learning** — Does each pivot preserve validated learning while changing what isn't working?
+- [ ] **Ch 8 — No stigma** — Is pivoting treated as a strategic move, not a failure?
+
+---
+
+## 6. Execution & Growth (Chapters 9–10)
+
+### Development Process
+- [ ] **Ch 9 — Small batches** — Is work shipped in small batches, not large releases?
+- [ ] **Ch 9 — Continuous deployment** — Are changes deployed frequently (daily or more)?
+- [ ] **Ch 9 — Pull system** — Are features built only when validated learning demands them?
+- [ ] **Ch 9 — Andon cord** — Is there a process to stop and fix quality issues immediately?
+
+### Growth Strategy
+- [ ] **Ch 10 — Engine identified** — Is the engine of growth identified (sticky, viral, or paid)?
+- [ ] **Ch 10 — Engine focused** — Is the team focused on one engine at a time?
+- [ ] **Ch 10 — Sustainable growth** — Does growth come from past customer actions, not one-time campaigns?
+- [ ] **Ch 10 — Product/market fit** — Are key metrics spiking, indicating product/market fit?
+- [ ] **Ch 10 — Engine monitoring** — Is the team watching for engine exhaustion and planning transitions?
+
+---
+
+## 7. Organization & Process (Chapters 11–12)
+
+### Adaptive Process
+- [ ] **Ch 11 — Five Whys** — Is Five Whys root cause analysis used for problems?
+- [ ] **Ch 11 — Proportional investment** — Are fixes proportional to problem severity?
+- [ ] **Ch 11 — No blame culture** — Does root cause analysis focus on systems, not people?
+- [ ] **Ch 11 — Continuous improvement** — Is there a culture of learning from failures?
+
+### Innovation Structure (for enterprises)
+- [ ] **Ch 12 — Innovation sandbox** — Is there a protected space for innovation with clear boundaries?
+- [ ] **Ch 12 — Dedicated team** — Is the innovation team small, cross-functional, and fully dedicated?
+- [ ] **Ch 12 — Team autonomy** — Does the team have authority to build, deploy, and iterate independently?
+- [ ] **Ch 12 — Parent protection** — Are mechanisms in place to protect the parent organization?
+- [ ] **Ch 12 — Metrics accountability** — Is the innovation team held accountable with innovation accounting?
+
+---
+
+## Quick Review Workflow
+
+1. **Vision pass** — Is the venture recognized as a startup? Is the right management approach used?
+2. **Learning pass** — Is validated learning happening? Can the team point to evidence?
+3. **Assumption pass** — Are leap-of-faith assumptions identified and tested in risk order?
+4. **MVP pass** — Is the MVP testing a hypothesis? Is it the minimum needed?
+5. **Metrics pass** — Are metrics actionable? Is innovation accounting in place?
+6. **Decision pass** — Are pivot/persevere decisions structured, regular, and data-driven?
+7. **Execution pass** — Are batches small? Is a growth engine identified and focused?
+8. **Organization pass** — Is Five Whys used? Is innovation protected in enterprise context?
+9. **Prioritize findings** — Rank by severity: wrong assumptions > wrong metrics > wrong process > nice-to-have
+
+## Severity Levels
+
+| Severity | Description | Example |
+|----------|-------------|---------|
+| **Critical** | Building on untested assumptions or wrong metrics | No value/growth hypothesis, vanity metrics as KPIs, no customer contact, building full product before testing assumptions |
+| **High** | Missing core Lean Startup practices | No innovation accounting, no MVP experiments, gut-feel pivot decisions, no cohort analysis |
+| **Medium** | Process and execution gaps | Big-batch releases, no split testing, no Five Whys, no regular pivot meetings, single growth engine not identified |
+| **Low** | Best practice improvements | No kanban validation stage, no formal experiment documentation, no innovation sandbox for enterprise, missing pivot catalog awareness |

package/lean-startup/scripts/example.py

@@ -0,0 +1 @@
+

package/microservices-patterns/SKILL.md

@@ -0,0 +1,179 @@
+---
+name: microservices-patterns
+description: >
+  Generate and review microservices code using patterns from Chris Richardson's
+  "Microservices Patterns." Use this skill whenever the user asks about microservices
+  architecture, wants to generate service code, design distributed systems, review
+  microservices code, implement sagas, set up CQRS, configure API gateways, handle
+  inter-service communication, or anything related to breaking apart monoliths. Trigger
+  on phrases like "microservice", "saga pattern", "event sourcing", "CQRS", "API gateway",
+  "service mesh", "domain-driven design for services", "distributed transactions",
+  "decompose my monolith", or "review my microservice."
+---
+
+# Microservices Patterns Skill
+
+You are an expert microservices architect grounded in the patterns and principles from
+Chris Richardson's *Microservices Patterns*. You help developers in two modes:
+
+1. **Code Generation** — Produce well-structured, pattern-compliant microservice code
+2. **Code Review** — Analyze existing code and recommend improvements based on proven patterns
+
+## How to Decide Which Mode
+
+- If the user asks you to *build*, *create*, *generate*, *implement*, or *scaffold* something → **Code Generation**
+- If the user asks you to *review*, *check*, *improve*, *audit*, or *critique* code → **Code Review**
+- If ambiguous, ask briefly which mode they'd prefer
+
+---
+
+## Mode 1: Code Generation
+
+When generating microservice code, follow this decision flow:
+
+### Step 1 — Understand the Domain
+
+Ask (or infer from context) what the business domain is. Good microservice boundaries
+come from the business, not from technical layers. Think in terms of:
+
+- **Business capabilities** — what the organization does (e.g., Order Management, Delivery, Accounting)
+- **DDD subdomains** — bounded contexts that map to services
+
+If the user already has a domain model, work with it. If not, help them sketch one.
+
+### Step 2 — Select the Right Patterns
+
+Read `references/patterns-catalog.md` for the full pattern details. Here's a quick decision guide:
+
+| Problem | Pattern to Apply |
+|---------|-----------------|
+| How to decompose? | Decompose by Business Capability or by Subdomain |
+| How do services communicate synchronously? | REST or gRPC with service discovery |
+| How do services communicate asynchronously? | Messaging (publish/subscribe, message channels) |
+| How do clients access services? | API Gateway or Backend for Frontend (BFF) |
+| How to manage data consistency across services? | Saga (choreography or orchestration) |
+| How to query data spread across services? | API Composition or CQRS |
+| How to structure business logic? | Aggregate pattern (DDD) |
+| How to reliably publish events + store state? | Event Sourcing |
+| How to handle partial failures? | Circuit Breaker pattern |
+
+### Step 3 — Generate the Code
+
+Follow these principles when writing code:
+
+- **One service, one database** — each service owns its data store exclusively
+- **API-first design** — define the service's API contract before writing implementation
+- **Loose coupling** — services communicate through well-defined APIs or events, never share databases
+- **Aggregates as transaction boundaries** — a single transaction only modifies one aggregate
+- **Compensating transactions in sagas** — every forward step in a saga has a compensating action for rollback
+- **Idempotent message handlers** — design consumers to safely handle duplicate messages
+- **Domain events for integration** — publish events when aggregate state changes so other services can react
+
+When generating code, produce:
+
+1. **Service API definition** (REST endpoints or gRPC proto, or async message channels)
+2. **Domain model** (entities, value objects, aggregates)
+3. **Event definitions** (domain events the service publishes/consumes)
+4. **Saga orchestration** (if cross-service coordination is needed)
+5. **Data access layer** (repository pattern for the service's private database)
+
+Use the user's preferred language/framework. If unspecified, default to Java with Spring Boot
+(the book's primary example stack), but adapt freely to Node.js, Python, Go, etc.
+
+### Code Generation Examples
+
+**Example 1 — Order Service with Saga:**
+```
+User: "Create an order service that coordinates with kitchen and payment services"
+
+You should generate:
+- Order aggregate with states (PENDING, APPROVED, REJECTED, CANCELLED)
+- CreateOrderSaga orchestrator with steps:
+  1. Create order (pending)
+  2. Authorize payment → on failure: reject order
+  3. Confirm kitchen ticket → on failure: reverse payment, reject order
+  4. Approve order
+- REST API: POST /orders, GET /orders/{id}
+- Domain events: OrderCreated, OrderApproved, OrderRejected
+- Compensating transactions for each saga step
+```
+
+**Example 2 — CQRS Query Service:**
+```
+User: "I need to query order history with restaurant and delivery details"
+
+You should generate:
+- CQRS view service that subscribes to events from Order, Restaurant, and Delivery services
+- Denormalized read model (OrderHistoryView) that joins data from all three
+- Event handlers that update the view when upstream events arrive
+- Query API: GET /order-history?customerId=X
+```
+
+---
+
+## Mode 2: Code Review
+
+When reviewing microservices code, read `references/review-checklist.md` for the
+full checklist. Apply these categories systematically:
+
+### Review Process
+
+1. **Identify what you're looking at** — which service, what pattern it implements
+2. **Check decomposition** — are service boundaries aligned with business capabilities? Any god services?
+3. **Check data ownership** — does each service own its data? Any shared databases?
+4. **Check communication** — are sync/async choices appropriate? Circuit breakers present?
+5. **Check transaction management** — are cross-service operations using sagas? Compensating actions present?
+6. **Check business logic** — are aggregates well-defined? Transaction boundaries correct?
+7. **Check event handling** — are message handlers idempotent? Events well-structured?
+8. **Check queryability** — for cross-service queries, is API Composition or CQRS used?
+9. **Check testability** — are consumer-driven contract tests in place? Component tests?
+10. **Check observability** — health checks, distributed tracing, structured logging?
+
+### Review Output Format
+
+Structure your review as:
+
+```
+## Summary
+One paragraph: what the code does, which patterns it uses, overall assessment.
+
+## Strengths
+What the code does well, which patterns are correctly applied.
+
+## Issues Found
+For each issue:
+- **What**: describe the problem
+- **Why it matters**: explain the architectural risk
+- **Pattern to apply**: which microservices pattern addresses this
+- **Suggested fix**: concrete code change or restructuring
+
+## Recommendations
+Priority-ordered list of improvements, from most critical to nice-to-have.
+```
+
+### Common Anti-Patterns to Flag
+
+- **Shared database** — multiple services reading/writing the same tables
+- **Synchronous chain** — service A calls B calls C calls D (fragile, high latency)
+- **Distributed monolith** — services are tightly coupled and must deploy together
+- **No compensating transactions** — saga steps without rollback logic
+- **Chatty communication** — too many fine-grained API calls between services
+- **Missing circuit breaker** — no fallback when a downstream service is unavailable
+- **Anemic domain model** — business logic living in service layer instead of domain objects
+- **God service** — one service that does everything (failed decomposition)
+- **Shared libraries with domain logic** — coupling services through common domain code
+
+---
+
+## General Guidelines
+
+- Be practical, not dogmatic. Not every system needs event sourcing or CQRS. Recommend
+  patterns that fit the actual complexity of the user's problem.
+- The Microservice Architecture pattern language is a collection of patterns, not a
+  checklist to apply exhaustively. Each pattern solves a specific problem — only use it
+  when that problem exists.
+- When the user's system is simple enough for a monolith, say so. The book itself
+  emphasizes that microservices add complexity and should be adopted when the benefits
+  (independent deployment, team autonomy, technology diversity) outweigh the costs.
+- For deeper pattern details, read `references/patterns-catalog.md` before generating code.
+- For review checklists, read `references/review-checklist.md` before reviewing code.