@event4u/agent-config 5.10.0 → 6.0.0

package/dist/agent-src/commands/pr/create/description-only.md

@@ -0,0 +1,161 @@
+---
+model_tier: medium
+name: git-pr-create-description-only
+pack: git
+replaces: [create-pr-description-only, create-pr:description-only]
+tier: 2
+cluster: git-pr-create
+sub: description-only
+skills: [git-workflow]
+description: Generate a PR description as a copyable markdown block — used standalone or by create-pr
+suggestion:
+  eligible: true
+  trigger_description: "write a PR description, draft the PR text"
+  trigger_context: "PR exists or branch ready for review without description"
+workspaces:
+  - agent-config-maintainer
+packs:
+  - git
+---
+
+# /create-pr:description-only
+
+> **Carve-out:** this command's *purpose* is the copyable preview of
+> the PR description. It therefore **ignores**
+> `verbosity.preview_artifacts` and `commands.create_pr.preview_description`
+> — both flags govern only the bare `/create-pr` flow's preview-and-
+> adjust loop. Removing the preview here would make the command a
+> no-op. Do not "fix" this; the suppression flags only apply when the
+> PR is actually being created.
+
+## Input
+
+The user may or may not provide a PR URL or branch name.
+
+## Instructions
+
+### 1. Detect PR / Branch
+
+1. If the user provides a GitHub PR URL → use that PR to get the changed files via API.
+2. If no URL → **auto-detect:**
+   - Get current branch (`git branch --show-current`).
+   - Search for an open PR on that branch via GitHub API
+     (`GET /repos/{owner}/{repo}/pulls?head={owner}:{branch}&state=open`).
+   - If exactly one PR found → use it (get files via `/pulls/{number}/files`).
+   - If no PR found → use `git diff origin/{default}..HEAD --stat` for the branch diff.
+3. **Never** reuse a PR number from earlier in the conversation.
+
+### 2. Gather context — **one parallel tool-call block**
+
+The four primary fetches below are **independent** and **must** be
+dispatched in a single parallel tool-call block, not serially. Serial
+reads here add 3+ round-trips per PR for zero benefit.
+
+```
+parallel:
+  1. Jira API           — GET /issue/{ticketId}   (skip when no ticket ID)
+  2. git diff           — git diff origin/{default}..HEAD --stat
+  3. git log            — git log origin/{default}..HEAD --format="%s"
+  4. view PR template   — .github/pull_request_template.md
+```
+
+After the block returns:
+
+- **Jira ticket**: ticket ID is extracted from the branch name
+  (e.g. `fix/DEV-4673-description` → `DEV-4673`) **before** the
+  parallel block. No ticket → skip fetch 1 silently; ask the user
+  for a number only after the block, and only if needed.
+- **PR template missing** → fall back to the structure in § 4.
+- **Read key changed files** (migrations, new classes, modified
+  services, route/config changes) — second parallel block, keyed
+  off the diff summary. Group all file reads in one block.
+- **Check roadmap/agent docs** that describe the feature intent
+  (if they exist) — fold into the second block.
+
+Anti-pattern (do **not** do this):
+
+```
+turn 1: fetch Jira
+turn 2: git diff
+turn 3: git log
+turn 4: view template
+turn 5: view file A
+turn 6: view file B
+```
+
+That's 6 round-trips for what should be 2.
+
+### 3. Build the PR title
+
+- Format: `{TICKET-ID}: {summary}` (e.g. `DEV-4673: Fix absence working time calculation`).
+- Use the Jira ticket summary if available, otherwise derive from commits.
+- If no ticket: use the most descriptive commit message or ask the user.
+
+### 4. Build the PR body
+
+**ALWAYS** use the PR template (`.github/pull_request_template.md`). Fill in its sections:
+
+- **Jira badge**: Replace `{TICKET-NUMBER}` with the actual ticket ID.
+- **Description**: Summarize the changes in 2-5 sentences. Explain *what* changed and *why*.
+  Use the Jira ticket description and commit messages as input.
+- **Type of change**: Check the appropriate checkbox(es) based on the changes.
+- **Checklist**: Leave as-is (the developer fills this in).
+- **Links**: Replace `{TICKET-NUMBER}` with the actual ticket ID.
+- **Screenshots**: Leave as `...` unless the user provides screenshots.
+
+If no PR template exists, use this structure:
+
+```markdown
+## Jira
+[{TICKET-ID}]({JIRA_BASE_URL}/browse/{TICKET-ID})
+
+## Changes
+- Bullet list of what was changed and why
+
+### Migrations
+- List new/changed migrations (if any)
+
+### Tests
+- List new/changed tests (if any)
+
+## How to test
+- Steps to verify the changes
+```
+
+### 5. Present as copyable block
+
+Show the **title** and **body** separately, each in a fenced code block so the user can copy them:
+
+```
+📋 PR Title:
+```
+{title}
+```
+
+📋 PR Body:
+```markdown
+{body}
+```
+```
+
+### 6. Ask for feedback
+
+Ask with numbered options:
+
+```
+> 1. Looks good — done
+> 2. Adjust — I'll tell you what to change
+```
+
+
+### Rules
+
+- **All output in the user's language** — but the PR body itself is in **English**.
+- **Always show the result before any further action** — never create a PR directly from this command.
+- **Always use the PR template** — read `.github/pull_request_template.md` and fill its sections. NEVER invent a custom structure.
+- **Be concise** in the description — no filler text, no restating the ticket title as a sentence.
+- **Group related changes** in the description — don't list every file, list logical changes.
+- **Mark breaking changes** clearly if the diff shows API contract changes (new/removed fields,
+  changed endpoints, changed response structure).
+- **Mention file/class names** where helpful, but don't list every single file.
+- **Highlight things reviewers should pay attention to** — complex logic, edge cases, trade-offs.

package/dist/agent-src/commands/pr/create.md

@@ -0,0 +1,254 @@
+---
+model_tier: medium
+name: git-pr-create
+disable-model-invocation: true
+pack: git
+intent: "Open a pull request with a generated description and stripped attribution footers"
+routes_to: [git-workflow]
+replaces: [create-pr]
+tier: 1
+cluster: git-pr-create
+skills: [git-workflow]
+description: Create a GitHub PR with structured description from Jira ticket and code changes
+suggestion:
+  eligible: true
+  trigger_description: "open a PR, create a pull request, make a PR for this branch"
+  trigger_context: "branch is ahead of base and not yet on a PR"
+workspaces:
+  - agent-config-maintainer
+packs:
+  - git
+---
+
+# /git-pr-create
+
+Top-level entry point for the `/create-pr` family. Bare `/create-pr`
+runs the full create-PR flow described below. The `:description-only`
+sub-command produces a copyable PR description without creating the PR.
+
+## Sub-commands
+
+| Sub-command | Routes to | Purpose |
+|---|---|---|
+| `/create-pr` (bare) | this file (`## Default flow`) | Full flow — generate description, push, create PR |
+| `/create-pr:description-only` | `commands/pr/create/description-only.md` | Generate the PR description as a copyable markdown block, no PR creation |
+
+## Dispatch
+
+1. Parse the user's argument: `/create-pr[:<sub>] [args]`.
+2. Bare `/create-pr` → run the `## Default flow` below verbatim.
+3. `/create-pr:description-only` → load
+   `commands/pr/create/description-only.md` and follow its
+   `## Instructions` section verbatim.
+4. Unknown sub-command → print the table above and ask which one.
+
+## Default flow
+
+Uses `/create-pr:description-only` to generate the PR content, then creates the PR via GitHub API.
+
+### 1. Check prerequisites
+
+- Verify the current branch is NOT the default branch (`main` / `master`).
+- Run `git status` — warn if there are uncommitted changes.
+- Run `git log origin/{default}..HEAD --oneline` to verify there are commits to push.
+- If the branch has not been pushed yet, ask the user (in their language) whether to push.
+
+### 1b. Freshness gate — MANDATORY before opening any PR
+
+The branch may have diverged from its target base while you were
+working. A PR opened against a stale base creates merge conflicts the
+moment another PR lands first — the exact failure that motivates this
+gate.
+
+Run, in order:
+
+1. `git fetch origin {target-base} --quiet` (default: `main`).
+2. `git rev-list --count HEAD..origin/{target-base}` — number of
+   commits HEAD is **behind** the base.
+3. `gh pr list --state open --base {target-base} --limit 20 --json number,headRefName,files`
+   — open PRs targeting the same base.
+
+**Decision matrix:**
+
+| Behind | Overlapping open PR touches same files? | Action |
+|---|---|---|
+| `0` | — | Proceed to Step 2 |
+| `1–N` | No | Surface the count, ask: rebase / merge-main / proceed-anyway / cancel |
+| `1–N` | **Yes** | STOP — surface the overlapping PR number, ask: stack on top of it / wait for it to land / proceed-anyway-and-accept-conflicts / cancel |
+
+Never improvise the base or silently proceed when the branch is behind
+and overlap exists. The 10-second fetch beats hours of rebase
+reconciliation after the parent PR lands.
+
+### 2. Generate PR content
+
+Run `/create-pr:description-only` Steps 1–4 to generate the PR title and body.
+This handles: Jira ticket extraction, diff analysis, commit messages, **PR template filling**.
+
+**CRITICAL**: The PR body MUST use the project's PR template (`.github/pull_request_template.md`).
+Read the template file and fill in its sections. If the template does not exist, use the
+fallback structure defined in `/create-pr:description-only`. NEVER invent a custom body structure.
+
+**Preview gate** — read `commands.create_pr.preview_description` from
+`.agent-settings.yml` (default `false` when unset):
+
+- `false` (default): skip Steps 5–6 of `/create-pr:description-only` (the
+  copyable preview block + adjust loop). Use the generated title and body
+  directly in Step 3 below. This saves agent tokens by avoiding a full
+  re-render of the description in chat. The user can still edit the PR
+  body in the GitHub UI after creation.
+- `true`: run Steps 5–6 of `/create-pr:description-only` — present the
+  title and body as copyable blocks and ask for adjustments before
+  proceeding. The user reviews and adjusts the content in that step.
+
+### 2b. Council review — explicitly excluded
+
+`/create-pr` does **not** prompt for council review, even when
+`ai_council.enabled: true`. Invoking the PR command is an explicit
+delivery action; interrupting it with a billable opt-in question is
+out of scope.
+
+Users who want a council pass on the diff run `/council diff:<base>..<head>`
+**before** `/create-pr`. Do not re-add the prompt here without an explicit
+user request.
+
+### 3. Create the PR (draft-vs-ready, verbosity-gated)
+
+- **Head branch**: EXACT output of `git branch --show-current` from step 1.
+- **Base branch**: default branch (`main` / `master`).
+
+**Behavior change vs. legacy:** with `verbosity.routine_confirmations:
+false` (default), `/create-pr` creates the PR as draft silently. Override
+per-invocation with `:ready` / `:final` / `:draft`. Restore the prompt
+by flipping `routine_confirmations: true`. See
+[`docs/customization.md` § Verbosity](../../docs/customization.md#verbosity).
+
+Resolve `"draft"` (first match wins):
+
+1. `:ready` / `:final` arg → `false`.
+2. `:draft` arg → `true`.
+3. `routine_confirmations: true` → ask `1. draft / 2. ready`.
+4. Default → `true` (silent draft).
+
+#### 3a. Tool selection — single-call mandate
+
+```
+POST THE PR WITH ONE github-api CALL.
+NEVER COMPOSE THE BODY THROUGH SHELL, PYTHON, OR TEMP FILES.
+```
+
+Use the `github-api` tool **directly** with the markdown body in the
+JSON `data` field. The body is a regular JSON string — escaping is the
+tool's job, not yours.
+
+```
+github-api
+  method: POST
+  path:   /repos/{owner}/{repo}/pulls
+  data:   { "title": "...", "body": "<markdown>", "head": "<branch>",
+            "base": "main", "draft": <bool> }
+```
+
+**Hard prohibitions** (each one cost 3+ extra tool calls in past runs):
+
+- ❌ `python3 -c "import urllib..."` / `python3 - <<PY ... PY` heredocs
+  to serialize the body or POST it.
+- ❌ `save-file PR_BODY.md` → read back → `curl -d @PR_BODY.md`.
+- ❌ `gh pr create --body-file …` shelling out when `github-api` is
+  available in this surface.
+- ❌ Splitting `title` and `body` into two API calls (create + PATCH).
+
+The body may contain any Markdown — code fences, tables, multi-line
+HTML, emoji. Do **not** preprocess, escape, or strip newlines before
+handing it to `github-api`.
+
+If the surface genuinely lacks `github-api` (rare), fall back to
+`gh pr create --title "..." --body-file <(echo -n "<body>")` as a
+**single** shell call, never the python-urllib path.
+
+#### 3b. Submit
+
+Create the PR with the approved title/body and the resolved `draft`.
+
+**Verify after `draft: false`** — the GitHub REST API sometimes ignores
+the flag:
+
+```bash
+gh pr view {number} --json isDraft --jq '.isDraft'
+# returns true → gh pr ready {number}
+```
+
+**Silent-draft postscript** (rule 4) → see step 4b.
+
+### 4. After creation
+
+#### 4a. Strip attribution footers (mandatory)
+
+Some `github-api` tool surfaces append attribution server-side after
+the agent has sent a clean body. Per
+[`no-attribution-footers`](../rules/no-attribution-footers.md), every
+PR body must be re-checked and stripped after every write.
+
+Run this strip-pass **after PR creation and after every body PATCH**:
+
+1. Re-fetch the PR body:
+   ```
+   GET /repos/{owner}/{repo}/pulls/{number}
+   ```
+2. Search the body (case-insensitive) for any of:
+   - `Generated with [Augment Code]` / `🤖 Generated with`
+   - `Pull Request opened by [Augment Code]`
+   - `Co-authored by Augment Code`
+   - Any `augmentcode.com` link the user did not ask for
+3. **No match → done.** Skip steps 4–5; the body is already clean.
+   This is the common path and **must not** spend a verify-GET.
+4. Match found → remove the footer(s) together with surrounding
+   `---` separators and trailing whitespace, then:
+   ```
+   PATCH /repos/{owner}/{repo}/pulls/{number}
+   { "body": "<cleaned body>" }
+   ```
+   Re-fetch the body **once** to verify the strip stuck. If a
+   pattern reappears (server re-injection), repeat the PATCH once;
+   if it still reappears, surface the issue to the user and stop
+   (do not enter a strip/PATCH loop).
+5. Briefly note in the reply how many footers were removed (omit
+   the line entirely when nothing was stripped — silence is the
+   expected path, not "no footers found").
+
+#### 4b. Show the PR URL (verbosity-gated)
+
+Per `verbosity.post_action_reports` (default `minimal`):
+
+- `off` → nothing.
+- `minimal` → `→ #N opened: <url>`. Append `→ created as draft — run
+  \`gh pr ready N\` to flip` when silent-draft (rule 4); omit on ready.
+- `full` → multi-line: PR number, URL, draft state, base/head, ready-reminder.
+
+#### 4c. Jira transition (only when transitioned)
+
+Linked ticket + `routine_confirmations: true` → ask `1. Yes / 2. No`.
+Default (`false`) → skip silently. **Only emit a transition line when
+an actual Jira API call succeeded** — never announce "skipped".
+
+#### 4d. Settings short-circuit — single read per run
+
+`verbosity.routine_confirmations`, `verbosity.post_action_reports`, and
+`commands.create_pr.preview_description` are read **once** at the top
+of the run and cached for the whole `/create-pr` invocation. Do **not**
+re-read `.agent-settings.yml` in 4b / 4c — both branches resolve from
+the cached values from step 1.
+
+When all three resolve to their silent defaults (`false` / `minimal` /
+`false`), steps 4b–4c collapse to the single `→ #N opened: <url>` line
+from 4b and a silent 4c. No extra file reads, no "checking settings…"
+narration, no confirmation prompts.
+
+### Rules
+
+- **Always use the PR template** from `.github/pull_request_template.md`.
+- **Preview is opt-in** — `commands.create_pr.preview_description` (default `false`). `/create-pr:description-only` always previews.
+- **Push the branch first** if needed (with permission).
+- **No attribution footers** — see [`no-attribution-footers`](../rules/no-attribution-footers.md); strip-pass at 4a defends against tool injection.
+- Only create the PR — never merge.
+- Only commit or push with explicit permission.

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

@@ -0,0 +1,235 @@
+---
+model_tier: inherit
+name: prediction-pool
+pack: fun
+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. **Enumerate
+every open question as an explicit checklist** (scores AND every bonus /
+award / special question) — that list is the run's contract; each entry must
+reach an answer. **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 / …): a **de-vigged
+consensus across the 5–10 biggest publicly-viewable bookmakers**
+(sharp-weighted, never one portal) as the primary signal → expected value
+under the Step-3 rules → participant field → tip. **Answer every entry on the
+Step-3 checklist** — scores AND every bonus / award / special question (top
+scorer, "team of the top scorer", group winners, most cards …); none blank.
+Tournament/outright/award probabilities come from real markets **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 | Books used |
+|---|---|---|---|---|---|
+
+Follow with group standings, the full bracket, **and a bonus/special-answer
+table with one row per open question from the Step-3 checklist — every entry
+answered, none blank**:
+
+| Question | Answer | Prob / EV | Risk | 1-line reason | Source (market / model) |
+|---|---|---|---|---|---|
+
+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.
+- **Answer every open question.** Scores AND every bonus / award / special
+  question; a run that ships scorelines only and leaves bonus questions blank
+  is incomplete.
+- **Consensus odds, not one portal.** Build the base from a de-vigged,
+  sharp-weighted consensus across the 5–10 biggest viewable books — never
+  mirror a single bookmaker.
+- **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.