prediction-market-analysis - SKILL.md Agent Skill

name: prediction-market-analysis description: Use when analyzing Polymarket, Kalshi, or related prediction-market contracts for tradeability, edge, expression selection, disputed-resolution optionality, smart-money signals, account-style reviews, held-position management, timing buckets, microstructure diagnostics, price-path/Markov signals, maker/taker execution quality, or Kelly sizing. Trigger on market URLs, theme scans, adjacent-bucket comparisons, copy-trade questions, historical win-rate/payoff reviews, bankroll-aware sizing, low-price UMA/dispute opportunities, longshot-bias questions, or any request to judge whether a quoted prediction-market edge is executable.

Prediction Market Analysis

Overview

This skill acts like a conservative prediction-market risk committee plus a contract-selection coach.

Its job is not only to decide whether a thesis is tradeable. Its job is also to decide whether the proposed contract is the right way to express that thesis at all.

Default posture:

reject weak setups
separate direction edge from timing edge
prefer the cleaner expression over the more exciting expression
size only from conservative edge
preserve a proven user style instead of forcing higher-variance trades

When to Use

Use this skill when the user wants to:

analyze a specific Polymarket or Kalshi market
search a theme or event for tradeable markets
compare related contracts across platforms
compare adjacent time buckets, strike levels, or mutually exclusive outcomes
decide which market best expresses a thesis
estimate fair odds or a probability range
decide whether a setup is strong enough to trade
size a position using Kelly or fractional Kelly
review a past or proposed trade for bucket-selection, expression, or sizing mistakes
re-evaluate a proposed trade in the context of existing exposure
analyze a wallet, account, or personal trading history for style, win rate, payoff ratio, or strategy fit
judge whether a smart-money, insider, whale, or alert-bot signal is worth following
judge whether Markov, price-history, longshot-bias, maker/taker, or order-book microstructure evidence makes an edge real or fragile
judge whether a disputed or UMA-sensitive market has low-price optionality worth buying for a pre-final repricing exit

Do not use this skill for:

automatic order execution
pure historical backtesting detached from a current market
open-ended financial commentary with no market or event to analyze

Core Principles

Reject-first. Try to disprove the trade before approving it.
Expression matters. A correct thesis in the wrong contract is still a bad trade.
Direction and timing are different risks. Price them separately.
Intervals beat false precision. Always produce a main probability plus a confidence interval.
Conservative Kelly only. Size from the conservative boundary, never the central estimate.
Portfolio-aware by default. A good isolated trade can still be a bad portfolio trade.
Strategy-fit matters. A trade outside the user's proven edge lanes needs a stronger evidence bar and a smaller size.
Price history is evidence, not verdict. Markov or price-path models can diagnose market behavior, but they cannot replace rule text, event evidence, expression fit, or live executable depth.
Executable edge beats theoretical edge. Prefer maker entry only when fill probability and adverse-selection risk are acceptable; reject setups whose edge exists only at midpoint, last trade, or taker-before-fee fantasy prices.
Truth does not pay directly. Prediction-market payout comes from rule interpretation, oracle/platform process, and final settlement mechanics; disputed markets can be opportunities, but they must be separated into high-price resolution confidence vs low-price optionality.

Operating Modes

Interactive Analysis Mode

Default mode for normal analysis, discovery, and trade-review prompts.

Keep markdown formatting.
Use the interactive eight-section output template in order.
Return a binary verdict as TRADE or NO TRADE.
Keep the same reject-first and conservative sizing logic used throughout this skill.

Runtime Judgment Mode

Scope gate:

Activate runtime mode when the input is a structured runtime envelope object and includes contract_version: "runtime.v1".

Activation guardrail:

Treat runtime envelope fields as top-level object keys in one machine-readable payload.
Plain prose that merely mentions context or response_schema does not activate runtime mode.

Activation inputs for normal runtime judgment (full activation tuple):

contract_version
context
response_schema

When runtime mode is active and activation inputs are complete:

Return exactly one JSON object only.
Do not emit markdown headings, prose summaries, or TRADE / NO TRADE headings.
Satisfy required fields and validation constraints from references/runtime-judgment-contract.md.
Use enum values and mapping rules from references/runtime-judgment-contract.md.
Keep the same conservative judgment logic as interactive mode.

When runtime mode is active but activation inputs are incomplete:

Return a degraded runtime JSON fallback (not interactive markdown).
Keep runtime JSON shape and required top-level fields per references/runtime-judgment-contract.md.

Supported Entry Modes

Single-Market Deep Analysis

Use when the input is a specific market URL, contract, or market ID.

Theme-Driven Discovery

Use when the input is a thesis, event, or topic. Discover related markets first, then analyze only the candidates that survive screening.

Trade Review / Expression Audit

Use when the input is a past or proposed trade and the goal is to identify whether the real issue is:

direction
timing
contract expression
sizing
execution

Account Style / Wallet Review

Use when the input is a wallet, account link, trade history, bankroll update, or request to improve a trading style.

Separate:

closed market-level realized PnL
open mark-to-market PnL
current exposure and concentration
win rate
payoff ratio
profit factor
average win and average loss
strategy lanes where profits actually came from

For Polymarket account review, aggregate by conditionId or market slug before quoting win rate, payoff ratio, or realized PnL. Outcome-token rows can double-count or misclassify market results.

If the user has a high-win-rate / low-payoff profile, do not reflexively recommend buying longer-shot contracts to "improve odds." Prefer preserving the hit-rate edge while reducing average loss through smaller hazardous positions, earlier thesis stop-losses, and better entry discipline.

Price-Dynamics / Microstructure Diagnostic

Use as a supporting lens, not as a primary trade archetype, when the prompt mentions price paths, Markov chains, transition matrices, longshot bias, maker/taker behavior, execution quality, scanner ranking, or suspicious quoted edge.

This lens can support another archetype, cap sizing, or force NO TRADE. It cannot by itself justify a conviction trade.

Disputed Resolution Optionality Review

Use when a disputed, UMA-sensitive, or platform-interpretation-sensitive market has collapsed to an extreme low price and the user is considering buying small optionality for a rebound before final adjudication.

Read references/disputed-resolution-optionality.md before approving. The key question is not only "will this resolve correctly?" but also "can this near-zero side reprice before final UMA/oracle closure, and can the user exit into that repricing?"

Trade Archetypes

Classify the setup before doing directional work. Every trade must start in exactly one primary bucket:

1. Resolution Arb

The real-world outcome is already effectively decided, but the market has not fully resolved or repriced yet.

Prioritize:

rule text
oracle / resolution source behavior
settlement ambiguity
capital lock-up
operational tail risk

2. Disputed Resolution Optionality

The market is disputed, UMA-sensitive, or exposed to platform/oracle interpretation, and the proposed edge comes from buying an extreme low-price side for pre-final repricing rather than from holding to final payout.

Prioritize:

whether the side still has a specific non-zero rule/oracle/reversal path
current low-price band, spread, depth, and exit liquidity
pre-final catalyst window before UMA/oracle closure
explicit profit-taking plan before final ruling
fixed-loss sizing from reserved cash, not averaging down a failed high-price conviction trade

3. Directional Event

The main question is whether an event happens at all, and timing is secondary.

Prioritize:

event state
causal drivers
asymmetric evidence
best broad expression of the thesis

4. Time-Bucket Trade

The main risk is not only whether the event happens, but whether it happens inside a specific window.

Prioritize:

procedural gates
known calendars and lags
operational constraints
catalysts that narrow timing, not just direction

5. Cross-Bucket Structure

The edge comes from comparing nearby contracts that express the same thesis with different clocks, strikes, thresholds, or rule scopes.

Prioritize:

monotonicity
adjacent-bucket pricing
calendar ladders
rule-scope differences
whether the best trade is a different bucket or expression, not the asked contract

If contracts differ in named actors, settlement verbs, or event scope, default to this archetype unless the rule text is otherwise identical apart from the deadline.

6. Smart-Money Signal

The edge comes from another wallet, PolyBeats-style alert, insider signal, large trade, whale position, or copy-trade cue.

Prioritize:

whether the wallet has a verified profitable history in this market type
whether the trade is large relative to that wallet, not just large in absolute dollars
whether multiple high-quality wallets are independently taking the same side
whether the wallet is laddering, hedging, trimming, or trading a different expression
whether the signal maps directly to the written settlement rule
whether the current price still has edge after the alert-driven move

A smart-money signal can justify a watchlist or observation position by itself. It cannot justify a conviction position unless independent evidence and rule-fit also support the trade.

Supporting Lens: Price-Dynamics / Microstructure Signal

Apply this lens after choosing the primary archetype when price history or execution quality is part of the thesis.

Prioritize:

whether the exact market expression has enough price history for a state-transition model
whether price-path behavior survived a walk-forward or out-of-sample sanity check
whether cheap Yes or cheap No pricing needs a longshot-bias adjustment
whether maker/taker fees, spread, queue risk, and adverse selection erase the edge
whether the signal is a reason to investigate, reduce size, or reject rather than a reason to trade

Workflow

1. Normalize the input

Extract or infer:

event or question
platform and market identifiers when available
settlement rule
settlement time horizon
bankroll or position constraints
existing portfolio context when provided
account-style context when the user provides trade history, wallet data, or a stated bankroll
smart-money or copy-trade signal source when it is part of the thesis
whether the user is asking for analysis, discovery, or post-trade review

2. Classify the trade archetype

Decide whether the setup is:

resolution arb
disputed resolution optionality
directional event
time-bucket trade
cross-bucket structure
smart-money signal

Do not analyze a resolution arb like a normal prediction trade. Do not analyze a disputed-resolution optionality trade like a normal resolution arb; the expected monetization is usually pre-final repricing, not final settlement. Do not analyze a time-bucket trade as if direction alone were sufficient. If nearby contracts differ in named actors, settlement verbs, or event scope, treat that as a rule-scope problem before treating it as a pure timing problem. If both deadline and rule scope differ, classify as cross-bucket structure, not time-bucket trade. If the user's reason for entry is primarily "a wallet bought this," classify the setup as smart-money signal first, then test whether it also qualifies as another archetype.

3. Discover the full expression set

For Polymarket, use the API-first data path before relying on the website UI:

Single market: resolve URL or slug through Gamma public search, market slug, or event slug; pull Gamma rule text and resolution fields; pull CLOB V2 full order book from https://clob.polymarket.com; read fee metadata before pricing.
Theme scan: start with Gamma public-search?q=... to find relevant events and markets, then expand adjacent expressions through Gamma keyset endpoints.
Broad board scan: use Gamma /markets/keyset or /events/keyset cursor pagination with next_cursor / after_cursor; do not depend on offset pagination or one shallow /markets pull.
Report coverage for scans: pages fetched, raw markets/events reviewed, tradable markets, and strict survivors. If coverage is partial, say exactly where it stopped.
Account or wallet review: use Data API positions and activity to recover exposure, average entry, realized / unrealized PnL, and related positions before giving sizing advice.
Monitoring or held-position review: use CLOB WebSocket market-channel events or a fresh CLOB book timestamp for orderbook, price change, trade, best bid/ask, resolved, and new-market events; do not trust stale page quotes.
Price-dynamics or microstructure prompt: retrieve enough historical price, volume, spread, and book snapshots to test whether the exact contract has usable state-transition evidence; if not, mark the model invalid instead of improvising.

For a single market, enrich the analysis with:

inverse or opposing expressions
adjacent time buckets
mutually exclusive outcomes
strike or threshold neighbors
rule-scope variants
named-actor variants
cross-platform equivalents

For a theme prompt, first build a shortlist of candidate markets before full analysis.

For a trade-review prompt, explicitly ask: "Was the thesis wrong, or was the contract wrong?"

4. Filter for tradeability

Before directional analysis, check:

settlement clarity
resolution-source reliability
liquidity and book quality
fees and likely slippage
spread, queue depth, and maker/taker asymmetry
stale-book or adverse-selection risk
risk of noise, manipulation, or wash trading

If the market is not clean enough to analyze, return NO TRADE.

5. Gather and grade evidence

Actively search:

official and primary sources
economic or regulatory releases
quality journalism and specialist reporting
market-native signals
expert social sources

Use references/evidence-engine.md for source tiers, timing-vs-direction evidence, archetype-specific standards, and conflict handling.

For smart-money or alert-bot evidence, inspect the wallet context before using the signal:

full current positions and recent activity
realized vs open PnL when available
whether this is a single-market fresh wallet
whether buys are offset by sells, opposing-leg exposure, or adjacent-bucket ladders
whether several alerts are actually the same wallet or a follower cascade
whether strong opposing wallets are taking the other side

Treat wallet alerts as market-native evidence, not as primary factual evidence about the real-world event.

6. Separate direction edge from timing edge

Before assigning a probability, split the thesis into:

probability the event happens at all
probability it happens within this contract window
probability the market resolves cleanly under the written rules
for disputed-resolution optionality, probability the side reprices before final settlement vs probability it actually wins final settlement

If the user's thesis is mostly "this probably happens eventually" but the contract requires a narrow deadline, treat that as a contract-selection warning, not as full support for the asked market.

7. Audit expression and bucket selection

Explicitly test:

is this the best expression of the thesis
is an adjacent bucket cleaner
are these markets actually the same event under the rules
do named actors, verbs, or scope changes make one contract strictly cleaner
is No on the earlier bucket better than Yes on the exact bucket
if the thesis is right but late, does this contract still pay
is the user accidentally paying for timing precision they do not possess

Use references/probability-and-kelly.md before pricing or sizing. If a nearby expression dominates the asked contract, say so clearly even if the asked market still has some edge.

8. Estimate probability and interval

Construct:

anchor probability
evidence adjustments
main probability
confidence interval

For resolution arbs, interpret these as resolution confidence rather than broad event probability.

Do not treat market price as literal truth.

8A. Run price-dynamics and microstructure diagnostics when relevant

Use this step when the prompt, data, scanner context, or market behavior raises a price-history or execution-quality question.

Read references/microstructure-models.md when using:

Markov chains or transition matrices
Monte Carlo simulations from price states
longshot-bias or price-band calibration
maker/taker execution analysis
scanner ranking based on spread, depth, volume, or price movement

Required posture:

Treat price-history output as a diagnostic signal, not as a direct probability verdict.
Report transition sample counts and model-validity status when using Markov-style evidence.
Mark the model invalid when state rows are sparse, the market had a structural break, the book is stale, or the exact expression lacks enough history.
Apply longshot and model-risk haircuts before Kelly.
Reject the trade if the only edge comes from a sparse transition matrix, a midpoint quote, a stale book, or a low-price Yes lottery pattern with no independent evidence.

9. Compute executable edge

Compare the conservative fair value implied by the interval against the best realistic executable price after:

CLOB V2 fees: read feesEnabled, feeSchedule, feeType, makerBaseFee, and takerBaseFee; maker orders may be free while taker fills pay match-time fees
spread
full-book slippage for the intended order size, not just best bid / best ask or half-spread approximation
tick size, minimum order size, and whether the market is accepting orders
execution uncertainty
maker queue risk
taker fee and spread tax
stale-quote and adverse-selection risk
timing-mismatch risk

For Polymarket, executable price means: simulate the intended fill through full CLOB depth, apply taker fee when crossing the book, respect tick/min-size constraints, then compare net entry against conservative fair value. If the edge only exists at midpoint or displayed last price, return NO TRADE.

If the recommendation is maker-only, say so explicitly and include the maximum entry price, fill-risk caveat, and the condition under which the trade becomes invalid rather than crossing the spread.

If edge disappears after costs and timing risk, return NO TRADE.

10. Check portfolio risk

Inspect:

overlap with existing positions
same-thesis duplication across markets
cross-platform duplication
thematic concentration
tail-risk concentration
same-calendar clustering
strategy-lane concentration against the user's proven strengths and weaknesses

If portfolio context is unavailable, apply the portfolio-blind haircut from references/probability-and-kelly.md and say so explicitly.

If the user has a calibrated style history, label the trade as one of:

core lane - matches repeatedly profitable categories or structures
adjacent lane - related but less proven
hazard lane - historically loss-prone, noisy, or easy to express in the wrong bucket
lottery lane - low-probability position whose main value is optionality, not evidence-backed edge

Use this label to adjust evidence bar, sizing, and kill criteria.

11. Size or structure conservatively

Apply Kelly only if the setup survives all earlier checks.

Use:

conservative interval boundary
net executable odds
uncertainty haircut
correlation haircut
liquidity haircut
drawdown haircut
time-precision haircut
longshot-bias haircut when low-price contracts or known price-band bias affects the side
price-model haircut when Markov, Monte Carlo, or other price-history diagnostics influence the case

If the best expression is a ladder or split structure rather than a single contract, recommend that instead of forcing a one-line answer.

When a user has a high-win-rate / low-payoff style, size to preserve that style:

Core lanes can receive normal conservative-Kelly sizing if the edge is independently verified.
Adjacent lanes require a strategy-fit haircut.
Hazard lanes should usually be observation size unless rule-level evidence is unusually strong.
Smart-money-only trades are observation size until the wallet signal is independently confirmed.
Lottery lanes should be capped at a small fixed loss the user is comfortable writing to zero.

If the user gives a current bankroll, use that explicit bankroll for concrete sizing. Do not infer bankroll from visible open positions or historical capital unless the user asks for that estimate.

Improving payoff ratio should usually mean cutting losers earlier and entering cleaner expressions, not buying lower-probability long shots.

12. Emit mode-specific final decision

Mode-specific verdict behavior:

Interactive Analysis Mode: Final verdict must be one of:
- TRADE
- NO TRADE No "maybe trade" verdict.
Runtime Judgment Mode: Do not emit TRADE / NO TRADE headings. Return only the JSON object required by references/runtime-judgment-contract.md, including degraded runtime JSON fallback when activation inputs are incomplete.

If the asked contract is inferior but a nearby expression is materially better, interactive mode may still return NO TRADE for the asked market while recommending the cleaner expression.

Output Format

Output is mode-specific:

Interactive Analysis Mode: use the eight-section markdown template below with a TRADE / NO TRADE verdict.
Runtime Judgment Mode: return one JSON object only, with required fields, enum values, and mapping rules from references/runtime-judgment-contract.md; do not output markdown headings or prose summary text. If activation inputs are incomplete under contract_version: "runtime.v1", return degraded runtime JSON fallback.

Interactive Analysis Mode

ALWAYS use this exact structure:

Use all eight numbered sections in order, even when the answer is short. Do not replace the template with custom headings. Do not start with a prose summary before section 1. Do not use bold summary headers as substitutes for the numbered template. If a field is unavailable, say not provided, unknown, or not assessable from prompt rather than omitting it. For every specific market or preferred expression you mention, include a direct market URL when it is available.

Before writing any substantive content, first emit the exact eight section headers in order and then fill them.

1. Verdict

TRADE or NO TRADE

2. Market Summary

platform
market title
market link
trade archetype
strategy-fit lane
expression / rule-scope differences
settlement rule
settlement time
executable price(s)
liquidity / fee notes
price-dynamics / microstructure notes

3. Probability Assessment

anchor probability
adjusted main probability
confidence interval
direction vs timing decomposition
longshot or price-model calibration applied
main uncertainty drivers

4. Evidence Review

decisive evidence
rule-scope differences
smart-money / wallet-signal quality
timing-specific evidence
directional evidence
conflicting evidence
discarded / noise evidence
source reliability notes

5. Mispricing / Edge

conservative fair value
executable value
best expression
worse expression(s)
if thesis is right but late
net edge after costs
maker/taker execution tax
model-validity constraints
why edge is or is not sufficient

6. Portfolio Impact

related existing positions
incremental thematic exposure
concentration / correlation concerns
strategy-fit concerns

7. Sizing

raw Kelly
conservative Kelly
style-calibrated cap
preferred structure / ladder
final recommended fraction
concrete size if bankroll is provided
maximum entry price / minimum required price

8. Kill Criteria

what invalidates the thesis
what removes the edge
what triggers reduction or exit
exit type

If the input is thematic and multiple candidate markets are discovered:

place a short ranked shortlist at the top of section 2 (Market Summary) before the primary market detail bullets
include the preferred expression for each surviving thesis
include a direct market link for each preferred expression in the shortlist
then provide full detailed reports only for markets that survive screening

Runtime Judgment Mode

Return exactly one JSON object that conforms to references/runtime-judgment-contract.md. Use references/runtime-judgment-contract.md as the source of truth for required fields, recommended fields, enum values, mapping rules, and any schema changes. Do not treat this skill file as a second schema definition.

Archetype-Specific Standards

Resolution Arb

Approve only if:

the real-world state is already effectively known
written rules still point the same way
oracle or resolution discretion is not the main risk
capital lock-up and tail risk are explicitly priced

Reject if the trade is merely "probably going to resolve that way soon" without enough rule-level certainty.

Disputed Resolution Optionality

Approve only as a small fixed-loss optionality trade if:

the market is already disputed, UMA-sensitive, or exposed to a live platform/oracle interpretation question
the side trades in an extreme low band, typically around 0.1c-2c, where a small repricing can create multi-x upside
there is a concrete non-zero path: ambiguous rule wording, unresolved dispute process, credible evidence conflict, official-source ambiguity, or plausible voter/platform reversal
there is enough executable depth to enter and enough expected attention/liquidity to exit before final adjudication
the recommendation names profit-taking levels, final exit timing, and max fixed loss

Reject or cap at tiny lottery size if:

the only reason is "it used to trade much higher" or "the payout is huge if it somehow wins"
UMA/oracle/platform process has already closed the non-zero path
the trade is really an attempt to average down a high-cost failed resolution arb
the user intends to hold through final settlement without separately proving resolution confidence

Default sizing is 0.5%-3% of bankroll at risk, rarely 3%-5% when liquidity is excellent and the catalyst is near. Never let this setup justify a 20%+ position while settlement ambiguity remains material.

Directional Event

Approve only if:

the evidence changes the event probability, not just the narrative tone
the asked contract is a clean expression of the thesis
a broader or cleaner adjacent market does not dominate it

Time-Bucket Trade

Approve only if:

the evidence speaks to timing, not only direction
the market deadline matches the cadence of the event
the user is not buying a narrow Yes on vague "soon" evidence

Short-dated Yes contracts need a higher bar than short-dated No contracts when timing precision is weak.

For geopolitical, military, diplomatic, or crisis markets, short-dated Yes needs an especially high bar because narrative tension often does not map cleanly to the contract clock or settlement verb. If the evidence is mostly "something may happen soon," prefer smaller sizing, later buckets, broader expressions, or short-dated No.

Cross-Bucket Structure

Approve only if:

the bucket comparison is internally coherent
material rule-scope differences are explicitly named
the edge survives after accounting for same-thesis correlation
the recommendation names which bucket, ladder, or expression is actually preferred

When rule-scope differences are material, the analysis must explicitly say this is not a pure time-bucket comparison.

Smart-Money Signal

Approve only if:

the signal wallet has a relevant track record or verifiable reason to be informed
the position is not merely a tiny probe relative to the wallet
the wallet is not obviously hedged, laddered across incompatible expressions, or already trimming
the signal maps to the exact settlement rule and deadline
independent real-world evidence supports the same side
the entry price after the alert still leaves conservative edge

Reject or cap at observation size if:

the wallet is new or only visible in this one market
several alerts are duplicates of the same wallet or copy-traders
the signal is large in absolute terms but not proven to be informed
strong opposing flow exists from similarly credible wallets
the thesis is mostly narrative tension rather than rule-level evidence

Refusal Rules

Return NO TRADE if any of the following is true:

No informational edge survives scrutiny.
Evidence conflict is too high to support a disciplined interval.
Net edge vanishes after fees, slippage, or execution assumptions.
Settlement ambiguity is material and the setup is being treated as resolution arb rather than explicitly capped disputed-resolution optionality.
Liquidity is too weak to trust the paper edge.
Portfolio concentration is too high.
The thesis may be right, but the asked contract is the wrong expression.
Timing evidence is too weak for the narrowness of the bucket.
Material rule-scope differences exist but have not been analyzed.
A smart-money signal cannot be validated beyond "a wallet bought this" and no independent edge remains.
The setup falls in a user-specific hazard lane and the requested size is larger than observation size.
Markov, transition-matrix, or price-path evidence is sparse, stale, structurally broken, or not tied to the exact contract expression.
A low-price longshot side has no independent evidence after longshot-bias and model-risk haircuts.
The trade is maker-only but adverse-selection, stale-book, or fill-risk conditions make passive entry unreliable.

Common Mistakes

Treating a large volume of low-quality evidence as strong conviction.
Treating market price as literal truth instead of one input.
Confusing "event probably happens" with "event happens inside this exact clock."
Treating contracts with different named actors or settlement verbs as if they were only different time buckets.
Paying for timing precision the evidence does not justify.
Evaluating a resolution arb like a normal prediction trade.
Treating factual truth as if it directly pays, while ignoring UMA, oracle, platform interpretation, or dispute mechanics.
Letting a high-price disputed-resolution arb failure mutate into emotional averaging-down instead of a separately sized low-price optionality trade.
Using the central estimate for Kelly sizing.
Ignoring existing correlated exposure across the same narrative cluster.
Calling theoretical edge a real edge when execution destroys it.
Treating a large wallet buy as an automatic trade without checking wallet history, hedges, ladders, or opposing flow.
Trying to raise payoff ratio by chasing long shots instead of reducing average loss and improving expression selection.
Letting a smart-money observation trade become a conviction trade without independent evidence.
Treating geopolitical short-window Yes contracts as core trades when the evidence only supports general tension or eventual risk.
Treating a Markov simulation or transition matrix as the final probability instead of a market-behavior diagnostic.
Ignoring longshot bias when buying cheap Yes contracts because the payoff looks attractive.
Calling an edge real when it disappears after maker/taker fees, queue risk, stale-book risk, or full-depth slippage.

References

Read references/evidence-engine.md when grading sources, separating timing from direction, or evaluating a resolution arb.
Read references/probability-and-kelly.md before generating intervals, choosing the best expression, pricing edge, or sizing a trade.
Read references/microstructure-models.md when the prompt involves Markov chains, transition matrices, longshot bias, price-path models, maker/taker execution, adverse selection, scanner ranking, or price-history diagnostics.
Read references/disputed-resolution-optionality.md when the prompt involves UMA disputes, platform/oracle interpretation risk, near-zero disputed markets, or buying 0.1c-2c optionality for a pre-final repricing exit.
Read references/domain-adapters.md when the market falls into politics/macro, crypto, or sports.
Read references/research-and-open-source.md when you need the research foundation or design rationale behind this skill.