asgard-ai-platform/grad-mechanism-design
Apply mechanism design (reverse game theory) to engineer incentive-compatible rules for allocation problems. Use this skill when the user needs to design auctions, voting systems, or matching markets, or when evaluating whether a proposed mechanism satisfies incentive compatibility and individual rationality constraints.
npx skills add https://github.com/asgard-ai-platform/skills --skill grad-mechanism-design
Mechanism design is the engineering side of game theory: instead of analyzing given games, you design the rules so that self-interested agents produce a desired outcome. The central tool is the revelation principle, which shows that any implementable outcome can be achieved by a direct mechanism where truth-telling is optimal. The field underpins auction design, voting systems, matching markets, and regulatory frameworks.
IRON LAW: A mechanism is incentive-compatible ONLY if truth-telling is a
dominant strategy — no mechanism can simultaneously maximize efficiency,
budget balance, and individual rationality (Myerson-Satterthwaite theorem).
Step 1 — Define the Design Problem
Specify the set of agents, their type spaces, the outcome space, and the social choice function you want to implement. Identify the objective: efficiency, revenue, fairness, or a weighted combination.
Step 2 — Apply the Revelation Principle
Restrict attention to direct revelation mechanisms. For each agent, the mechanism asks for a reported type and maps the profile of reports to an outcome and transfers. Check whether truthful reporting constitutes a Bayesian Nash equilibrium (BNE-IC) or dominant strategy equilibrium (DSIC).
Step 3 — Verify Constraints
Check three core constraints: (1) Incentive Compatibility — no agent gains by misreporting; (2) Individual Rationality — each agent is at least as well off participating as not; (3) Budget Balance — the designer does not run a deficit. Apply Myerson-Satterthwaite to determine which constraints can co-exist.
Step 4 — Characterize and Optimize
Use the envelope theorem to derive the payment rule from the allocation rule. Optimize the objective subject to binding constraints. Report which trade-offs are unavoidable.
## Mechanism Design Analysis: [Context]
### Design Problem
- **Agents**: [who participates]
- **Type space**: [private information each agent holds]
- **Outcome space**: [possible allocations]
- **Objective**: [efficiency / revenue / fairness]
### Proposed Mechanism
- **Allocation rule**: [how outcomes map to reports]
- **Payment rule**: [transfers as function of reports]
### Constraint Verification
| Constraint | Satisfied? | Notes |
|--------------------------|------------|-------|
| Incentive Compatibility | Yes / No | |
| Individual Rationality | Yes / No | |
| Budget Balance | Yes / No | |
### Impossibility Trade-offs
[Which constraints conflict per Myerson-Satterthwaite; what the designer must sacrifice]
### Recommendation
[Chosen mechanism and rationale]
Take asgard-ai-platform/grad-mechanism-design from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.