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.