improve-business skill
Guided journey from a stalled, plateaued business to one with an honest diagnosis, a working operating rhythm, and offers repriced to real value. Orchestrates eight skills phase by phase - good-strategy-bad-strategy, traction-eos, high-output-management, team-topologies, drive-motivation, lean-analytics, negotiation, monetizing-innovation - asking the user questions at every decision point and recording results in the project docs/ folder (STRATEGY.md, OPERATIONS.md, METRICS.md, IMPROVE-BUSINESS-PLAN.md) so the journey resumes across sessions. Use when the user wants to fix a business that has plateaued, diagnose why growth stalled, tighten strategy and execution, re-motivate a team, or says ''revenue is flat and I do not know why''. Starting from scratch with no customers: use create-business. Once the fundamentals work and the goal is expansion: use grow-business. When the product itself drags the business down: use improve-app. For one framework in isolation, invoke that skill directly.
Is the improve-business skill safe?
Clean: nothing in its files matched our rules. We read 2 files in the folder on 2026-09-28.
No findings.
Install the improve-business skill
A skill is a folder. Copy it into your agent's skills folder and the agent loads it when the task matches its description.
git clone --depth 1 https://github.com/wondelai/skills.git /tmp/skills mkdir -p ~/.claude/skills cp -r /tmp/skills/improve-business ~/.claude/skills/improve-business
In the Claude apps, zip the folder and upload it from the Skills settings. The folder on GitHub
The instructions your agent would load
SKILL.md as published, without the frontmatter. Read it on GitHub
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
Operating Rules
- Resume first. Before anything else, read docs/IMPROVE-BUSINESS-PLAN.md and every artifact in the Journey Map. If the tracker exists, summarize the journey state in 3-5 lines and ask which phase to enter. Done when the user has confirmed an entry point. A journey with a tracker is resumed, never restarted.
- Intake on first run only. No tracker: run the Intake below, then create docs/IMPROVE-BUSINESS-PLAN.md with every phase statused pending | in-progress | awaiting-evidence | done | deferred: reason | skipped: reason. Done when the tracker exists and the user has confirmed the phase plan.
- Phase entry. Announce: what the phase does, the decision it forces, the artifact it produces, rough effort. Offer proceed / skip / defer — phases marked GATE may be deferred, never skipped. Mark the phase in-progress on proceed. Done when the user chose.
- Skill invocation and fallback. Load the phase's skill and use it: each phase's Invoke line names the skill by slug — use that skill to run the phase. If it is not available, offer: npx skills add wondelai/skills/ --global. If the user declines, run the phase from its Brief — the minimum viable method. State which mode you are in.
- In-phase decisions. Ask every question under "Decide with the user" — with concrete options and your recommendation. Record the choice in the tracker's Key Decisions. A decision made silently is a defect.
- Phase exit. Present the draft artifact content for sign-off before writing. On approval: write or extend the docs/ files, update the tracker (status, Key Decisions, Next Actions). Done when the files are written and the phase row shows done.
- Artifact discipline. Read before writing; create a file only if missing, otherwise extend — add or update your sections, preserve everyone else's. Files are UPPERCASE in docs/. Every recommendation lands as a checkbox or a table row with owner and priority. See references/artifact-templates.md when creating a docs/ file for the first time — create it from the full skeleton (all section headings), then fill the sections your phase names.
- Diagnosis before treatment. No new initiative, reorg, or pricing change starts before docs/STRATEGY.md holds a written Diagnosis the user has confirmed. When asked to jump straight to Phase 4, 7, or 8, complete Phase 1 first (or confirm it is already done and recorded). Done when a confirmed Diagnosis exists before any treatment phase writes its artifact.
Intake
Ask these before creating the tracker:
- What is the plateau — flat revenue, rising churn, a team working hard with nothing moving? (Frames the Phase 1 diagnosis and the Phase 6 OMTM.)
- What passes for your current strategy today — a deck, OKRs, a goal list, nothing written? (Feeds Phase 1; if none exists the diagnosis work is larger.)
- How big is the team and how is it structured? (Sizes the Rocks and 1:1 system in Phases 2-3; gates Phase 4.)
- Do you run technology teams, or is this a services / brick-and-mortar business? (team-topologies is engineering-specific — skip Phase 4 for non-tech orgs.)
- When was pricing last set, and on what basis — cost-plus, competitor, or value? (Gates Phase 8; cost/competitor pricing signals margin left on the table.)
- What is your sales win rate, and do you hear price objections? (Near-100% win rate with no pushback signals minivation — Phase 8.)
- Where does work get stuck — within teams or between them? (Between-team stalls point at Phase 4; within-team points at Phases 3 and 5.)
Phase-skip heuristics: skip Phase 4 when you don't run technology teams or teams already deliver cleanly; skip Phase 5 when morale is engaged and not the constraint; skip Phase 7 when no large renewals or vendor contracts are in play; skip Phase 8 only if pricing was recently repriced from validated willingness to pay.
Then create docs/IMPROVE-BUSINESS-PLAN.md from the template and confirm the phase plan. Done when docs/IMPROVE-BUSINESS-PLAN.md exists with every phase statused and the user has confirmed the plan.
Phases
Phase 1 — Diagnose the real challenge (good-strategy-bad-strategy) — GATE
Purpose: Name the single critical challenge capping the business, so every later layer works the right constraint. Phases 2-8 may not start before this Diagnosis is confirmed.
Brief (fallback): Good strategy has a kernel — an honest diagnosis of the critical challenge, a guiding policy, and coherent actions. Bad strategy is fluff, goals dressed as strategy, and forty "priorities" that concentrate nothing. Treat the funnel as a chain-link system and find the one binding link; investing in strong links is wasted until the weak one is fixed. Set a proximate objective close enough that the team can see how to hit it, and force a no-list.
Invoke: Use the good-strategy-bad-strategy skill with the current annual plan, OKRs, or deck pasted in. Ask it to (a) audit the plan as strategy and score it 0-10, (b) write a proper kernel, (c) name the binding chain-link constraint and one proximate objective for the quarter.
Decide with the user: Does the diagnosis name the real obstacle, not a symptom? Which single link (lead-gen / activation / retention / expansion) is the binding constraint, and what is the proximate objective? What goes on the no-list — what will you deliberately stop doing?
Artifact: Create docs/STRATEGY.md with ## Diagnosis (critical challenge + binding constraint), ## Guiding Policy (including the proximate objective), ## Coherent Actions (Action | Owner | Due | Status), and ## No-List. Update the tracker.
Done when: STRATEGY.md holds a confirmed Diagnosis, a Guiding Policy, 3-5 Coherent Actions with owners, and a No-List — only then are Phases 2-8 unlocked.
Phase 2 — Install an execution rhythm (traction-eos)
Purpose: Convert the strategy into a weekly operating rhythm that survives Monday.
Brief (fallback): Vision without traction is hallucination. Set 3-7 quarterly Rocks — each with one owner, SMART, binary (done or not, no partial credit) — aimed at the proximate objective. Install the Level 10 Meeting: same day and time, 90 minutes, fixed agenda ending in 60 minutes of IDS (Identify, Discuss, Solve) driven to root cause. Never cancel it.
Invoke: Use the traction-eos skill with STRATEGY.md's guiding policy and proximate objective. Ask for (a) 5-7 quarterly Rocks with owners and binary criteria, flagging any that are business-as-usual, (b) a Level 10 agenda with time boxes, (c) an IDS pass on the top recurring issue.
Decide with the user: Which 5-7 Rocks make the quarter (cap at seven)? Who owns each? What weekly cadence for the Level 10, and who facilitates?
Artifact: Create docs/OPERATIONS.md with ## Vision/Traction Summary, ## Rocks (this quarter) (Rock | Owner | Binary done-condition | Status), and ## Meeting Cadence (Meeting | Rhythm | Agenda). Update the tracker.
Done when: OPERATIONS.md holds 5-7 owned binary Rocks tied to the proximate objective and a scheduled Level 10 cadence the user has committed to.
Phase 3 — Manage for output, not activity (high-output-management)
Purpose: Multiply the team's output by getting the operator off the critical path.
Brief (fallback): A manager's output equals the output of their organization plus the neighboring teams they influence. Negative-leverage habits — meddling, waffling, being the approval bottleneck — multiply downward. High-leverage tools: subordinate-owned 1:1s at a cadence set by task-relevant maturity (TRM), and delegation-with-monitoring — delegate what you know best, monitor at task level, sample deeper when TRM is low, lighter as it rises.
Invoke: Use the high-output-management skill with the operator's last two weeks of calendar and the tasks they keep grabbing back. Ask for a leverage audit, a redesigned week built around forecasted key events, and a 1:1 plus delegation system for direct reports.
Decide with the user: Which negative-leverage habits to cut? The 1:1 cadence per report (set by TRM, not seniority)? Which tasks to delegate-with-monitoring off the critical path?
Artifact: Extend docs/OPERATIONS.md: add ## Management Leverage (1:1 cadence per report, delegation decisions, monitoring depth). Update the tracker.
Done when: OPERATIONS.md records a 1:1 cadence for every direct report and at least one delegation decision that removes the operator as a bottleneck.
Phase 4 — Reshape teams around value streams (team-topologies)
Purpose: Remove structural friction when work keeps getting stuck between teams rather than within them.
Brief (fallback): Conway's law — you ship your communication structure. Reduce every team to one of four types: stream-aligned (the default), enabling, complicated-subsystem, platform. Cap cognitive load: at most one complicated domain per team; never split a single domain across two teams. Shed domains or remove extraneous load before adding headcount. Define each interaction mode: collaboration, X-as-a-service, or facilitating.
Invoke: Use the team-topologies skill with each current team and what it does day to day. Ask it to classify teams, flag anti-patterns (shared-services ticket queue, teams split by function not value stream), diagnose cognitive load, and propose value-stream-aligned boundaries with explicit interaction modes.
Decide with the user: First — is the plateau structural (handoffs dominate lead time, recurring coordination meetings, everyone's-and-no-one's ownership)? If not, skip. If yes: which domains to shed, which extraneous load to platform-ize.
Artifact: Extend docs/OPERATIONS.md: add ## Team Structure (team topology, per-team type, cognitive-load notes, interaction modes). Update the tracker.
Done when: either the phase is skipped with a recorded reason, or OPERATIONS.md holds a four-type classification and a proposed value-stream structure with interaction modes.
Phase 5 — Re-motivate the people who checked out (drive-motivation)
Purpose: Rebuild intrinsic motivation instead of throwing money at disengagement.
Brief (fallback): For any task needing cognitive effort, if-then rewards degrade performance — they crowd out intrinsic motivation, narrow focus, foster short-term thinking. What sustains it is Autonomy (task, time, technique, team), Mastery (visible progress at a challenge between boredom and anxiety), and Purpose (serving something larger than the quarter). Pay enough to take money off the table, then stop using it as the lever; replace if-then bonuses with now-that recognition.
Invoke: Use the drive-motivation skill with how incentives, reviews, and goals currently run. Ask for an AMP audit scored 0-10, the places controlling if-then rewards crowd out motivation, and specific autonomy / mastery / purpose fixes including a shift to now-that recognition.
Decide with the user: Which if-then rewards to retire? Which autonomy levers (the four T's) to grant? How to convert recognition from if-then to now-that?
Artifact: Extend docs/OPERATIONS.md: add ## Motivation (Autonomy / Mastery / Purpose) (Lever | Finding | Fix). Update the tracker.
Done when: OPERATIONS.md holds an AMP audit with at least one concrete fix per pillar, and the decision on if-then versus now-that rewards is recorded.
Phase 6 — Measure the one number that tells the truth (lean-analytics)
Purpose: Replace a dashboard of vanity metrics with one honest number tied to the riskiest assumption.
Brief (fallback): Good metrics are comparative, understandable, ratios or rates (not ever-growing totals), and behavior-changing — if a number won't change what you do next, stop watching it. The cumulative up-and-to-the-right chart is the top vanity tell. Pick one OMTM for the riskiest part of the business right now, guard it with a counter-metric so it can't be gamed, and draw a line in the sand: a target, a date, and a pre-committed miss response decided before results arrive.
Invoke: Use the lean-analytics skill with the current dashboard and the business model and stage. Ask it to purge vanity metrics into actionable ratios, name the OMTM plus counter-metric, and build cohort retention tables to test the stickiness gate.
Decide with the user: What business model and stage are we in? Which single OMTM and counter-metric? The line in the sand — target, date, and pre-committed action if we miss?
Artifact: Create docs/METRICS.md with ## Stage & One Metric That Matters, ## KPI Definitions (Metric | Definition | Actionable ratio? | Owner), ## Baselines & Targets (including the line in the sand), ## Funnel, and ## Cohort Notes. Update the tracker.
Done when: METRICS.md names one OMTM with a counter-metric and a line in the sand, and the vanity metrics are rewritten as actionable ratios.
Phase 7 — Stop leaking margin in negotiations (negotiation)
Purpose: Protect price in renewals and vendor contracts, and capture what customers truly value.
Brief (fallback): The path to a good deal runs through making the other side feel understood; no deal beats a bad deal. Tools: the accusation audit (preemptively voice their objections), calibrated questions ("how am I supposed to do that?"), labeling ("it sounds like…"), and the Ackerman plan (decreasing increments ending on a precise non-round number plus a non-monetary sweetener). Hunt the Black Swans — secret constraints, hidden motivations, unknown context — behind any competing bid; it is rarely the real story.
Invoke: Use the negotiation skill with the specific renewal or vendor contract (numbers, the threat, your instinct). Ask for an accusation audit, five calibrated questions to surface the Black Swan, and an Ackerman plan with a non-monetary concession — never concede without getting something back.
Decide with the user: For each big negotiation: the target and walk-away, the concessions you will trade (never for free), and the real driver (Black Swan) behind the price threat.
More skills from wondelai/skills
- A37signals-wayBuild lean, opinionated products using the 37signals philosophy from "Getting Real", "Rework", and "Shape Up". Use when the user mentions "Getting Real", "Rework", "Shape Up", "37signals", "Basecamp method", "six-week cycles", "fixed time variable scope", "appetite vs estimates", "betting table", "breadboarding", "fat marker sketch", "build less", "underdo the competition", "opinionated software", "we have too many meetings", "how do we ship faster", or "stop overbuilding". Also trigger when cutting scope to ship sooner, running a small team, or avoiding long-term roadmaps. Covers shaping, betting, building, and the art of saying no. For MVP validation, see lean-startup. For design sprints, see design-sprint.
- A37signals-wayBuild lean, opinionated products using the 37signals philosophy from "Getting Real", "Rework", and "Shape Up". Use when the user mentions "Getting Real", "Rework", "Shape Up", "37signals", "Basecamp method", "six-week cycles", "fixed time variable scope", "appetite vs estimates", "betting table", "breadboarding", "fat marker sketch", "build less", "underdo the competition", "opinionated software", "we have too many meetings", "how do we ship faster", or "stop overbuilding". Also trigger when cutting scope to ship sooner, running a small team, or avoiding long-term roadmaps. Covers shaping, betting, building, and the art of saying no. For MVP validation, see lean-startup. For design sprints, see design-sprint.
- A37signals-wayBuild lean, opinionated products using the 37signals philosophy from "Getting Real", "Rework", and "Shape Up". Use when the user mentions "Getting Real", "Rework", "Shape Up", "37signals", "Basecamp method", "six-week cycles", "fixed time variable scope", "appetite vs estimates", "betting table", "breadboarding", "fat marker sketch", "build less", "underdo the competition", "opinionated software", "we have too many meetings", "how do we ship faster", or "stop overbuilding". Also trigger when cutting scope to ship sooner, running a small team, or avoiding long-term roadmaps. Covers shaping, betting, building, and the art of saying no. For MVP validation, see lean-startup. For design sprints, see design-sprint.
- Aarchitecture-optimizationGuided journey from a working codebase grown slow and tangled to one measurably fast, cleanly bounded, and readable. Orchestrates eight skills phase by phase - working-with-legacy-code, clean-architecture, software-design-philosophy, refactoring-patterns, system-design, ddia-systems, release-it, pragmatic-programmer - every phase carries its method inline so it runs standalone, asking the user questions at every decision point and recording results in the project docs/ folder (PERFORMANCE.md, ARCHITECTURE.md, ARCHITECTURE-OPTIMIZATION-PLAN.md) so the journey resumes across sessions. Use when the user wants to make an app faster, untangle drifted boundaries, fix slow endpoints and queries, or says ''it works but it is slow and getting worse''. For an untested prototype, improve-code-quality; for an aged codebase you fear to touch, remove-technical-debt; for greenfield structure, design-code-architecture; for marketing-site page speed, improve-website. For one framework in isolation, invoke that skill directly.
- Aarchitecture-optimizationGuided journey from a working codebase grown slow and tangled to one measurably fast, cleanly bounded, and readable. Orchestrates eight skills phase by phase - working-with-legacy-code, clean-architecture, software-design-philosophy, refactoring-patterns, system-design, ddia-systems, release-it, pragmatic-programmer - every phase carries its method inline so it runs standalone, asking the user questions at every decision point and recording results in the project docs/ folder (PERFORMANCE.md, ARCHITECTURE.md, ARCHITECTURE-OPTIMIZATION-PLAN.md) so the journey resumes across sessions. Use when the user wants to make an app faster, untangle drifted boundaries, fix slow endpoints and queries, or says ''it works but it is slow and getting worse''. For an untested prototype, improve-code-quality; for an aged codebase you fear to touch, remove-technical-debt; for greenfield structure, design-code-architecture; for marketing-site page speed, improve-website. For one framework in isolation, invoke that skill directly.
- Aarchitecture-optimizationGuided journey from a working codebase grown slow and tangled to one measurably fast, cleanly bounded, and readable. Orchestrates eight skills phase by phase - working-with-legacy-code, clean-architecture, software-design-philosophy, refactoring-patterns, system-design, ddia-systems, release-it, pragmatic-programmer - every phase carries its method inline so it runs standalone, asking the user questions at every decision point and recording results in the project docs/ folder (PERFORMANCE.md, ARCHITECTURE.md, ARCHITECTURE-OPTIMIZATION-PLAN.md) so the journey resumes across sessions. Use when the user wants to make an app faster, untangle drifted boundaries, fix slow endpoints and queries, or says ''it works but it is slow and getting worse''. For an untested prototype, improve-code-quality; for an aged codebase you fear to touch, remove-technical-debt; for greenfield structure, design-code-architecture; for marketing-site page speed, improve-website. For one framework in isolation, invoke that skill directly.
- Ablue-ocean-strategyCreate uncontested market space using value innovation instead of competing head-to-head. Use when the user mentions "blue ocean", "red ocean", "strategy canvas", "ERRC framework", "value innovation", "non-customers", "buyer utility map", "the market is too crowded", "how do we stand out", or "escape the price war". Also trigger when exploring a new market category, or finding underserved or non-customers. Covers the Four Actions Framework, Six Paths, buyer utility map, and value-cost trade-offs. For real strategy formulation and bad-strategy detection, see good-strategy-bad-strategy. For tech adoption strategy, see crossing-the-chasm. For product positioning, see obviously-awesome.
- Ablue-ocean-strategyCreate uncontested market space using value innovation instead of competing head-to-head. Use when the user mentions "blue ocean", "red ocean", "strategy canvas", "ERRC framework", "value innovation", "non-customers", "buyer utility map", "the market is too crowded", "how do we stand out", or "escape the price war". Also trigger when exploring a new market category, or finding underserved or non-customers. Covers the Four Actions Framework, Six Paths, buyer utility map, and value-cost trade-offs. For real strategy formulation and bad-strategy detection, see good-strategy-bad-strategy. For tech adoption strategy, see crossing-the-chasm. For product positioning, see obviously-awesome.
- Ablue-ocean-strategyCreate uncontested market space using value innovation instead of competing head-to-head. Use when the user mentions "blue ocean", "red ocean", "strategy canvas", "ERRC framework", "value innovation", "non-customers", "buyer utility map", "the market is too crowded", "how do we stand out", or "escape the price war". Also trigger when exploring a new market category, or finding underserved or non-customers. Covers the Four Actions Framework, Six Paths, buyer utility map, and value-cost trade-offs. For real strategy formulation and bad-strategy detection, see good-strategy-bad-strategy. For tech adoption strategy, see crossing-the-chasm. For product positioning, see obviously-awesome.
- Aclean-architectureStructure software around the Dependency Rule: source code dependencies point inward from frameworks to use cases to entities. Use when the user mentions "architecture layers", "dependency rule", "ports and adapters (hexagonal)", "onion architecture", "screaming architecture", "where should business logic go", "decouple from the database", "swap the framework without a rewrite", or "keep business rules independent". Also trigger when deciding which layer code belongs in, isolating core logic from infrastructure, defining module boundaries, or debating whether the framework should call your code or the reverse. Covers component principles, boundaries, and SOLID. For code-level quality, see clean-code. For domain modeling, see domain-driven-design.
- Aclean-architectureStructure software around the Dependency Rule: source code dependencies point inward from frameworks to use cases to entities. Use when the user mentions "architecture layers", "dependency rule", "ports and adapters (hexagonal)", "onion architecture", "screaming architecture", "where should business logic go", "decouple from the database", "swap the framework without a rewrite", or "keep business rules independent". Also trigger when deciding which layer code belongs in, isolating core logic from infrastructure, defining module boundaries, or debating whether the framework should call your code or the reverse. Covers component principles, boundaries, and SOLID. For code-level quality, see clean-code. For domain modeling, see domain-driven-design.
- Aclean-architectureStructure software around the Dependency Rule: source code dependencies point inward from frameworks to use cases to entities. Use when the user mentions "architecture layers", "dependency rule", "ports and adapters (hexagonal)", "onion architecture", "screaming architecture", "where should business logic go", "decouple from the database", "swap the framework without a rewrite", or "keep business rules independent". Also trigger when deciding which layer code belongs in, isolating core logic from infrastructure, defining module boundaries, or debating whether the framework should call your code or the reverse. Covers component principles, boundaries, and SOLID. For code-level quality, see clean-code. For domain modeling, see domain-driven-design.