wondelai/skills

# The 37signals Product Development Framework

A system for building profitable software without bloat, bureaucracy, or burnout, distilled from three books: *Getting Real* (build less), *Rework* (say no by default), and *Shape Up* (fix time, flex scope). Use it to shape work, bet on six-week cycles, run small autonomous teams, and ship on a predictable cadence.

## Core Principle

**Build less.** The best products do fewer things exceptionally well — simplicity is the destination, not the starting point. Traditional development adds; the 37signals way subtracts: build half a product (not a half-assed product), say no by default, fix the time and flex the scope. Constraints are what make great work possible — six weeks, three people, and a shaped pitch force you to find the essential version.

## Scoring

**Goal: 10/10.** Rate product plans, feature scopes, and team processes 0-10 against these principles. Report the current score and the specific changes needed to reach 10/10.

- **9-10:** Fixed-time cycles, shaped pitches, small teams, no backlog, opinionated defaults, clear copy
- **7-8:** Mostly shaped work and small teams, but some scope creep or process overhead

# Architecture Optimization

Optimize a working codebase on three axes at once — architecture, code quality, and performance —
without breaking what works. This is an interactive, resumable journey of eight phases: the agent asks
before every decision and records the outcome in your project's `docs/` folder, so you can stop after
any phase and pick up later. It is for a system that ships and earns but has grown slow and tangled;
the structure phases make the code safe and cheap to change, the performance phases make it measurably
fast, and the closing phases keep it that way.

## Core Principle

**Measure before optimizing, pin before restructuring — the profiler and the safety net decide, not
intuition.** Premature optimization is the root of much evil not because optimization is bad, but
because unmeasured optimization targets the wrong 97% of the code; and a restructure without pinned

# Blue Ocean Strategy Framework

Strategic framework for creating uncontested market space that makes the competition irrelevant, based on the simultaneous pursuit of differentiation and low cost.

## Core Principle

**Don't compete in bloody red oceans. Create blue oceans of uncontested market space.** Most companies fight for share in existing industries; winners create new market space where competition is irrelevant by delivering a leap in value for both buyers and themselves. Competition-based strategy is zero-sum — value innovation creates new demand and breaks the value-cost trade-off.

## Scoring

**Goal: 10/10.** Score a strategy by how many of the five Quick Diagnostic rows it satisfies, mapped to the bands below:

- **9-10** — divergent strategy-canvas curve, eliminates AND creates factors, breaks the value-cost trade-off, converts non-customers, and delivers a 10x utility leap (all 5 rows).
- **7-8** — value innovation is real but one gate is weak (e.g. strong divergence and cost cuts, but still chasing existing customers rather than non-customers).

# Clean Architecture Framework

A disciplined approach to structuring software so that business rules remain independent of frameworks, databases, and delivery mechanisms. Apply these principles when designing system architecture, reviewing module boundaries, or advising on dependency management.

## Core Principle

**Source code dependencies must point inward — toward higher-level policies.** Nothing in an inner circle can know anything about an outer circle. This single rule produces systems that are testable and independent of frameworks, UI, database, and any external agency. Business rules are what matter; databases, web frameworks, and delivery mechanisms are details — when details depend on policies, you can defer decisions, swap implementations, and test business logic in isolation.

## Scoring

**Goal: 10/10.** Score one point for each of the seven Quick Diagnostic rows the architecture satisfies (0-7), then map to a 0-10 band: 6-7 satisfied = **9-10** (Dependency Rule holds, business logic is framework- and DB-independent); 4-5 = **6-8** (core is testable but some details leak inward); 2-3 = **3-5** (framework or persistence dictates structure); 0-1 = **0-2** (no boundaries — business rules live in controllers and ORM models). Report the score, the failed diagnostic rows, and the specific inversion needed to fix each.

### 1. Dependency Rule and Concentric Circles

# Clean Code Framework

A disciplined approach to writing code that communicates intent, minimizes surprises, and welcomes change. Apply these principles when writing new code, reviewing pull requests, refactoring legacy systems, or advising on code quality.

## Core Principle

**Code is read far more often than it is written — optimize for the reader.** The read-to-write ratio is well over 10:1, so every naming choice, function boundary, and formatting decision either adds clarity or adds cost. Clean code reads like well-written prose: names reveal intent, functions tell a story one step at a time, and the Boy Scout Rule applies — always leave the code cleaner than you found it.

## Scoring

**Goal: 10/10.** Rate any code 0-10 against the principles below. Report the current score and the specific improvements needed to reach 10/10.

- **9-10:** Names reveal intent, functions are small and focused, error handling is consistent, tests are clean and comprehensive
- **7-8:** Mostly clean with minor naming ambiguities or a few long functions; tests may lack edge cases

# The Cold Start Problem

A framework for starting and scaling products that live or die by network effects — marketplaces, social apps, messaging, and collaboration tools — distilled from Andrew Chen's *The Cold Start Problem*. Use it to launch products that are worthless until other users show up, to sequence growth network by network, and to navigate the five stages: the cold start, the tipping point, escape velocity, hitting the ceiling, and the moat.

## Core Principle

**Network effects start as a liability, not an asset.** Value lives in connections between users, and on day one there are none — the same force that makes a dense network unstoppable makes an empty one useless. You don't escape by launching to a market; you escape by building one tiny, complete, self-sustaining network at a time, solving its hard side first, then tipping adjacent networks with a repeatable playbook until the market follows.

## Scoring

**Goal: 10/10.** Rate launch plans and growth strategies for networked products 0-10 against the principles below. Report the current score and the specific changes needed to reach 10/10.

- **9-10:** Named atomic network with an instrumented magic moment, hard side solved first, repeatable tipping playbook, density/liquidity metrics, explicit ceiling and moat plan
- **7-8:** Clear atomic network and hard-side focus, but tipping tactics are ad hoc or metrics still track totals over density

# Word-of-Mouth & Virality Framework

A framework for engineering word-of-mouth and making products, ideas, and content contagious, based on Jonah Berger's research into why things catch on. Use it to design shareability into products, campaigns, and content instead of hoping for luck.

## Core Principle

**Virality is not born — it is engineered.** Products spread because they were designed — consciously or not — to be shared. Only 7% of word-of-mouth happens online; the other 93% happens in offline conversations, so virality is about the psychology of sharing, not social media mechanics. Those psychological patterns are predictable and can be engineered into anything using the STEPPS framework.

See: [references/word-of-mouth.md](references/word-of-mouth.md) when the brief over-indexes on social media — it makes the offline-vs-online case, lists conversation triggers, and gives a WOM measurement/audit method.

## Scoring

**Goal: 10/10.** Score each of the six STEPPS drivers (the six Quick Diagnostic rows) — **0** absent, **1** present but weak, **2** strong and deliberate — for a raw 0-12, then map: 11-12 -> 10, 9-10 -> 8-9, 6-8 -> 6-7, 3-5 -> 4-5, 0-2 -> <=3. Bands:
- **9-10** — three or more drivers at strength 2, at least one of them Public or Social Currency (the self-propagating ones), and the brand survives the Trojan Horse test.

# Continuous Discovery Habits Framework

Framework for building a sustainable weekly practice of customer discovery that keeps product teams progressing toward desired outcomes. Discovery is not a phase before development — it is embedded in the ongoing rhythm of product work so every decision is informed by fresh evidence.

## Core Principle

**Good product discovery requires a continuous cadence, not a one-time event.** Teams that talk to customers every week, map opportunities visually, and test assumptions before building consistently outperform teams that rely on intuition, stakeholder opinions, or quarterly research cycles. The benchmark: at least one customer touchpoint per week, every week, by the product trio (product manager, designer, engineer).

## Scoring

**Goal: 10/10.** Score a discovery practice by the seven Quick Diagnostic rows below — start at 3, add 1 point per row answered "yes" (max 10). Bands: **9-10** = weekly cadence, a living Opportunity Solution Tree, systematic assumption testing, and every shipped feature traceable to a customer opportunity; **5-6** = some discovery happening but ad hoc, PM-only, or disconnected from delivery; **≤3** = intuition- and stakeholder-driven with no regular customer contact. Report the current score, the failing rows, and the specific fix for each.

## Framework

# Conversion Optimization

Turn one leaking conversion flow — a landing page, a signup, a checkout, an in-app onboarding — into a
measured, tested funnel. This is an interactive, resumable journey of seven phases: the agent asks
before every decision and records the outcome in your project's `docs/` folder, so you can stop after
any phase and pick up later. It works on websites and inside products alike; the unit of work is the
flow and its ONE action, not the whole site.

## Core Principle

**Find the leak with numbers, learn the reason from customers, fix message → offer → proof → friction
in that order, and prove every fix with a pre-committed test.** The order is causal: a number tells
you *where*, only research tells you *why*, motivation must be raised before friction-cutting pays,
and an untested fix is a guess that compounds. This skill sequences the phases, asks the decision

# Create an App

Take a raw app idea to a validated, cleanly architected first version that ships on a sustainable cadence — without over-building for scale you have not earned, or writing a prototype that calcifies into a rewrite. This journey runs ten phases: it asks before every decision and records each choice in `docs/` so you can stop and resume across sessions. The early phases often produce no code at all; once an experiment greenlights building, the engineering phases build the real thing well.

## Core Principle

**Validate fast while keeping options open: make the expensive-to-reverse decisions early and defer everything cheap.** Spend scarce early effort on the few things that compound — the riskiest assumption, the dependency boundaries, the domain language — and aggressively avoid waste everywhere else.

This skill sequences the phases, asks the questions, and records the decisions; the constituent skills carry the method. Invoke them rather than improvising their frameworks.

## Journey Map

| Phase | Skill | Question it answers | Artifact |
|---|---|---|---|

# Create a Business

Take a raw idea to a business you can defend on every axis: who it is for, what job it does, why it is different, why it wins, what it costs, and why anyone would pay. This journey runs ten phases in sequence, looping back as evidence accumulates. It is interactive — the agent asks before every decision — and resumable: all state lives in `docs/` so you can stop and restart across sessions. The order is the point: demand before building, strategy before scale, price before product.

## Core Principle

**Earn your evidence before you spend your runway: demand before building, strategy before scale, price before product.** You can be wrong about your product in a week, or wrong about your business in a year — pick the week. This skill sequences the phases, asks the questions at every decision point, and records what you decide in `docs/`. The constituent skills carry the method — invoke them rather than improvising their frameworks.

## Journey Map

| Phase | Skill | Question it answers | Artifact |
|---|---|---|---|
| 1 | jobs-to-be-done | What progress is the customer really hiring us for? | Creates docs/CUSTOMER.md |
| 2 | mom-test | Is the job real, painful, and worth paying to solve? | Extends docs/CUSTOMER.md — GATE |

# Create a Website

A blank page becomes a live, high-converting website through ten phases run in one dependency-respecting order: message, then design, then conversion, then a brutal review. This journey is interactive — the agent asks before every decision and never designs before the message is settled — and resumable, because every decision and artifact lives in the project's `docs/` folder. You drive the phases; the constituent skills carry the method.

## Core Principle

**Message before design, design before conversion — in that order; looks-fine is the floor, not the goal.** A visitor decides in five seconds whether to stay, and that decision rides on whether they instantly understand what you do and why it matters to *them* — so clarity comes first and design serves it. This skill sequences the phases, asks the questions, and records the decisions; the constituent skills carry the frameworks. Invoke them rather than improvising their method.

## Journey Map

| Phase | Skill | Question it answers | Artifact |
|---|---|---|---|
| 1 | one-page-marketing | Who is this for, and what is the site's one job? | Creates docs/MARKETING.md; extends docs/CUSTOMER.md |
| 2 | storybrand-messaging | What do we say, with the customer as hero? | Creates docs/POSITIONING.md, docs/WEBSITE.md |

# CRO Methodology

Scientific, customer-centric approach to conversion rate optimization based on the CRE Methodology(TM). Extraordinary improvements come from understanding WHY visitors don't convert, not from copying competitors or applying generic tips.

## Core Principle

**Don't guess -- discover.** Every visitor who doesn't convert has a reason. Discover those reasons through research, then systematically eliminate them with evidence and proof. This evidence-based approach consistently outperforms "best practices", intuition, competitor copying, and expert opinion.

## Scoring

**Goal: 10/10.** Score any landing page, funnel, or conversion flow against the seven Quick Diagnostic rows below: award ~1.4 points per row answered "yes" (7 rows = 9.8, capped at 10). Bands: **9-10** = single clear action, research-grounded O/CO table, value prop legible in 5 seconds, proof at every friction point, funnel mapped, path free of UX blockers; **5-6** = guessed objections, generic best-practices copy, proof buried in FAQs; **<=3** = competing CTAs, no funnel map, claims with no proof. Report the current score and the specific diagnostic rows failing.

## The CRO Frameworks

# Crossing the Chasm Framework

Strategic framework for marketing and selling disruptive technology products, particularly the transition from early adopters to mainstream customers.

## Core Principle

**There is a chasm between early adopters and the mainstream market.** Most tech companies fail not because they can't build great products, but because they can't cross from visionaries who love new technology to pragmatists who just want solutions that work. The two groups want fundamentally different things -- what wins over innovators actively repels the early majority -- so you must change your strategy, and your whole product, to cross.

If the product is modern PLG/freemium B2B SaaS, read [references/b2b-saas.md](references/b2b-saas.md) first -- it remaps every step below (the chasm, beachhead, whole product, metrics) for self-serve trials, free tiers, and the false-signal trap where 1,000 free users looks like a crossing but isn't.

## Scoring

**Goal: 10/10.** Score any tech go-to-market by the Quick Diagnostic at the end: count the rows answered "yes" and map the 7 rows onto a 0-10 scale (roughly 1.4 points per satisfied row).

# Designing Data-Intensive Applications Framework

A principled approach to building reliable, scalable, and maintainable data systems. Apply these principles when choosing databases, designing schemas, architecting distributed systems, or reasoning about consistency and fault tolerance.

## Core Principle

**Data outlives code.** Applications are rewritten and frameworks come and go, but data persists for decades -- prioritize the long-term correctness, durability, and evolvability of the data layer. Most applications are data-intensive, not compute-intensive: the hard problems are data volume, complexity, and rate of change, and explicit consistency/availability/latency trade-offs separate robust systems from fragile ones.

## Scoring

**Goal: 10/10.** Score a data architecture by the seven Quick Diagnostic rows below: award ~1.4 points per row answered "yes" with evidence (deliberate, documented trade-off), 0 where the answer is "no" or unknown.

- **9-10:** every domain choice -- data model, storage engine, replication, partitioning, isolation, derived-data, fault handling -- is deliberate, documented, and matched to actual read/write/consistency requirements; failover tested.
- **5-6:** core choices made but two or three diagnostic rows fail -- e.g. default isolation level unknown, hot-key risk unhandled, or failover untested.

# Design Code Architecture

Design the architecture for a new app: get the small number of expensive-to-reverse decisions right and stay aggressively simple everywhere else. This is an interactive, resumable journey of eight phases — the agent asks before every decision and records the outcome in your project's `docs/` folder, so you can stop after any phase and resume later. It runs from the most foundational and hardest-to-reverse (boundaries, domain) through the tunable (data, resilience) to the cross-cutting disciplines (complexity, reversibility, scope) you apply throughout. A weekend project uses three phases lightly; a funded team building toward launch wants the whole stack.

## Core Principle

**Architecture is the set of decisions that are expensive to reverse: make exactly those deliberately, and defer everything cheap.** This skill sequences the phases, asks the decision questions, and records every choice in `docs/`. The constituent skills carry the method — invoke them rather than improvising their frameworks. The whole strategy is to convert expensive decisions into cheap ones by putting a boundary in front of them, so the irreducibly expensive set stays small enough to get right with care.

## Journey Map

| Phase | Skill | Question it answers | Artifact |
|---|---|---|---|
| 1 | clean-architecture | Do source-code dependencies point inward — is the core testable with no DB, web, or framework? | Creates docs/ARCHITECTURE.md |
| 2 | domain-driven-design | Where does the business actually split, and what does each term mean? | Extends docs/ARCHITECTURE.md |

# Design of Everyday Things Framework

Foundational design principles for creating products that are intuitive, discoverable, and understandable. The "bible of UX" — applicable to physical products, software, and any human-designed system.

## Core Principle

**Good design is actually a lot harder to notice than poor design, in part because good designs fit our needs so well that the design is invisible.** When something fails, users blame themselves — but the fault is almost always in the design. Great design bridges the gap between what people want to do and what the product allows: it is discoverable (you can figure out what to do) and understandable (you can figure out what happened).

## Scoring

**Goal: 10/10.** Score 2 points per satisfied row of the Quick Diagnostic (5 rows = discoverability, evaluation, error recovery, mapping, constraints). Bands: **9-10** = users act without instructions, understand every outcome, and recover from any error; **5-6** = one gulf or error path is broken; **<=3** = users must consult a manual or routinely blame themselves. Report the current score and the diagnostic rows failing it.

## The Two Gulfs

# Design Sprint Framework

A five-day process for answering critical business questions through design, prototyping, and testing ideas with customers. Developed at Google Ventures and used by Google, Slack, Airbnb, and hundreds of startups.

## Core Principle

**Compress months of debate, design, and testing into one week — and test with real users before writing any production code.** The sprint replaces endless discussion with a fixed Monday-to-Friday spine, hard time-boxes, and a single Decider, so a high-stakes product question gets a real answer in five days instead of five months.

## Scoring

**Goal: 10/10.** Score a sprint plan or execution by awarding 1 point for each item present and correct (10 total). Report the score and the missing items needed to reach 10/10.

1. Decider committed for the full week; one Sprint Master facilitating.
2. Monday produces a target customer and moment (not a vague "test the product").

# Domain-Driven Design Framework

Framework for tackling software complexity by modeling code around the business domain. The greatest risk in software is not technical failure -- it is building a model that does not reflect how the business actually works.

## Core Principle

**The model is the code; the code is the model.** Software should embody a deep, shared understanding of the business domain. When domain experts and developers speak the same language and that language is directly expressed in the codebase, complexity becomes manageable and the system evolves gracefully as the business changes.

## Scoring

**Goal: 10/10.** Score a domain model by awarding **1 point per satisfied row of the Quick Diagnostic** (7 rows) plus up to 3 points for depth: +1 if the Core Domain has a genuinely rich model (not just CRUD), +1 if invariants live inside aggregates rather than in services, +1 if the ubiquitous language is consistent across conversation, code, and tests. Bands: **9-10** = expert-readable names, explicit context boundaries with ACLs, small aggregates, behavior-rich entities, events for cross-aggregate flow, an identified Core Domain; **5-6** = some domain language but leaky boundaries or anemic objects; **<=3** = technical naming, one model for everything, logic scattered in services. Report the score and the specific diagnostic rows failing.

## Framework

# Drive Motivation Framework

Design motivation systems for products, teams, and organizations using the science of intrinsic motivation.

## Core Principle

**The secret to high performance isn't rewards and punishment — it's the deeply human need to direct our own lives, learn and create new things, and do better for ourselves and our world.** For any task requiring even rudimentary cognitive effort, external rewards either don't work or actively worsen performance. Intrinsic motivation — Autonomy, Mastery, Purpose (AMP) — drives lasting engagement.

## Scoring

**Goal: 10/10.** Score any motivation system (product features, team incentives, gamification, engagement loops) against the [Quick Diagnostic](#quick-diagnostic): start at 5, add 1 for each of the first five rows answered "yes," then **subtract 2 if the sixth row is also "yes"** — an "if-then" reward doing the motivating crowds out the rest. Bands:

- **9-10** — autonomy, mastery, and purpose all present; no if-then crowding-out.
- **5-6** — one pillar carries the system; the other two are weak or extrinsic.

# Good Strategy Bad Strategy

A framework for creating and auditing strategy, distilled from Richard Rumelt's *Good Strategy Bad Strategy: The Difference and Why It Matters*. Good strategy has a simple underlying logic — an honest diagnosis of the critical challenge, a guiding policy for overcoming it, and coherent actions that carry the policy out. Use this skill to detect the four hallmarks of bad strategy and to replace goal lists and vision decks with a working kernel.

## Core Principle

**Strategy is coherent action backed by an honest diagnosis — not goals, vision, or wishful thinking.** A goal ("20% growth") names an ambition; a strategy explains how the ambition will be achieved given the actual obstacles. Bad strategy is not the absence of strategy but an active substitute for it: buzzword fluff, refusal to name the challenge, and laundry lists of initiatives. The heart of strategy work is choice — concentrating effort and resources on the one or two pivotal objectives whose accomplishment unlocks everything else.

## Scoring

**Goal: 10/10.** Score strategies, plans, and strategy documents by walking the eight rows of the Quick Diagnostic and counting how many pass. Report the current score and the specific changes needed to reach 10/10. The bands below name what each tier looks like; the row count keeps the rating reproducible run to run.

- **9-10 (8 rows pass):** Complete kernel — honest diagnosis, choiceful guiding policy, coordinated resource-backed actions — aimed at a pivot point, with an explicit list of what will not be done
- **7-8 (6-7 pass):** Kernel present but one element weak: thin diagnosis, a policy that rules little out, or actions not yet coordinated and funded

# Grow an App

Your app has users who sign up and then quietly disappear — cohorts decay, daily actives are flat, the activation funnel leaks where it always has, and nothing looks obviously broken. This journey seals the bucket: it turns first-time users into activated, then habitual, then would-miss-it users across eight interactive phases. The agent asks before every decision and records the outcome in `docs/`, so the work resumes across sessions instead of restarting. Growth here is an engineering and design problem, not a bigger ad budget.

## Core Principle

**Fix the leaky bucket before pouring in acquisition: habit, activation, and retention come before any growth spend.** This skill sequences the eight phases, asks every decision question, and records each choice in `docs/`. The constituent skills carry the method — invoke them rather than improvising their frameworks.

## Journey Map

| Phase | Skill | Question it answers | Artifact |
|---|---|---|---|
| 1 | hooked-ux | Why do users come back without us paying? | Extends docs/PRODUCT.md |
| 2 | improve-retention | Why don't new users reach the loop? | Extends docs/PRODUCT.md |

# Grow a Business

You already have the hard part: a product people pay for. Revenue is real but lumpy — a good month came from a conference you happened to attend or a referral that happened to land, and none of it repeats on demand. This journey turns that traction into a repeatable growth engine across nine phases: a marketing map, an irresistible offer, an outbound motion, engineered word-of-mouth, persuasion on every surface, a mainstream go-to-market, a compounding network, one honest metric, and the discipline to hold price. It is interactive — the agent asks before every decision — and resumable, because every decision and asset is recorded in `docs/`. Install the whole stack at once with `npx skills add wondelai/skills --all --global`, or let each phase pull its skill on demand.

## Core Principle

**Build a repeatable growth engine: each phase produces an asset the next phase consumes — offer feeds pipeline, pipeline feeds word-of-mouth, metrics keep it honest.** The order is load-bearing; a skipped Phase 1 leaves the later phases with no shared target. This skill sequences the phases, asks the decision questions, and records the answers. The constituent skills carry the method — invoke them rather than improvising their frameworks.

The offer comes before every channel on purpose: sending traffic to a weak offer is the most expensive mistake in growth, so Phase 2 is fixed before outbound, virality, or repositioning turn on.

## Journey Map

| Phase | Skill | Question it answers | Artifact |
|---|---|---|---|

# Grow a Website

Take a site that already has traffic and under-monetizes it, and turn it into a research-driven growth engine: more leads captured, more buyers persuaded, a sharper offer, and visitors who bring more visitors. This journey runs eight phases — the agent asks before it decides at every fork, and all state lives in `docs/` so you can stop and resume across sessions. It sequences the work; it does not redesign the site on a hunch.

## Core Principle

**Most traffic problems are conversion problems in costume: capture and convert the visitors you have before buying more.** This skill sequences the phases, asks the decision questions, and records every choice in `docs/`. The constituent skills carry the method — invoke them rather than improvising their frameworks. Research comes before optimization, and the offer comes before the page polish, always.

## Journey Map

| Phase | Skill | Question it answers | Artifact |
|---|---|---|---|
| 1. Discover why visitors leave | cro-methodology | Why do visitors not convert, and what is worth testing? | Extends docs/WEBSITE.md, docs/METRICS.md, docs/EXPERIMENTS.md |
| 2. Capture the not-ready 97% | scorecard-marketing | How do we keep the leads who aren't ready to buy? | Extends docs/WEBSITE.md, docs/MARKETING.md |

# High Output Management

Manage teams the way Andy Grove ran Intel: a manager's output is not what the manager does — it is what their organization produces. This skill turns *High Output Management* into auditable practice: production principles for knowledge work, output indicators, managerial leverage, meetings as the medium of management, clean decisions, OKRs, and a management style matched to task-relevant maturity.

## Core Principle

**A manager's output = the output of their organization + the output of the neighboring organizations under their influence.** Nothing a manager does — emails, meetings, reviews, decisions — counts in itself; it counts only through how it raises that combined output. Since managerial time is the scarce input, the craft reduces to one question asked relentlessly: of everything I could do right now, what creates the most output per hour spent? Choose high-leverage activities; eliminate negative-leverage ones.

## Scoring

**Goal: 10/10.** Rate management practices, calendars, and processes 0-10 against the principles below. State the current score and the specific changes needed to reach 10/10.

- **9-10:** Output indicators with quality pairs, subordinate-owned 1:1s on a TRM-based cadence, delegation with task-level monitoring, OKRs that stretch without driving pay, calendar built around forecasted key events
- **7-8:** Process meetings run well, but a few activity metrics, ad hoc decision meetings, or skipped training sessions remain

# High Performance Browser Networking Framework

A systematic approach to web performance grounded in how browsers, protocols, and networks actually work. Apply these principles when building frontend applications, setting performance budgets, configuring servers, or diagnosing slow page loads.

## Core Principle

**Latency, not bandwidth, is the bottleneck.** Most web performance problems stem from too many round trips, not too little throughput. A 5x bandwidth increase yields diminishing returns; a 5x latency reduction transforms the user experience.

**The foundation:** Every request passes through DNS resolution, TCP handshake, TLS negotiation, and HTTP exchange before a single byte of content arrives — each step adding round-trip latency. High-performance applications minimize round trips, parallelize requests, and eliminate unnecessary network hops. Understanding the protocol stack is the prerequisite for meaningful optimization.

## Scoring

**Goal: 10/10.** Score by how many of the eight Quick Diagnostic rows pass, weighted toward the field metrics: **9-10** = all eight pass (the four field-metric rows in the green plus content-hashing, HTTP/2+, minimized render-blocking, and compression); **5-6** = the four field-metric rows pass but one or more transport/caching/compression rows fail; **<=3** = any field-metric row is in the red. Always report the score, which diagnostic rows failed, and the specific fix for each.

# Hook Model Framework

Framework for building habit-forming products. Habits are not created — they are built through successive cycles through the Hook.

## Core Principle

**The Hook Model** = a four-phase loop that connects the user's problem to your solution frequently enough to form a habit, moving usage from deliberate to automatic.

```
Trigger → Action → Variable Reward → Investment
    ↑                                      │
    └──────────────────────────────────────┘
```

# Grand Slam Offer Creation Framework

Framework for creating offers so good people feel stupid saying no. What you sell (the offer) matters more than how you sell it or who you sell it to.

## Core Principle

**The offer is the #1 lever in any business: a Grand Slam Offer sells despite mediocre marketing, while the best marketing in the world cannot save a bad offer.** Before optimizing funnels, running more ads, or hiring salespeople, fix the offer. A Grand Slam Offer maximizes Dream Outcome and Perceived Likelihood of Achievement while minimizing Time Delay and Effort & Sacrifice — becoming a category of one with no comparable alternative.

## Scoring

**Goal: 10/10.** Score any offer by the 7-row Quick Diagnostic at the end of this file — award ~1.4 points per row answered "yes," rounding to a 0-10 scale. Bands: **9-10** = all/nearly all rows pass (irresistible: 10x perceived value, reversed risk, ethical scarcity, named dollar-valued bonuses, a category-of-one bundle, a MAGIC name); **5-6** = value and market are right but risk, bonuses, or scarcity are missing; **<=3** = a commodity priced on cost with no guarantee or reason to act now. Always report the current score and the specific diagnostic rows that must flip to "yes" to reach 10/10.

## The Grand Slam Offer Framework

# Improve an App

The app already ships and works — users, screens, a real flow — but the experience feels rough where it
should feel effortless. Across nine phases this journey fixes what users feel, in evidence order: re-anchor
on the job, remove friction, polish the look and the moments, sharpen the words, persuade honestly, and end
with a review brutal enough to cut. It is interactive (the agent asks before deciding) and resumable (state
lives in `docs/`). Code-level causes route out to the code journeys — this pass fixes the product experience.

## Core Principle

**Fix what users feel, in evidence order: re-anchor on the job the app is hired for, remove friction before
polish, sharpen the words, persuade honestly, and end with a review brutal enough to cut.** A prettier
screen on a confusing flow loses users at the same rate — the order of the phases is the whole game.

# Improve a Business

An interactive, resumable journey for a business that already runs but has stopped moving — real revenue, real customers, a flat line. Across eight phases it works the layers in order (strategy, execution, management, structure, motivation, metrics, margin, pricing), diagnosing before treating rather than chasing one tactic at a time. The agent asks before every decision and records each choice in `docs/` so the turnaround survives across sessions.

## Core Principle

**A plateau is a diagnosis failure: diagnose before treating, and work the layers in order — strategy, execution, management, structure, motivation, metrics, margin, pricing.** Poking one tactic at a time never breaks a plateau because the constraints compound. This skill sequences the phases, asks the decision questions, and records what was decided; the constituent skills carry the actual method — invoke them rather than improvising their frameworks.

## Journey Map

| Phase | Skill | Question it answers | Artifact |
|---|---|---|---|
| 1 | good-strategy-bad-strategy | What single challenge is capping the business? | Creates docs/STRATEGY.md — GATE |
| 2 | traction-eos | How do we execute the strategy every week? | Creates docs/OPERATIONS.md |

# Improve Code Quality

Turn a working-but-untested vibe-coded prototype into a product you can ship and operate. This is an
interactive, resumable journey of nine phases: the agent asks before every decision and records the
outcome in your project's `docs/` folder, so you can stop after any phase and pick up later. A
week-old prototype is already legacy code — so the first move is a safety net, and every phase after
it is verifiable because of that net.

## Core Principle

**A week-old untested prototype is already legacy code: flip tactical to strategic — safety net
first, then readability, structure, and production hardening in order.** This skill sequences the
phases, asks the decision questions, and records every choice in `docs/`. The constituent skills
carry the method — invoke them rather than improvising their frameworks. Skipping ahead (refactoring

# Behavior Design Framework

Framework for designing products that reliably change behavior. Behavior is not about willpower or motivation — it is a design problem with a predictable equation.

## Core Principle

**The Fogg Behavior Model** = B=MAP. Behavior happens when Motivation, Ability, and a Prompt converge at the same moment.

```
            HIGH ┃
                 ┃   ★ Behavior happens
                 ┃  (above the Action Line)
                 ┃
  Motivation     ┃━━━━━━━━━━━━━━━━━━━━━━━ ← Action Line

# Improve a Website

An interactive, resumable journey that turns a live-but-underperforming website into a ranked backlog of
defensible fixes. Across eight phases it diagnoses why visitors don't convert, then fixes usability,
hierarchy, typography, message, speed, memory, and errors — asking you at each decision point and
recording results in `docs/`. Each change is tied to a reason; the big ones ship as tests.

## Core Principle

**Diagnose, fix, prove: evidence from real visitors decides what changes, and every fix ships as a
testable hypothesis.** Order is deliberate — research first, then usability, look, message, speed,
memory, and error-tolerance, because each phase's output feeds the next.

This skill sequences the phases, asks the decision questions, and records what you decide. The

# Influence Psychology Framework

Apply six decades of persuasion science — Cialdini's research into why people say "yes" — to product, copy, and sales, ethically.

## Core Principle

**People don't make decisions rationally — they use mental shortcuts (heuristics) that can be triggered to influence behavior.** These shortcuts evolved because they're usually reliable, but they can also be exploited. Understanding them lets you design products, messaging, and experiences that align with how people actually decide.

## Scoring

**Goal: 10/10.** When reviewing or creating persuasive elements (features, copy, flows, campaigns), run the Quick Diagnostic, then score against the bands below and apply the ethics gate. Always report the current score and the specific change needed to reach 10/10.

- **9-10** — Multiple principles deliberately layered; every claim truthful; users can reverse the decision; passes the transparency test (still works if the user knows the strategy); safe for vulnerable users.
- **7-8** — Principles deliberately layered and honest, but one gap (e.g. weak reversibility, or a single principle where layering was possible).

# Empowered Product Teams Framework

Framework for building products customers love through empowered teams that own continuous discovery and delivery. The best product companies don't ship features -- they solve problems, and they give teams the autonomy and accountability to figure out how.

## Core Principle

**Empowered product teams** = cross-functional groups given problems to solve (not features to build) who own discovery and delivery end-to-end.

Most product failures come not from bad engineering or design but from building things nobody wants. Feature teams receive roadmaps and execute; empowered teams receive objectives and discover solutions. The difference between a feature factory and an innovation engine is whether teams are missionaries (driven by vision and empathy) or mercenaries (driven by a handed-down backlog).

## Scoring

**Goal: 7/7.** Score product team structures, discovery practices, or delivery processes by the Quick Diagnostic below -- **1 point per satisfied row**, scored 0-7. Bands: **6-7** = empowered teams own outcomes and discovery runs continuously with engineers; **4-5** = discovery happens but inconsistently, or teams own output with partial outcome accountability; **<=3** = a feature factory: teams receive a roadmap of dated features and skip discovery. Always state the current score and the specific failed diagnostic rows to fix to reach 7/7.

# iOS Human Interface Guidelines Design Skill

Framework for designing native iOS interfaces that feel intuitive, consistent, and aligned with Apple's design philosophy. Based on Apple's Human Interface Guidelines, the definitive resource for apps that integrate seamlessly with iPhone, iPad, and the Apple ecosystem.

## Core Principle

Apple's iOS design philosophy rests on three pillars: **clarity** (every element legible and purposeful), **deference** (the interface never overshadows the content it presents), and **depth** (layering, transitions, and realistic motion convey hierarchy and spatial relationships).

**The foundation:** The best iOS apps internalize this philosophy rather than following HIG rules mechanically. Native components, system conventions, and platform consistency aren't constraints---they're the reason iOS users trust and enjoy apps that feel like they belong.

## Scoring

**Goal: 10/10.** Score 1 point per satisfied row of the Quick Diagnostic (6 rows), plus up to 4 points for native idiom: +1 semantic colors/text styles throughout (no hardcoded values), +1 system controls over custom reimplementations, +1 standard gestures and meaningful haptics, +1 SF Symbols and correct app-icon shape. Bands: **9-10** = native, accessible, adapts to Dark Mode and Dynamic Type, zero foreign patterns; **5-6** = works but leaks Android idioms or hardcodes color/size; **<=3** = fails safe areas, touch targets, or VoiceOver. Always state the score and the specific improvements needed to reach 10/10.

# Jobs to Be Done Framework

Framework for discovering innovation based on a fundamental truth: customers don't buy products -- they "hire" them to do a specific job in their lives.

## Core Principle

**Job to Be Done** = the progress a customer wants to make in specific circumstances.

Key elements of the definition:
- **Progress** (not goal, not solution) -- the customer wants to move from the current state to a better one
- **Circumstances** -- context determines the job, not customer attributes (demographics are useless)
- **Hiring/Firing** -- the customer actively chooses a product for the "job"

## Scoring

# Lean Analytics

A data discipline for startups distilled from Alistair Croll and Benjamin Yoskovitz's *Lean Analytics*: separate metrics that change decisions from numbers that merely flatter, then point the whole company at the One Metric That Matters for your business model and stage. Use it to choose metrics, audit dashboards, set targets, and plan instrumentation.

## Core Principle

**Focus on the one metric that matters right now — everything else is noise that feels like progress.** Startups die from lack of focus more often than lack of data. The discipline is knowing your business model, knowing your stage, and tracking the single number that tells you whether the riskiest part of the business is working. A metric earns attention only if it changes what you do next.

## Scoring

**Goal: 10/10.** Rate metric choices, dashboards, and instrumentation plans 0-10 against these principles. Report the current score and the specific changes needed to reach 10/10.

- **9-10:** One OMTM matched to model and stage, paired counter-metric, a line in the sand with a pre-committed miss response, cohorted and segmented data
- **7-8:** Mostly actionable ratios and a plausible OMTM, but no explicit target, weak cohorting, or too many "key" metrics