@event4u/agent-config 5.6.1 → 5.7.0

package/.agent-src/commands/cost-report.md

@@ -56,15 +56,20 @@ profile recommendation per the table:
 |---|---|---|
 | 🟢 OK | < 50% | within budget — no action |
 | 🟡 INFO | ≥ 50% | log notification, no UX disruption |
-| 🟠 WARNING | ≥ 75% | suggest [`/set-cost-profile balanced→minimal`](set-cost-profile.md) |
-| 🔴 CRITICAL | ≥ 90% | recommend model downgrades, consider [`/set-cost-profile minimal`](set-cost-profile.md) |
+| 🟠 WARNING | ≥ 75% | suggest dropping the **model tier** — `model.auto_switch: auto`, or pick a lighter `model_tier` for routine work (the dominant spend lever) |
+| 🔴 CRITICAL | ≥ 90% | recommend a lighter model tier first; only as a last resort suggest [`/set-cost-profile minimal`](set-cost-profile.md) **with a capability-loss warning** |
 | 🛑 HARD_STOP | ≥ 100% | halt non-essential work; review before continuing (`budget.mjs check` exits 1) |
 
-If `level` ≥ WARNING and the current `cost_profile` in `.agent-settings.yml`
-is not already `minimal`, add an explicit suggestion sentence:
+**Lever order matters.** Per-turn spend is dominated by the **model** (a high→lite
+tier swap is roughly a 10× cost delta) and by query/response volume — not by how many
+rules load. `rule_loading_tier` loads its rule bodies roughly once per session (a small,
+fixed cost), so lowering it saves little and *reduces the agent's guardrail coverage*.
+Recommend the model lever first:
 
-> Run [`/set-cost-profile`](set-cost-profile.md) to switch from your
-> current profile to a leaner one.
+> Budget ≥ {level}. The biggest lever is the **model tier** — set
+> `model.auto_switch: auto` (or pick a lighter `model_tier` for routine turns).
+> Lowering `rule_loading_tier` saves far less and drops behavioural guardrails —
+> use [`/set-cost-profile minimal`](set-cost-profile.md) only as a last resort.
 
 ### 4. First-run: prompt to set a budget
 
@@ -109,7 +114,7 @@ Allowed values: `today`, `week`, `month`, `all` (default).
 
 ## See also
 
-- [`/set-cost-profile`](set-cost-profile.md) — change `cost_profile` in
+- [`/set-cost-profile`](set-cost-profile.md) — change `rule_loading_tier` in
   `.agent-settings.yml`.
 - [`/agent-status`](agent-status.md) — per-conversation token estimate
   (different scope: in-flight estimate, not historical actuals).

package/.agent-src/commands/prediction-pool.md

@@ -0,0 +1,215 @@
+---
+model_tier: inherit
+name: prediction-pool
+tier: 2
+description: "Fill a prediction pool (kicktipp, football/basketball WM): optimize expected points under the rules, enter tips via Playwright. Triggers 'Tippspiel', 'kicktipp', 'predict the pool'."
+skills: [prediction-pool-optimizer]
+suggestion:
+  eligible: true
+  trigger_description: "fill my Tippspiel, kicktipp tips, predict the pool, betting/prediction pool predictions, optimize my pool tips for an event"
+  trigger_context: "user wants tips for a prediction pool (kicktipp etc.) for an upcoming sports event and wants them computed and/or entered into the pool's web UI"
+workspaces:
+  - small-business
+packs:
+  - fun
+lifecycle: experimental
+trust:
+  level: experimental
+install:
+  default: false
+  removable: true
+---
+
+# /prediction-pool
+
+`/prediction-pool [<event>] [--pool-url <url>] [--council off|event|match] [--submit] [--fresh|--continue]`
+
+Fills out a **prediction pool** (kicktipp-style company pools: football
+WM, basketball WM, …) by optimizing for the **maximum expected points
+under the pool's actual scoring rules** — not for the most likely match
+outcome. Researches market odds, computes expected-value tips, presents a
+table for approval, then enters them into the pool's web UI via Playwright.
+
+The cognition lives in the [`prediction-pool-optimizer`](../skills/prediction-pool-optimizer/SKILL.md)
+skill (rules → market odds → expected value → participant field → tip).
+This command is the orchestrator: event selection, the persisted analysis,
+the optional AI-council pass, the Playwright entry, and the human gates.
+
+**Hard gates (always):**
+- **You log in.** The agent opens the page headful; it never reads,
+  stores, or types your credentials.
+- **The agent never submits.** It fills the candidate tips and stops —
+  *you* submit, unless you passed `--submit` (or say so this turn).
+- **Not betting or financial advice.** Decision support for a game; you
+  approve and submit.
+
+**Block on ambiguity:** an unresolvable event, a missing pool URL with no
+saved analysis, or contradictory flags (`--fresh` and `--continue`,
+`--council` value not in `off|event|match`) halts with a precise message —
+no silent best-guess.
+
+## Inputs
+
+| Input | Required | Meaning |
+|---|---|---|
+| `<event>` | no | The event to tip (e.g. "Football WM 2026"). Omitted → the command proposes 1–3 upcoming events + free input (Step 1). |
+| `--pool-url <url>` | once per event | The pool's tip page. Saved into the per-event analysis; reused on later runs. |
+| `--council off\|event\|match` | no | AI-council depth for the analysis. Default `off`; the command offers it at Step 4. `event` = one pass over the whole sheet; `match` = per-match (costlier). |
+| `--submit` | no | Pre-authorize the agent to submit after entry. Default: never submit. |
+| `--fresh` / `--continue` | no | Force a new analysis vs. build on the saved one (Step 2). Default: ask. |
+
+## Steps
+
+### 1. Resolve the event (block on ambiguity)
+
+- `<event>` supplied → use it; derive a slug (`football-wm-2026`).
+- **Omitted → propose, then stop and wait.** Name 1–3 *upcoming* events
+  (use the current date; research what is imminent) and offer free input:
+
+  ```
+  > Which event should I generate tips for?
+  >
+  > 1. <imminent event A>
+  > 2. <imminent event B>
+  > 3. <imminent event C>
+  > 4. Something else — name it
+  ```
+
+### 2. Resolve the per-event analysis (state ground-truth)
+
+Look for `agents/tmp/prediction-pool/<slug>.md`.
+
+- **None →** start a new analysis (created at Step 9, never before).
+- **Exists →** read it. Then:
+  - It was **edited externally** since the last run (mtime newer than the
+    last `## Run <ts>` header, or it no longer parses) → surface that and
+    ask **merge / overwrite / abort** — never silently overwrite manual edits.
+  - Otherwise ask **build on it** (`--continue`) or **start fresh**
+    (`--fresh`); the flags pre-answer this for non-interactive runs.
+
+The analysis holds the pool URL, the parsed rules, the current tip state,
+and standing notes — so re-tuning later is fast.
+
+### 3. Read the pool rules FIRST
+
+Resolve the pool URL (`--pool-url` → saved analysis → ask). Then run the
+optimizer skill's **rules pass** against the pool's rule page: exact result
+vs. goal-difference vs. tendency points, bonus questions, joker rules,
+quote/rarity scoring, special rules, deadlines, strategy limits. **No tips
+before the rules are understood** — the whole strategy depends on them.
+
+### 4. Run the optimizer + offer the AI-council pass
+
+Run [`prediction-pool-optimizer`](../skills/prediction-pool-optimizer/SKILL.md),
+adapted to the event's sport (football / basketball / …): market odds as
+the primary signal → expected value under the Step-3 rules → participant
+field → tip. Tournament/outright probabilities come from real outright
+odds **or** the skill's executed Poisson helper — **never** a hallucinated
+"I simulated 10,000 runs".
+
+**Offer the AI-council pass (default off).** Unless `--council` is set,
+ask once:
+
+```
+> Run the AI council over the analysis for a sharper second opinion?
+>
+> 1. No — use my analysis as is
+> 2. Yes, per event — one council pass over the whole tip sheet
+> 3. Yes, per match — each match judged separately (more accurate, costlier)
+```
+
+When on, run **graduated** to control cost: a cheap single-model pass
+flags the riskiest matches first, then the full council reviews only the
+flagged matches (`event`) or every match (`match`). Fold the council's
+verdicts back into the table before Step 5. Council spend always asks
+first per [`ai-council`](../../../core/.agent-src.uncondensed/skills/ai-council/SKILL.md).
+
+### 5. Output the approval table — ask whether & where to enter
+
+Present the tips exactly as they would be entered, then **wait**:
+
+| Match | Tip | Prob / EV | Risk | 1-line reason | Odds used |
+|---|---|---|---|---|---|
+
+Follow with group standings, the full bracket, and bonus-question answers
+where the event has them. Then ask **whether to enter** and **into which
+pool** (the saved URL, a different one, or none). Do **not** write the
+analysis yet (Step 9) — tips are not yet confirmed.
+
+### 6. Enter via Playwright (you log in)
+
+Open the pool page **headful**. **You log in yourself** — the agent waits
+and never touches credentials. Resolve the platform adapter:
+
+- **Known platform** (e.g. kicktipp) → load the declarative selector map
+  `scripts/prediction-pool/adapters/<platform>.yml` (field → CSS selector). The
+  generic, trusted driver fills the inputs from the map — the adapter is
+  **data, not code**.
+- **Unknown platform → vision-assisted synthesis.** Screenshot the page,
+  identify the tip inputs, **highlight them** and ask you to confirm the
+  mapping, then fill from the confirmed ephemeral map. No code is run from
+  an untrusted source.
+
+### 7. Stop before submit
+
+Fill the candidate results and **stop**. *You* press submit. The agent
+submits only if `--submit` was passed or you authorize it **this turn**
+(mirrors [`non-destructive-by-default`](../../../core/.agent-src.uncondensed/rules/non-destructive-by-default.md)).
+
+### 8. Offer a second pool
+
+Ask whether to also enter the same (or re-optimized) tips on another
+pool / site. If yes, loop Steps 3–7 for that pool.
+
+### 9. Persist / extend the analysis (only now)
+
+Append a run-stamped section to `agents/tmp/prediction-pool/<slug>.md`: pool
+URL(s), parsed rules, the entered tips with state `entered, not submitted`
+(or `submitted` if Step 7 submitted), council verdicts if any, and
+standing notes. Append-only — earlier runs stay as history. This is the
+base the next run reads (Step 2).
+
+### 10. New-platform adapter — offer to contribute (gated)
+
+If Step 6 synthesized a new selector map, offer to (a) save it locally and
+(b) open a **PR** adding `scripts/prediction-pool/adapters/<platform>.yml` so
+coverage grows for everyone. The PR carries **declarative selector data
+only** — never executable code — and only on explicit permission (no
+auto-commit, no auto-push).
+
+### 11. Report
+
+Print: event + slug, pool URL(s), rules summary, council depth used,
+matches tipped, entry result (`entered, not submitted` | `submitted`),
+adapter (`<platform>.yml` | `vision-synthesized` | `pr-offered`), analysis
+file path. No commit. No push.
+
+## Rules
+
+- **You log in; the agent never handles credentials.** Headful only.
+- **The agent never submits** unless `--submit` or this-turn authorization.
+- **Rules first.** No tips before the pool's scoring is parsed.
+- **No hallucinated simulation.** Outright odds or executed Poisson code —
+  never a claimed-but-unrun Monte-Carlo.
+- **Analysis is written only after tips are confirmed** (Step 9), never
+  before — and never silently over an externally edited file.
+- **Adapters are declarative data, not code.** Unknown platforms use the
+  ephemeral vision path; contributed adapters are selector maps via PR.
+- **AI council is opt-in, default off**, and always asks before spending.
+- **Not betting or financial advice.** A fun tool; you decide and submit.
+- **No commit, no push, no PR** without explicit permission (the adapter
+  PR offer is gated).
+- **Kill-switch.** Ships `lifecycle: experimental` · `install.default:
+  false`. Disable = remove the command + `prediction-pool-optimizer` skill, then
+  regenerate the projected tool trees.
+
+## See also
+
+- [`prediction-pool-optimizer`](../skills/prediction-pool-optimizer/SKILL.md) — the
+  rules → odds → EV → field → tip cognition.
+- [`scripts/prediction-pool/adapters/_schema.md`](../../../scripts/prediction-pool/adapters/_schema.md) —
+  the declarative adapter data contract (for PR contributions).
+- [`ai-council`](../../../core/.agent-src.uncondensed/skills/ai-council/SKILL.md) —
+  the optional second-opinion pass (Step 4).
+- [`playwright-architect`](../../../core/.agent-src.uncondensed/skills/playwright-architect/SKILL.md) —
+  browser-automation patterns for the entry step.

package/.agent-src/commands/set-cost-profile.md

@@ -2,7 +2,7 @@
 model_tier: inherit
 name: set-cost-profile
 tier: 1
-description: Change the cost_profile in .agent-settings.yml — shows each profile's meaning and applies the selection
+description: Change the rule_loading_tier in .agent-settings.yml — shows each profile's meaning and applies the selection
 skills: [file-editor]
 suggestion:
   eligible: false
@@ -17,7 +17,7 @@ packs:
 
 # /set-cost-profile
 
-Changes `cost_profile` in `.agent-settings.yml`. Four profiles are defined in
+Changes `rule_loading_tier` in `.agent-settings.yml`. Four profiles are defined in
 the [`agent-settings` template](../templates/agent-settings.md#cost-profiles):
 
 - `minimal` · `balanced` · `full` · `custom`
@@ -32,7 +32,7 @@ the [`agent-settings` template](../templates/agent-settings.md#cost-profiles):
   directly or ask the agent — the merge rules live in
   [`layered-settings`](../docs/guidelines/agent-infra/layered-settings.md#section-aware-merge-rules).
 - For role modes use [`/mode`](mode.md) — different concept (sets
-  `roles.active_role`, not `cost_profile`).
+  `roles.active_role`, not `rule_loading_tier`).
 
 ## Steps
 
@@ -49,7 +49,7 @@ Profile names are case-insensitive on input; the file value stays lowercase.
 Read `.agent-settings.yml`. If missing, tell the user to run
 `scripts/install` first and stop — do not create the file here.
 
-Extract the current `cost_profile` value.
+Extract the current `rule_loading_tier` value.
 
 ### 3. Load profile descriptions
 
@@ -63,7 +63,7 @@ Render the current value and present numbered choices with the hint text
 extracted in step 3:
 
 ```
-> Current: cost_profile = {current}
+> Current: rule_loading_tier = {current}
 >
 > 1. minimal — {hint from template}
 > 2. balanced — {hint from template}
@@ -77,7 +77,7 @@ value directly — still echo the old → new line in step 6.
 
 ### 5. Write the value
 
-Update `cost_profile` in `.agent-settings.yml` using the
+Update `rule_loading_tier` in `.agent-settings.yml` using the
 [section-aware merge rules](../docs/guidelines/agent-infra/layered-settings.md#section-aware-merge-rules)
 (preserve comments, preserve key order, touch only the changed field).
 
@@ -86,7 +86,7 @@ If the user picked "Keep current", do nothing and stop.
 ### 6. Confirm
 
 ```
-> cost_profile: {old} → {new}
+> rule_loading_tier: {old} → {new}
 ```
 
 If the new profile activates a surface the user hasn't used before
@@ -106,7 +106,7 @@ steps here, that's the docs' job.
 ## Cloud Behavior
 
 On cloud surfaces (Claude.ai Web, Skills API) this command is **fully inert** —
-there is no `.agent-settings.yml` to write and no `cost_profile` toggle to
+there is no `.agent-settings.yml` to write and no `rule_loading_tier` toggle to
 flip. Cost behaviour on those surfaces is governed by the platform itself.
 
 ## See also

package/.agent-src/commands/sync-agent-settings.md

@@ -41,7 +41,7 @@ Use when:
 
 ## When NOT to use
 
-- To change a value (`ide`, `cost_profile`, `max_parallel`) → edit the
+- To change a value (`ide`, `rule_loading_tier`, `max_parallel`) → edit the
   file directly or ask the agent; the sync only reconciles structure.
 - To create `.agent-project-settings.yml` (team file) → that is a
   separate concern; this command only touches the developer file.
@@ -95,7 +95,7 @@ Free-text replies (`"nö"`, `"leave it"`, unrecognized input) count as
 
 ### 4. Profile override
 
-The script auto-detects the profile from the target's `cost_profile`
+The script auto-detects the profile from the target's `rule_loading_tier`
 key and falls back to `minimal`. To sync against a different profile
 (e.g. during a profile change), pass `--profile balanced` or
 `--profile full` — but ask the user first; changing the profile is a

package/.agent-src/presets/README.md

@@ -4,7 +4,7 @@ Seed presets for the [preset system](../../docs/contracts/config-presets.md).
 Each preset bundles governance knobs (autonomy / confidence / risk /
 council / mcp / cost / notifications) so the user picks a stance, not
 a dozen individual values. Boundary against `profile.id`, `pack.id`,
-and `cost_profile` lives in
+and `rule_loading_tier` lives in
 [ADR-010](../../docs/decisions/ADR-010-profile-pack-preset-boundary.md).
 
 ## Seed set (v2.x — fixed)

package/.agent-src/profiles/README.md

@@ -4,7 +4,7 @@ Seed profiles for the [profile system](../../docs/contracts/profile-system.md).
 Each profile answers *who is the user?* — audience identity that
 selects the default skill/command surface, README entry-paragraph,
 and persona pre-selection. Boundary against `preset.id`, `pack.id`,
-and `cost_profile` lives in
+and `rule_loading_tier` lives in
 [ADR-010](../../docs/decisions/ADR-010-profile-pack-preset-boundary.md).
 
 ## Seed set (v2.x — fixed)

package/.agent-src/rules/non-destructive-by-default.md

@@ -1,7 +1,7 @@
 ---
 type: "always"
 tier: "safety-floor"
-description: "Agent is never destructive — Hard Floor always asks for prod-trunk merges, deploys, pushes, prod data/infra, bulk deletions, and bulk-deletion/infra commits; no autonomy or roadmap bypass"
+description: "Hard Floor: agent asks before prod-trunk commits/merges, deploys, pushes, prod data/infra, bulk deletions/infra commits; verify branch before each commit; no autonomy or roadmap bypass"
 alwaysApply: true
 load_context:
   - ../contexts/authority/destructive-mechanics.md
@@ -28,6 +28,7 @@ Triggers below require explicit user confirmation **on this turn** — not from
 | Trigger | Examples |
 |---|---|
 | **Production-branch merge** | `main`, `master`, `prod`, `production`, `release/*`, or any branch the project marks as deployment trunk |
+| **Commit on a production branch** | any `git commit` while `HEAD` is on a prod trunk (set above). **Verify branch before every commit** — `main` is opt-in only, never inferred from a prior turn or a merged PR that left the repo on `main` |
 | **Deploy / release** | `terraform apply` on prod, `kubectl apply` on prod, deploy scripts, release commands, tag pushes that trigger CI deployment |
 | **Push to remote** | any `git push` (also covered by [`scope-control`](scope-control.md), restated so the floor never weakens) |
 | **Production data / infra** | prod DB writes / migrations, prod config, secrets rotation, IAM / role / policy, DNS, anything in a `prod`-scoped path or pipeline |

package/.agent-src/skills/prediction-pool-optimizer/SKILL.md

@@ -0,0 +1,196 @@
+---
+model_tier: high
+name: prediction-pool-optimizer
+description: "Optimize prediction-pool tips (kicktipp etc.): pool rules + market odds → the expected-points-maximizing tip per match. Triggers 'optimize my pool tips', 'best kicktipp picks', 'predict'."
+domain: product
+personas: []
+workspaces:
+  - small-business
+packs:
+  - fun
+lifecycle: experimental
+trust:
+  level: experimental
+install:
+  default: false
+  removable: true
+---
+
+# prediction-pool-optimizer
+
+> Turn a prediction pool's **scoring rules** plus **market odds** into the
+> tip that maximizes **expected points** — not the most likely outcome.
+> Sport-agnostic core with per-sport probability blocks. Consumed by
+> [`/prediction-pool`](../../commands/prediction-pool.md). The optimization target is
+> the pool's score, so the chain is always **rules → odds → expected value
+> → participant field → tip**, never "who wins this match?".
+
+## When to use
+
+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`](../../commands/prediction-pool.md) 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.**
+
+## Hard rules
+
+- **Rules before tips.** Never produce a tip before the pool's scoring is
+  parsed (Procedure step 1). Strategy is a function of the rules.
+- **Odds are the primary signal.** Bookmaker / market probabilities already
+  fold in form, squad, injuries, travel, climate. Use them as the
+  calibration base; only override with *current* information (confirmed
+  lineups, late injuries, suspensions, manager change).
+- **No invented numbers.** Emit no probability you cannot derive from odds
+  or from **actually executed** code. Tournament/outright numbers come from
+  real outright odds **or** the executed Poisson helper — never a claimed
+  "I ran 10,000 simulations".
+- **One-sentence justification** per tip. Short.
+
+## Procedure
+
+### 1. Parse the pool rules
+
+From the pool's rule page, extract and document:
+
+- Points for **exact result** / **goal (point) difference** / **tendency**.
+- **Bonus questions** (champion, top scorer, group winners …).
+- **Joker / multiplier** rules.
+- **Quote / rarity** scoring (rare correct tips score more)? — flips the
+  whole strategy toward contrarian (step 4).
+- Special scorings, **deadlines**, and **strategy limits** (e.g. max N
+  identical tips).
+- **The goal**: place well, or *win* a large pool? (changes variance — step 4.)
+
+### 2. Build the data base
+
+Primary: current bookmaker odds, aggregated market probabilities, model
+forecasts (e.g. Opta), Elo/SPI ratings. Secondary (only when it adds signal
+the odds have not yet absorbed): confirmed lineups, injuries, suspensions,
+manager change, recent form, home advantage, head-to-head, rest/travel,
+weather. De-vig the odds (remove the bookmaker margin) before treating them
+as probabilities.
+
+### 3. Per-match probabilities (sport block)
+
+Compute, per match, the outcome distribution and the most plausible exact
+results. Pick the block for the event's sport:
+
+**Football / soccer**
+- Model goals as **Poisson** per side from each team's expected goals;
+  draws are real (~22–28% baseline) — people under-tip them.
+- Outcome split: home-win / draw / away-win; then the exact-score grid.
+- Common EV-strong exact results: 1:0, 2:1, 1:1, 2:0.
+
+**Basketball**
+- **No draws.** Model the points margin as roughly **Gaussian** around the
+  market spread; pair with the moneyline for win probability and the
+  total (over/under) for the score level.
+- Tendency = sign of (margin); "exact result" rules are rare — read step 1.
+
+**Generic fallback (other sports)**
+- Derive the outcome split straight from de-vigged moneyline odds; estimate
+  a plausible score from the market total. State the model used.
+
+Cross-check the model against the market; on a large divergence, re-check
+the data and explain the cause before trusting it.
+
+### 4. Convert to the EV-maximizing tip
+
+Map probabilities to the tip with the **highest expected points under the
+step-1 rules** — not the prettiest match.
+
+- **Standard fixed-point scoring + goal "place well"** → tip the EV-maximal
+  result per match. Favourites with modest scorelines dominate. **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.
+- **Goal = win a large pool** → on a *subset* of matches, take calculated
+  variance (plausible underdogs) to create upside, poker-tournament style.
+
+**Participant-field thresholds** (when two tips are close, prefer the one
+with the higher edge over the typical participant):
+
+- Pool **N < 20** → maximize EV, ignore the field.
+- **20 ≤ N < 100 and you are in the prize positions** → maximize EV.
+- **N ≥ 100, or you are outside the top ~20%** → add field-relative
+  variance (move off the consensus on a subset; rough Kelly-fraction sizing).
+
+Respect all strategy limits from step 1 (max identical tips, etc.).
+
+### 5. Tournament & bonus questions (no hallucination)
+
+For group winners, KO rounds, champion, and bonus questions, use **either**:
+
+- real **outright market odds** ("to win group", "to reach final",
+  "outright winner"), **or**
+- the executed Poisson tournament simulator:
+
+  ```bash
+  python3 scripts/prediction-pool/poisson_sim.py <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.**
+
+Optimize bonus answers on the same expected-points basis. Re-run as late as
+the deadline allows: re-check confirmed lineups, injuries, suspensions, and
+odds movement, then adjust. The pool's per-match deadline is the only hard
+constraint.
+
+## Output format
+
+1. **Approval table** — one row per match:
+
+   ```
+   Match | Tip | Prob / EV | Risk (low/med/high) | 1-line reason | Odds used
+   ```
+
+2. **Group standings, the full bracket, and bonus-question answers** where
+   the event has them.
+3. **Self-check note** — confirm the tips reconcile with
+   [`reference/ev-fixtures.md`](reference/ev-fixtures.md) (known pool rules +
+   market odds → a known-good EV tip). If your method disagrees with a
+   fixture, your method is wrong — find the error (usually a forgotten
+   partial-points term or un-de-vigged odds), don't ship the tip.
+
+Handed back to [`/prediction-pool`](../../commands/prediction-pool.md) for the approval
+gate — the skill never enters or submits anything.
+
+## Gotcha
+
+- **Tipping the modal result, not the EV-maximal one.** The single most
+  likely scoreline rarely maximizes partial points — compute EV across the
+  result grid, don't eyeball the favourite.
+- **Forgetting to de-vig.** Raw bookmaker odds sum to >100%; treating them
+  as probabilities inflates the favourite. Remove the margin first.
+- **Contrarian under fixed points.** Deviating "to stand out" only helps
+  under quote/rarity rules or a win-a-large-pool goal — otherwise it burns EV.
+- **Claimed-but-unrun simulation.** Numbers like "I ran 10,000 tournaments"
+  without executing `poisson_sim.py` are hallucinated — run the code or use
+  outright odds.
+
+## Do NOT
+
+- Tip the most likely result instead of the EV-maximal one.
+- Go contrarian under standard fixed-point scoring with a "place well" goal.
+- Report Monte-Carlo numbers without running `poisson_sim.py`.
+- Treat raw odds as probabilities without removing the vig.
+- Give betting or financial advice — this optimizes a game; the human submits.
+
+## See also
+
+- [`/prediction-pool`](../../commands/prediction-pool.md) — the orchestrator (event,
+  persistence, Playwright entry, gates).
+- [`reference/ev-fixtures.md`](reference/ev-fixtures.md) — known-good
+  rules+odds → EV examples.
+- [`scripts/prediction-pool/poisson_sim.py`](../../../../scripts/prediction-pool/poisson_sim.py) —
+  the executed tournament simulator.

package/.agent-src/skills/prediction-pool-optimizer/evals/triggers.json

@@ -0,0 +1,18 @@
+{
+  "skill": "prediction-pool-optimizer",
+  "description": "7 should-trigger + 5 should-not-trigger queries. Should-trigger covers DE + EN phrasings and the core intent (pool tips, kicktipp, expected-points optimization across sports). Should-not-trigger covers near-miss neighbours: regulated financial advice (finance pack), plain match-result prediction with no pool, generic web research, AI video, and real-money sportsbook betting (out of scope / refuse).",
+  "queries": [
+    {"q": "optimize my kicktipp tips for the football WM 2026", "trigger": true},
+    {"q": "fill my company Tippspiel for the basketball world cup", "trigger": true},
+    {"q": "welche Tipps maximieren meine Punkte im kicktipp-Tippspiel?", "trigger": true},
+    {"q": "best picks for our office prediction pool given the scoring rules", "trigger": true},
+    {"q": "maximiere meine erwarteten Punkte im Tippspiel, nicht nur wer gewinnt", "trigger": true},
+    {"q": "predict our office kicktipp pool for the WM", "trigger": true},
+    {"q": "mach mein Tippspiel für die WM", "trigger": true},
+    {"q": "should we invest in this startup based on a DCF?", "trigger": false, "note": "regulated financial valuation → dcf-modeling / finance pack"},
+    {"q": "who will win tonight's match?", "trigger": false, "note": "plain result prediction, no pool / no scoring rules to optimize"},
+    {"q": "research the best running shoes for me", "trigger": false, "note": "generic web research → research / deep-research"},
+    {"q": "make a hype video for the world cup final", "trigger": false, "note": "AI video pipeline → /video"},
+    {"q": "place a €50 bet on the favourite at my bookmaker", "trigger": false, "note": "real-money sportsbook wagering — out of scope, not what this fun pool tool does"}
+  ]
+}