Mmcp.market

drive-motivation skill

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

Design motivation systems using Autonomy, Mastery, and Purpose (AMP) for products and teams. Use when the user mentions "intrinsic motivation", "gamification isnt working", "rewards arent working", "autonomy", "mastery", "purpose-driven", "my team is disengaged", or "how do I motivate people". Also trigger when designing onboarding progression, fixing broken gamification, or building team structures that sustain high performance. Covers why carrot-and-stick fails and how to build progress systems. For habit-forming product loops, see hooked-ux. For retention behavior design, see improve-retention.

A100/100content scan

Is the drive-motivation skill safe?

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

No findings.

Install the drive-motivation 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/team-motivation/skills/drive-motivation ~/.claude/skills/drive-motivation
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

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: 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.
  • ≤3 — relies on rewards, mandates, or controlling behaviors; intrinsic motivation absent.

Always state the current score, which diagnostic rows failed, and the specific fixes to reach 10/10.

Motivation 1.0, 2.0, and 3.0

The Seven Deadly Flaws of Extrinsic Rewards

"If-then" rewards ("If you do X, then you get Y"):

The boundary: extrinsic rewards work only for routine, algorithmic tasks with no intrinsic interest. For creative work, complex problem-solving, or long-term engagement, they backfire.

See references/extrinsic-rewards.md when a reward or incentive scheme is backfiring — the named studies behind each flaw and a decision rule for when rewards are safe to use.

The Three Pillars: Autonomy, Mastery, Purpose

1. Autonomy

Core concept: The desire to direct our own lives — choice over what, when, how, and with whom. Autonomy ≠ independence: people can act with choice while staying interdependent with a team.

The Four T's of Autonomy:

Product applications:

Autonomy violations: "You must complete X before Y", unskippable tutorials, mandatory notifications, and forced single paths through the experience.

See references/autonomy.md when designing onboarding, feeds, or workflow controls — full Four T's patterns plus the autonomy audit checklist.

2. Mastery

Core concept: The desire to get better at something that matters. Mastery is a mindset, not a destination — it's asymptotic, and the joy is in the pursuit.

Three laws of mastery:

  • Mastery is a mindset — ability is developed, not fixed (Dweck's growth mindset). Frame failures as learning, not judgment.
  • Mastery is a pain — it demands effort and deliberate practice. Flow (Csikszentmihalyi) lives between boredom and anxiety, so calibrate challenge to skill level.
  • Mastery is asymptotic — users never fully arrive. Always offer a next level, next challenge.

Flow conditions: clear goals, immediate feedback, challenge/skill balance, sense of control.

Product applications:

Mastery violations: flat difficulty that never adapts, and failure that is punished rather than framed as learning.

See references/mastery.md when designing progress, difficulty, or feedback systems — flow-state calibration, deliberate practice, and the mastery audit checklist.

3. Purpose

Core concept: The yearning to act in service of something larger than ourselves. Purpose is the context for the other two pillars — without it, autonomy is directionless and mastery hollow.

Three expressions of purpose:

Product applications:

Purpose prescriptions: show aggregate impact ("Together, our users have saved 1M hours"), connect individual actions to collective outcomes, and celebrate meaningful milestones over vanity metrics.

See references/purpose.md when wiring impact, community, or values features — Goals/Words/Policies patterns and the purpose audit checklist.

AMP Applied: Product Design

Gamification Done Right vs. Wrong

Example — Duolingo: autonomy (choose language, pace, topics), mastery (adaptive difficulty, skill levels), purpose ("learn a language to connect with people"). Caution: streaks can shift from intrinsic mastery to extrinsic loss aversion.

Team Motivation

Compensation and Incentives

Pay people enough to take money off the table — fair, ideally above-market — then focus on AMP; beyond "enough," more money doesn't increase motivation. Prefer "now-that" rewards (unexpected recognition after the fact: "You hit target! Here's a bonus.") over "if-then" rewards ("If you hit target, you get a bonus"), which create pressure and short-term thinking.

See references/applications.md when applying AMP to a concrete gamification, team-management, or compensation design — worked examples and escalation tables.

Type I vs. Type X Behavior

Design products and teams that cultivate Type I behavior: it's made, not born; it doesn't disdain money or recognition; it's renewable; and it promotes well-being.

See references/type-i.md when shifting a team or user base from Type X to Type I — the full behavioral contrast and conversion tactics. For real-world AMP programs (Atlassian ShipIt, 3M, ROWE, Duolingo, Wikipedia), see references/case-studies.md.

Common Mistakes

Quick Diagnostic

Audit any motivation system:

Further Reading

Based on Daniel Pink's research on motivation science:

  • "Drive: The Surprising Truth About What Motivates Us" by Daniel H. Pink
  • "To Sell Is Human" by Daniel H. Pink (applying motivation to sales and persuasion)

About the Author

Daniel H. Pink is the author of seven books, including four New York Times bestsellers. Drive, translated into 40+ languages, changed how organizations think about motivation, and his TED Talk on motivation science is among the most-viewed of all time. He was previously chief speechwriter for Vice President Al Gore.

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