progression-systems
Difficulty curves, flow-channel targeting, power-curve math, unlock pacing, reward scheduling, XP/level formulas, and prestige/new-game-plus loops. Use when designing level-up or progression systems, tuning a difficulty ramp, deciding when to unlock content or abilities, implementing adaptive difficulty, choosing between linear/quadratic/exponential curves, or when players report 'too easy,' 'too hard,' 'grindy,' or 'plateaus too long.' For the psychology of why progression motivates see motivation-design; for stat balance between simultaneously-available items see game-balance.
What this skill does
# Progression Systems
**Purpose:** Tools for designing how players grow in power, skill, and access over time. Good progression makes every session feel rewarding. Bad progression creates grind, frustration, or trivialized content.
**Influences:** Frameworks here draw on systematic balance methodology (power curves, pacing math), experience engineering theory (accessibility/depth model), cognitive UX research (flow channel, cognitive pacing), and flow theory from positive psychology.
---
## When to Activate
Use this skill when:
- Designing XP curves, level-up formulas, or unlock schedules
- Tuning difficulty ramps for a campaign or level sequence
- Players report the game is "too easy," "too hard," or "grindy"
- Implementing adaptive difficulty or dynamic scaling
- Planning content pacing for a long-form game
- Deciding what to gate behind progression vs. make available from the start
---
## Core Model: Accessibility and Depth
Two independent axes that progression systems must serve:
```
Depth (high ceiling)
|
| +-----------+
| | The Goal | ← Easy to start, deep to master
| +-----------+
|
+-------------------→ Accessibility (low floor)
```
- **Accessibility** (low floor) — Can a novice play and have a good time?
- **Depth** (high ceiling) — Is there room for an expert to keep improving?
These are NOT opposites. The best systems score high on both. Techniques:
| Technique | How It Works | Example |
|-----------|-------------|---------|
| **Layered complexity** | Simple surface, deep internals | Chess: easy rules, infinite strategy |
| **Optional complexity** | Advanced systems exist but aren't required | Type matchups you can ignore if you over-level |
| **Skill-based progression** | The *player* improves, not just the character | Combo execution, map knowledge, timing |
---
## Power Curves
How player power grows over time. The curve shape determines how the game *feels*.
### Curve Types
```
Power
| Exponential S-Curve (often ideal)
| / _____
| / /
| / /
| / /
| / /
| / ____/
| / /
| / /
| / ___/
|/___________/
+----------------------------------→ Time
Linear Logarithmic
/ ___________
/ /
/ /
/ /
/ /
+-------------------→ +-------------------→
```
| Curve | Feel | When to Use | Risk |
|-------|------|-------------|------|
| **Linear** | Consistent, predictable | Tutorial sections, first hour | Boring over long spans |
| **Exponential** | Dramatic, accelerating | Short games, power fantasies | Unmanageable late game |
| **Logarithmic** | Diminishing returns | Realistic simulations | Feels unrewarding as ceiling approaches |
| **S-Curve** | Slow start → rapid middle → plateau | Most progression systems | Requires careful inflection point placement |
### Felt vs. Actual Power
Players need to *feel* stronger even when mathematical power growth slows.
**Techniques for maintaining felt power at diminishing actual power:**
- New abilities that *look* dramatic even if numerically modest
- Visual upgrades (armor appearance, particle effects, screen presence)
- New *types* of interaction rather than bigger numbers
- Areas of the world that were previously inaccessible
- AI enemies that react more dramatically to the player's attacks
**Template: Power Curve Spreadsheet**
```
| Level | XP Required | Cumulative XP | Power Rating | Felt Power | New Content |
|-------|-------------|---------------|--------------|------------|-------------|
| 1 | 0 | 0 | 10 | Low | Tutorial |
| 2 | 100 | 100 | 15 | Growing | Ability A |
| 3 | 150 | 250 | 19 | Growing | |
| 4 | 225 | 475 | 22 | Moderate | Area B |
| 5 | 340 | 815 | 25 | Moderate | Ability B |
```
---
## XP and Level Math
### Common XP Formulas
**Linear scaling:** `xp_for_level(n) = base * n`
- Simple, predictable, gets grindy fast
**Polynomial:** `xp_for_level(n) = base * n^exponent`
- Exponent 1.5-2.0 is common
- Gradually increasing time between levels
**Exponential:** `xp_for_level(n) = base * growth_rate^n`
- Dramatic acceleration, use sparingly
- Works when matched with exponential reward scaling
**Practical approach:**
1. Decide how long each level should *feel* in play time
2. Estimate XP gain per minute of intended play
3. Back-calculate the required XP per level
4. Plot and smooth the curve
5. Playtest and adjust — the math is a starting point, not the answer
### Level Count Rule of Thumb
Target a level-up every 10-30 minutes of play in the early game, stretching to 30-60 minutes in mid/late game. Work backward from intended game length to determine level count. Short games (2-5 hours) need fewer levels (10-15); long games (50+ hours) need more (50-100) but risk grind at scale.
---
## The Flow Channel
Challenge should approximate skill level — the "flow channel" from psychology:
```
Challenge
| Anxiety
| /
| / FLOW CHANNEL
| / /
| / /
|/ /
| / Boredom
|/
+------------------→ Skill
```
- **Above the channel** → anxiety, frustration, quitting
- **Below the channel** → boredom, disengagement
- **In the channel** → engagement, "just one more try"
### Targeting the Channel
- [ ] Does difficulty scale with demonstrated player skill (not just time played)?
- [ ] Are there multiple difficulty signals? (Speed, accuracy, strategy quality, not just "did they die?")
- [ ] Does the channel widen as skill increases? (Experts tolerate more variance)
- [ ] Can players self-select difficulty? (Options, optional challenges, difficulty modes)
### Adaptive Difficulty
If implementing dynamic difficulty adjustment (DDA):
**Do:**
- Adjust invisibly (enemy spawn rate, AI aggression, resource availability)
- Base adjustments on multiple signals (death rate + time-to-complete + resource usage)
- Apply gradually — sudden shifts feel unfair
**Don't:**
- Make it visible — players who notice rubber-banding feel cheated
- Adjust core challenge identity (if the game is about precision, don't make hitboxes bigger)
- Scale only HP/damage (lazy, breaks balance, doesn't change the *experience*)
---
## The Difficulty Sandwich
Good progression peels three layers of challenge:
```
Layer 1 (bottom): Mechanical skill (can I physically do this?)
Layer 2 (middle): Cognitive challenge (do I understand what to do?)
Layer 3 (top): Strategic depth (can I optimize my approach?)
```
**Progression phases:**
- **Early game:** Layer 1 only — learn controls, build muscle memory
- **Mid game:** Layer 1 + 2 — learn systems, understand interactions
- **Late game:** All three — master strategy, optimize builds, find efficiencies
**Anti-pattern:** Introducing Layer 3 challenges before Layer 1 is comfortable. Don't ask for strategic thinking while the player is still fumbling with controls.
---
## Content Pacing
New content (mechanics, enemies, zones, abilities) should arrive at inflection points on the power curve.
**Rules of thumb:**
- Introduce new content when the player has *just* mastered the previous content
- Each new element should change *how* the player plays, not just *what* they fight
- Space unlocks so there's always something recent to explore and something to anticipate
- The longest stretch without new content should be shorter than the player's patience — and that's shorter than you think
### Unlock Pacing Checklist
- [ ] Is there a meaningful unlock or new mechanic every 15-30 minutes? (Adjustable per genre)
- [ ] Do unlocks change player beRelated in Design
contribute
IncludedLocal-only OSS contribution command center. Auto-refreshes the user's in-flight PR and issue state on invoke so conversations start with full context — no need to brief Claude on what's in flight. Helps the user find issues to contribute to on GitHub, builds per-repo dossiers of what each upstream expects (CLA, DCO, branch convention, AI policy, draft-first, review bots, issue templates), runs deterministic gates before any external action so AI-assisted contributions don't reach maintainers as slop. State is markdown-only: candidate files at ~/.contribute-system/candidates/, repo dossiers at ~/.contribute-system/research/, append-only event log at ~/.contribute-system/log.jsonl. No database, no cloud calls. Use when the user asks about their PRs / issues / contributions, wants to find new work to take on, claim an issue, build/refresh a repo's dossier, or draft a Design Issue or PR. Trigger with "/contribute", "what's my PR status", "find a contribution", "claim issue X", "draft a Design Issue for Y", "refresh dossier for Z".
architectural-analysis
IncludedUser-triggered deep architectural analysis of a codebase or scoped subtree across eight modes — information architecture, data flow, integration points, UI surfaces, interaction patterns, data model, control flow, and failure modes. This skill should be used when the user asks to "diagram this codebase," "map the architecture," "show the data flow," "give me an ERD," "trace control flow," "find the integration points," "verify the layout pattern," "audit the UX architecture," or any similar request whose primary deliverable is mermaid diagrams plus cited reports under docs/architecture/. Dispatches haiku/sonnet sub-agents in parallel for per-mode exploration, then verifies every citation mechanically before any node lands in a diagram. Not for one-off prose explanations of code (use code-explanation) or for high-level system design from scratch (use system-design).
mcp
IncludedModel Context Protocol (MCP) server development and tool management. Languages: Python, TypeScript. Capabilities: build MCP servers, integrate external APIs, discover/execute MCP tools, manage multi-server configs, design agent-centric tools. Actions: create, build, integrate, discover, execute, configure MCP servers/tools. Keywords: MCP, Model Context Protocol, MCP server, MCP tool, stdio transport, SSE transport, tool discovery, resource provider, prompt template, external API integration, Gemini CLI MCP, Claude MCP, agent tools, tool execution, server config. Use when: building MCP servers, integrating external APIs as MCP tools, discovering available MCP tools, executing MCP capabilities, configuring multi-server setups, designing tools for AI agents.
react-native-skia
IncludedDesign, build, debug, and optimise high-polish animated graphics in React Native or Expo using @shopify/react-native-skia, Reanimated, and Gesture Handler. Use when the user wants canvas-driven UI, shaders, paths, rich text, image filters, sprite fields, Skottie, video frames, snapshots, web CanvasKit setup, or performance tuning for custom motion-heavy elements such as loaders, hero art, cards, charts, progress indicators, particle systems, or gesture-driven surfaces. Also use when the user asks for fluid, glow, glass, blob, parallax, 60fps/120fps, or GPU-friendly animated effects in React Native, even if they do not explicitly say "Skia". Do not use for ordinary form/layout work with standard views.
plaid
IncludedProduct Led AI Development — guides founders from idea to launched product. Six capabilities: Idea (discover a product idea), Validate (pressure-test the idea against fatal flaws, problem reality, competition, and 2-week MVP feasibility), Plan (vision intake + document generation), Design (translate image references into a design.md spec), Launch (go-to-market strategy), and Build (roadmap execution). Use when someone says "PLAID", "plaid idea", "help me find an idea", "product idea", "idea from my business", "idea from my expertise", "plaid validate", "validate my idea", "pressure-test", "is this idea good", "find fatal flaws", "validate the problem", "plan a product", "define my vision", "generate a PRD", "product strategy", "plaid design", "design from image", "translate image to design", "create design.md", "extract design tokens", "plaid launch", "go-to-market", "launch plan", "GTM strategy", "launch playbook", "plaid build", "build the app", "start building", or "execute the roadmap".
nextjs-framer-motion-animations
IncludedAdds production-safe Motion for React or Framer Motion animations to Next.js apps, including reveal, hover and tap micro-interactions, whileInView, stagger, AnimatePresence, layout and layoutId transitions, reorder, scroll-linked UI, and lightweight route-content transitions. Use when the user asks to add, refactor, or debug Motion or Framer Motion in App Router or Pages Router codebases, especially around server/client boundaries, reduced motion, LazyMotion, bundle size, hydration, or route transitions. Avoid for GSAP-style timelines, WebGL or 3D scenes, heavy scroll storytelling, or CSS-only effects unless Motion is explicitly requested.