| name | prediction-markets |
| description | Use this skill whenever a DRF-2 forecast could be calibrated against real prediction markets. It teaches the prediction_market_search tool (Polymarket's public Gamma API — no API key required) — how to derive short high-recall queries, which markets to trust (open, priced, liquid), how to keep the snapshot diverse across events, and how to use market-implied probabilities as calibration anchors rather than ground truth, including the divergence-explanation rule. |
| allowed-tools | ["prediction_market_search","tool_search","read_file","write_file"] |
Prediction Markets Skill
1. Why markets, and what they are not
Prediction-market prices are the aggregated, money-weighted belief of people with skin in the game — an excellent calibration anchor for a forecast. They are NOT ground truth: prices move continuously, thin markets are noisy, and market questions rarely match your forecast's resolution criteria word-for-word. The workflow is: fetch → filter → compare → explain divergence — never copy.
The prediction_market_search tool queries Polymarket's public Gamma API (gamma-api.polymarket.com — no key, no wallet; the polymarket-cli tool is just a thin wrapper over this same public API) for active markets and returns, per market: market_id, exchange ("polymarket"), question, implied_yes_prob (the "Yes" price), volume, liquidity, event_title. It is degrade-safe: network failure / nothing found → empty result. An empty result is an answer — note "no liquid markets overlap this question" and move on; never fabricate a market or a price.
2. Query craft (full-text search likes short phrases)
Market search is full-text; short phrases (≤5 words) work best — tariff, semiconductor export, AI capex, Fed rate cut, US midterms.
Derive up to ~6 queries deterministically from the run's materials:
- The 2–3 most salient noun phrases of the central question (strip stopwords and generic forecast-speak like "forecast", "impact", "scenario"; keep short all-caps acronyms — AI, EU, GDP).
- The run's hot topics (up to 4).
- The top 2–3 actor names by salience.
- Deduplicate case-insensitively; trim each query to ≤5 words.
Do not reissue near-duplicate queries; a thin result means change the phrase's angle (another actor, another driver), not its word order.
3. Filtering (which markets deserve to be anchors)
Keep a market only if ALL hold — an unfiltered market table is worse than none:
- Open:
closed is not true. (Do NOT trust the active flag — Polymarket leaves it true on already-resolved markets; closed is the reliable gate.)
- Priced:
implied_yes_prob — parsed from the market's outcomes/outcomePrices at the "Yes" index — is a number strictly inside (0, 1). A price of exactly 0 or 1 means the market has effectively resolved and is worthless as an anchor.
- Liquid enough:
volume ≥ ~200 — ultra-low-volume prices are noise, not information.
- Deduplicated by
market_id across queries (keep the first-matching query for traceability).
Rank the survivors by volume (descending), then cap each event to ~3 markets (event_title) before taking the top ~20. This matters: a single multi-outcome event — e.g. "How many Fed rate cuts in 2026?" with sub-markets for 0,1,2,…,12 — otherwise floods the whole snapshot with one topic's high-volume ladder and crowds out every other relevant event. Diversity across events beats depth within one.
4. Using the anchors
- Render a "Prediction Market Signals" section in the research report / brief: a table with market question (+
market_id), venue, implied P(yes), and volume, plus the standing caveat that this is a machine-fetched snapshot of moving prices.
- Cite, don't copy. Where a forecast overlaps a listed market, cite the market's implied probability in the forecast's
adjustment_rationale and attach market_anchor: {market_id, implied_yes_prob}. Your probability remains YOUR probability, produced by your own base-rate + evidence + simulation reasoning.
- The divergence rule: when your probability differs from the cited market by more than 10 percentage points, explain the divergence explicitly — what the market is missing or mispricing (private research signal, simulation dynamics, definitional mismatch between the market question and your statement). Silent large divergence is a defect; so is silent convergence achieved by copying.
- Question-match honesty: check that the market's question, horizon, and resolution rules actually correspond to your statement before anchoring. A near-miss market (different threshold, different date) can still be cited — with the mismatch named — but must not be pasted into
market_anchor as if equivalent.
- Freshness: note the fetch time context; a snapshot ages fast around catalysts. Re-fetch rather than reason from a stale table when the report stage runs long after research.
5. Failure modes
- ❌ Long natural-language queries ("what is the probability that the US will raise tariffs in 2026") — full-text search returns junk; use
tariff, US tariffs.
- ❌ Anchoring on a closed, unpriced, or resolved (price 0/1) market.
- ❌ Trusting the
active flag instead of closed — resolved Polymarket markets stay active: true.
- ❌ Letting one multi-outcome event's sub-market ladder dominate the whole snapshot (cap per event).
- ❌ Copying the market price as your forecast probability (that is abdication, not calibration).
- ❌ Diverging >10pp from a cited market without an explicit explanation.
- ❌ Treating a market with mismatched threshold/date as equivalent to your statement.
- ❌ Fabricating market IDs or prices when the tool returns nothing.
- ❌ Presenting the snapshot as live truth without the freshness caveat.
