# Mechanism Designer

> Design incentive-compatible mechanisms for specific allocation, auction, voting, or governance problems. Use when the user needs to create rules for a strategic situation — choosing an auction format, designing a matching system, structuring incentives for a team or platform, or building governance rules for an organization or DAO.

- Skill: `npbuilds/mechanism-designer` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add npbuilds/mechanism-designer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/npbuilds/mechanism-designer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: npbuilds (https://skillmd.com/u/npbuilds)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/npbuilds/mechanism-designer

---


# Mechanism Designer — The Engineer

Take a design problem — "how should we allocate X?", "what auction should we use?", "how do we make truthful reporting optimal?" — and produce a concrete mechanism with proven incentive properties. This skill bridges theory to practice: it knows the impossibility results (what you can't have) and the constructive results (what you can build).

## How to Run

### Input

The user provides:
1. **The allocation problem** — what's being allocated, to whom, under what constraints
2. **Design objectives** — what the designer cares about (efficiency, revenue, fairness, simplicity, strategy-proofness)
3. **Constraints** — budget limits, participation constraints, institutional requirements, computational limits
4. **Information structure** — what's private, what's public, what can be verified

### Steps

#### Step 1 — Characterize the Design Space

Identify the mechanism design setting:

| Dimension | Options | Implications |
|-----------|---------|-------------|
| **Transfers** | Money available / restricted / none | With money → auctions, VCG. Without → matching, voting |
| **Items** | Single / multiple / combinatorial | Multiple items → combinatorial complexity, complementarities |
| **Agents** | Symmetric / asymmetric | Asymmetric → standard results may not apply |
| **Values** | Private / common / interdependent | Common values → winner's curse, information aggregation matters |
| **Repetition** | One-shot / repeated | Repeated → dynamic mechanism design, renegotiation |
| **Verification** | Outcomes verifiable / not | Unverifiable → moral hazard, contract theory |

#### Step 2 — Identify Impossibility Constraints

Before designing, check which impossibility theorems bind:

- **Myerson-Satterthwaite**: Can't have efficiency + IC + IR + budget balance in bilateral trade with private values
- **Gibbard-Satterthwaite**: Can't have strategy-proofness + non-dictatorship with 3+ alternatives (no transfers)
- **Arrow**: Can't have universal domain + Pareto + IIA + non-dictatorship for social rankings
- **Green-Laffont**: VCG is the only Groves mechanism that is IC in dominant strategies for general valuations; but it may run a deficit

Flag which constraints the user's problem hits. This determines the feasible design space.

#### Step 3 — Select a Mechanism Class

Based on the setting and constraints, choose the appropriate mechanism family:

**With transfers (auctions/payments)**:
- Revenue goal → Myerson optimal auction (with reserve prices)
- Efficiency goal → VCG mechanism
- Simplicity + good properties → Second-price / English auction
- Multiple items + complements → Combinatorial clock auction
- Budget-constrained bidders → Clinching auctions, adaptive reserves

**Without transfers (matching/allocation)**:
- Two-sided stability → Deferred acceptance (DA)
- One-sided efficiency → Top trading cycles (TTC)
- Simplicity → Serial dictatorship / random priority
- Probabilistic fairness → Probabilistic serial

**Preference aggregation (voting)**:
- Condorcet consistency → Schulze method, ranked pairs
- Simplicity + manipulation resistance → Approval voting
- Intensity expression → Quadratic voting
- Single-peaked domain → Median voter rule (strategy-proof)

#### Step 4 — Specify the Mechanism

Produce a complete mechanism specification:

```
MECHANISM SPECIFICATION
───────────────────────
Name: [descriptive name]
Setting: [who participates, what's allocated, constraints]

Rules:
  1. Elicitation: [what participants report — bids, rankings, approvals, etc.]
  2. Allocation: [how the outcome is determined from reports]
  3. Payments: [if applicable — how much each participant pays/receives]

Properties:
  - Incentive compatibility: [DSIC / BIC / not IC — and why]
  - Efficiency: [Pareto efficient / approximately efficient / not efficient]
  - Individual rationality: [ex post IR / interim IR / not IR]
  - Revenue/budget: [surplus, deficit, or balanced]
  - Fairness: [envy-free, proportional, or other fairness properties]

Limitations:
  - [which desirable properties are sacrificed and why]
  - [what impossibility theorem constrains the design]
```

#### Step 5 — Analyze Incentive Properties

Formally verify the mechanism's incentive properties:

1. **Is truthful reporting optimal?** Under what equilibrium concept (dominant strategy, Bayes-Nash)?
2. **What are the manipulation opportunities?** If not fully IC, how much can agents gain by misreporting?
3. **What happens under collusion?** Can groups of agents profitably coordinate deviations?
4. **Is participation voluntary?** Would any agent prefer not to participate (IR violation)?

#### Step 6 — Practical Deployment Considerations

Address implementation concerns:

- **Computational complexity**: Can the mechanism be run efficiently? Winner determination in combinatorial auctions is NP-hard.
- **Communication complexity**: How much information must participants report? Full preference rankings are exponential for combinatorial settings.
- **Robustness**: How sensitive is the mechanism to modeling assumptions? Does it work under slight misspecification?
- **Simplicity**: Can participants understand the rules? Overly complex mechanisms may fail in practice even if theoretically optimal.
- **Dynamics**: If repeated, can participants learn to manipulate over time?

### Output

A structured mechanism design document:

```
## Mechanism Design: [Problem Name]

### Problem
[What's being allocated, to whom, under what constraints]

### Design Objectives
[Priority-ordered list of goals]

### Impossibility Constraints
[Which theorems limit what's achievable]

### Proposed Mechanism
[Full specification — elicitation, allocation, payments]

### Incentive Analysis
[IC, IR, efficiency, fairness properties with justification]

### Practical Considerations
[Computational, communicational, robustness, simplicity]

### Alternatives Considered
[Other mechanism classes and why the proposed one was chosen]
```

## Error Handling

**Problem is underspecified**: Ask the user to clarify the objective function. "Design a fair system" needs specifics — fair by what criterion? Envy-free? Proportional? Equitable?

**Impossibility theorem blocks all objectives**: Present the tradeoff explicitly. "You want efficiency, strategy-proofness, and budget balance. Myerson-Satterthwaite says you can get at most two. Which do you prioritize?"

**No known optimal mechanism exists**: Propose the best-known mechanism with its properties, and identify the gap. Note whether the problem is an active research area.

**Mechanism is too complex for the setting**: Simplify. A theoretically suboptimal but practically implementable mechanism often beats the optimal one that nobody understands. Milgrom's practical auction design philosophy: "Getting 90% of the theoretical optimum with a mechanism people can actually use is better than 100% with one they can't."