feat(strands-py): add GoalLoop vended plugin with docs

.agents/skills/docs-audit/SKILL.md

@@ -52,6 +52,7 @@ Specific checks:
 - Are parameter names and types correct against the latest SDK source?
 - Are any documented features deprecated or removed?
 - Are internal cross-reference links working?
+- **Snippet file conventions:** TypeScript code must live in sibling `.ts` snippet files (included via `--8<--`), never inlined in MDX. Each TypeScript fence should include both an imports snippet (`_imports.ts`) and a body snippet so the rendered block is self-contained. Verify that each `--8<-- "path:region"` directive references a real file with a matching `[start:region]`/`[end:region]` pair. Flag inlined TypeScript or missing imports includes as structural issues.
 
 ### Step 4: AI-readability check
 

.agents/skills/docs-reviewer/SKILL.md

@@ -27,24 +27,39 @@ Reference `../../references/voice-guide.md` for the full layer definitions. Chec
 - **Narrative flow:** Start with why the topic matters and what use-case problems it solves. Throughout, show how to implement using Strands SDK in a self-contained, concise way.
 - **Framing:** Does the first sentence of every section describe the developer's goal? Flag sections leading with API descriptions.
 - **Register:** Is the tone appropriate for the content type?
-- **Constraints:** Scan for banned phrases, em-dashes, passive voice, hedging. Apply type-aware overrides (passive in reference is fine; longer sentences in explanation are fine). Flag any prose inside a `<Tab>` that names the language of that tab (e.g., "Python requires..." inside the Python tab, "In TypeScript..." inside the TypeScript tab). The reader chose the tab; they know what language they're reading. Flag language-specific identifiers spelled out manually in shared prose — these should use the `<Syntax>` component to adapt to the reader's language selection.
+- **Constraints:** Scan for banned phrases, em-dashes, passive voice, hedging. Apply type-aware overrides (passive in reference is fine; longer sentences in explanation are fine).
 - **Authenticity:** Structural variety, visible editorial choices, concision.
 
-### 2. Terminology Consistency
+### 2. Multi-Language Correctness
+
+For pages with `<Tabs>` for Python and TypeScript:
+
+- Prose between tabs is language-neutral. Flag prose inside a `<Tab>` that names the language of that tab (e.g., "Python requires..." inside the Python tab). The reader chose the tab; they know.
+- Flag language-specific identifiers spelled out manually in shared prose — these should use the `<Syntax>` component to adapt to the reader's language selection.
+- Headings describe the concept, not the API. Flag headings containing language-specific parameter names or syntax (e.g. `preserve_context=False`, `preserveContext: false`). The table of contents should read the same regardless of language.
+- Callout boxes (`:::note`, `:::caution`, etc.) meet the bar defined in `mdx-authoring.md`. Most facts belong as inline prose.
+
+### 3. Terminology Consistency
 
 Reference `../../references/terminology.md`. Check every technical term against the lock file. Flag any non-canonical synonym.
 
-### 3. Code Example Quality
+### 4. Code Example Quality
 
 For each code block:
 - Structurally complete (Stripe principle): imports present, variables defined, copy-paste-ready without hunting for context.
 - Self-explanatory (Deno principle): makes sense without surrounding prose; comments explain intent, not mechanics.
 - Self-documenting, concise variable names (no `foo`, `bar`, `my_var`).
 - Focused on one concept.
 - Non-deterministic output labeled "Typical output" per voice guide patterns.
-- Claim parity: every claim made by surrounding prose or in-snippet comments is demonstrated by the code. If the prose says "this retries an additional error type," the code must show the override. If a comment says "preserves the status field," that field must appear in the reconstruction. Type-correct snippets that don't back their claims slip past typecheck and erode trust faster than missing examples.
+- Claim parity: every claim made by surrounding prose or in-snippet comments is demonstrated by the code. If the prose says "this retries an additional error type," the code must show the override. Type-correct snippets that don't back their claims slip past typecheck and erode trust faster than missing examples.
+
+Site build conventions (reference `../../references/mdx-authoring.md`):
+- TypeScript code uses `--8<--` snippet includes from sibling `.ts` files, never inlined in MDX. Flag raw TypeScript inside a code fence.
+- Each TypeScript fence includes both an imports snippet and a body snippet. A body-only include missing its imports is incomplete.
+- Python may be inlined.
+- Diagrams use ` ```mermaid ` fences, not ASCII art or box-drawing characters.
 
-### 4. Human+AI Readability
+### 5. Human+AI Readability
 
 - Context at top (first paragraph states what the page covers).
 - Prerequisites explicit (not assumed from prior pages).
@@ -54,17 +69,17 @@ For each code block:
 - Inline code backtick-formatted.
 - Page works standalone for both a human from search and an AI assistant.
 
-### 5. Content Type Alignment
+### 6. Content Type Alignment
 
 - Does structure match what the voice guide prescribes for this type?
 - Is information in the right place? (No conceptual background in how-to guides.)
 - Cross-references point to the correct type (how-to links to reference for details, not duplicating).
 
 ## Verdict System
 
-After scoring all five dimensions, assign exactly one verdict:
+After scoring all dimensions, assign exactly one verdict:
 
-**Ship it** — All five dimensions score well. At most one warning with minor phrasing suggestions. Zero failing scores. Zero terminology violations. Code examples are structurally complete. Ready for human review.
+**Ship it** — All dimensions score well. At most one warning with minor phrasing suggestions. Zero failing scores. Zero terminology violations. Code examples are structurally complete. Ready for human review.
 
 **Tighten** — Two or more warnings, or one failing score fixable without restructuring. Typical triggers: voice register bleed, 3+ terminology slips, >40% verbosity, missing "typical output" labels, structural sameness (no editorial judgment visible). Provide specific line-level fixes. Writer addresses and re-submits.
 
@@ -86,6 +101,7 @@ If unsure between Tighten and Rethink: "Can the writer fix this by editing in pl
 | Dimension | Score | Key Finding |
 |-----------|-------|-------------|
 | Voice stack | ... | ... |
+| Multi-language | ... | ... |
 | Terminology | ... | ... |
 | Code examples | ... | ... |
 | AI-readability | ... | ... |

.agents/skills/docs-writer/SKILL.md

@@ -49,14 +49,24 @@ Write each section following the outline.
 - Match snippet length to the complexity of what's being demonstrated. Bias toward brevity. If setup machinery dwarfs the feature being shown, the snippet is overweight.
 - Snippets must be copy-paste-runnable: imports present, variables defined, no missing context.
 - Prefer prose over a snippet for trivial API surface. A single property, a single method call, or a one-line config change is often clearer as inline backtick code in a sentence than as a dedicated code block. Reach for a snippet when the shape, ordering, or interaction between calls carries the lesson.
+- Diagrams use ` ```mermaid ` fences (flowchart, sequence, etc.). Never use ASCII art or box-drawing characters for diagrams. The site renders mermaid natively.
 
 ### Step 3b: Apply MDX formatting
 
-Apply MDX formatting patterns from `../../references/mdx-authoring.md` — especially Tabs/Tab syntax, the `<Syntax>` component for inline language-specific identifiers, snippet includes, and callout syntax.
+Apply MDX formatting patterns from `../../references/mdx-authoring.md` — especially Tabs/Tab syntax, the `<Syntax>` component for inline language-specific identifiers, snippet includes, and callout syntax (default to inline prose; callouts are rare).
 
 When shared prose needs to reference a language-specific identifier (method name, parameter, class, etc.), use `<Syntax py="..." ts="..." />`. This keeps prose clean and adapts to the reader's language selection. Never spell out both variants manually in prose.
 
-Code examples longer than a few lines live in runnable `.ts`/`.py` source files alongside the MDX page, not inline. Pull them in via the `--8<--` include syntax. See "Snippet Inclusion" and "TypeScript Snippet Scoping" in `mdx-authoring.md` for the imports/body file pattern and naming conventions.
+**TypeScript code is never inlined in MDX.** All TypeScript examples live in runnable `.ts` snippet files alongside the page and are included via `--8<--` directives. Two files per page:
+
+- **`<page>_imports.ts`** — one named snippet region per example's import set. Every example gets its own imports snippet so the rendered block is self-contained.
+- **`<page>.ts`** — body snippets scoped in blocks.
+
+In the MDX, each TypeScript code fence contains two `--8<--` includes (imports + body) inside a single fence so it renders as one copy-pasteable block. Every example must include its imports — a body-only include that omits the import line produces a snippet that isn't runnable.
+
+Read `../../references/mdx-authoring.md` ("Snippet Inclusion" and "TypeScript Snippet Scoping") for the full specification. Look at any existing page with TypeScript tabs in the same directory for the concrete file layout.
+
+Python code may be inlined directly in the MDX since Python files in the docs tree don't go through a type-checker.
 
 ### Step 4: Constrain
 
@@ -71,7 +81,9 @@ Then self-check against hard constraints:
 - Terminology matches the lock file
 - Code examples are contextually complete (imports present, runnable)
 - Code examples use proper backtick formatting
-- Never name the language inside its own tab. The reader selected the tab; they already know. State facts directly without prefixing the language name.
+- All prose outside a `<Tab>` is language-neutral. No Python or TypeScript parameter names, no language-specific syntax (e.g. `preserve_context=False` or `preserveContext: false`). Describe the concept in plain English; the code inside each tab shows the language-specific spelling.
+- Headings describe the concept, never the API. No parameter names or syntax in headings.
+- Never name the language inside its own tab. The reader selected the tab; they already know.
 
 ### Step 4b: Verify code accuracy
 
@@ -123,6 +135,7 @@ Follow the git workflow described in the repo's `AGENTS.md` and `CONTRIBUTING.md
 
 ## Gotchas
 
+- **Never inline TypeScript in MDX.** TypeScript examples live in sibling `.ts` snippet files and are included via `--8<--` directives. Inlined TypeScript fails review. See Step 3b and `mdx-authoring.md`.
 - Always verify code against SDK source. The most common failure mode is plausible imports that don't exist or parameters with wrong names.
 - Terminology lock is strict. "Hook" not "callback." "Plugin" not "middleware." "Tool" not "function." Check before drafting.
 - The constraint overrides table relaxes different rules per content type. Don't apply tutorial constraints to reference pages.

site/src/config/navigation.yml

@@ -88,6 +88,7 @@ sidebar:
               - docs/user-guide/concepts/plugins/skills
               - docs/user-guide/concepts/plugins/steering
               - docs/user-guide/concepts/plugins/context-offloader
+              - docs/user-guide/concepts/plugins/goal-loop
           - label: Interventions
             items:
               - label: "Overview"