Use when reviewing UI for accessibility — WCAG 2.2 AA, keyboard nav, focus, ARIA, contrast, screen-reader semantics — even on 'is this a11y-OK?' or 'mach das barrierefrei'.
The English summary is being prepared. Showing the original description.
Optimize prediction-pool tips (kicktipp etc.): rules + multi-book consensus odds → expected-points-max answer for every question, scores AND bonus. Triggers 'optimize my pool tips', 'predict'.
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
Turn a prediction pool's scoring rules plus a consensus of the major bookmakers' odds into the answer that maximizes expected points — not the most likely outcome — for every open question in the pool: match scores AND every bonus / award / special question (top scorer, group winners, champion, most cards …). Sport-agnostic core with per-sport probability blocks. Consumed by
/prediction-pool. The optimization target is the pool's score, so the chain is always rules → odds → expected value → participant field → answer, never "who wins this match?".
Use when someone wants the best tips for a prediction / betting pool
(kicktipp-style company pools — football WM, basketball WM, …) and the
target is pool points, not match truth. Triggered by the
/prediction-pool command (Steps 3–5) or directly
when a user asks to optimize / maximize their pool picks.
The one idea that makes this skill correct: the highest-probability result is not the highest-expected-value tip. Under most pool rules a 2:1 or 1:0 scores the same partial points as the "obvious" pick but hits more often; under quote/rarity rules a rare-but-plausible result is worth more. Always optimize the pool's points, never the truth of the match.
score_ev.ts, step 4a), never the eye. A
3:2 / 4:1 / 1:4 in the output is the signature of a skipped computation.From the pool's rule page, extract and document:
Primary signal: current bookmaker odds, but aggregated across the 5–10 biggest publicly-viewable books, not a single portal:
references/odds-and-bonus.md.Secondary (only when it adds signal the consensus has not yet absorbed): confirmed lineups, injuries, suspensions, manager change, recent form, home advantage, head-to-head, rest/travel, weather, model forecasts (Opta), Elo/SPI ratings.
Compute, per match, the outcome distribution and the most plausible exact results. Pick the block for the event's sport:
Football / soccer
Basketball
Generic fallback (other sports)
Cross-check the model against the consensus; on a large divergence, re-check the data and explain the cause before trusting it.
Map probabilities to the tip with the highest expected points under the step-1 rules — not the prettiest match.
Do not hand-pick a scoreline. Run the executed grid optimiser — it builds the full Poisson score grid and returns the expected-points-max tip under the step-1 point tiers:
npx tsx node_modules/@event4u/agent-config/src/scripts/prediction-pool/score_ev.ts --lh <home-xg> --la <away-xg> \
--tendency <t> --diff <d> --exact <e> # one match
npx tsx node_modules/@event4u/agent-config/src/scripts/prediction-pool/score_ev.ts matches.json \
--tendency <t> --diff <d> --exact <e> # batch, prints a ranked table
Two facts the grid makes unavoidable — and intuition gets wrong:
High scorelines are almost never EV-max. Under any partial-points rule a moderate favourite peaks at 1:0 / 2:0 / 2:1; 1:0 wins surprisingly often, and the top of the EV surface is flat (1:0 vs 2:1 vs 2:0 separated by hundredths). A 3:2 / 4:1 / 1:4 tip is never the optimum — if a tip like that appears, the grid was not run.
Draws are under-tipped. A correctly-tipped draw banks the goal-difference tier on every draw scoreline, so in a close match (xG within ~0.4) a 1:1 can out-score a 1:0. The grid surfaces this; the eye does not. People tip too few draws — let the computation, not the gut, decide.
Standard fixed-point scoring + goal "place well" → tip the grid's EV-max per match. No contrarian — only your tip matters for your score, so deliberately tipping "different" just burns EV.
Quote / rarity scoring → weigh rarer-but-plausible results against their
higher payout; take rarity when payout × probability wins (raise --exact
weight or post-process the ranked table by the multiplier).
When the goal is to win a large pool (not place), the target flips from E(points) to P(finish ahead of the whole field) — and pure EV-max converges with the crowd, so it cannot open a gap. Measure it with the executed field simulator instead of a "rough Kelly" hand-wave:
npx tsx node_modules/@event4u/agent-config/src/scripts/prediction-pool/pool_winsim.ts pool.json --runs 4000 --max-flips 4
It models the field as softmax-EV tippers, reports P(win) for the
EV-max-everywhere baseline, then greedily reports which few tips to flip
off EV-max (and the EV cost + P(win) gain of each). Read the output as the
field threshold, empirically:
Respect all strategy limits from step 1 (max identical tips, etc.).
Walk the step-1 checklist and answer each entry. Pick the method by
question type — full taxonomy + per-type method in
references/odds-and-bonus.md:
Tournament structure (group winners, KO rounds, finalists, champion): use real outright market odds ("to win group", "to reach final", "outright winner") aggregated per step 2, or the executed Poisson tournament simulator:
npx tsx node_modules/@event4u/agent-config/src/scripts/prediction-pool/poisson_sim.ts <teams-xg.json> --runs 20000
It plays the bracket from per-team expected goals and prints empirical advancement / title probabilities. Run it — never report simulated numbers you did not actually compute.
Award / player markets (top scorer, most assists, "which team supplies the top scorer", golden boot, most cards): use the matching special market — e.g. aggregate per-player "top goalscorer" odds by team to answer "which team has the top scorer". Where no clean market exists, derive from a stated model (e.g. squad strength × games-expected) and label it as a model estimate, not a market number.
Binary / over-under specials (will there be a red card, over/under total goals/cards): take the de-vigged consensus probability for the line and pick the EV-max side under the question's point weight.
Optimize every answer on the same expected-points basis as the scores. Re-run as late as each question's deadline allows: re-check confirmed lineups, injuries, suspensions, and odds movement, then adjust. The per-question deadline is the only hard constraint.
Approval table — one row per match:
Match | Tip | Prob / EV | Risk (low/med/high) | 1-line reason | Books used
Books used names the consensus base (e.g. "consensus of 7 books, sharp-weighted").
Bonus & special answers — one row per open question from the step-1 checklist, every entry answered (none left blank):
Question | Answer | Prob / EV | Risk | 1-line reason | Source (market / model)
Group standings and the full bracket where the event has them.
Self-check note — (a) confirm the tips reconcile with
references/ev-fixtures.md (known pool rules +
market odds → a known-good EV tip); (b) confirm the bonus table has the
same number of rows as the step-1 checklist — a shorter table means a
question was dropped. If your method disagrees with a fixture, your method
is wrong — find the error (usually a forgotten partial-points term,
un-de-vigged odds, or following one book instead of the consensus), don't
ship the tip.
Handed back to /prediction-pool for the approval
gate — the skill never enters or submits anything.
score_ev.ts across
the result grid, don't eyeball the favourite.score_ev.ts.pool_winsim.ts; it returns the exact flips that raise P(finish 1st)
most per unit of EV given up.poisson_sim.ts are hallucinated — run the code or use
outright odds.score_ev.ts — and never emit a
3:2 / 4:1 / 1:4 tip, which is never EV-max under partial points.pool_winsim.ts.poisson_sim.ts / pool_winsim.ts./prediction-pool — the orchestrator (event,
persistence, Playwright entry, gates).references/odds-and-bonus.md — the major-book
list + sharpness-weighted consensus recipe, and the bonus / award / special
question taxonomy with a per-type method.references/ev-fixtures.md — known-good
rules+odds → EV examples.node_modules/@event4u/agent-config/src/scripts/prediction-pool/score_ev.ts —
the executed exact-score EV optimiser (step 4a; λ + rule → EV-max scoreline).node_modules/@event4u/agent-config/src/scripts/prediction-pool/pool_winsim.ts —
the executed field model + P(finish 1st) simulator and flip-finder (step 4b).node_modules/@event4u/agent-config/src/scripts/prediction-pool/poisson_sim.ts —
the executed tournament simulator (step 5).No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Use when reviewing UI for accessibility — WCAG 2.2 AA, keyboard nav, focus, ARIA, contrast, screen-reader semantics — even on 'is this a11y-OK?' or 'mach das barrierefrei'.
The English summary is being prepared. Showing the original description.
Use when defining or auditing the activation event — aha-moment selection, retention correlation, falsifiable definition. Triggers on 'what is our aha moment', 'redefine activation'.
The English summary is being prepared. Showing the original description.
Use when capturing an architectural decision — file naming, next ADR number, Status / Context / Decision / Consequences, index regen; fires even without saying 'ADR'.
The English summary is being prepared. Showing the original description.
Adversarial critique — devil's advocate, stress-test, honest teardown ('poke holes', 'be brutal', 'was hältst du davon'); explicit request only. Routine code or design review → code-review.
The English summary is being prepared. Showing the original description.
Use when reading, creating, or updating agent documentation, module docs, roadmaps, or AGENTS.md. Understands the full .augment/, agents/, and copilot-instructions structure.
The English summary is being prepared. Showing the original description.
Use for an adversarial red-team / blue-team / auditor review of an AI agent's CONFIG + behaviour (rules, skills, MCP, hooks, permissions) — attack-chain → defensive-gap list, not a code audit.
The English summary is being prepared. Showing the original description.