agentleFS
varunk130varunk130/claude-code-skills/skills/game-theory/mechanism-design-planner/SKILL.md

mechanism-design-planner

Skill1 starsChanged 21 days agoMITView on GitHub

Designs auctions, matching mechanisms, pricing schemes, and incentive structures using mechanism-design principles - Incentive Compatibility (IC), Individual Rationality (IR), revenue equivalence, and budget balance. Use when designing a marketplace pricing model or referral program; allocating internal resources; running a Request for Proposal (RFP) or procurement process; choosing an auction format; or setting any allocation rule where participants act strategically.

The file

We split this skill into the rules it gives an agent

2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Test edge cases: thin participation, lopsided value distributions, single dominant bidder

    line 121
  2. Distinctive:

    Use first-price when truthful revelation matters

    line 144

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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:

PropertyDefinitionWhen critical
Incentive Compatibility (IC)Truth-telling is a (dominant or Bayesian) best responseAlways desirable; near-mandatory at scale
Individual Rationality (IR)Participating beats opting out for each typeRequired for voluntary participation
Pareto efficiencyNo reallocation makes everyone weakly better offWelfare-maximizing settings
Budget balanceMechanism's payments sum to zero (or non-positive)Self-sustaining without subsidy
No-deficitMechanism doesn't lose moneyWeaker than budget balance
Strategy-proofnessTruth is a dominant strategyWhen robust simplicity matters
Pareto optimality of matchingNo coalition can improve via reassignmentMatching 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

ClassUse caseNotes
English (open ascending)Single-item, transparent, commonFamiliar; reveals second-highest value
Sealed-bid first-priceSingle-item, sealed, paid own bidShading optimal; complex strategy
Sealed-bid second-price (Vickrey)Single-item, sealed, paid 2nd priceTruth-telling is a dominant strategy (IC)
Vickrey-Clarke-Groves (VCG)Multi-item, combinatorialIC plus efficient; revenue may be low; complex
Posted-priceMany small buyers, low-frictionLoses revenue from high-value buyers; simple
Scoring auctionMulti-attribute (price plus quality plus delivery)Common in procurement
CombinatorialBundle allocations (spectrum, gates)Computationally hard; needs careful design
Deferred-acceptance (Gale-Shapley)Two-sided matching (schools, residencies)Strategy-proof for proposing side
Top trading cyclesPareto-efficient matching with prioritiesStrategy-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

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.