Mechanism Design Planner

Mechanism Design Planner

> Reverse-engineers the rules so that participants acting in their own interest produce the outcome you want.

What this skill is

A workflow that frames an allocation problem as a mechanism-design problem, surfaces the design objectives (efficiency, revenue, fairness, simplicity), picks the right mechanism class (first-price, second-price, Vickrey-Clarke-Groves (VCG), posted-price, matching, scoring auction), checks the canonical properties (Incentive Compatibility (IC), Individual Rationality (IR), budget balance, no-deficit), and stress-tests against collusion and gaming.

What it solves

• Mechanisms that are gamed because participants have private information and weak incentives to reveal it
• Auctions that maximize revenue in theory but kill participation in practice
• Pricing models that look optimal until customers stop adopting
• Allocation rules that produce inefficient outcomes (the wrong party wins)
• Programs (referrals, compensation plans, Requests for Proposal (RFPs)) that produce unintended behaviors

When to invoke

• Designing a marketplace pricing model (commissions, dynamic pricing, surge)
• Procurement or RFP design where bidders are strategic
• Auction format decisions (English, sealed-bid, second-price, combinatorial)
• Internal resource allocation (compute quota, headcount, budget)
• Matching problems (school choice, dorm assignment, kidney exchange, marketplace pairing)
• Incentive compensation, referral programs, bug bounties

Phase 1: State the problem formally

• Participants - buyers, sellers, candidates, applicants
• Private information - what does each participant know that others (and the designer) don't?
• Allocation outcome - what is being allocated and to whom?
• Transfers - what payments or rewards move between parties?
• Designer's objective - efficiency, revenue, fairness, participation, simplicity (pick 1-2 primary)
• Constraints - budget, legal, computational, fairness

Without explicit private information, mechanism design doesn't apply - it's just an allocation rule.

Phase 2: Specify desired properties

Choose which properties the mechanism must satisfy:

| Property | Definition | When critical | |----------|-----------|---------------| | Incentive Compatibility (IC) | Truth-telling is a (dominant or Bayesian) best response | Always desirable; near-mandatory at scale | | Individual Rationality (IR) | Participating beats opting out for each type | Required for voluntary participation | | Pareto efficiency | No reallocation makes everyone weakly better off | Welfare-maximizing settings | | Budget balance | Mechanism's payments sum to zero (or non-positive) | Self-sustaining without subsidy | | No-deficit | Mechanism doesn't lose money | Weaker than budget balance | | Strategy-proofness | Truth is a dominant strategy | When robust simplicity matters | | Pareto optimality of matching | No coalition can improve via reassignment | Matching markets |

Standard tension: efficiency, IR, IC, and budget balance simultaneously is often impossible (the Myerson-Satterthwaite result for bilateral trade). State the trade-off explicitly.

Phase 3: Pick a mechanism class

| Class | Use case | Notes | |-------|----------|-------| | English (open ascending) | Single-item, transparent, common | Familiar; reveals second-highest value | | Sealed-bid first-price | Single-item, sealed, paid own bid | Shading optimal; complex strategy | | Sealed-bid second-price (Vickrey) | Single-item, sealed, paid 2nd price | Truth-telling is a dominant strategy (IC) | | Vickrey-Clarke-Groves (VCG) | Multi-item, combinatorial | IC plus efficient; revenue may be low; complex | | Posted-price | Many small buyers, low-friction | Loses revenue from high-value buyers; simple | | Scoring auction | Multi-attribute (price plus quality plus delivery) | Common in procurement | | Combinatorial | Bundle allocations (spectrum, gates) | Computationally hard; needs careful design | | Deferred-acceptance (Gale-Shapley) | Two-sided matching (schools, residencies) | Strategy-proof for proposing side | | Top trading cycles | Pareto-efficient matching with priorities | Strategy-proof; efficient |

Pick the mechanism whose properties match your objectives.

Phase 4: Revenue equivalence and expected outcomes

The Revenue Equivalence Theorem: under standard assumptions (risk-neutral bidders, Independent Private Values (IPV), symmetric, no reserve), all efficient single-item auctions yield the same expected revenue to the seller.

Implication: format choice is often not about expected revenue - it's about variance, transparency, complexity, IC, and resistance to collusion.

Compute under the chosen mechanism:

• Expected efficiency (probability the highest-value participant wins)
• Expected revenue (closed-form for standard auctions; simulation for non-standard)
• Expected participation (do all types prefer joining?)
• Worst-case loss or regret

Phase 5: Reserve prices, fees, and quotas

• Reserve price - minimum price; trades efficiency for revenue (excludes low-value buyers)
• The Myerson optimal reserve: where marginal revenue equals zero; depends on value distribution
• Entry fee - screens out low-value participants; can reduce participation
• Quotas or caps - limit allocation per participant; useful in matching to prevent monopolization
• Subsidies - encourage participation on the thin side of the market

Each lever has efficiency, revenue, and participation trade-offs. Quantify each.

Phase 6: Collusion and gaming resistance

Stress-test the mechanism:

• Bid rotation - bidders take turns winning
• Sham bidding - phantom bidders inflating second-price auctions
• Coordination via signaling - early bids signaling intentions (open auctions susceptible)
• Sniping - last-second bids in soft-close auctions
• Misreporting - overstating need to get a larger allocation
• Reverse-engineering scores - gaming a scoring formula

Design defenses:

• Hard close versus soft close
• Anonymous bidders
• Sealed versus open
• Reserve plus proxy bids
• Audit plus penalty
• Periodic re-randomization

Phase 7: Simulate before launch

For any non-trivial mechanism, simulate:

• 1,000+ trials with realistic participant value distributions
• Stress with strategic and non-strategic mix
• Compute mean and worst-case allocation efficiency
• Compute revenue distribution, not just expected revenue
• Test edge cases: thin participation, lopsided value distributions, single dominant bidder

Output

• Problem statement: participants, private information, allocation, transfers, objective
• Property requirements with explicit trade-offs noted
• Recommended mechanism class with reasoning
• Parameter settings: reserve, fees, quotas
• Expected outcomes: efficiency, revenue, participation
• Collusion and gaming threat map with mitigations
• Simulation results across realistic scenarios
• Launch plan with monitoring metrics to detect manipulation

Operating rules

Always

• State the private information explicitly
• Choose 1-2 primary objectives (efficiency, revenue, fairness, simplicity)
• Pick a mechanism whose properties match the objectives
• Stress-test against collusion and gaming
• Simulate before launch

Never

• Use first-price when truthful revelation matters
• Promise efficiency, IR, IC, and budget balance simultaneously for bilateral trade
• Skip reserve-price tuning
• Launch a complex mechanism without participant simulation
• Ignore behavioral deviations from rational play

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: varunk130
• Source: varunk130/claude-code-skills
• License: MIT

Install and usage instructions live in the source repository linked above.