chore: import upstream snapshot with attribution

cli-tool/components/loops/engineering/adversarial-review-loop.md

@@ -0,0 +1,45 @@
+---
+name: adversarial-review-loop
+description: Has a second, independent model review every change before merge so two different reviewers must agree — code only lands when both clear the bar.
+category: engineering
+interval: 15m
+stop-condition: The implementing agent and the independent cross-model reviewer both approve with no blocking findings and tests pass.
+components: [agent:expert-advisors/architect-review, command:git-workflow/gemini-review, command:git-workflow/pr-review]
+tags: [code-review, cross-model, quality, loop]
+---
+
+# Adversarial-Review Loop
+
+> **Loop Engineering** — the verifier inside the loop is the hard part, and an agent grading its own homework will delete the failing test and call it done. This loop puts a *second, different* model in the reviewer seat: two model families must agree before code lands.
+
+## 🎯 Goal
+Implement a change, then have an **independent cross-model reviewer** argue against it. Iterate on findings until both the builder and the outside reviewer sign off — no self-grading.
+
+## ⏱️ Schedule
+Suggested interval: `15m` (or run until the change is merge-ready).
+
+## ▶️ Run it
+```
+/loop 15m "Implement the change. Then have a different model review it adversarially for correctness, security and design. Address every blocking finding and re-run tests. Land it only when both the builder and the independent reviewer agree there are no blocking findings. Max 5 review rounds."
+```
+
+## 🔁 Iteration steps
+1. **Build** — implement the next slice.
+2. **Cross-review** — run `/gemini-review` so a *different* model family critiques the diff.
+3. **Reason** — collect blocking findings from the outside reviewer.
+4. **Act** — fix them; `architect-review` validates the revision; re-run tests.
+5. **Observe** — re-review with `/pr-review`; loop until both sides agree (cap the rounds).
+
+## 🛑 Stopping condition
+Both reviewers report zero blocking findings and tests pass — or the review-round cap is reached and the loop hands off with the open findings.
+
+## 💰 Budget & guardrails
+A `--max-iter` style cap on review rounds and a severity threshold: only findings at/above the bar block. Two independent models must agree, so neither can rubber-stamp itself.
+
+## 🧩 Referenced components
+- `agent:expert-advisors/architect-review` — the in-house reviewer.
+- `command:git-workflow/gemini-review` — an independent, different-model review.
+- `command:git-workflow/pr-review` — structured re-review checklist.
+
+## 💡 Example
+The builder ships an auth change; the cross-model reviewer flags a timing-attack risk the in-house reviewer missed. The loop fixes it, both agree, and only then does it land.

cli-tool/components/loops/engineering/anti-spin-build-loop.md

@@ -0,0 +1,45 @@
+---
+name: anti-spin-build-loop
+description: Builds toward a machine-checkable contract with explicit anti-spin guardrails — stops on no progress, repeated approaches, flip-flopping, or a spend budget.
+category: engineering
+interval: 15m
+stop-condition: The machine-checkable contract passes, or an anti-spin guard trips (no progress, repeated/flip-flopping approach, or budget hit).
+components: [agent:expert-advisors/architect-review, command:git-workflow/pr-review, hook:quality-gates/scope-guard]
+tags: [reliability, guardrails, budget, loop]
+---
+
+# Anti-Spin Build Loop
+
+> **Loop Engineering** — most agent loops never stop to ask whether they're actually making progress, so they retry the same broken approach or quietly edit the test to pass. This loop runs build → audit → verify against a machine-checkable contract, with explicit stops that detect spinning.
+
+## 🎯 Goal
+Drive toward a verifiable contract while actively guarding against the classic failure mode: an agent that loops forever without converging.
+
+## ⏱️ Schedule
+Suggested interval: `15m`.
+
+## ▶️ Run it
+```
+/loop 15m "Build toward the goal, then audit and verify against a machine-checkable contract. Track progress each pass. Stop if you make no progress, repeat an approach you already tried, flip-flop between two approaches, or hit the budget. Finish only when the contract passes — never by weakening the contract or the tests."
+```
+
+## 🔁 Iteration steps
+1. **Build** — advance toward the contract.
+2. **Audit** — `architect-review` checks the change; `scope-guard` blocks weakening the tests/contract.
+3. **Verify** — run the machine-checkable contract; record progress vs. last pass.
+4. **Anti-spin check** — no progress? repeated approach? flip-flop? budget hit? → stop and report.
+5. **Observe** — if making progress and contract not yet met, loop; else `/pr-review` and hand off.
+
+## 🛑 Stopping condition
+Contract passes, **or** an anti-spin guard trips — whichever comes first.
+
+## 💰 Budget & guardrails
+Hard caps on iterations and spend; no-progress, repeated-approach and flip-flop detection. The contract and tests are immutable — the loop may not edit them to "pass".
+
+## 🧩 Referenced components
+- `agent:expert-advisors/architect-review` — independent audit each pass.
+- `command:git-workflow/pr-review` — structured review at handoff.
+- `hook:quality-gates/scope-guard` — prevents weakening tests/contract to fake success.
+
+## 💡 Example
+Chasing a contract for a parser, the loop tries approach A, then B, then drifts back to A — the flip-flop guard trips and it stops with a clear report instead of burning tokens forever.

cli-tool/components/loops/engineering/build-test-fix-loop.md

@@ -0,0 +1,45 @@
+---
+name: build-test-fix-loop
+description: Builds the next item on the plan, then runs tests, typecheck and lint, feeding every failure back as the next instruction until the build is green.
+category: engineering
+interval: 10m
+stop-condition: The build is green — tests, typecheck and lint all pass — and the checker reports nothing left to fix.
+components: [agent:development-team/test-runner, hook:testing/test-runner, command:testing/generate-tests]
+tags: [testing, build, ci, loop]
+---
+
+# Build–Test–Fix Loop
+
+> **Loop Engineering** — the single most-demoed loop pattern: a builder writes code and a checker runs tests, typecheck and lint and reports exactly what broke. They pass work back and forth until it's clean. A one-shot agent ships its bugs; this loop catches them.
+
+## 🎯 Goal
+Implement the next item on the plan, then run the full check gate (tests + typecheck + lint), feed **every** failure back as the next instruction, and repeat until the build is green.
+
+## ⏱️ Schedule
+Suggested interval: `10m` (or run until done on a feature).
+
+## ▶️ Run it
+```
+/loop 10m "Build the next item on the plan, then run tests, typecheck and lint. Feed every failure back as the next instruction and fix it. Add a test for anything that lacked coverage. Stop when the build is green and the checker has nothing left to report."
+```
+
+## 🔁 Iteration steps
+1. **Build** — implement the next plan item.
+2. **Check** — the `test-runner` hook runs tests, typecheck and lint automatically.
+3. **Reason** — collect every failure into a concrete fix list.
+4. **Act** — fix each; add tests with `/generate-tests` for uncovered paths.
+5. **Observe** — re-run the gate; loop until fully green.
+
+## 🛑 Stopping condition
+Tests, typecheck and lint all pass and the checker reports nothing outstanding.
+
+## 💰 Budget & guardrails
+Cap iterations or spend so a stubborn failure can't spin forever — surface anything that fails the same way twice for human eyes.
+
+## 🧩 Referenced components
+- `agent:development-team/test-runner` — runs and interprets the check gate.
+- `hook:testing/test-runner` — fires the suite automatically each pass.
+- `command:testing/generate-tests` — covers gaps the loop uncovers.
+
+## 💡 Example
+Implementing a new endpoint, the loop catches a type error, then a failing integration test, then a lint warning — fixing each in turn — and exits only when all three gates are green.

cli-tool/components/loops/engineering/builder-reviewer-loop.md

@@ -0,0 +1,42 @@
+---
+name: builder-reviewer-loop
+description: Passes code between a builder and an independent reviewer subagent until the review has no blocking findings and tests pass.
+category: engineering
+interval: 15m
+stop-condition: The reviewer reports zero blocking findings and the full test suite passes.
+components: [agent:expert-advisors/architect-review, agent:development-team/test-runner, command:git-workflow/pr-review]
+tags: [code-review, subagents, quality, loop]
+---
+
+# Builder–Reviewer Loop
+
+> **Loop Engineering** — separate the *builder* from the *reviewer* so the agent doesn't grade its own work. Code bounces between them until it genuinely passes.
+
+## 🎯 Goal
+Implement a change, then have an **independent reviewer subagent** critique it; iterate on the findings until the review is clean and tests are green.
+
+## ⏱️ Schedule
+Suggested interval: `15m` (or run until done on a single feature).
+
+## ▶️ Run it
+```
+/loop 15m "Implement the next slice of the feature. Then hand it to an independent reviewer subagent for an adversarial review. Address every blocking finding and re-run tests. Continue until the reviewer has no blocking findings and the suite passes."
+```
+
+## 🔁 Iteration steps
+1. **Build** — implement the next slice of work.
+2. **Review** — the `architect-review` agent inspects the diff for correctness, design and risk.
+3. **Plan** — collect blocking findings into a fix list.
+4. **Act** — address each finding; re-run the suite with `test-runner`.
+5. **Observe** — re-review with `/pr-review`; if blocking findings remain, loop again.
+
+## 🛑 Stopping condition
+Reviewer reports zero blocking findings **and** all tests pass.
+
+## 🧩 Referenced components
+- `agent:expert-advisors/architect-review` — the independent reviewer (no self-grading).
+- `agent:development-team/test-runner` — runs the suite each pass.
+- `command:git-workflow/pr-review` — structured review checklist.
+
+## 💡 Example
+The builder ships a new caching layer; the reviewer flags a race condition and a missing eviction test. The loop fixes both, re-reviews, and exits clean.

cli-tool/components/loops/engineering/completion-contract-loop.md

@@ -0,0 +1,45 @@
+---
+name: completion-contract-loop
+description: Writes a contract of what "done" means and what evidence proves each requirement before any work starts, then refuses to claim success without that evidence.
+category: engineering
+interval: on-demand
+stop-condition: Every requirement in the completion contract is satisfied with verifiable evidence (tests, output, diffs).
+components: [agent:expert-advisors/critical-thinking, command:testing/test-coverage, command:git-workflow/create-pr]
+tags: [goal, verification, definition-of-done, loop]
+---
+
+# Completion-Contract Loop
+
+> **Loop Engineering** — the `/goal` verb runs until a verifiable condition is true. This loop fixes the most common failure: an agent that says "done" when it isn't. It defines "complete" and the evidence for each requirement *upfront*, then can't declare victory without it.
+
+## 🎯 Goal
+Before doing any work, write a **completion contract**: each requirement plus the concrete evidence that proves it. Then execute until every requirement is backed by evidence.
+
+## ⏱️ Schedule
+Trigger: `on-demand` (a goal that runs to a condition, not a timer).
+
+## ▶️ Run it
+```
+/goal First write a completion contract: list each requirement and the exact evidence that proves it (a passing test, a command output, a diff). Confirm the contract, then implement. Do not claim success for any requirement without its evidence. Done only when every requirement has evidence. Stop after N turns if blocked.
+```
+
+## 🔁 Iteration steps
+1. **Contract** — `critical-thinking` drafts requirements + the evidence each needs.
+2. **Plan** — order the work by requirement.
+3. **Act** — implement one requirement at a time.
+4. **Prove** — attach evidence (coverage via `/test-coverage`, command output, diff); no evidence, not done.
+5. **Observe** — when all requirements have evidence, open a PR with `/create-pr` linking the contract.
+
+## 🛑 Stopping condition
+Every contract requirement is satisfied with verifiable evidence — or the turn/budget cap is hit and the loop reports what's still unproven.
+
+## 💰 Budget & guardrails
+A separate check confirms each piece of evidence rather than trusting the worker's self-report. Hard turn cap so an unprovable requirement can't spin.
+
+## 🧩 Referenced components
+- `agent:expert-advisors/critical-thinking` — authors and enforces the contract.
+- `command:testing/test-coverage` — supplies measurable evidence.
+- `command:git-workflow/create-pr` — ships the result with the contract attached.
+
+## 💡 Example
+Asked to "add rate limiting", the loop first writes a contract (limit enforced, 429 returned, headers set, tested) and only reports done once each line has a passing test as evidence.

cli-tool/components/loops/engineering/docs-sweep-loop.md

@@ -0,0 +1,42 @@
+---
+name: docs-sweep-loop
+description: Keeps documentation aligned with the current codebase and opens a reviewable pull request on every pass.
+category: engineering
+interval: 30m
+stop-condition: Every public API, command and config option is documented and the docs build passes with no warnings.
+components: [agent:documentation/documentation-engineer, command:documentation/update-docs, command:git-workflow/create-pr]
+tags: [documentation, automation, ci, loop]
+---
+
+# Docs Sweep Loop
+
+> **Loop Engineering** — instead of prompting the agent by hand, you define a recurring goal and let Claude observe, plan, act and verify until a stop condition is true. This loop keeps documentation continuously in sync with the code.
+
+## 🎯 Goal
+Keep the project's documentation accurate and complete as the codebase changes, and surface every update as a small, reviewable pull request rather than a giant batch.
+
+## ⏱️ Schedule
+Suggested interval: `30m` (or run after each merge to `main`).
+
+## ▶️ Run it
+```
+/loop 30m "Compare the docs against the current code. Find any public API, CLI flag, config option, or behavior that changed or is undocumented. Update the docs to match, then open a focused PR. Continue until docs and code fully agree."
+```
+
+## 🔁 Iteration steps
+1. **Perceive** — diff the docs against the current source (signatures, flags, env vars, examples).
+2. **Reason** — list concrete drift: missing pages, stale snippets, broken links, renamed APIs.
+3. **Plan** — pick the smallest meaningful slice to fix this pass.
+4. **Act** — update the docs with the `documentation-engineer` agent and `/update-docs`.
+5. **Observe** — build the docs; if it passes with no warnings, open a PR with `/create-pr`. Otherwise fix and repeat.
+
+## 🛑 Stopping condition
+All public surfaces are documented, examples compile, links resolve, and the docs build is warning-free.
+
+## 🧩 Referenced components
+- `agent:documentation/documentation-engineer` — drives the doc edits.
+- `command:documentation/update-docs` — refreshes generated docs.
+- `command:git-workflow/create-pr` — opens the reviewable PR.
+
+## 💡 Example
+After a release that renamed three CLI flags, the loop detects the drift, rewrites the affected pages and examples, verifies the build, and opens `docs: sync CLI flag renames` for review.

cli-tool/components/loops/engineering/five-minute-maintainer-loop.md

@@ -0,0 +1,45 @@
+---
+name: five-minute-maintainer-loop
+description: Every few minutes while you work, makes one small verified repository improvement — a flaky test, a stale comment, a missing type — one change, one commit.
+category: engineering
+interval: 5m
+stop-condition: You end the session, or there is no safe low-risk improvement left to make this pass.
+components: [agent:development-team/test-runner, command:git-workflow/commit, hook:quality-gates/scope-guard]
+tags: [maintenance, hygiene, automation, loop]
+---
+
+# Five-Minute Maintainer Loop
+
+> **Loop Engineering** — the `/loop` verb repeats a task *while you are present*. This one does continuous, low-risk upkeep on a tight timer while you focus on the real work. Inspired by Peter Steinberger's five-minute maintainer.
+
+## 🎯 Goal
+Every few minutes, make exactly **one** small, verified improvement to the repo — and let the agent decide *what* to clean. That judgment is the whole point; nothing is hardcoded.
+
+## ⏱️ Schedule
+Suggested interval: `5m` (runs while your session is open).
+
+## ▶️ Run it
+```
+/loop 5m "Make one small, verified repository improvement: a flaky test, a stale comment, a missing type, a dead import. One change, one commit, tests green. Never touch anything risky or architectural. If nothing safe remains, say so and wait."
+```
+
+## 🔁 Iteration steps
+1. **Perceive** — scan for a small, low-risk improvement opportunity.
+2. **Reason** — confirm it is safe; the `scope-guard` hook blocks risky/out-of-scope edits.
+3. **Act** — make the single change.
+4. **Verify** — run the suite with `test-runner`; only proceed if green.
+5. **Observe** — commit with `/commit`; one change, one commit. Wait for the next tick.
+
+## 🛑 Stopping condition
+You end the session, or there is no safe improvement left this pass (the loop idles rather than inventing risky work).
+
+## 💰 Budget & guardrails
+One change per tick; never refactors or touches production-critical paths. Set a per-session token budget before walking away.
+
+## 🧩 Referenced components
+- `agent:development-team/test-runner` — verifies each change is green.
+- `command:git-workflow/commit` — one clean commit per improvement.
+- `hook:quality-gates/scope-guard` — blocks risky / out-of-scope edits.
+
+## 💡 Example
+While you build a feature, the loop quietly fixes a flaky timer test, removes a dead import, and adds a missing return type — three tiny green commits — without ever touching the feature you're working on.

cli-tool/components/loops/engineering/goal-refiner-loop.md

@@ -0,0 +1,44 @@
+---
+name: goal-refiner-loop
+description: Rewrites a vague request into a precise goal — exact end state, how to verify it, what not to touch, and the stop condition — then executes against it.
+category: engineering
+interval: on-demand
+stop-condition: The refined goal's verifiable end state is reached, or its explicit turn/budget cap is hit.
+components: [agent:expert-advisors/critical-thinking, agent:development-team/code-architect]
+tags: [goal, planning, prompting, loop]
+---
+
+# Goal-Refiner Loop
+
+> **Loop Engineering** — "your agent is not dumb, your instructions are just vague." This loop's only first job is to turn a fuzzy ask into a rigorous, verifiable goal before any code is written, then run the `/goal` against it.
+
+## 🎯 Goal
+Convert a vague request into a precise goal — the exact end state, how it will be verified, what must not be touched, and the stop condition — confirm it, then execute.
+
+## ⏱️ Schedule
+Trigger: `on-demand`.
+
+## ▶️ Run it
+```
+/goal Before doing anything, rewrite my request into a precise goal: the exact end state, how you will verify it, what you must not touch, and the stop condition (including a turn cap). Confirm that goal with me, then execute against it and stop when the end state is verified.
+```
+
+## 🔁 Iteration steps
+1. **Refine** — `critical-thinking` rewrites the ask into a crisp, testable goal.
+2. **Scope** — `code-architect` defines the blast radius: what's in, what must not be touched.
+3. **Confirm** — surface the refined goal for a quick yes before acting.
+4. **Act** — execute against the goal.
+5. **Verify** — check the end state against the stated verification; stop when met.
+
+## 🛑 Stopping condition
+The goal's verifiable end state is reached, or the turn/budget cap is hit (the loop reports how far it got).
+
+## 💰 Budget & guardrails
+Every refined goal carries an explicit "what not to touch" and a turn cap, so an under-specified ask can't sprawl into a risky, open-ended run.
+
+## 🧩 Referenced components
+- `agent:expert-advisors/critical-thinking` — sharpens the goal and verification.
+- `agent:development-team/code-architect` — bounds scope and the do-not-touch list.
+
+## 💡 Example
+"Make the app faster" becomes "p95 of /search ≤ 200ms measured by the existing benchmark, without changing the public API, stop after 8 turns" — and the loop executes against that.

cli-tool/components/loops/engineering/perf-budget-loop.md

@@ -0,0 +1,42 @@
+---
+name: perf-budget-loop
+description: Profiles and optimizes the app pass after pass until it consistently meets a defined performance budget.
+category: engineering
+interval: 20m
+stop-condition: The target metric meets the budget across repeated runs with no functional regressions.
+components: [agent:performance-testing/performance-engineer, command:performance/performance-audit, command:performance/optimize-bundle-size]
+tags: [performance, optimization, profiling, loop]
+---
+
+# Performance Budget Loop
+
+> **Loop Engineering** — hold the agent to a concrete, measurable budget and let it optimize until the number is real and stable.
+
+## 🎯 Goal
+Drive a target metric (page load, bundle size, p95 latency, etc.) under its budget by profiling, fixing the biggest bottleneck each pass, and re-measuring — without breaking functionality.
+
+## ⏱️ Schedule
+Suggested interval: `20m`.
+
+## ▶️ Run it
+```
+/loop 20m "Profile the app against the performance budget. Find the single biggest bottleneck, fix it, and re-measure. Verify no tests break. Continue until the metric meets the budget across three consecutive runs."
+```
+
+## 🔁 Iteration steps
+1. **Perceive** — run `/performance-audit` and capture the current metric.
+2. **Reason** — the `performance-engineer` agent identifies the top bottleneck.
+3. **Plan** — choose one optimization (code-split, cache, query, bundle).
+4. **Act** — apply it (e.g. `/optimize-bundle-size`).
+5. **Observe** — re-measure; require the budget to hold across repeated runs before stopping.
+
+## 🛑 Stopping condition
+Metric ≤ budget across consecutive runs, with no functional regression.
+
+## 🧩 Referenced components
+- `agent:performance-testing/performance-engineer` — diagnoses bottlenecks.
+- `command:performance/performance-audit` — measures each pass.
+- `command:performance/optimize-bundle-size` — one of the optimization levers.
+
+## 💡 Example
+Targeting a 200 KB JS budget, the loop lazy-loads a chart library, trims a moment.js import, and de-dupes a dependency until the bundle stabilizes under budget.

cli-tool/components/loops/engineering/production-error-sweep-loop.md

@@ -0,0 +1,42 @@
+---
+name: production-error-sweep-loop
+description: Triages production errors, finds the root cause, ships a verified fix, and repeats until the error budget is clean.
+category: engineering
+interval: 15m
+stop-condition: No unresolved high-severity production errors remain and each fix is verified in tests.
+components: [agent:expert-advisors/debug, agent:security/incident-responder, command:git-workflow/create-pr]
+tags: [debugging, incidents, reliability, loop]
+---
+
+# Production Error Sweep Loop
+
+> **Loop Engineering** — keep an autonomous responder working the error queue, one root cause at a time, until production is quiet.
+
+## 🎯 Goal
+Continuously pull the top production error, find its **root cause** (not just the symptom), ship a tested fix, and verify the error stops recurring.
+
+## ⏱️ Schedule
+Suggested interval: `15m` (or trigger on new error alerts).
+
+## ▶️ Run it
+```
+/loop 15m "Take the highest-impact unresolved production error. Reproduce it, find the root cause, write a regression test, fix it, and open a PR. Continue until no high-severity errors remain."
+```
+
+## 🔁 Iteration steps
+1. **Perceive** — read the top error by impact (frequency × severity).
+2. **Reason** — reproduce and trace to the true root cause with the `debug` agent.
+3. **Plan** — design a minimal fix plus a regression test that fails first.
+4. **Act** — implement the fix; the `incident-responder` agent documents impact and mitigation.
+5. **Observe** — confirm the regression test passes, then open a PR with `/create-pr`.
+
+## 🛑 Stopping condition
+The high-severity error queue is empty and every fix is covered by a passing regression test.
+
+## 🧩 Referenced components
+- `agent:expert-advisors/debug` — root-cause analysis.
+- `agent:security/incident-responder` — impact assessment and mitigation notes.
+- `command:git-workflow/create-pr` — ships each fix for review.
+
+## 💡 Example
+A recurring null-pointer crash is traced to an unvalidated webhook payload; the loop adds a failing regression test, fixes the validation, verifies, and opens `fix: validate webhook payload before parse`.

cli-tool/components/loops/engineering/repo-cleanup-loop.md

@@ -0,0 +1,42 @@
+---
+name: repo-cleanup-loop
+description: Recovers valuable unmerged work and prunes stale branches and PRs until the repository is tidy.
+category: engineering
+interval: 7d
+stop-condition: No stale branches or abandoned PRs remain and any salvageable work has been captured.
+components: [command:git-workflow/branch-cleanup, agent:git/git-workflow-manager, skill:git/git-context-controller]
+tags: [git, maintenance, cleanup, loop]
+---
+
+# Repository Cleanup Loop
+
+> **Loop Engineering** — a recurring janitor that keeps the repo's branch and PR list honest without deleting anything valuable.
+
+## 🎯 Goal
+Find stale branches and abandoned PRs, **recover** any work worth keeping (extract to an issue or fresh branch), and safely remove the rest.
+
+## ⏱️ Schedule
+Suggested interval: `7d` (weekly). Because this loop can delete branches, keep the cadence slow and review its actions.
+
+## ▶️ Run it
+```
+/loop 7d "Scan branches and PRs. For each stale one, decide: salvage valuable work into an issue/branch, or delete if fully merged or abandoned. Never lose unmerged work. Continue until the branch and PR list is clean."
+```
+
+## 🔁 Iteration steps
+1. **Perceive** — list branches/PRs by last activity with `git-context-controller`.
+2. **Reason** — classify each: merged, abandoned, or contains salvageable work.
+3. **Plan** — decide salvage vs delete for the oldest item.
+4. **Act** — salvage to an issue/branch, then prune with `/branch-cleanup`; the `git-workflow-manager` agent guides safe operations.
+5. **Observe** — confirm nothing valuable was lost; continue down the list.
+
+## 🛑 Stopping condition
+No stale branches or abandoned PRs remain and all salvageable work is captured.
+
+## 🧩 Referenced components
+- `command:git-workflow/branch-cleanup` — prunes merged/stale branches.
+- `agent:git/git-workflow-manager` — guards safe git operations.
+- `skill:git/git-context-controller` — inspects branch/PR history.
+
+## 💡 Example
+A six-month-old `spike/new-parser` branch holds a useful prototype; the loop extracts it into an issue with the diff attached, then deletes the branch.

cli-tool/components/loops/engineering/test-coverage-loop.md

@@ -0,0 +1,42 @@
+---
+name: test-coverage-loop
+description: Adds meaningful tests pass after pass until the suite reaches a target coverage threshold and stays green.
+category: engineering
+interval: 20m
+stop-condition: Coverage meets or exceeds the target (e.g. 90%) with all tests passing and no flaky additions.
+components: [agent:performance-testing/test-automator, command:testing/test-coverage, command:testing/generate-tests]
+tags: [testing, coverage, quality, loop]
+---
+
+# Test Coverage Loop
+
+> **Loop Engineering** — a recurring goal that drives the agent to grow real test coverage incrementally instead of in one risky batch.
+
+## 🎯 Goal
+Raise test coverage toward a defined target by adding **meaningful** tests for the least-covered, highest-risk code first — never gaming the metric with empty assertions.
+
+## ⏱️ Schedule
+Suggested interval: `20m`.
+
+## ▶️ Run it
+```
+/loop 20m "Measure current test coverage. Pick the lowest-covered, highest-risk module and add real, behavior-focused tests for it. Re-run the suite. Continue until coverage is at least 90% with everything passing."
+```
+
+## 🔁 Iteration steps
+1. **Perceive** — run the coverage report and rank uncovered code by risk.
+2. **Reason** — identify branches, error paths and edge cases that lack tests.
+3. **Plan** — choose one module/area to cover this pass.
+4. **Act** — generate tests with `test-automator` + `/generate-tests`.
+5. **Observe** — re-run `/test-coverage`; if the suite is green and coverage rose, continue; if flaky, fix before moving on.
+
+## 🛑 Stopping condition
+Coverage ≥ target, full suite passes, and no newly-added test is flaky.
+
+## 🧩 Referenced components
+- `agent:performance-testing/test-automator` — authors the tests.
+- `command:testing/test-coverage` — measures progress each pass.
+- `command:testing/generate-tests` — scaffolds new test cases.
+
+## 💡 Example
+Starting at 61%, the loop targets the untested error branches of the payment module first, climbing a few points per pass until it crosses 90% with a green suite.

cli-tool/components/loops/engineering/ticket-to-pr-loop.md

@@ -0,0 +1,42 @@
+---
+name: ticket-to-pr-loop
+description: Converts open bug reports and issues into verified, reviewer-ready pull requests, one ticket per pass.
+category: engineering
+interval: 30m
+stop-condition: Every actionable ticket in scope has a verified PR or is flagged for human input.
+components: [command:git-workflow/fix-github-issue, command:git-workflow/create-pr, hook:git/conventional-commits]
+tags: [issues, pull-requests, automation, loop]
+---
+
+# Ticket-to-PR-Ready Loop
+
+> **Loop Engineering** — turn a backlog of issues into a steady stream of small, verified PRs without hand-holding each one.
+
+## 🎯 Goal
+Pick one actionable ticket, implement and verify the fix, and open a PR that a reviewer can approve quickly — then move to the next ticket.
+
+## ⏱️ Schedule
+Suggested interval: `30m`.
+
+## ▶️ Run it
+```
+/loop 30m "Take the next actionable open issue. Implement the fix in an isolated branch, add tests, verify, and open a conventional-commit PR linking the issue. If a ticket needs product decisions, label it for human review and skip. Continue until the queue is clear."
+```
+
+## 🔁 Iteration steps
+1. **Perceive** — read the next open, actionable issue.
+2. **Reason** — confirm scope; if it needs human/product input, label and skip.
+3. **Plan** — outline the change and the test that proves it.
+4. **Act** — implement with `/fix-github-issue`; commits follow `conventional-commits`.
+5. **Observe** — run tests; on green, open a PR with `/create-pr` that links the issue.
+
+## 🛑 Stopping condition
+No actionable tickets remain — each is either a verified PR or flagged for human input.
+
+## 🧩 Referenced components
+- `command:git-workflow/fix-github-issue` — implements the ticket fix.
+- `command:git-workflow/create-pr` — opens the linked PR.
+- `hook:git/conventional-commits` — enforces clean, conventional commit messages.
+
+## 💡 Example
+A "typo in error message" issue becomes a one-line fix with a snapshot test and a `fix: correct auth error copy (#412)` PR, all within a single pass.

cli-tool/components/loops/evaluation/devils-advocate-loop.md

@@ -0,0 +1,42 @@
+---
+name: devils-advocate-loop
+description: Adversarially challenges a design or decision until every serious objection is resolved or explicitly accepted.
+category: evaluation
+interval: 15m
+stop-condition: No unresolved serious objections remain — each is fixed or consciously accepted with rationale.
+components: [agent:expert-advisors/architect-review, agent:expert-advisors/critical-thinking, command:git-workflow/pr-review]
+tags: [evaluation, design-review, decision-making, loop]
+---
+
+# Devil's-Advocate Loop
+
+> **Loop Engineering** — put a dedicated critic in the loop. It keeps attacking the design until the proposal survives scrutiny or is knowingly accepted with its trade-offs.
+
+## 🎯 Goal
+Stress-test a design, RFC, or architectural decision by generating the strongest possible objections, then resolving or explicitly accepting each one — no objection silently ignored.
+
+## ⏱️ Schedule
+Suggested interval: `15m` (or run until the design is settled).
+
+## ▶️ Run it
+```
+/loop 15m "Act as a devil's advocate against the current design. Raise the strongest objections (scaling, security, cost, edge cases, maintainability). For each, either fix the design or record an explicit accepted trade-off with rationale. Continue until no serious objection is unresolved."
+```
+
+## 🔁 Iteration steps
+1. **Perceive** — read the current design/decision.
+2. **Reason** — the `critical-thinking` agent generates the strongest counter-arguments.
+3. **Plan** — for each objection, choose fix vs accept-with-rationale.
+4. **Act** — update the design or the decision log; `architect-review` validates the revision.
+5. **Observe** — re-run with `/pr-review`; stop only when nothing serious is unresolved.
+
+## 🛑 Stopping condition
+Every serious objection is either resolved or recorded as an explicit, justified trade-off.
+
+## 🧩 Referenced components
+- `agent:expert-advisors/architect-review` — validates each revision.
+- `agent:expert-advisors/critical-thinking` — generates adversarial objections.
+- `command:git-workflow/pr-review` — structured review of the design changes.
+
+## 💡 Example
+A proposed single-region database is challenged on availability; the loop either adds a replication plan or records "single-region accepted for MVP, revisit at scale" with reasoning.

cli-tool/components/loops/evaluation/human-approval-loop.md

@@ -0,0 +1,45 @@
+---
+name: human-approval-loop
+description: Runs the task, then pauses and sends you approve / revise / skip before anything ships — human review as a first-class queue where the stop condition is your approval.
+category: evaluation
+interval: on-demand
+stop-condition: You approve the result (it ships) or skip/redirect it — nothing ships without explicit human approval.
+components: [hook:quality-gates/plan-gate, hook:automation/telegram-notifications, command:git-workflow/create-pr]
+tags: [human-in-the-loop, approval, safety, loop]
+---
+
+# Human-in-the-Loop Approval Loop
+
+> **Loop Engineering** — same loop shape as the autonomous ones, but the stop condition is *your approval* instead of a passing test. The agent does the work, then waits at a gate: approve, revise, or skip.
+
+## 🎯 Goal
+Run the task, then **pause** and route the result to you for a decision before anything ships — treating human review as its own queue with clear actions.
+
+## ⏱️ Schedule
+Trigger: `on-demand` (each item pauses for your call before shipping).
+
+## ▶️ Run it
+```
+/loop run the next task, then pause and send me approve / revise / skip before anything ships. On approve, continue and ship. On revise, take my note and redo. On skip, move to the next item. Never ship without my approval.
+```
+
+## 🔁 Iteration steps
+1. **Act** — complete the task up to the point of shipping.
+2. **Gate** — the `plan-gate` hook halts before any irreversible/ship step.
+3. **Ask** — send approve / revise / skip via `telegram-notifications`.
+4. **Branch** — approve → ship (e.g. `/create-pr`); revise → apply note and redo; skip → next item.
+5. **Observe** — record the decision; nothing ships unattended.
+
+## 🛑 Stopping condition
+You approve (ship) or skip/redirect — the loop never ships without an explicit human decision.
+
+## 💰 Budget & guardrails
+The gate is the safety: irreversible actions wait for a human. Add a reminder/deadline so pending items don't pile up silently, and a budget for the work done before each gate.
+
+## 🧩 Referenced components
+- `hook:quality-gates/plan-gate` — halts before irreversible/ship steps.
+- `hook:automation/telegram-notifications` — sends the approve/revise/skip prompt.
+- `command:git-workflow/create-pr` — the ship action on approval.
+
+## 💡 Example
+The agent drafts a refund-policy change, pauses, and pings you on Telegram. You hit "revise" with a note; it redoes the draft and pings again — and only ships after you approve.

cli-tool/components/loops/evaluation/quality-streak-loop.md

@@ -0,0 +1,42 @@
+---
+name: quality-streak-loop
+description: Runs realistic scenarios and fixes failures until the suite passes N times in a row with no regressions.
+category: evaluation
+interval: 20m
+stop-condition: The scenario suite passes N consecutive times (e.g. 5) with zero failures.
+components: [agent:performance-testing/test-automator, hook:testing/test-runner, command:testing/test-quality-analyzer]
+tags: [evaluation, reliability, testing, loop]
+---
+
+# Quality Streak Loop
+
+> **Loop Engineering** — don't trust a single green run. Require a *streak* of clean passes to prove stability before stopping.
+
+## 🎯 Goal
+Exercise the product with realistic scenarios, fix every failure, and keep going until the suite passes N consecutive times — catching flakiness and intermittent bugs.
+
+## ⏱️ Schedule
+Suggested interval: `20m`.
+
+## ▶️ Run it
+```
+/loop 20m "Run the realistic scenario suite. Fix any failure you find, including flaky ones. Reset the streak counter on any failure. Continue until the suite passes 5 times in a row."
+```
+
+## 🔁 Iteration steps
+1. **Perceive** — run the scenario suite via the `test-runner` hook.
+2. **Reason** — analyze failures (real bug vs flake) with `/test-quality-analyzer`.
+3. **Plan** — fix the failure and harden the test.
+4. **Act** — implement the fix with `test-automator`; reset the streak on any failure.
+5. **Observe** — repeat; only stop after N consecutive clean runs.
+
+## 🛑 Stopping condition
+N consecutive passes (default 5) with zero failures or flakes.
+
+## 🧩 Referenced components
+- `agent:performance-testing/test-automator` — fixes and hardens tests.
+- `hook:testing/test-runner` — auto-runs the suite.
+- `command:testing/test-quality-analyzer` — distinguishes real bugs from flakes.
+
+## 💡 Example
+The suite passes 4 times then a timing-dependent test flakes; the loop stabilizes it with a deterministic clock and restarts the streak until it hits 5 clean.

cli-tool/components/loops/operations/nightly-changelog-loop.md

@@ -0,0 +1,42 @@
+---
+name: nightly-changelog-loop
+description: Updates the changelog every night with user-relevant changes and notifies the team when it ships.
+category: operations
+interval: 24h
+stop-condition: The changelog reflects all merged, user-facing changes since the last entry and the team has been notified.
+components: [agent:documentation/changelog-generator, hook:automation/change-logger, hook:automation/slack-notifications]
+tags: [changelog, operations, release-notes, loop]
+---
+
+# Nightly Changelog Loop
+
+> **Loop Engineering** — a scheduled operations loop that turns the day's merges into a clean, user-facing changelog and announces it automatically.
+
+## 🎯 Goal
+Each night, collect everything merged since the last entry, translate it into **user-relevant** changelog notes (not raw commits), and notify the team.
+
+## ⏱️ Schedule
+Suggested interval: `24h` (run overnight).
+
+## ▶️ Run it
+```
+/loop 24h "Gather all changes merged since the last changelog entry. Write clear, user-facing release notes grouped by Added/Changed/Fixed. Update the changelog file, commit it, and post a summary to the team channel. Skip internal-only changes."
+```
+
+## 🔁 Iteration steps
+1. **Perceive** — read merges since the last changelog entry via `change-logger`.
+2. **Reason** — filter to user-facing changes; group as Added / Changed / Fixed.
+3. **Plan** — draft concise, human-readable notes.
+4. **Act** — update the changelog with `changelog-generator` and commit.
+5. **Observe** — post the summary through `slack-notifications`; confirm delivery.
+
+## 🛑 Stopping condition
+Changelog covers all user-facing changes since the last entry and the team notification was sent.
+
+## 🧩 Referenced components
+- `agent:documentation/changelog-generator` — writes the release notes.
+- `hook:automation/change-logger` — captures what changed.
+- `hook:automation/slack-notifications` — announces the update.
+
+## 💡 Example
+Overnight the loop turns 14 merged PRs into 5 user-facing bullet points, commits `docs: changelog 2026-06-20`, and posts the summary to `#releases`.

cli-tool/components/loops/operations/overnight-pr-routine-loop.md

@@ -0,0 +1,46 @@
+---
+name: overnight-pr-routine-loop
+description: A nightly routine that watches your open PRs, auto-fixes build failures, answers review comments in a fresh worktree, and rebases stale branches while you sleep.
+category: operations
+interval: daily
+stop-condition: Every fixable PR is green and updated; anything ambiguous is left flagged for human review.
+components: [command:git-workflow/worktree-init, command:git-workflow/create-pr, agent:git/git-workflow-manager, hook:automation/slack-notifications]
+tags: [schedule, pull-requests, automation, loop]
+---
+
+# Overnight PR Routine
+
+> **Loop Engineering** — the `/schedule` verb runs a routine *while you are gone*. This is the "I don't write code, I write loops, and they write the code while I sleep" pattern: a scheduled routine that lands the fixable PRs overnight.
+
+## 🎯 Goal
+Each night, work the open-PR queue: auto-fix build failures, answer review comments in an isolated worktree, rebase stale branches — and leave anything ambiguous for a human in the morning.
+
+## ⏱️ Schedule
+Trigger: `daily` (overnight routine, runs while your laptop is closed).
+
+## ▶️ Run it
+```
+/schedule every night, watch my open PRs. For each: auto-fix build failures, answer review comments in a fresh worktree, and rebase what is stale. Leave anything ambiguous or product-sensitive for me. Keep state in git so a crash loses nothing. Post a morning summary.
+```
+
+## 🔁 Iteration steps
+1. **Perceive** — list open PRs and their CI/review state.
+2. **Isolate** — spin a fresh worktree per PR with `/worktree-init` (no cross-contamination).
+3. **Act** — `git-workflow-manager` fixes build failures, addresses review comments, rebases stale branches.
+4. **Verify** — re-run CI; push only when green; ambiguous items are flagged, never guessed.
+5. **Report** — post a morning summary via `slack-notifications`; update each PR with `/create-pr`.
+
+## 🛑 Stopping condition
+Every fixable PR is green and updated; ambiguous/product-sensitive items are flagged for human review (not auto-merged).
+
+## 💰 Budget & guardrails
+A nightly spend ceiling; never auto-merges; isolated worktrees so parallel fixes don't collide; state in git so a crash is recoverable.
+
+## 🧩 Referenced components
+- `command:git-workflow/worktree-init` — isolated workspace per PR.
+- `command:git-workflow/create-pr` — updates/opens PRs.
+- `agent:git/git-workflow-manager` — safe rebases, fixes and comment replies.
+- `hook:automation/slack-notifications` — the morning summary.
+
+## 💡 Example
+You wake up to three PRs rebased and green, two review comments answered with commits, and one PR flagged "needs a product decision" — exactly the one you should look at.