summer-engine 2.6.6 → 2.8.0

package/skills/workflow/playtesting-a-feature/SKILL.md

@@ -29,12 +29,9 @@ Static analysis is necessary but never sufficient for gameplay features. A clean
 NO "FEATURE SHIPPED" CLAIM WITHOUT A PLAYED WALKTHROUGH
 ```
 
-If you have not, in this session, called `summer_play` and either:
+If you have not, in this session, driven the feature and read back what happened, you cannot claim it works.
 
-1. Walked the feature yourself via MCP-driven repros where possible, OR
-2. Asked the user to walk it and confirmed the result via `summer_get_console` / `summer_get_debugger_errors`
-
-— then you cannot claim the feature works.
+**You walk the feature. Not the user.** A `RunVerification` probe presses your game's real inputs, reads state back across frames, and saves real rendered frames. Handing the walkthrough to the user is a last resort for things a probe genuinely cannot judge — see [What only a human can answer](#what-only-a-human-can-answer) — not the default.
 
 ## The Loop
 
@@ -51,7 +48,57 @@ Before pressing play, write down — in one or two sentences — what "feature w
 
 If you cannot describe the golden path in one sentence, you do not understand the feature well enough to verify it. Ask the user.
 
-### 2. Press play
+### 2. Walk the golden path with a probe
+
+Write the golden path as a `RunVerification` probe and send it as a raw op through `summer_batch`. The engine spawns a hidden, disposable game instance positioned offscreen, runs your GDScript, writes `results.json` plus any frames you saved, and kills the instance. It never touches the user's open editor, and nothing appears on their screen.
+
+```
+summer_batch ops:[{
+  "op": "RunVerification",
+  "probe_source": "<your GDScript>",
+  "max_seconds": 20
+}]
+```
+
+A probe extends `SummerProbeBase` and has: `report(key, value)`, `save_frame(name)`, `dump_tree()`, `press(action, hold_ms)`, `key(keycode, hold_ms)`, `finish()`.
+
+```gdscript
+extends SummerProbeBase
+
+func _ready() -> void:
+    await super._ready()
+    for i in 20:
+        await get_tree().physics_frame          # let the scene settle
+
+    var player := get_tree().current_scene.get_node("Player")
+    var start: Vector2 = player.position
+    save_frame("00_start")
+
+    await press("move_right", 500)              # await, or the hold never elapses
+    await get_tree().physics_frame
+    report("walked_right", player.position.x > start.x + 50)
+    save_frame("01_after_walk")
+
+    var y_before: float = player.position.y
+    await press("jump", 50)
+    var apex := y_before
+    for i in 25:
+        await get_tree().physics_frame
+        apex = min(apex, player.position.y)
+    report("jumped", apex < y_before - 30)
+    save_frame("02_after_jump")
+
+    finish()
+```
+
+Four rules the probe API will punish you for breaking:
+
+- **`press()` and `key()` are coroutines.** `await press("jump", 50)` — calling them bare starts the press and never releases it. You also cannot store one in a variable and await it later; it returns void.
+- **Assert on physics-frame-derived state.** `await get_tree().physics_frame` N times, then read positions. That is reproducible run to run.
+- **Assert inequalities, never exact values.** `press(hold_ms)` waits on the wall clock, so the number of physics frames a key is held drifts between runs — the same walk lands on x=245 one run and x=250 the next. `position.x > start.x + 50` is a real assertion; `position.x == 250.0` is a flaky test you wrote yourself.
+- **The global RNG is not seeded.** Anything downstream of `randf()` differs every run. Assert ranges, or seed it yourself in the probe.
+
+If the probe cannot express the check — no `SummerProbeBase` in this build, or a genuinely out-of-process feature — fall back to `summer_play` + console reads:
 
 ```
   summer_clear_console
@@ -61,14 +108,9 @@ If you cannot describe the golden path in one sentence, you do not understand th
 
 `summer_clear_console` first so the buffer is not polluted by a previous session's errors. If you skip this, you will chase ghost errors that have nothing to do with the current feature.
 
-### 3. Walk the golden path
-
-The MCP cannot simulate keyboard input, mouse motion, or controller. So either:
-
-- **The user plays.** Ask them to walk the exact golden path you defined. Wait for their confirmation that they did. Then check state.
-- **You drive via scene mutation.** For features that can be triggered through `summer_set_prop` or function calls exposed to the editor (e.g. autoload methods), drive them programmatically. Be honest about which path you took.
+### 3. Read back what actually happened
 
-After the walkthrough:
+The probe's `results.json` is your primary evidence. Then check the editor's own view:
 
 ```
   summer_get_console            (look for unexpected prints, warnings)
@@ -76,8 +118,20 @@ After the walkthrough:
   summer_get_diagnostics        (overall counts)
 ```
 
+A probe also collects engine errors itself — `results.json` carries `errors_seen`. Read it. An empty `reports` block with `finished: false` means the probe hit its `max_seconds` ceiling before calling `finish()`, which is a failure, not a pass.
+
 If anything is non-zero or unexpected, the feature is not done. Go to `summer:debug`.
 
+### What only a human can answer
+
+A probe reports facts. It cannot hold an opinion. Ask the user only when the question is genuinely experiential:
+
+- **Does it feel right?** Floaty jumps, sluggish input, mushy hit feedback — see `summer:debugging-game-feel`.
+- **Does it look good?** Composition, colour, readability. A probe can prove a light exists and prove the frame is not black; it cannot tell you the scene is ugly.
+- **Is this fun?** Not a measurable property.
+
+"I cannot simulate input" is not on that list, and has not been true since `RunVerification` shipped. If you catch yourself asking the user to press a key, write the probe instead.
+
 ### 4. Probe the edges
 
 The golden path proves the happy case. Most gameplay bugs live in the edges. Before claiming done, probe at least these four classes:
@@ -120,13 +174,15 @@ The console catches "looks right but isn't right" cases — silent errors, depre
 
 ## When to record video vs when console+diagnostics is enough
 
-Console + diagnostics + your walkthrough description is usually enough. Ask the user for a video or screenshot when:
+Your probe already produces the visual record: `save_frame()` writes a real rendered JPEG at each step, and a sequence of them across a movement is a flipbook of the feature happening. **You are not the only one who cannot see the game — until you save frames, nobody can.** Save them at the interesting moments and read them back.
+
+Ask the user for a video or a live look only when:
 
-- The feature is **visual** (camera, lighting, particles, animation, UI layout) and the user is the only one who can see the result.
 - The feature **feels wrong** — see `summer:debugging-game-feel`. Frame counts and console output cannot capture "the jump feels floaty."
-- The bug is **non-deterministic** — sometimes-works features need a recording to share with anyone diagnosing later.
+- The bug is **non-deterministic** and your probe cannot reproduce it after several attempts.
+- The judgement is aesthetic — see [What only a human can answer](#what-only-a-human-can-answer).
 
-Don't ask for video reflexively. Most features can be verified through `summer_get_console` + a "did the golden path work?" question. Cost-aware.
+Don't ask reflexively. A saved frame sequence answers most "did it visually work" questions without involving the user at all.
 
 ## Red Flags — STOP
 
@@ -137,10 +193,15 @@ Don't ask for video reflexively. Most features can be verified through `summer_g
 | "User said make this — I'll move on once it builds" | The user wants the feature to work, not to build. |
 | "It would take too long to play" | Playtest takes 60 seconds. Shipping a broken feature costs hours. |
 | "The unit test passes" | Unit tests cover code paths, not gameplay sequences. |
-| "I already played it in a previous session" | State changed. Press play in this session. |
+| "I already played it in a previous session" | State changed. Verify in this session. |
 | "I'll let the user catch any issues" | That is the user's job description for a non-AI engineer. Yours is to ship working features. |
 | Skipping `summer_clear_console` before `summer_play` | You will chase last session's errors. |
 | Skipping `summer_get_console` because diagnostics looked fine | Silent warnings and signal misfires hide there. |
+| "The MCP can't simulate input, so the user has to test it" | False. `RunVerification` presses actions and keys. Write the probe. |
+| "I'll ask the user to press jump and tell me what happened" | You can press jump. They should not have to QA your work. |
+| Probe returned `finished: false`, you called it a pass | It hit `max_seconds` before `finish()`. That is a failure. |
+| Asserting `position.x == 250.0` in a probe | Hold time is wall-clock. Assert `> start.x + 50`. |
+| `press("jump", 50)` without `await` | It is a coroutine. The key is never released. |
 
 ## Rationalization Prevention
 
@@ -154,10 +215,22 @@ Don't ask for video reflexively. Most features can be verified through `summer_g
 
 ## When the engine isn't running
 
-If `summer_play` returns "Summer Engine is not running":
+`RunVerification` is dispatched by the editor, so it needs the editor running. **The verify instance itself does not.** You can spawn exactly the same probe runtime straight from your shell, with no editor at all:
+
+```bash
+/Applications/Summer.app/Contents/MacOS/Summer \
+  --path <project-dir> \
+  --summer-verify <abs-path-to-probe.gd> \
+  --summer-verify-out <abs-out-dir> \
+  --summer-verify-max 30
+```
+
+Then read `<out-dir>/results.json` and the JPEGs beside it. The probe must extend the base class — copy `summer_probe_base.gd` into the project and `extends "res://summer_probe_base.gd"`, or use the project's `tests/autopilot/` scaffold if it has one. See `summer:headless-scripting` for the full pattern and its traps.
+
+So if `summer_play` returns "Summer Engine is not running":
 
-1. Tell the user: `summer run` to start it.
-2. Do not claim the feature is verified from static analysis alone. Say: "Code compiles and looks correct, but I cannot playtest until the engine is running."
+1. Run the probe directly from the shell as above. That is a real playtest.
+2. Only if that is also impossible: tell the user `summer run` to start the editor, and say plainly "code compiles and looks correct, but I have not played it" — do not claim verification from static analysis alone.
 3. When the engine comes back, run the loop.
 
 ## The Bottom Line

package/skills/workflow/skill-create/SKILL.md

@@ -15,9 +15,9 @@ allowed-tools: Read Write Glob Grep
 
 Ask the user:
 - **Name** (kebab-case, ≤ 64 chars). Example: `state-machine-patterns`.
-- **Category** (one of the 20 in `SKILL_CATEGORIES` at `src/lib/skills-registry.ts`). Example: `scripting-patterns`.
+- **Category** (must be one of the values in the `SKILL_CATEGORIES` array at `src/lib/skills-registry.ts` — read it, do not guess). Example: `scripting-patterns`.
 - **One-sentence description** for the frontmatter.
-- **Template-id** (optional). Lookup against `references/template-registry.md`.
+- **Template-id** (optional). Lookup against `../../../references/template-registry.md`.
 
 ### 2. Create the folder
 
@@ -80,13 +80,13 @@ May I <action>?
 
 → **template-id**: `<template-id>`
 → **Repo**: <github URL from references/template-registry.md>
-→ **Bootstrap**: `summer template clone <template-id> my-game`
+→ **Bootstrap**: `summer create <template-id> my-game` (see `summer list templates` for the slugs)
 
 ## See also
 
-- `references/godot-version.md`
-- `references/mcp-tools-reference.md`
-- `references/gd-style.md`
+- `../../../references/godot-version.md`
+- `../../../references/mcp-tools-reference.md`
+- `../../../references/gd-style.md`
 - (other relevant skills)
 ```
 
@@ -149,5 +149,5 @@ This skill writes files (the new skill folder + plugin manifest update + TS regi
 
 ## See also
 
-- `references/collaborative-protocol.md`
+- `../../../references/collaborative-protocol.md`
 - `workflow/skill-test/SKILL.md`

package/skills/workflow/skill-test/SKILL.md

@@ -21,7 +21,7 @@ For a single skill at `skills/<category>/<name>/`, run these checks:
    - At least one `summer_*` MCP tool example.
    - At least one file-edit fallback block (e.g., raw `.tscn` snippet) OR an explicit "no fallback for this — Summer MCP required" note.
 4. **Collaborative protocol.** If the skill triggers user-visible writes, body must contain at least one of: `May I`, `I'm about to`, `Continue?`, `OK?`, `Proceed?`. Skills that only inspect/read are exempt.
-5. **Template-id resolved.** If the skill's frontmatter declares `template-id: <id>`, that id must exist in `references/template-registry.md`.
+5. **Template-id resolved.** If the skill's frontmatter declares `template-id: <id>`, that id must exist in `../../../references/template-registry.md`.
 6. **Tests/spec.md present.** Every skill in a non-`_meta` category must have `tests/spec.md` with at least one `## Case` heading.
 7. **Relative links resolve.** Every `](../references/...)`, `](../../references/...)`, `](./references/...)`, and `](./examples/...)` link must point at an existing file (FAIL if broken). Forward references in `## See also` to other SKILL.md files (e.g., `[design-mechanic](../../gameplay-mechanics/design-mechanic/SKILL.md)`) are allowed to dangle and only WARN if the target is missing — the catalog evolves and skills should be free to point at planned skills.
 
@@ -80,7 +80,7 @@ This skill is **read-only**. It never writes. No "May I" needed.
 
 ## See also
 
-- `references/collaborative-protocol.md`
-- `references/template-registry.md`
+- `../../../references/collaborative-protocol.md`
+- `../../../references/template-registry.md`
 - `tests/runner.md`
 - `tests/specs/` — per-skill behavioral specs

package/skills/workflow/using-summer/SKILL.md

@@ -36,12 +36,22 @@ If `CLAUDE.md` says "skip the brainstorm, just build it" and a skill says "alway
 Two layers:
 
 - **Skills** — discipline guides that fire on specific situations: brainstorming a game, designing a mechanic, building an FPS controller, debugging a crash, shipping a build. Each one is a SKILL.md you load via the Skill tool.
-- **MCP tools** — `summer_*` tools that talk to the running Summer Engine on `localhost:6550`. Scene mutation (`summer_add_node`, `summer_set_prop`), inspection (`summer_get_scene_tree`, `summer_inspect_node`), play/diagnostics (`summer_play`, `summer_get_diagnostics`), asset import/generation (`summer_import_from_url`, `summer_generate_3d`), and 30+ more.
+- **MCP tools** — `summer_*` tools that talk to the running Summer Engine on `localhost:6550`. Scene mutation (`summer_add_node`, `summer_set_prop`), inspection (`summer_get_scene_tree`, `summer_inspect_node`), play/diagnostics (`summer_play`, `summer_get_diagnostics`), asset import/generation (`summer_import_from_url`, `summer_generate_3d`), whole-project sync to Summer Cloud (`summer_cloud_push`, `summer_cloud_pull`; see `summer:summer-cloud`), and 30+ more.
 
-**Scripting language:** Summer Engine is compatible with Godot 4.5. You can write game code in either:
+**Scripting language:** The user is making a Summer game with the Summer SDK.
+GDScript is the default creator language. Summer currently uses the 4.6.1
+upstream technical base, plans to adopt 4.7.1 next, and follows upstream
+continuously. Confirm version-sensitive behavior from the engine's own version
+string rather than turning that base into the product identity. You can write
+game code in either:
 
 - **GDScript** (`.gd`) — the default. Best supported by Summer skills (see `summer:gdscript-patterns`). Use this unless the user has explicitly chosen C#.
-- **C#** (`.cs`) — fully supported by the engine. There is no `summer:csharp-patterns` skill yet — when writing C#, use the Godot 4.5 C# API from first principles. The patterns are different (different lifecycle method names, different signal API, different export attributes), so don't blindly translate GDScript idioms. Confirm with the user that they want C# before producing it; switching languages mid-project is painful.
+- **C#** (`.cs`) — supported by the shipped Mono build. There is no
+  `summer:csharp-patterns` skill yet. When writing C#, use the upstream C# API
+  reference matching the current Summer technical base. The lifecycle, signal
+  API, and export attributes differ, so do not blindly translate GDScript
+  idioms. Confirm that the user wants C# before producing it; switching
+  languages mid-project is painful.
 
 Scenes are always `.tscn`/`.scn`. Resources are always `.tres`/`.res`. Drive the engine through `summer_*` tools — do not hand-edit `.tscn` files; the editor holds in-memory state that diverges from disk.
 
@@ -90,6 +100,7 @@ These thoughts mean STOP. Check skills first.
 | "I'll write the GDScript myself, no skill" | `gdscript-patterns` encodes idioms that Claude/Codex/Cursor regularly get wrong (signal connection, type hints, `_ready` vs `_process`). |
 | "The engine isn't running, I'll just edit files" | Editing scene files directly while the engine is running silently overwrites in-memory state. Check the skill. |
 | "I remember this skill" | Skills evolve. Re-read the current version. |
+| "I'll just zip the project to move it to another machine" | `summer:summer-cloud` syncs the whole project (big assets included) by hash, with restorable versions. Load it whenever the user mentions sync, a second machine, sharing with a teammate, backing up assets, or restoring a version. |
 
 ## Skill Priority
 
@@ -128,6 +139,24 @@ If skills aren't found or the MCP server fails to start:
 2. If not, point them at: `npx -y summer-engine@latest setup <agent> --yes --force`.
 3. If `summer doctor` is available, run it: `summer doctor` reports auth, engine, port, project memory, and skill state.
 
+## When Summer Is Stale
+
+Run `summer doctor` early in a fresh Summer session when setup, MCP tools, slash commands, or skills behave oddly. If doctor reports `cli-version-current` or `skills-version-stale` as warning/fail, refresh before continuing:
+
+```
+npx clear-npx-cache && npx -y summer-engine@latest setup <agent> --yes --force
+```
+
+Use the real agent slug from doctor or the current environment (`claude-code`, `codex`, `cursor`, `gemini`, `github-copilot`, `vscode-copilot`, `opencode`, etc.).
+
+Why this exact command matters:
+
+- `@latest` forces npm/npx to resolve the current published Summer CLI instead of reusing a stale cached package.
+- `clear-npx-cache` clears old npx package material on machines that keep serving an older Summer.
+- `setup ... --force` rewrites copied skill/slash-command files, which do not update just because the MCP server restarted.
+
+After the refresh, restart or reload the agent/MCP session if tools were missing. MCP tool changes load on MCP reconnect; copied skills and slash commands load when the agent notices the rewritten files or starts a fresh session.
+
 ## User Instructions Trump Everything
 
 A direct user instruction ("skip the brainstorm", "just write the code", "don't use the MCP, edit files") overrides this skill. Surface the trade-off in one sentence ("Skipping brainstorm — heads up, scope creep is the most common reason game projects die.") and proceed as instructed.

package/skills/workflow/verification-before-completion/SKILL.md

@@ -45,6 +45,7 @@ Skip any step = lying, not verifying
 | Linter clean | Linter output: 0 errors | Partial check, extrapolation |
 | Build succeeds | Build command: exit 0 | Linter passing, logs look good |
 | Bug fixed | Test original symptom: passes | Code changed, assumed fixed |
+| Gameplay behaviour works | `RunVerification` probe: pressed the input, read the state back | Script compiles, game boots, diagnostics clean |
 | Regression test works | Red-green cycle verified | Test passes once |
 | Agent completed | VCS diff shows changes | Agent reports "success" |
 | Requirements met | Line-by-line checklist | Tests passing |
@@ -72,6 +73,7 @@ Skip any step = lying, not verifying
 | "I'm tired" | Exhaustion ≠ excuse |
 | "Partial check is enough" | Partial proves nothing |
 | "Different words so rule doesn't apply" | Spirit over letter |
+| "There's no way to test gameplay, I'll ask the user" | There is. A `RunVerification` probe presses input and reads state back. Ask the user only for what a probe cannot judge. |
 
 ## Key Patterns
 

package/skills/workflow/writing-plans/SKILL.md

@@ -13,7 +13,7 @@ Assume they are a skilled developer, but know almost nothing about our toolset o
 
 **Announce at start:** "I'm using the writing-plans skill to create the implementation plan."
 
-**Context:** If working in an isolated worktree, it should have been created via the `summer:using-git-worktrees` skill at execution time.
+**Context:** If the work needs isolation from the current checkout, create a git worktree for it before execution starts.
 
 **Save plans to:** `docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md`
 - (User preferences for plan location override this default)
@@ -49,7 +49,7 @@ This structure informs the task decomposition. Each task should produce self-con
 ```markdown
 # [Feature Name] Implementation Plan
 
-> **For agentic workers:** REQUIRED SUB-SKILL: Use summer:subagent-driven-development (recommended) or summer:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+> **For agentic workers:** implement this plan task-by-task, in order, checking off each step as it lands. Steps use checkbox (`- [ ]`) syntax for tracking. Dispatch a fresh subagent per task where the tasks are independent (see summer:dispatching-parallel-agents), otherwise execute inline with a review checkpoint after each task.
 
 **Goal:** [One sentence describing what this builds]
 
@@ -139,14 +139,14 @@ After saving the plan, offer execution choice:
 
 **1. Subagent-Driven (recommended)** - I dispatch a fresh subagent per task, review between tasks, fast iteration
 
-**2. Inline Execution** - Execute tasks in this session using executing-plans, batch execution with checkpoints
+**2. Inline Execution** - Execute tasks in this session, batched with checkpoints
 
 **Which approach?"**
 
 **If Subagent-Driven chosen:**
-- **REQUIRED SUB-SKILL:** Use summer:subagent-driven-development
-- Fresh subagent per task + two-stage review
+- One fresh subagent per task, each given the task's full text and nothing else from this session's history. See `summer:dispatching-parallel-agents` for prompt structure and when parallelism is safe.
+- Two-stage review: read the subagent's summary, then verify the diff yourself before starting the next task.
 
 **If Inline Execution chosen:**
-- **REQUIRED SUB-SKILL:** Use summer:executing-plans
-- Batch execution with checkpoints for review
+- Execute tasks in order in this session, stopping at a checkpoint after each task for review.
+- Never batch past a failing step. Fix it, verify it, then continue.

package/skills/workflow/writing-skills/SKILL.md

@@ -15,7 +15,7 @@ You write test cases (pressure scenarios with subagents), watch them fail (basel
 
 **Core principle:** If you didn't watch an agent fail without the skill, you don't know if the skill teaches the right thing.
 
-**REQUIRED BACKGROUND:** You MUST understand summer:test-driven-development before using this skill. That skill defines the fundamental RED-GREEN-REFACTOR cycle. This skill adapts TDD to documentation.
+**REQUIRED BACKGROUND:** This skill adapts the RED-GREEN-REFACTOR cycle to documentation. The cycle: write the test first and watch it FAIL for the reason you expect (red), make the smallest change that passes it (green), then clean up without changing behaviour (refactor). A test you never saw fail proves nothing.
 
 **Official guidance:** For Anthropic's official skill authoring best practices, see anthropic-best-practices.md. This document provides additional patterns and guidelines that complement the TDD-focused approach in this skill.
 
@@ -280,10 +280,12 @@ wc -w skills/path/SKILL.md
 **When writing documentation that references other skills:**
 
 Use skill name only, with explicit requirement markers:
-- ✅ Good: `**REQUIRED SUB-SKILL:** Use summer:test-driven-development`
+- ✅ Good: `**REQUIRED SUB-SKILL:** Use summer:verification-before-completion`
 - ✅ Good: `**REQUIRED BACKGROUND:** You MUST understand summer:investigating-bugs`
-- ❌ Bad: `See skills/testing/test-driven-development` (unclear if required)
-- ❌ Bad: `@skills/testing/test-driven-development/SKILL.md` (force-loads, burns context)
+- ❌ Bad: `See skills/debugging/debug` (unclear if required)
+- ❌ Bad: `@skills/debugging/debug/SKILL.md` (force-loads, burns context)
+
+**Check the skill exists before you point at it.** The registry of shipped skills is the `SKILL_REGISTRY` array in `src/lib/skills-registry.ts` and the `skills:` array in `.claude-plugin/plugin.json`. A `REQUIRED SUB-SKILL` pointing at a skill that was never shipped is worse than no cross-reference: the reader stops and looks for something that does not exist.
 
 **Why no @ links:** `@` syntax force-loads files immediately, consuming 200k+ context before you need them.
 
@@ -390,7 +392,7 @@ Edit skill without testing? Same violation.
 - Don't "adapt" while running tests
 - Delete means delete
 
-**REQUIRED BACKGROUND:** The summer:test-driven-development skill explains why this matters. Same principles apply to documentation.
+**Why this matters:** an untested change is an assertion, not a result. Same principle in documentation as in code.
 
 ## Testing All Skill Types
 

package/skills/workflow/writing-skills/testing-skills-with-subagents.md

@@ -10,7 +10,7 @@ You run scenarios without the skill (RED - watch agent fail), write skill addres
 
 **Core principle:** If you didn't watch an agent fail without the skill, you don't know if the skill prevents the right failures.
 
-**REQUIRED BACKGROUND:** You MUST understand summer:test-driven-development before using this skill. That skill defines the fundamental RED-GREEN-REFACTOR cycle. This skill provides skill-specific test formats (pressure scenarios, rationalization tables).
+**REQUIRED BACKGROUND:** the RED-GREEN-REFACTOR cycle as stated just above. This reference supplies the skill-specific test formats on top of it (pressure scenarios, rationalization tables).
 
 **Complete worked example:** See examples/CLAUDE_MD_TESTING.md for a full test campaign testing CLAUDE.md documentation variants.