AetherAI3 · dbarrante · Jul 20, 2026
diff --git a/README.md b/README.md
@@ -2,7 +2,7 @@
 
 # Agentic Loops
 
-**21 autonomous, self-contained "loop" systems that turn Claude Code (or any AI coding agent) into a full audit-and-fix pipeline — with built-in adversarial review, confidence scoring, and safe rollback.**
+**22 autonomous, self-contained "loop" systems that turn Claude Code (or any AI coding agent) into a full audit-and-fix pipeline — with built-in adversarial review, confidence scoring, and safe rollback.**
 
 [![GitHub stars](https://img.shields.io/github/stars/DBarr3/agentic-loops?style=social)](https://github.com/DBarr3/agentic-loops/stargazers)
 [![License: MIT](https://img.shields.io/badge/license-MIT-blue.svg?style=flat-square)](LICENSE)
@@ -24,7 +24,7 @@ Each loop is a complete, runnable audit-and-fix system in one markdown file —
 
 - [Quick Start](#quick-start)
 - [The Loop Catalog](#the-loop-catalog)
-- [Meta-Loops — Loops That Run the Other 15](#meta-loops--loops-that-run-the-other-15)
+- [Meta-Loops — Loops That Run the Catalog](#meta-loops--loops-that-run-the-catalog)
 - [How It Works](#how-it-works)
 - [Installing as a Claude Code Skill](#installing-as-a-claude-code-skill)
 - [Suggested Cadence](#suggested-cadence)
@@ -66,14 +66,15 @@ Three ways to use this repo:
 | [13](skills/LOOP-13-drift-debt.md) | Architectural Drift & Debt | Continuous Evaluation | read-only | Detects layer violations, circular deps, dead APIs/services; scores technical debt 0–100 across six axes, trended over time. |
 | [14](skills/LOOP-14-governance-telemetry.md) | Governance & Telemetry | Runtime Observability | read-only | Audits the autonomous system itself: is it improving, looping, degrading, wasting tokens, or getting less reliable? |
 | [15](skills/LOOP-15-self-optimization.md) | Self-Optimization Meta-Loop | Continuous Evaluation | branch-mutating (loops only) | The recursive-improvement loop: failure → root cause → fix → generalized pattern → proposed diff to the loops themselves. Human-gated always. |
+| [22](skills/LOOP-22-website-growth-overhaul.md) | Website Growth & Simplification Overhaul | Website Growth, Search Visibility & Generative Discovery | branch-mutating | Evidence-first whole-site overhaul: simplify routes/content/UI, repair technical SEO, validate entity truth, test generative retrieval, and protect accessibility, performance, and conversion. |
 
 **Risk classes:** `read-only` never touches your code · `branch-mutating` works only on an isolated loop branch, never main · `infra-touching` reads live infrastructure and proposes plans, never applies changes without explicit approval. (Same three classes apply to the meta-loops and integration below.)
 
-## Meta-Loops — Loops That Run the Other 15
+## Meta-Loops — Loops That Run the Catalog
 
-LOOP-01 through LOOP-15 each audit one fixed surface. LOOP-16 through LOOP-20 are the five base meta-loops: they take *other loops* — or a plain-language goal — as their input. LOOP-21 is the first integration loop, composing all five into a full merge lifecycle. Notation below: `[NN + NN]` = loops feeding in, `→` = then, `?` = branch point.
+LOOP-01 through LOOP-15 and LOOP-22 each audit one fixed surface. LOOP-16 through LOOP-20 are the five base meta-loops: they take *other loops* — or a plain-language goal — as their input. LOOP-21 is the first integration loop, composing all five into a full merge lifecycle. Notation below: `[NN + NN]` = loops feeding in, `→` = then, `?` = branch point.
 
-**[LOOP-20 — Goal Pipeline](skills/LOOP-20-goal-pipeline.md) is the one to start with** — the front door. Hand it a goal in plain English and it plans, checks, and dispatches the other 19 for you. Everything below is a tool LOOP-20 already knows how to reach for.
+**[LOOP-20 — Goal Pipeline](skills/LOOP-20-goal-pipeline.md) is the one to start with** — the front door. Hand it a goal in plain English and it plans, checks, and dispatches the applicable catalog loops for you. Everything below is a tool LOOP-20 already knows how to reach for.
 
 ---
 
@@ -110,12 +111,12 @@ Diverse candidate ideas, one shared debate-and-mutation arena, one converged ide
 Pairs with: any loops with open findings to seed candidates from + 11 (final gate on the handoff) + 20 (receives it).
 
 **[20 — Goal Pipeline](skills/LOOP-20-goal-pipeline.md)** · `read-only→branch` · **flagship**
-Plain-language goal in, validated dependency-checked plan out, dispatched into whichever of 01–19 fit.
+Plain-language goal in, validated dependency-checked plan out, dispatched into whichever catalog loops fit.
 ```
 20: goal="harden API + dedupe code" → decompose → [01] + [13] independent → 16 fan-out → 11 reviews plan → dispatch
 ```
 *Example: one goal implies two unrelated tasks — LOOP-20 proves they don't conflict, hands both to LOOP-16 to run in parallel instead of you manually sequencing them, and keeps re-checking the plan as results come in.*
-Pairs with: everything — this is the loop that decides which of the other 19 to run.
+Pairs with: everything — this is the loop that decides which other loops to run.
 
 **[21 — Merge Protocol](skills/LOOP-21-merge-protocol.md)** · `branch-mutating` · **integration**
 Anchor the real remote trunk, capture a PR and its goals immutably, adversarially simplify it one verified change at a time, prove CI actually ran, merge only with operator approval, then replay the original contract over the entire integrated trunk and open a scoped follow-up PR for real gaps.
@@ -157,6 +158,7 @@ A reasonable starting rhythm — tune it to your team:
 | Pre-release | 08 (CI/CD), 12 (test/mutation/chaos), 06 (UX/UI) |
 | Monthly deep audit | 07 (infra), 09 (data layer), 10 (AI security), 05 (memory) |
 | Continuous / every N runs | 14 (governance), then 15 (self-optimization) |
+| Relaunch or growth overhaul | 22 (website growth, simplification, SEO/GEO) |
 
 ## Contributing
 

diff --git a/skills/LOOP-20-goal-pipeline.md b/skills/LOOP-20-goal-pipeline.md
@@ -1,7 +1,7 @@
 ---
 name: loop-goal-pipeline
 loop-id: LOOP-20
-description: The catalog's entry gate — turns a plain-language goal into a validated, cycle-checked task DAG, adversarially reviews the plan, then dispatches it into any combination of LOOP-01..19, re-verifying the DAG continuously as execution proceeds and routing verification failures back to goal clarification instead of running on a broken plan
+description: The catalog's entry gate — turns a plain-language goal into a validated, cycle-checked task DAG, adversarially reviews the plan, then dispatches it into any applicable catalog loops, re-verifying the DAG continuously as execution proceeds and routing verification failures back to goal clarification instead of running on a broken plan
 domain: Goal Intake & Plan Validation — Catalog Entry Gate
 risk-class: read-only→branch
 default-debate: FREE-MAD
@@ -11,9 +11,9 @@ composed-of: [LOOP-11, LOOP-16]
 
 # Mission
 
-Every other loop in this catalog assumes it already knows its target and scope. LOOP-20 is what decides that — the front door a plain-language goal walks through before any of LOOP-01 through LOOP-19 ever runs. A goal enters, gets validated for clarity and scope, decomposed into a task graph, checked for cycles and contradictions, adversarially reviewed, and only THEN dispatched — as one loop or, via LOOP-16's fan-out orchestrator, several independent loops running in parallel. Two properties separate this from a simple task-router: **the DAG is re-verified continuously as execution proceeds, not just once at intake** (a downstream loop's finding can invalidate an assumption the plan was built on — LOOP-20 catches that instead of letting execution drift silently out of sync with the plan), and **a verification failure routes back to goal clarification, not into a bad execution** (a cyclic or contradictory task graph means the goal itself was under-specified, and the fix belongs at the goal layer, not patched over in the DAG).
+Every other loop in this catalog assumes it already knows its target and scope. LOOP-20 is what decides that — the front door a plain-language goal walks through before a catalog loop runs. A goal enters, gets validated for clarity and scope, decomposed into a task graph, checked for cycles and contradictions, adversarially reviewed, and only THEN dispatched — as one loop or, via LOOP-16's fan-out orchestrator, several independent loops running in parallel. Two properties separate this from a simple task-router: **the DAG is re-verified continuously as execution proceeds, not just once at intake** (a downstream loop's finding can invalidate an assumption the plan was built on — LOOP-20 catches that instead of letting execution drift silently out of sync with the plan), and **a verification failure routes back to goal clarification, not into a bad execution** (a cyclic or contradictory task graph means the goal itself was under-specified, and the fix belongs at the goal layer, not patched over in the DAG).
 
-Without this loop, the other 19 are individually excellent but the operator has to manually decide "which loop, what scope, in what order" every time — and nothing catches a goal that implies a plan with a hidden circular dependency (e.g. "harden the API and also don't change any endpoint contracts the API hardening pass would need to change") until it's halfway executed. LOOP-20 is that missing layer: a validated goal produces a validated plan, and the plan's own execution keeps proving itself valid as it runs.
+Without this loop, the other catalog loops are individually excellent but the operator has to manually decide "which loop, what scope, in what order" every time — and nothing catches a goal that implies a plan with a hidden circular dependency (e.g. "harden the API and also don't change any endpoint contracts the API hardening pass would need to change") until it's halfway executed. LOOP-20 is that missing layer: a validated goal produces a validated plan, and the plan's own execution keeps proving itself valid as it runs.
 
 # Trigger
 
@@ -33,7 +33,7 @@ Without this loop, the other 19 are individually excellent but the operator has
 # Preconditions
 
 - [PROTOCOL] read.
-- The target catalog (this repo's `skills/LOOP-01..19-*.md`) readable, so node 2 can match goal-implied work to real loop capabilities rather than inventing dispatch targets that don't exist.
+- The target catalog (this repo's `skills/LOOP-*.md`) readable, so node 2 can match goal-implied work to real loop capabilities rather than inventing dispatch targets that don't exist.
 - Loop branch created before node 7 (dispatch) — nodes 1–6 are read-only planning; nothing mutates until a validated, adversarially-reviewed plan exists.
 
 # Execution DAG (numbered nodes, [P] = parallelizable)
@@ -58,7 +58,7 @@ Failure conditions: goal passes the clarity bar but the target doesn't exist/isn
 Output artifact: `node-1-goal-validation.md` (pass/fail + specific gaps if fail).
 
 **Node 2 — Task decomposition.**
-Action: break the validated goal into discrete tasks. For each task, match it against this catalog's real loop descriptions (`skills/LOOP-01..19-*.md`) — a task like "audit the backend for OWASP issues" maps to LOOP-01, "close test coverage gaps" maps to LOOP-12, "tune this one retry threshold" maps to LOOP-18, etc. A task with no reasonable match is NOT force-fit; it's marked `novel` for node 4.
+Action: break the validated goal into discrete tasks. For each task, match it against this catalog's real loop descriptions (`skills/LOOP-*.md`) — a task like "audit the backend for OWASP issues" maps to LOOP-01, "close test coverage gaps" maps to LOOP-12, "overhaul website SEO/GEO and simplify the public experience" maps to LOOP-22, and "tune this one retry threshold" maps to LOOP-18. A task with no reasonable match is NOT force-fit; it's marked `novel` for node 4.
 Tools: Read (catalog descriptions), reasoning tier for the matching judgment.
 Failure conditions: goal decomposes into zero tasks (too abstract despite passing node 1) → route to node 8 (back to node 1) rather than proceeding with an empty plan.
 Output artifact: `node-2-task-decomposition.md` — task table: `task | matched loop (or novel) | rationale`.