Mmcp.market

traction-eos skill

by wondelai·wondelai/skills·2.3k stars·MIT

Implement the Entrepreneurial Operating System (EOS) to align vision and execution across a company. Use when the user mentions "EOS", "Entrepreneurial Operating System", "V/TO", "quarterly rocks", "Level 10 meetings", "accountability chart", "IDS process", "my company feels chaotic", "we keep having the same problems", or "get the whole team aligned". Also trigger when a growing company needs meeting structure, goal-setting frameworks, or a systematic way to solve recurring organizational issues. Covers the six EOS components: Vision, People, Data, Issues, Process, Traction. For team motivation design, see drive-motivation. For lean experimentation, see lean-startup.

A100/100content scan

Is the traction-eos skill safe?

Clean: nothing in its files matched our rules. We read 10 files in the folder on 2026-09-28.

No findings.

Install the traction-eos 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/plugins/strategy-growth/skills/traction-eos ~/.claude/skills/traction-eos
available in every project

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

Entrepreneurial Operating System (EOS)

A complete system for running a business with six key components. Designed for entrepreneurial companies ($2M-$50M revenue, 10-250 employees) that want to align vision and execution.

Core Principle

Most businesses suffer from the same core issues: people, vision, traction. Great vision without traction is hallucination; traction without vision is aimless. EOS connects the two through a practical weekly operating rhythm that strengthens the Six Key Components of any organization.

Scoring

Goal: 10/10. Score the business by how many of the six Quick Diagnostic rows pass (each component is either in place or not), mapped to the bands below. Bands: 9-10 = all six diagnostic rows pass and rocks consistently hit 80%+ completion; 7-8 = five rows pass, one component weak; 5-6 = three to four rows pass; 3-4 = one to two rows pass; <=2 = no operating rhythm in place. Always state the current score, the failing diagnostic rows, and the next action for each.

The Six Key Components

Vision → People → Data → Issues → Process → Traction

1. Vision Component

Question: Does everyone in the organization know where you're going and how you plan to get there?

Tool: Vision/Traction Organizer (V/TO) — answers eight questions on two pages:

Process: Leadership completes the V/TO together (2-day off-site), shares it with the entire organization, reviews quarterly, updates annually.

Key insight: If the leadership team can't agree on the V/TO, you have a bigger problem — alignment comes first.

See references/vto.md when filling in the V/TO — the eight-question template and the off-site exercise sequence.

2. People Component

Question: Do you have the right people in the right seats?

Tool: Accountability Chart — not an org chart; it defines the structure and who owns what.

Visionary ←→ Integrator
              ├── Sales/Marketing
              ├── Operations
              └── Finance
  • Visionary: Big ideas, culture, key relationships, creative problem solving
  • Integrator: Runs the business day-to-day, manages the team, executes the vision
  • Rule: One person per seat — shared accountability is no accountability

Tool: People Analyzer — evaluate every person on two dimensions:

  1. Right Person (core values fit): Rate +, +/-, or - on each core value. Must be "+" on all; one "+/-" is a conversation; any "-" means wrong person.
  2. Right Seat (GWC): Gets it (understands the role), Wants it (genuinely), Capacity (mental, physical, emotional). Must be "yes" on all three.

People decisions:

  • Right person, right seat → keep and invest in
  • Right person, wrong seat → move to the right seat
  • Wrong person, right seat → coach or exit (hardest call)
  • Wrong person, wrong seat → exit immediately

See references/people.md when building the accountability chart or running People Analyzer — templates plus GWC scoring guidance.

3. Data Component

Question: Are you managing based on objective data, or subjective opinions?

Tool: Scorecard — a weekly report card of 5-15 numbers that tell you how the business is doing. Weekly data spots problems 2-4 weeks earlier than monthly and replaces gut-feel management with accountability.

Scorecard rules:

  • Activity-based metrics (leading indicators), not results (lagging)
  • Weekly numbers — monthly is too slow to react
  • Every number has an owner and a goal
  • Red/green: on track or off track

Example:

Metric selection: If you had to go on vacation for 4 weeks, what 5-15 numbers would tell you how the business is doing?

See references/data.md when building the scorecard — templates plus how to pick leading-indicator metrics.

4. Issues Component

Question: Are you identifying, discussing, and solving issues quickly?

Tool: Issues Solving Track (IDS) — Identify → Discuss → Solve:

  1. Identify: Ask "Why?" until you reach the root cause (not the symptom); state the issue in one sentence
  2. Discuss: Everyone gets input (not equal time); stop tangents; one issue at a time, time-boxed 5-15 minutes
  3. Solve: Make the decision, assign action items (who + what + when), move on

Three types of issues:

Issues list rules: Anyone can add issues; prioritize most important first; unsolved issues carry forward — not everything gets solved each meeting.

Common IDS failures: discussing symptoms instead of root cause, rehashing the same issue weekly, ending without clear action items.

See references/issues.md when facilitating IDS — a Five Whys worked example and tangent-control tactics.

5. Process Component

Question: Have you documented and consistently followed your core processes?

Tool: Core Process Documentation — the 20/80 rule: document 20% of your processes to get 80% consistency.

Core processes to identify: HR (hiring, onboarding, reviews), sales (lead → close), operations (delivery, fulfillment), customer service (support → resolution), finance (invoicing, collections).

Documentation format: Name the process, list 5-20 major steps with just enough detail (not a 50-page manual), make it visual where possible.

Example: Sales Process "The Closer"

  1. Qualify lead (BANT: Budget, Authority, Need, Timeline)
  2. Discovery call (30 min, question guide)
  3. Demo (customized to their pain points)
  4. Proposal (within 24 hours)
  5. Follow up (3 touches in 7 days)
  6. Close or disqualify

Followed By All (FBA): Document it, train on it, measure compliance, update quarterly.

See references/process.md when documenting a core process — full templates and a worked HR/sales/ops example.

6. Traction Component

Question: Are you executing on your vision every day?

Rocks (Quarterly Priorities)

The 3-7 most important things to accomplish in the next 90 days. Ninety days is long enough to achieve something meaningful, short enough to maintain urgency.

Rock-setting process:

  1. Review the V/TO (vision, 3-year, 1-year)
  2. Brainstorm what must get done this quarter to stay on track
  3. Narrow to 3-7 company rocks, one owner each
  4. Each leadership member also sets 3-7 individual rocks
  5. Share with the organization and track weekly

SMART rocks: Specific ("Launch new pricing page", not "improve pricing"), Measurable (clear completion criteria), Achievable in 90 days, Realistic given resources, Time-bound (due end of quarter).

Rock scoring: Done = checked off (no partial credit); not done = carried forward or dropped. Target 80%+ completion. Beware rocks that are just "business as usual" — they don't move the needle.

See references/rocks.md when setting quarterly rocks — the binary done-test, the nine-row mistakes table, and a mid-quarter check-in.

Level 10 Meeting (Weekly Leadership Meeting)

The most important meeting in EOS. Every week, same day, same time, same agenda — 90 minutes, never longer.

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.

All agent skills → · MCP servers