@event4u/agent-config 5.10.1 → 6.1.0

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

@@ -0,0 +1,279 @@
+---
+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
+visibility: advanced
+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.
+
+### 1c. PR-gate — archive completed roadmaps (MANDATORY)
+
+A roadmap that reached 100% (`count_open == 0 && count_deferred == 0`) must
+land **already archived** in this PR — never merged-but-unarchived into the
+trunk (that rot is exactly what the PR-gate replaces; see
+[`roadmap-progress-sync`](../../../rules/roadmap-progress-sync.md) § PR-gate).
+Run the deterministic sweep:
+
+```bash
+python3 .augment/scripts/archive_completed_roadmaps.py   # --changed-only (default)
+```
+
+It `git mv`s each completed roadmap (that this branch touched, per
+`git log origin/main..HEAD`) into `agents/roadmaps/archive/`, rewrites inbound
+`agents/roadmaps/<x>.md` references to the archive path, regenerates the
+dashboard, and stages all of it. No agent-set annotation is involved —
+completion is read from the checkbox counts.
+
+- **It staged changes → commit them onto this branch** (`chore(roadmaps):
+  archive completed roadmaps`) and include them in the push, so the PR carries
+  the archival. Do **not** create the PR with completed-but-unarchived roadmaps
+  in the working tree.
+- **It reported nothing → proceed.** No completed roadmap in this branch.
+
+### 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,236 @@
+---
+model_tier: inherit
+name: prediction-pool
+pack: fun
+tier: 2
+visibility: internal
+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.

package/dist/agent-src/commands/prepare-for-review.md

@@ -0,0 +1,108 @@
+---
+model_tier: high
+name: prepare-for-review
+pack: engineering-base
+tier: 2
+visibility: internal
+skills: [git-workflow, quality-tools]
+description: Prepare a PR branch for local review — updates main and merges the full branch chain so the branch is up to date
+suggestion:
+  eligible: true
+  trigger_description: "get this branch ready for review, rebase and prep for PR"
+  trigger_context: "branch behind base or part of a PR chain"
+workspaces:
+  - agent-config-maintainer
+packs:
+  - meta
+---
+
+# prepare-for-review
+
+## Input
+
+The user provides a PR number or ticket number (e.g. `DEV-1234` or `#42`).
+
+### PR detection
+
+1. If the user provides a GitHub PR URL or PR number → use that PR directly.
+2. If the user provides a Jira ticket number (e.g. `DEV-1234`) → search for an open PR linked to that ticket:
+   - Search via GitHub API for an open PR whose branch name contains the ticket number.
+   - If exactly one PR is found → confirm with the user: "I found PR #{number} on branch `{branch}`. Is that the one?"
+   - If none or multiple found → ask the user for the PR number or URL.
+3. **Never** reuse a PR number from earlier in the conversation without confirmation.
+
+## Instructions
+
+### 1. Fetch the PR
+
+- Use the GitHub API to get the PR details: base branch, head branch, and title.
+
+### 2. Build the branch chain
+
+- If **base branch is `main`** → chain is: `main → {head branch}`
+- If **base branch is NOT `main`** → the base branch itself may have a non-main base.
+  - Recursively fetch the PR for the base branch (search for an open PR with that head branch).
+  - Keep going until you reach `main`.
+  - Build the full ordered chain, e.g.: `main → feature/base → feature/sub → feature/target`
+
+### 3. Update main
+
+```bash
+git checkout main
+git pull origin main
+```
+
+If this fails, abort and report the error to the user.
+
+### 4. Fetch all branches
+
+Before any local checkout or merge, fetch all branches in the chain from `origin`:
+
+```bash
+git fetch origin {branch-1} {branch-2} ...
+```
+
+This ensures the branches exist locally and are up to date, even in a fresh clone.
+
+### 5. Merge chain bottom-up
+
+For each consecutive pair in the chain (starting from `main` upward):
+
+```bash
+git checkout {child-branch}
+git merge {parent-branch} --no-edit
+```
+
+- If a **merge conflict** occurs at any point:
+  - Run `git merge --abort`
+  - Abort the entire process immediately
+  - Report to the user exactly which branches conflicted
+  - Do NOT proceed further
+
+### 6. Check out the target branch
+
+Once all merges succeed:
+
+```bash
+git checkout {head-branch-of-target-PR}
+```
+
+### 7. Report (verbosity-gated)
+
+Read `verbosity.post_action_reports` from `.agent-settings.yml` (default
+`minimal`).
+
+- `off` → emit nothing on success; surface warnings/errors only.
+- `minimal` (default) → one line:
+  `→ {branch} ready · {N} branches merged · {warnings or "clean"}`.
+- `full` → multi-line block listing:
+  - Which branch chain was processed (in order)
+  - That the target branch is now checked out and up to date
+  - Any warnings (e.g. branch was already up to date)
+
+## Rules
+
+- **Do NOT push** any branch — only local merges.
+- **Do NOT create manual commits** — only `git merge` may create merge commits as part of this workflow.
+- **Abort immediately** on any conflict — do not try to resolve conflicts.
+- **Always fetch fresh PR data** — never reuse stale data from earlier in the conversation.