diff --git a/.cursor-plugin/marketplace.json b/.cursor-plugin/marketplace.json
index 49f6d8ec..2446e592 100644
--- a/.cursor-plugin/marketplace.json
+++ b/.cursor-plugin/marketplace.json
@@ -26,7 +26,12 @@
     {
       "name": "thermos",
       "source": "thermos",
-      "description": "Thermo-nuclear branch review: deep security/correctness audits, harsh code-quality rubrics, parallel subagents, thermos orchestration, and optional merge-ready PR flows."
+      "description": "Rigorous branch review: deep security/correctness audits, harsh code-quality rubrics, parallel subagents, thermos orchestration, and optional merge-ready PR flows."
+    },
+    {
+      "name": "rigorous-implementation",
+      "source": "rigorous-implementation",
+      "description": "Implement code changes with structural simplicity, clean boundaries, and fresh verification evidence."
     },
     {
       "name": "create-plugin",
diff --git a/README.md b/README.md
index b3348e89..0c94d946 100644
--- a/README.md
+++ b/README.md
@@ -8,7 +8,8 @@ Official Cursor plugins for popular developer tools, frameworks, and SaaS produc
 |:-------|:-------|:-------|:---------|:-------------------------------------|
 | `continual-learning` | [Continual Learning](continual-learning/) | Cursor | Developer Tools | Incremental transcript-driven memory updates for AGENTS.md using high-signal bullet points only. |
 | `cursor-team-kit` | [Cursor Team Kit](cursor-team-kit/) | Cursor | Developer Tools | Internal team workflows used by Cursor developers for CI, code review, shipping, local automation, and verification. |
-| `thermos` | [Thermos](thermos/) | Cursor | Developer Tools | Thermo-nuclear branch review: deep security/correctness audits, harsh code-quality rubrics, parallel subagents, thermos orchestration, and optional merge-ready PR flows. |
+| `thermos` | [Thermos](thermos/) | Cursor | Developer Tools | Rigorous branch review: deep security/correctness audits, harsh code-quality rubrics, parallel subagents, thermos orchestration, and optional merge-ready PR flows. |
+| `rigorous-implementation` | [Rigorous Implementation](rigorous-implementation/) | Coding Agent System | Developer Tools | Implement code changes with structural simplicity, clean boundaries, and fresh verification evidence. |
 | `create-plugin` | [Create Plugin](create-plugin/) | Cursor | Developer Tools | Scaffold and validate new Cursor plugins. |
 | `agent-compatibility` | [Agent Compatibility](agent-compatibility/) | Cursor | Developer Tools | CLI-backed repo compatibility scans plus Cursor agents that audit startup, validation, and docs against reality. |
 | `cli-for-agent` | [CLI for Agents](cli-for-agent/) | Cursor | Developer Tools | Patterns for designing CLIs that coding agents can run reliably: flags, help with examples, pipelines, errors, idempotency, dry-run. |
diff --git a/cursor-team-kit/README.md b/cursor-team-kit/README.md
index f25739dc..00d9584c 100644
--- a/cursor-team-kit/README.md
+++ b/cursor-team-kit/README.md
@@ -31,14 +31,14 @@ Internal-style workflows for CI, code review, shipping, and test reliability. Th
 | `fix-merge-conflicts` | Resolve merge conflicts, validate build/tests, and summarize decisions |
 | `deslop` | Remove AI-generated code slop and clean up code style |
 | `workflow-from-chats` | Extract durable working preferences from chats into skills, rules, or docs |
-| `thermo-nuclear-code-quality-review` | Run an unusually strict maintainability review (code-judo, 1k-line rule, spaghetti, boundaries) |
+| `rigorous-code-quality-review` | Run an evidence-driven review with verified blockers, calibrated severity, and convergent re-reviews |
 
 ### Agents
 
 | Agent | Description |
 |:------|:------------|
 | `ci-watcher` | Monitor GitHub Actions runs and return concise pass/fail summaries |
-| `thermo-nuclear-code-quality-review` | Task subagent that runs the thermo-nuclear code quality rubric against a diff |
+| `rigorous-code-quality-review` | Task subagent that runs the rigorous code quality rubric against a diff |
 
 ### Rules
 
diff --git a/cursor-team-kit/agents/rigorous-code-quality-review.md b/cursor-team-kit/agents/rigorous-code-quality-review.md
new file mode 100644
index 00000000..f5b08313
--- /dev/null
+++ b/cursor-team-kit/agents/rigorous-code-quality-review.md
@@ -0,0 +1,23 @@
+---
+name: rigorous-code-quality-review
+description: Evidence-driven code quality audit for acceptance, correctness, regressions, and maintainability. Invoked via Task after a parent gathers diff, file contents, and prior review evidence. Loads the rubric from the `rigorous-code-quality-review` skill in the cursor-team-kit plugin.
+---
+
+# Rigorous Code Quality Review
+
+You are a **Task subagent**. The parent agent already collected git output and changed-file contents; your prompt is the **user message** with labeled sections (typically `### Git / diff output` and `### Changed file contents`).
+
+## Rubric
+
+1. Load the `rigorous-code-quality-review` skill (shipped in the cursor-team-kit plugin) and treat its `SKILL.md` as the **complete** rubric, including its evidence bar, severity calibration, durable findings, and re-review convergence rules.
+2. If that skill is not available, fall back to an evidence-driven audit: verify the task contract, report all demonstrated blockers, separate optional improvements, and preserve prior finding identity on re-review.
+
+## Work
+
+- Apply the rubric to the task contract, diff, contents, and prior findings supplied by the parent. Trace cross-file impact when the change touches module boundaries.
+- Output in the **priority order** the rubric specifies. Include every verified blocker on the initial pass; suppress new optional findings on re-review.
+- Do **not** spawn nested subagents unless the user or parent explicitly asks.
+
+## Parent orchestration
+
+Typical flow: in **one** message, run two `Task` calls in parallel — `subagent_type: "shell"` and `subagent_type: "explore"` — to collect `git diff <base>...HEAD` output and full contents of changed files (default base `main`). Then invoke this agent with `subagent_type: "rigorous-code-quality-review"` and a user prompt containing `### Git / diff output` and `### Changed file contents`.
diff --git a/cursor-team-kit/agents/thermo-nuclear-code-quality-review.md b/cursor-team-kit/agents/thermo-nuclear-code-quality-review.md
deleted file mode 100644
index dc83d959..00000000
--- a/cursor-team-kit/agents/thermo-nuclear-code-quality-review.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-name: thermo-nuclear-code-quality-review
-description: Thermo-nuclear code quality audit (maintainability, structure, 1k-line rule, spaghetti, code-judo). Invoked via Task after a parent gathers diff and file contents. Loads the rubric from the `thermo-nuclear-code-quality-review` skill in the cursor-team-kit plugin.
----
-
-# Thermo-Nuclear Code Quality Review
-
-You are a **Task subagent**. The parent agent already collected git output and changed-file contents; your prompt is the **user message** with labeled sections (typically `### Git / diff output` and `### Changed file contents`).
-
-## Rubric
-
-1. Load the `thermo-nuclear-code-quality-review` skill (shipped in the cursor-team-kit plugin) and treat its `SKILL.md` as the **complete** rubric — tone, approval bar, output ordering, code-judo / 1k-line / spaghetti rules.
-2. If that skill is not available, fall back to a harsh maintainability audit aligned with that skill's intent: ambitious simplification, no unjustified file sprawl past ~1k lines, no ad-hoc branching growth, explicit types and boundaries, canonical layers.
-
-## Work
-
-- Apply the rubric **only** to what the diff and contents show. Trace cross-file impact when the change touches module boundaries.
-- Output in the **priority order** the rubric specifies. Be direct and high-conviction; skip cosmetic nits when structural issues exist.
-- Do **not** spawn nested subagents unless the user or parent explicitly asks.
-
-## Parent orchestration
-
-Typical flow: in **one** message, run two `Task` calls in parallel — `subagent_type: "shell"` and `subagent_type: "explore"` — to collect `git diff <base>...HEAD` output and full contents of changed files (default base `main`). Then invoke this agent with `subagent_type: "thermo-nuclear-code-quality-review"` and a user prompt containing `### Git / diff output` and `### Changed file contents`.
diff --git a/cursor-team-kit/skills/rigorous-code-quality-review/SKILL.md b/cursor-team-kit/skills/rigorous-code-quality-review/SKILL.md
new file mode 100644
index 00000000..dadd9268
--- /dev/null
+++ b/cursor-team-kit/skills/rigorous-code-quality-review/SKILL.md
@@ -0,0 +1,164 @@
+---
+name: rigorous-code-quality-review
+description: Run an evidence-driven code review that verifies acceptance, correctness, security, regressions, and maintainability while making repeated reviews converge. Use for rigorous code review, deep code-quality audit, or re-review after requested changes.
+---
+
+# Rigorous Code Quality Review
+
+Review the current change against its explicit acceptance criteria and documented repository contracts. Preserve a high quality bar, but block only on demonstrated risk or unmet requirements. Do not block on taste, speculation, change size, or the pursuit of perfect code.
+
+Make the review convergent. Perform a complete first pass, preserve stable findings across revisions, and focus later passes on resolution and regressions instead of restarting an open-ended audit.
+
+## Sources of Truth
+
+Use these sources in order of relevance:
+
+1. The task description, acceptance criteria, and demo or verification statement.
+2. Repository instructions, architecture documents, public contracts, and established invariants.
+3. The actual diff, changed-file contents, callers, and affected boundaries.
+4. Prior review findings, fixer notes, and verification history.
+5. Fresh tests, builds, linters, traces, or focused reproductions.
+6. First-party provider documentation when the change depends on an external API.
+
+Distinguish behavior introduced by the change from pre-existing behavior. Do not turn unrelated pre-existing problems into blockers for the current change.
+
+## Review Workflow
+
+### 1. Orient to the review
+
+- Determine whether this is the initial review or a re-review.
+- Read the full task contract before judging the implementation.
+- Inspect the complete diff and enough surrounding code to understand changed behavior.
+- Read prior findings and verification records when they exist.
+- Build a compact acceptance map: each criterion, the implementing code, and the evidence that proves or disproves it.
+
+### 2. Perform one complete discovery pass
+
+On the initial review, examine every meaningful changed area through these lenses:
+
+- acceptance and functional correctness
+- security, authorization, privacy, and trust boundaries
+- data integrity, persistence, migrations, and compatibility
+- API, protocol, and external-provider contracts
+- concurrency, cancellation, cleanup, retries, and resource ownership
+- error handling and failure behavior
+- architectural ownership, types, abstractions, and maintainability
+- tests, observability, documentation, and operational behavior required by acceptance
+
+Report every verified blocking finding discovered in this pass. Do not intentionally save findings for later rounds or impose an arbitrary cap on blocking findings. Deduplicate symptoms that share one root cause.
+
+### 3. Verify every candidate blocker
+
+Before reporting a blocking finding:
+
+1. Identify the exact changed code and causal path.
+2. State a concrete input, state, or execution path that triggers the problem.
+3. Tie the impact to an acceptance criterion, documented contract, repository invariant, or material user/system risk.
+4. Run the smallest useful check when execution is practical.
+5. Actively try to disprove the finding by checking callers, guards, tests, types, and documentation.
+6. Lower the severity or omit the finding when the evidence does not survive that check.
+
+Do not block on vague claims such as "this could break," "this might be cleaner," or "there may be an edge case." Explain what breaks and why.
+
+For external APIs, compare fixtures, mocks, paths, payloads, auth, scopes, pagination, and rate-limit behavior with first-party documentation. Missing documentation is a reason to gather evidence, not automatically a defect. Block only when conformance is required and cannot be established or when the implementation demonstrably contradicts the contract.
+
+### 4. Classify findings accurately
+
+Use these classes even if the host represents them with different severity names:
+
+#### Blocking
+
+Request changes only for a verified issue introduced by the current change that materially affects one or more of:
+
+- an explicit acceptance criterion
+- functional correctness or an existing supported behavior
+- security, authorization, privacy, or tenant isolation
+- data integrity, migration safety, or compatibility
+- an API, schema, protocol, or external-provider contract
+- concurrency, cancellation, resource cleanup, or failure recovery
+- a documented architectural invariant whose violation creates concrete maintenance or correctness risk
+- required tests, documentation, or operability named by the task contract
+
+#### Non-blocking
+
+Record as non-blocking when the suggestion is useful but not required for safe acceptance:
+
+- alternative abstractions or "code judo" opportunities
+- naming, local readability, or stylistic improvements
+- optional simplification without a demonstrated regression
+- speculative hardening without a reachable failure path
+- broader cleanup outside the current acceptance criteria
+
+#### Pre-existing
+
+Identify a pre-existing defect separately when it is important context. Do not make it a blocker unless the current change worsens it or the task explicitly requires fixing it.
+
+Change size and file length are context, never verdicts. Review a large change in coherent slices and keep whole-system interactions in view; do not reject it merely because it is large.
+
+### 5. Make findings actionable and durable
+
+For each finding, provide:
+
+- a stable identifier such as `CR-001`
+- severity and category
+- the narrowest useful file and line reference
+- the observed evidence and concrete failure path
+- the violated criterion, contract, or invariant
+- the user or system impact
+- the required outcome, without over-prescribing an implementation when several fixes are valid
+
+Attempt to falsify each finding before publishing it. Prefer one root-cause finding over several comments on its symptoms.
+
+When the host output schema has no finding-id field, prefix the category or problem text with the stable identifier. Always preserve the host's required output contract.
+
+### 6. Make re-reviews converge
+
+On every re-review:
+
+1. Load all prior findings and the fixer evidence.
+2. Mark each prior finding as resolved, unresolved, or invalidated.
+3. Inspect the repair delta and the surrounding interactions needed to detect regressions.
+4. Do not reopen a resolved finding under new wording.
+5. Suppress new nits and optional redesign requests.
+6. Add a new blocker only when it is verified, materially important, and introduced or exposed by the repair. For unchanged code, add one only when concrete new evidence proves a task-scope defect that would make approval unsafe; explain the new evidence.
+7. Approve as soon as all acceptance criteria are evidenced and no verified blockers remain.
+
+Do not restart a fresh architectural audit on every revision. CAS or the host system owns retry and scheduling policy; this skill must not prescribe a fixed review-cycle limit, stop autonomous work because of the number of attempts, or refuse a review because of change size.
+
+## Structural Quality Standards
+
+Evaluate maintainability seriously, using evidence rather than aesthetic preference:
+
+- Prefer direct, boring code over brittle or magical behavior.
+- Keep logic in the canonical owning layer and reuse established helpers.
+- Flag ad-hoc branches, nullable modes, casts, or loosely shaped data when they obscure a real invariant or create a demonstrated failure risk.
+- Question wrappers and abstractions that add indirection without clarifying ownership or behavior.
+- Prefer explicit boundary parsing and typed contracts.
+- Check that independent work is not needlessly serialized and related updates cannot leave material partial state.
+- Look for simpler designs that delete concepts and branches, but keep them non-blocking unless the current structure creates a concrete regression or violates a documented invariant.
+
+A maintainability finding may block when the diff demonstrably makes a supported behavior unsafe, violates a documented boundary, duplicates conflicting sources of truth, or introduces complexity with a concrete correctness or ownership failure. "I would design this differently" is not enough.
+
+## Approval Standard
+
+Approve when:
+
+- the implementation satisfies the explicit acceptance criteria
+- relevant verification passes or equivalent evidence establishes the required behavior
+- no verified blocking findings remain
+- the change does not demonstrably regress supported behavior, safety, data integrity, or documented architectural invariants
+
+The code does not need to be perfect. Non-blocking improvements may remain. Favor approval once the change is a verified improvement and is safe within its stated contract.
+
+## Output Expectations
+
+Lead with the verdict and a concise evidence summary. Order findings as:
+
+1. blocking findings
+2. unresolved prior findings
+3. non-blocking findings
+4. pre-existing observations
+
+For an initial review, include all verified blockers rather than a deliberately small subset. For a re-review, show the disposition of prior blockers and report only qualifying new blockers. Do not flood the author with cosmetic notes.
+
+Respect the host's required format, fields, and verdict semantics. Do not substitute this skill's prose format for a platform-mandated JSON or command-based review contract.
diff --git a/cursor-team-kit/skills/thermo-nuclear-code-quality-review/SKILL.md b/cursor-team-kit/skills/thermo-nuclear-code-quality-review/SKILL.md
deleted file mode 100644
index ac76a2bc..00000000
--- a/cursor-team-kit/skills/thermo-nuclear-code-quality-review/SKILL.md
+++ /dev/null
@@ -1,192 +0,0 @@
----
-name: thermo-nuclear-code-quality-review
-description: Run an extremely strict maintainability review for abstraction quality, giant files, and spaghetti-condition growth. Use for a thermo-nuclear code quality review, thermonuclear review, deep code quality audit, or especially harsh maintainability review.
-disable-model-invocation: true
----
-
-# Thermo-Nuclear Code Quality Review
-
-Use this skill for an unusually strict review focused on implementation quality, maintainability, abstraction quality, and codebase health.
-
-Above all, this skill should push the reviewer to be **ambitious** about code structure. Do not merely identify local cleanup opportunities. Actively search for "code judo" moves: restructurings that preserve behavior while making the implementation dramatically simpler, smaller, more direct, and more elegant.
-
-## Core Prompt
-
-Start from this baseline:
-
-> Perform a deep code quality audit of the current branch's changes.
-> Rethink how to structure / implement the changes to meaningfully improve code quality without impacting behavior.
-> Work to improve abstractions, modularity, reduce Spaghetti code, improve succinctness and legibility.
-> Be ambitious, if there is a clear path to improving the implementation that involves restructuring some of the codebase, go for it.
-> Be extremely thorough and rigorous. Measure twice, cut once.
-
-## Non-Negotiable Additional Standards
-
-Apply the baseline prompt above, plus these explicit review rules:
-
-0. **Be ambitious about structural simplification.**
-   - Do not stop at "this could be a bit cleaner."
-   - Look for opportunities to reframe the change so that whole branches, helpers, modes, conditionals, or layers disappear entirely.
-   - Prefer the solution that makes the code feel inevitable in hindsight.
-   - Assume there is often a "code judo" move available: a re-organization that uses the existing architecture more effectively and makes the change dramatically simpler and more elegant.
-   - If you see a path to delete complexity rather than rearrange it, push hard for that path.
-
-1. **Do not let a PR push a file from under 1k lines to over 1k lines without a very strong reason.**
-   - Treat this as a strong code-quality smell by default.
-   - Prefer extracting helpers, subcomponents, modules, or local abstractions instead of letting a file sprawl past 1000 lines.
-   - If the diff crosses that threshold, explicitly ask whether the code should be decomposed first.
-   - Only waive this if there is a compelling structural reason and the resulting file is still clearly organized.
-
-2. **Do not allow random spaghetti growth in existing code.**
-   - Be highly suspicious of new ad-hoc conditionals, scattered special cases, or one-off branches inserted into unrelated flows.
-   - If a change adds "weird if statements in random places", treat that as a design problem, not a stylistic nit.
-   - Prefer pushing the logic into a dedicated abstraction, helper, state machine, policy object, or separate module instead of tangling an existing path.
-   - Call out changes that make the surrounding code harder to reason about, even if they technically work.
-
-3. **Bias toward cleaning the design, not just accepting working code.**
-   - If behavior can stay the same while the structure becomes meaningfully cleaner, push for the cleaner version.
-   - Do not rubber-stamp "it works" implementations that leave the codebase messier.
-   - Strongly prefer simplifications that remove moving pieces altogether over refactors that merely spread the same complexity around.
-
-4. **Prefer direct, boring, maintainable code over hacky or magical code.**
-   - Treat brittle, ad-hoc, or "magic" behavior as a code-quality problem.
-   - Be skeptical of generic mechanisms that hide simple data-shape assumptions.
-   - Flag thin abstractions, identity wrappers, or pass-through helpers that add indirection without buying clarity.
-
-5. **Push hard on type and boundary cleanliness when they affect maintainability.**
-   - Question unnecessary optionality, `unknown`, `any`, or cast-heavy code when a clearer type boundary could exist.
-   - Prefer explicit typed models or shared contracts over loosely-shaped ad-hoc objects.
-   - If a branch relies on silent fallback to paper over an unclear invariant, ask whether the boundary should be made explicit instead.
-
-6. **Keep logic in the canonical layer and reuse existing helpers.**
-   - Call out feature logic leaking into shared paths or implementation details leaking through APIs.
-   - Prefer existing canonical utilities/helpers over bespoke one-offs.
-   - Push code toward the right package, service, or module instead of normalizing architectural drift.
-
-7. **Treat unnecessary sequential orchestration and non-atomic updates as design smells when the cleaner structure is obvious.**
-   - If independent work is serialized for no good reason, ask whether the flow should run in parallel instead.
-   - If related updates can leave state half-applied, push for a more atomic structure.
-   - Do not over-index on micro-optimizations, but do flag avoidable orchestration complexity that makes the implementation more brittle.
-
-## Primary Review Questions
-
-For every meaningful change, ask:
-
-- Is there a "code judo" move that would make this dramatically simpler?
-- Can this change be reframed so fewer concepts, branches, or helper layers are needed?
-- Does this improve or worsen the local architecture?
-- Did the diff add branching complexity where a better abstraction should exist?
-- Did a previously cohesive module become more coupled, more stateful, or harder to scan?
-- Is this logic living in the right file and layer?
-- Did this change enlarge a file or component past a healthy size boundary?
-- Are there repeated conditionals that signal a missing model or missing helper?
-- Is the implementation direct and legible, or does it rely on special cases and incidental control flow?
-- Is this abstraction actually earning its keep, or is it just a wrapper?
-- Did the diff introduce casts, optionality, or ad-hoc object shapes that obscure the real invariant?
-- Is this logic living in the canonical layer, or did the diff leak details across a boundary?
-- Is this orchestration more sequential or less atomic than it needs to be?
-
-## What to Flag Aggressively
-
-Escalate findings when you see:
-
-- A complicated implementation where a cleaner reframing could delete whole categories of complexity.
-- Refactors that move code around but fail to reduce the number of concepts a reader must hold in their head.
-- A file crossing 1000 lines due to the PR, especially if the new code could be split out.
-- New conditionals bolted onto unrelated code paths.
-- One-off booleans, nullable modes, or flags that complicate existing control flow.
-- Feature-specific logic leaking into general-purpose modules.
-- Generic "magic" handling that hides simple structure and makes the code harder to reason about.
-- Thin wrappers or identity abstractions that add indirection without simplifying anything.
-- Unnecessary casts, `any`, `unknown`, or optional params that muddy the real contract.
-- Copy-pasted logic instead of extracted helpers.
-- Narrow edge-case handling implemented in the middle of an already busy function.
-- Refactors that technically pass tests but make the code less modular or less readable.
-- "Temporary" branching that is likely to become permanent debt.
-- Bespoke helpers where the codebase already has a canonical utility for the job.
-- Logic added in the wrong layer/package when it should live somewhere more central.
-- Sequential async flow where obviously independent work could stay simpler and clearer with parallel execution.
-- Partial-update logic that leaves state less atomic than necessary.
-
-## Preferred Remedies
-
-When you identify a code-quality problem, prefer suggestions like:
-
-- Delete a whole layer of indirection rather than polishing it.
-- Reframe the state model so conditionals disappear instead of getting centralized.
-- Change the ownership boundary so the feature becomes a natural extension of an existing abstraction.
-- Turn special-case logic into a simpler default flow with fewer exceptions.
-- Extract a helper or pure function.
-- Split a large file into smaller focused modules.
-- Move feature-specific logic behind a dedicated abstraction.
-- Replace condition chains with a typed model or explicit dispatcher.
-- Separate orchestration from business logic.
-- Collapse duplicate branches into a single clearer flow.
-- Delete wrappers that do not meaningfully clarify the API.
-- Reuse the existing canonical helper instead of introducing a near-duplicate.
-- Make type boundaries more explicit so the control flow gets simpler.
-- Move the logic to the package/module/layer that already owns the concept.
-- Parallelize independent work when that also simplifies the orchestration.
-- Restructure related updates into a more atomic flow when partial state would be harder to reason about.
-
-Do not be satisfied with "maybe rename this" feedback when the real issue is structural.
-Do not be satisfied with a merely cleaner version of the same messy idea if there is a plausible path to a much simpler idea.
-
-## Review Tone
-
-Be direct, serious, and demanding about quality.
-Do not be rude, but do not soften major maintainability issues into mild suggestions.
-If the code is making the codebase messier, say so clearly.
-If the implementation missed an opportunity for a dramatic simplification, say that clearly too.
-
-Good phrases:
-
-- `this pushes the file past 1k lines. can we decompose this first?`
-- `this adds another special-case branch into an already busy flow. can we move this behind its own abstraction?`
-- `this works, but it makes the surrounding code more spaghetti. let's keep the behavior and restructure the implementation.`
-- `this feels like feature logic leaking into a shared path. can we isolate it?`
-- `this abstraction seems unnecessary. can we just keep the direct flow?`
-- `why does this need a cast / optional here? can we make the boundary more explicit instead?`
-- `this looks like a bespoke helper for something we already have elsewhere. can we reuse the canonical one?`
-- `i think there's a code-judo move here that makes this much simpler. can we reframe this so these branches disappear?`
-- `this refactor moves complexity around, but doesn't really delete it. is there a way to make the model itself simpler?`
-
-## Output Expectations
-
-Prioritize findings in this order:
-
-1. Structural code-quality regressions
-2. Missed opportunities for dramatic simplification / code-judo restructuring
-3. Spaghetti / branching complexity increases
-4. Boundary / abstraction / type-contract problems that make the code harder to reason about
-5. File-size and decomposition concerns
-6. Modularity and abstraction issues
-7. Legibility and maintainability concerns
-
-Do not flood the review with low-value nits if there are larger structural issues.
-Prefer a smaller number of high-conviction comments over a long list of cosmetic notes.
-
-## Approval Bar
-
-Do not approve merely because behavior seems correct.
-The bar for approval is:
-
-- no clear structural regression
-- no obvious missed opportunity to make the implementation dramatically simpler when such a path is visible
-- no unjustified file-size explosion
-- no obvious spaghetti-growth from special-case branching
-- no obviously hacky or magical abstraction that makes the code harder to reason about
-- no unnecessary wrapper/cast/optionality churn obscuring the real design
-- no clear architecture-boundary leak or avoidable canonical-helper duplication
-- no missed opportunity for an obvious decomposition that would materially improve maintainability
-
-Treat these as presumptive blockers unless the author can justify them clearly:
-
-- the PR preserves a lot of incidental complexity when there is a plausible code-judo move that would delete it
-- the PR pushes a file from below 1000 lines to above 1000 lines
-- the PR adds ad-hoc branching that makes an existing flow more tangled
-- the PR solves a local problem by scattering feature checks across shared code
-- the PR adds an unnecessary abstraction, wrapper, or cast-heavy contract that makes the design more indirect
-- the PR duplicates an existing helper or puts logic in the wrong layer when there is a clear canonical home
-
-If those conditions are not met, leave explicit, actionable feedback and push for a cleaner decomposition.
diff --git a/rigorous-implementation/.codex-plugin/plugin.json b/rigorous-implementation/.codex-plugin/plugin.json
new file mode 100644
index 00000000..315ed7ca
--- /dev/null
+++ b/rigorous-implementation/.codex-plugin/plugin.json
@@ -0,0 +1,36 @@
+{
+  "name": "rigorous-implementation",
+  "version": "1.0.0",
+  "description": "Implement code changes with structural simplicity, clean boundaries, and fresh verification evidence.",
+  "author": {
+    "name": "Coding Agent System",
+    "url": "https://github.com/codingagentsystem"
+  },
+  "homepage": "https://github.com/codingagentsystem/plugins/tree/main/rigorous-implementation",
+  "repository": "https://github.com/codingagentsystem/plugins",
+  "license": "MIT",
+  "keywords": [
+    "implementation",
+    "code-quality",
+    "maintainability",
+    "refactoring",
+    "verification"
+  ],
+  "skills": "./skills/",
+  "interface": {
+    "displayName": "Rigorous Implementation",
+    "shortDescription": "Build simple, maintainable, verified changes.",
+    "longDescription": "An implementer-first workflow for producing structurally clean code, avoiding branching and file-size regressions, verifying behavior, and handing off concrete diff evidence.",
+    "developerName": "Coding Agent System",
+    "category": "Developer Tools",
+    "capabilities": [
+      "Write"
+    ],
+    "websiteURL": "https://github.com/codingagentsystem/plugins/tree/main/rigorous-implementation",
+    "defaultPrompt": [
+      "Implement this change rigorously and verify it.",
+      "Refactor this without adding structural complexity.",
+      "Fix this bug with clean boundaries and tests."
+    ]
+  }
+}
diff --git a/rigorous-implementation/.cursor-plugin/plugin.json b/rigorous-implementation/.cursor-plugin/plugin.json
new file mode 100644
index 00000000..7ac8a2e3
--- /dev/null
+++ b/rigorous-implementation/.cursor-plugin/plugin.json
@@ -0,0 +1,27 @@
+{
+  "name": "rigorous-implementation",
+  "displayName": "Rigorous Implementation",
+  "version": "1.0.0",
+  "description": "Implement code changes with structural simplicity, clean boundaries, and fresh verification evidence.",
+  "author": {
+    "name": "Coding Agent System"
+  },
+  "homepage": "https://github.com/codingagentsystem/plugins/tree/main/rigorous-implementation",
+  "repository": "https://github.com/codingagentsystem/plugins",
+  "license": "MIT",
+  "keywords": [
+    "implementation",
+    "code-quality",
+    "maintainability",
+    "refactoring",
+    "verification"
+  ],
+  "category": "developer-tools",
+  "tags": [
+    "implementation",
+    "quality",
+    "delivery",
+    "verification"
+  ],
+  "skills": "./skills/"
+}
diff --git a/rigorous-implementation/LICENSE b/rigorous-implementation/LICENSE
new file mode 100644
index 00000000..4b0505c0
--- /dev/null
+++ b/rigorous-implementation/LICENSE
@@ -0,0 +1,22 @@
+MIT License
+
+Copyright (c) 2026 Cursor
+Copyright (c) 2026 Coding Agent System
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
diff --git a/rigorous-implementation/README.md b/rigorous-implementation/README.md
new file mode 100644
index 00000000..8d937051
--- /dev/null
+++ b/rigorous-implementation/README.md
@@ -0,0 +1,13 @@
+# Rigorous Implementation
+
+An implementer-first companion to the rigorous code-quality review rubric. It helps coding agents design, implement, self-review, verify, and hand off changes that should pass a demanding maintainability review without avoidable rework.
+
+## Skill
+
+Invoke `rigorous-implementation` when implementing a feature, bug fix, or refactor that should prioritize structural simplicity, clean ownership and type boundaries, controlled file growth, documented external contracts, and fresh completion evidence.
+
+The skill works with Codex and Cursor plugin discovery. It does not add tools or permissions; it shapes how an existing implementer approaches the code change.
+
+## License
+
+MIT. The workflow is derived from the rigorous review rubric distributed by Cursor under the MIT License.
diff --git a/rigorous-implementation/skills/rigorous-implementation/SKILL.md b/rigorous-implementation/skills/rigorous-implementation/SKILL.md
new file mode 100644
index 00000000..31e9302b
--- /dev/null
+++ b/rigorous-implementation/skills/rigorous-implementation/SKILL.md
@@ -0,0 +1,110 @@
+---
+name: rigorous-implementation
+description: Implement features, fixes, and refactors with an unusually high bar for structural simplicity, maintainability, clean boundaries, and verification. Use when Codex is acting as an implementer, writing or changing production code, responding to strict review feedback, or preparing a change that must avoid giant files, scattered special cases, weak type contracts, architectural drift, and unverified completion claims.
+---
+
+# Rigorous Implementation
+
+Implement the requested behavior while making the changed code simpler, more direct, and easier to maintain. Apply the structural standards of a strict code-quality review during implementation instead of waiting for review to discover avoidable problems.
+
+## Operating Contract
+
+- Treat the task description, acceptance criteria, demo, repository instructions, and host role rules as authoritative.
+- Preserve existing behavior unless the task explicitly changes it.
+- Inspect the relevant architecture, tests, call sites, and canonical helpers before choosing a design.
+- Keep all work within the permissions and output protocol supplied by the host. This skill does not grant tools, change task state, or replace required handoff formats.
+- Do not claim completion without a concrete diff and fresh verification evidence.
+
+## Workflow
+
+### 1. Establish Ground Truth
+
+Before editing:
+
+- Identify the requested behavior and map each acceptance criterion to code and verification.
+- Trace the existing execution path far enough to understand ownership, invariants, and nearby extension points.
+- Search for canonical models, utilities, patterns, and tests before adding a new abstraction.
+- When changing an external API integration, ground endpoints, payloads, auth, pagination, and fixtures in current provider documentation.
+- Note any ambiguity that would materially change the implementation. Resolve it from repository evidence when possible; otherwise surface it instead of guessing.
+
+### 2. Choose the Simplest Structural Move
+
+Look for a code-judo move before adding machinery: a change in ownership, data shape, or control flow that makes branches, wrappers, modes, or special cases disappear.
+
+Prefer a design that:
+
+- extends the canonical layer that already owns the concept;
+- reuses an existing helper or model;
+- makes invalid states difficult to represent;
+- reduces the number of concepts a reader must hold;
+- isolates policy from orchestration and side effects;
+- keeps related state changes atomic where practical.
+
+Do not introduce a framework, generic abstraction, or configuration surface when a direct implementation is clearer.
+
+### 3. Implement in Coherent Slices
+
+- Make the smallest complete structural change that satisfies the task, not the smallest textual diff.
+- Add or update tests alongside behavior changes when practical.
+- Keep domain logic out of transport, UI, storage, or shared utility layers that do not own it.
+- Use explicit types and boundary validation instead of casts, broad optionality, silent fallbacks, or loosely shaped objects.
+- Keep independent work parallel when that simplifies orchestration; keep dependent state transitions ordered and atomic.
+- Delete obsolete branches, wrappers, or duplication made unnecessary by the change.
+
+### 4. Self-Review Before Handoff
+
+Review the resulting diff as a demanding maintainer. Ask:
+
+- Can the design be reframed so fewer branches, flags, helpers, or concepts are needed?
+- Did the change add special-case logic to an already busy path?
+- Is every new abstraction earning its indirection?
+- Does the code live in the correct module and layer?
+- Did a file cross or approach 1,000 lines because decomposition was deferred?
+- Are types and invariants explicit at boundaries?
+- Do fixtures and mocks match documented external contracts?
+- Is there dead code or accidental complexity left after the implementation?
+
+Fix high-confidence structural problems before requesting review.
+
+### 5. Verify and Hand Off
+
+Run the strongest relevant checks available for the changed surface. Prefer targeted tests first, then broader tests in proportion to risk. Record exact commands and outcomes.
+
+The handoff must include:
+
+- a concise summary of the implemented behavior;
+- the changed files or diff scope;
+- how acceptance criteria were satisfied;
+- fresh test, build, lint, typecheck, or manual-verification results;
+- any remaining risk, unverified edge case, or external blocker.
+
+If the host requires structured JSON or another schema, express this evidence through that schema rather than inventing a competing format.
+
+## Structural Standards
+
+Treat these as implementation blockers unless repository evidence justifies an exception:
+
+1. **Unnecessary complexity.** Delete concepts and branches when a simpler model can express the behavior.
+2. **File sprawl.** Do not push a file from below 1,000 lines to above 1,000 lines without a compelling structural reason. Decompose first.
+3. **Scattered special cases.** Do not bolt feature flags or ad hoc conditionals into unrelated flows. Give the behavior a clear owner.
+4. **Empty abstractions.** Avoid pass-through wrappers, identity helpers, and generic mechanisms that add indirection without clarity.
+5. **Weak boundaries.** Avoid unnecessary `any`, `unknown`, casts, nullable modes, and silent fallback when an explicit contract is possible.
+6. **Architectural drift.** Put logic in the canonical package, service, component, or model and reuse established helpers.
+7. **Brittle orchestration.** Avoid needless serialization, partial updates, and hidden side effects when a clearer parallel or atomic structure exists.
+8. **Guessed contracts.** Do not create provider fixtures or API behavior from memory when authoritative documentation can establish ground truth.
+
+## Scope Discipline
+
+Be ambitious about simplifying the changed path, but do not turn a focused task into an unrelated codebase rewrite. Expand scope only when the broader structural change is necessary to implement the requested behavior safely and cleanly. Preserve user-owned changes, generated artifacts, and unrelated dirty worktree state.
+
+## Definition of Done
+
+Completion requires all of the following:
+
+- requested behavior is implemented;
+- acceptance criteria are demonstrably satisfied;
+- no obvious structural regression remains in the changed path;
+- no unjustified file-size or branching explosion was introduced;
+- tests and verification are fresh and relevant;
+- the handoff contains diff evidence and any reviewer-relevant context;
+- unresolved failures or risks are reported plainly rather than hidden behind a success claim.
diff --git a/rigorous-implementation/skills/rigorous-implementation/agents/openai.yaml b/rigorous-implementation/skills/rigorous-implementation/agents/openai.yaml
new file mode 100644
index 00000000..7c141b69
--- /dev/null
+++ b/rigorous-implementation/skills/rigorous-implementation/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+  display_name: "Rigorous Implementation"
+  short_description: "Build structurally clean, maintainable changes"
+  default_prompt: "Use $rigorous-implementation to implement this change with simple structure, clean boundaries, and fresh verification."
diff --git a/thermos/.cursor-plugin/plugin.json b/thermos/.cursor-plugin/plugin.json
index e1cb7cde..ae1aa68d 100644
--- a/thermos/.cursor-plugin/plugin.json
+++ b/thermos/.cursor-plugin/plugin.json
@@ -2,18 +2,18 @@
   "name": "thermos",
   "displayName": "Thermos",
   "version": "1.0.0",
-  "description": "Thermo-nuclear branch review: deep correctness and security audits plus harsh code-quality rubrics, parallel subagents, thermos orchestration, and optional take-the-wheel and FSD merge-ready flows.",
+  "description": "Rigorous branch review: deep correctness and security audits plus harsh code-quality rubrics, parallel subagents, thermos orchestration, and optional take-the-wheel and FSD merge-ready flows.",
   "author": {
     "name": "Cursor",
     "email": "plugins@cursor.com"
   },
-  "homepage": "https://github.com/cursor/plugins",
-  "repository": "https://github.com/cursor/plugins",
+  "homepage": "https://github.com/codingagentsystem/plugins",
+  "repository": "https://github.com/codingagentsystem/plugins",
   "license": "MIT",
   "logo": "assets/logo.png",
   "keywords": [
     "thermos",
-    "thermo-nuclear",
+    "rigorous-review",
     "code-review",
     "deep-review",
     "code-quality",
diff --git a/thermos/CHANGELOG.md b/thermos/CHANGELOG.md
index 89a95a63..fac22e96 100644
--- a/thermos/CHANGELOG.md
+++ b/thermos/CHANGELOG.md
@@ -3,6 +3,6 @@
 ## 1.0.0
 
 - Initial Thermos plugin release.
-- Skills: `thermo-nuclear-review`, `thermo-nuclear-code-quality-review`, `thermos`.
-- Agents: `thermo-nuclear-review-subagent`, `thermo-nuclear-code-quality-review-subagent`.
+- Skills: `deep-code-review`, `rigorous-code-quality-review`, `thermos`.
+- Agents: `deep-code-review-subagent`, `rigorous-code-quality-review-subagent`.
 - Architecture diagram embedded as a mermaid block in README.
diff --git a/thermos/README.md b/thermos/README.md
index 77e950ae..1ba23007 100644
--- a/thermos/README.md
+++ b/thermos/README.md
@@ -1,6 +1,6 @@
 # Thermos plugin
 
-Thermo-nuclear branch review for Cursor agents: deep correctness and security audits, harsh maintainability rubrics, and parallel subagent orchestration.
+Rigorous branch review for Cursor agents: deep correctness and security audits, harsh maintainability rubrics, and parallel subagent orchestration.
 
 ## Installation
 
@@ -17,15 +17,15 @@ flowchart TB
   end
 
   subgraph L1["Subagents"]
-    SNR[thermo-nuclear-review-subagent]
-    SNCQ[thermo-nuclear-code-quality-review-subagent]
+    SNR[deep-code-review-subagent]
+    SNCQ[rigorous-code-quality-review-subagent]
   end
 
   DIFF[git diff + file contents]
 
   subgraph L0["Skills"]
-    TNR[thermo-nuclear-review]
-    TNCQ[thermo-nuclear-code-quality-review]
+    TNR[deep-code-review]
+    TNCQ[rigorous-code-quality-review]
   end
 
   TH --> SNR
@@ -40,16 +40,16 @@ flowchart TB
 
 | Skill | Description |
 |:------|:------------|
-| `thermo-nuclear-review` | Deep branch audit (bugs, breakages, security, devex, feature-gate leaks). |
-| `thermo-nuclear-code-quality-review` | Strict maintainability audit (code-judo, 1k-line rule, spaghetti, boundaries). |
+| `deep-code-review` | Deep branch audit (bugs, breakages, security, devex, feature-gate leaks). |
+| `rigorous-code-quality-review` | Evidence-driven audit with verified blockers, calibrated severity, and convergent re-reviews. |
 | `thermos` | Run both review subagents in parallel and synthesize findings. |
 
 ## Agents
 
 | Agent | Description |
 |:------|:------------|
-| `thermo-nuclear-review-subagent` | Task subagent for deep review rubric (diff-scoped). |
-| `thermo-nuclear-code-quality-review-subagent` | Task subagent for code-quality rubric (diff-scoped). |
+| `deep-code-review-subagent` | Task subagent for deep review rubric (diff-scoped). |
+| `rigorous-code-quality-review-subagent` | Task subagent for code-quality rubric (diff-scoped). |
 
 ## Typical usage
 
@@ -59,11 +59,11 @@ flowchart TB
 2. Invoke both subagents in one message with `run_in_background: true`.
 3. Synthesize prioritized, deduped findings.
 
-**Single skill:** invoke `thermo-nuclear-review` or `thermo-nuclear-code-quality-review` in the main agent, or the matching subagent after gathering diff context.
+**Single skill:** invoke `deep-code-review` or `rigorous-code-quality-review` in the main agent, or the matching subagent after gathering diff context.
 
 ## Migration from cursor-team-kit
 
-`cursor-team-kit` previously included only `thermo-nuclear-code-quality-review`. That skill and agent now live in **Thermos** alongside deep review and `thermos`. Remove the old thermo entries from team-kit when you install this plugin to avoid duplicates.
+`cursor-team-kit` previously included only `rigorous-code-quality-review`. That skill and agent now live in **Thermos** alongside deep review and `thermos`. Remove the old review entries from team-kit when you install this plugin to avoid duplicates.
 
 ## License
 
diff --git a/thermos/agents/thermo-nuclear-review-subagent.md b/thermos/agents/deep-code-review-subagent.md
similarity index 66%
rename from thermos/agents/thermo-nuclear-review-subagent.md
rename to thermos/agents/deep-code-review-subagent.md
index 0253a283..6da69fba 100644
--- a/thermos/agents/thermo-nuclear-review-subagent.md
+++ b/thermos/agents/deep-code-review-subagent.md
@@ -1,15 +1,15 @@
 ---
-name: thermo-nuclear-review-subagent
-description: Thermo-nuclear branch audit (bugs, breaking changes, security, devex, feature-flag leaks) scoped to the diff. Invoked via Task after a parent gathers diff and file contents. Loads rubric from the thermo-nuclear-review skill in the Thermos plugin.
+name: deep-code-review-subagent
+description: Deep branch audit (bugs, breaking changes, security, devex, feature-flag leaks) scoped to the diff. Invoked via Task after a parent gathers diff and file contents. Loads rubric from the deep-code-review skill in the Thermos plugin.
 ---
 
-# Thermo Nuclear Review (Deep review)
+# Deep Code Review (Deep review)
 
 You are a **Task subagent**. The parent agent already collected git output and changed-file contents; your prompt is the **user message** with labeled sections (typically `### Git / diff output` and `### Changed file contents`).
 
 ## Rubric
 
-1. Load the `thermo-nuclear-review` skill (shipped in the Thermos plugin) and follow its `SKILL.md` exactly: scope (only added/modified code), breaking functionality and devex, feature leaks, intended breakage, over-reporting, final response / PR discussion rules, critical rules.
+1. Load the `deep-code-review` skill (shipped in the Thermos plugin) and follow its `SKILL.md` exactly: scope (only added/modified code), breaking functionality and devex, feature leaks, intended breakage, over-reporting, final response / PR discussion rules, critical rules.
 2. If that skill is not available, still act as a security- and correctness-focused diff-scoped reviewer with the same rigor (no issues with unfinished research when you can verify in-repo).
 
 ## Work
@@ -25,4 +25,4 @@ Do **not** spawn nested subagents unless the user or parent explicitly asks.
 
 ## Parent orchestration
 
-Typical flow: in **one** message, run two `Task` calls in parallel — `subagent_type: "shell"` and `subagent_type: "explore"` — to collect `git diff <base>...HEAD` output and full contents of changed files (default base `main`). Then invoke this agent with `subagent_type: "thermo-nuclear-review-subagent"` and a user prompt containing `### Git / diff output` and `### Changed file contents`.
+Typical flow: in **one** message, run two `Task` calls in parallel — `subagent_type: "shell"` and `subagent_type: "explore"` — to collect `git diff <base>...HEAD` output and full contents of changed files (default base `main`). Then invoke this agent with `subagent_type: "deep-code-review-subagent"` and a user prompt containing `### Git / diff output` and `### Changed file contents`.
diff --git a/thermos/agents/rigorous-code-quality-review-subagent.md b/thermos/agents/rigorous-code-quality-review-subagent.md
new file mode 100644
index 00000000..16c063a6
--- /dev/null
+++ b/thermos/agents/rigorous-code-quality-review-subagent.md
@@ -0,0 +1,23 @@
+---
+name: rigorous-code-quality-review-subagent
+description: Evidence-driven code quality audit for acceptance, correctness, regressions, and maintainability. Invoked via Task after a parent gathers diff, file contents, and prior review evidence. Loads the rubric from the rigorous-code-quality-review skill in the Thermos plugin.
+---
+
+# Rigorous Code Quality Review
+
+You are a **Task subagent**. The parent agent already collected git output and changed-file contents; your prompt is the **user message** with labeled sections (typically `### Git / diff output` and `### Changed file contents`).
+
+## Rubric
+
+1. Load the `rigorous-code-quality-review` skill (shipped in the Thermos plugin) and treat its `SKILL.md` as the **complete** rubric, including its evidence bar, severity calibration, durable findings, and re-review convergence rules.
+2. If that skill is not available, fall back to an evidence-driven audit: verify the task contract, report all demonstrated blockers, separate optional improvements, and preserve prior finding identity on re-review.
+
+## Work
+
+- Apply the rubric to the task contract, diff, contents, and prior findings supplied by the parent. Trace cross-file impact when the change touches module boundaries.
+- Output in the **priority order** the rubric specifies. Include every verified blocker on the initial pass; suppress new optional findings on re-review.
+- Do **not** spawn nested subagents unless the user or parent explicitly asks.
+
+## Parent orchestration
+
+Typical flow: in **one** message, run two `Task` calls in parallel — `subagent_type: "shell"` and `subagent_type: "explore"` — to collect `git diff <base>...HEAD` output and full contents of changed files (default base `main`). Then invoke this agent with `subagent_type: "rigorous-code-quality-review-subagent"` and a user prompt containing `### Git / diff output` and `### Changed file contents`.
diff --git a/thermos/agents/thermo-nuclear-code-quality-review-subagent.md b/thermos/agents/thermo-nuclear-code-quality-review-subagent.md
deleted file mode 100644
index 08ccbaa9..00000000
--- a/thermos/agents/thermo-nuclear-code-quality-review-subagent.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-name: thermo-nuclear-code-quality-review-subagent
-description: Thermo-nuclear code quality audit (maintainability, structure, 1k-line rule, spaghetti, code-judo). Invoked via Task after a parent gathers diff and file contents. Loads rubric from the thermo-nuclear-code-quality-review skill in the Thermos plugin.
----
-
-# Thermo-Nuclear Code Quality Review
-
-You are a **Task subagent**. The parent agent already collected git output and changed-file contents; your prompt is the **user message** with labeled sections (typically `### Git / diff output` and `### Changed file contents`).
-
-## Rubric
-
-1. Load the `thermo-nuclear-code-quality-review` skill (shipped in the Thermos plugin) and treat its `SKILL.md` as the **complete** rubric — tone, approval bar, output ordering, code-judo / 1k-line / spaghetti rules.
-2. If that skill is not available, fall back to a harsh maintainability audit aligned with that skill's intent: ambitious simplification, no unjustified file sprawl past ~1k lines, no ad-hoc branching growth, explicit types and boundaries, canonical layers.
-
-## Work
-
-- Apply the rubric **only** to what the diff and contents show. Trace cross-file impact when the change touches module boundaries.
-- Output in the **priority order** the rubric specifies. Be direct and high-conviction; skip cosmetic nits when structural issues exist.
-- Do **not** spawn nested subagents unless the user or parent explicitly asks.
-
-## Parent orchestration
-
-Typical flow: in **one** message, run two `Task` calls in parallel — `subagent_type: "shell"` and `subagent_type: "explore"` — to collect `git diff <base>...HEAD` output and full contents of changed files (default base `main`). Then invoke this agent with `subagent_type: "thermo-nuclear-code-quality-review-subagent"` and a user prompt containing `### Git / diff output` and `### Changed file contents`.
diff --git a/thermos/skills/thermo-nuclear-review/SKILL.md b/thermos/skills/deep-code-review/SKILL.md
similarity index 93%
rename from thermos/skills/thermo-nuclear-review/SKILL.md
rename to thermos/skills/deep-code-review/SKILL.md
index 1aa5dfd0..f1fcc843 100644
--- a/thermos/skills/thermo-nuclear-review/SKILL.md
+++ b/thermos/skills/deep-code-review/SKILL.md
@@ -1,10 +1,9 @@
 ---
-name: thermo-nuclear-review
-description: Comprehensive security and correctness audit of a branch's changes. Use for thermo nuclear, thermonuclear, or deep review requests, or branch/PR diff audits focused on bugs, breaking changes, security issues, devex regressions, and feature-gate leaks.
-disable-model-invocation: true
+name: deep-code-review
+description: Comprehensive security and correctness audit of a branch's changes. Use for deep code review requests or branch/PR diff audits focused on bugs, breaking changes, security issues, devex regressions, and feature-gate leaks.
 ---
 
-# Thermo Nuclear Review
+# Deep Code Review
 
 Use this skill for a comprehensive security and correctness audit of a checked-out branch.
 
diff --git a/thermos/skills/rigorous-code-quality-review/SKILL.md b/thermos/skills/rigorous-code-quality-review/SKILL.md
new file mode 100644
index 00000000..dadd9268
--- /dev/null
+++ b/thermos/skills/rigorous-code-quality-review/SKILL.md
@@ -0,0 +1,164 @@
+---
+name: rigorous-code-quality-review
+description: Run an evidence-driven code review that verifies acceptance, correctness, security, regressions, and maintainability while making repeated reviews converge. Use for rigorous code review, deep code-quality audit, or re-review after requested changes.
+---
+
+# Rigorous Code Quality Review
+
+Review the current change against its explicit acceptance criteria and documented repository contracts. Preserve a high quality bar, but block only on demonstrated risk or unmet requirements. Do not block on taste, speculation, change size, or the pursuit of perfect code.
+
+Make the review convergent. Perform a complete first pass, preserve stable findings across revisions, and focus later passes on resolution and regressions instead of restarting an open-ended audit.
+
+## Sources of Truth
+
+Use these sources in order of relevance:
+
+1. The task description, acceptance criteria, and demo or verification statement.
+2. Repository instructions, architecture documents, public contracts, and established invariants.
+3. The actual diff, changed-file contents, callers, and affected boundaries.
+4. Prior review findings, fixer notes, and verification history.
+5. Fresh tests, builds, linters, traces, or focused reproductions.
+6. First-party provider documentation when the change depends on an external API.
+
+Distinguish behavior introduced by the change from pre-existing behavior. Do not turn unrelated pre-existing problems into blockers for the current change.
+
+## Review Workflow
+
+### 1. Orient to the review
+
+- Determine whether this is the initial review or a re-review.
+- Read the full task contract before judging the implementation.
+- Inspect the complete diff and enough surrounding code to understand changed behavior.
+- Read prior findings and verification records when they exist.
+- Build a compact acceptance map: each criterion, the implementing code, and the evidence that proves or disproves it.
+
+### 2. Perform one complete discovery pass
+
+On the initial review, examine every meaningful changed area through these lenses:
+
+- acceptance and functional correctness
+- security, authorization, privacy, and trust boundaries
+- data integrity, persistence, migrations, and compatibility
+- API, protocol, and external-provider contracts
+- concurrency, cancellation, cleanup, retries, and resource ownership
+- error handling and failure behavior
+- architectural ownership, types, abstractions, and maintainability
+- tests, observability, documentation, and operational behavior required by acceptance
+
+Report every verified blocking finding discovered in this pass. Do not intentionally save findings for later rounds or impose an arbitrary cap on blocking findings. Deduplicate symptoms that share one root cause.
+
+### 3. Verify every candidate blocker
+
+Before reporting a blocking finding:
+
+1. Identify the exact changed code and causal path.
+2. State a concrete input, state, or execution path that triggers the problem.
+3. Tie the impact to an acceptance criterion, documented contract, repository invariant, or material user/system risk.
+4. Run the smallest useful check when execution is practical.
+5. Actively try to disprove the finding by checking callers, guards, tests, types, and documentation.
+6. Lower the severity or omit the finding when the evidence does not survive that check.
+
+Do not block on vague claims such as "this could break," "this might be cleaner," or "there may be an edge case." Explain what breaks and why.
+
+For external APIs, compare fixtures, mocks, paths, payloads, auth, scopes, pagination, and rate-limit behavior with first-party documentation. Missing documentation is a reason to gather evidence, not automatically a defect. Block only when conformance is required and cannot be established or when the implementation demonstrably contradicts the contract.
+
+### 4. Classify findings accurately
+
+Use these classes even if the host represents them with different severity names:
+
+#### Blocking
+
+Request changes only for a verified issue introduced by the current change that materially affects one or more of:
+
+- an explicit acceptance criterion
+- functional correctness or an existing supported behavior
+- security, authorization, privacy, or tenant isolation
+- data integrity, migration safety, or compatibility
+- an API, schema, protocol, or external-provider contract
+- concurrency, cancellation, resource cleanup, or failure recovery
+- a documented architectural invariant whose violation creates concrete maintenance or correctness risk
+- required tests, documentation, or operability named by the task contract
+
+#### Non-blocking
+
+Record as non-blocking when the suggestion is useful but not required for safe acceptance:
+
+- alternative abstractions or "code judo" opportunities
+- naming, local readability, or stylistic improvements
+- optional simplification without a demonstrated regression
+- speculative hardening without a reachable failure path
+- broader cleanup outside the current acceptance criteria
+
+#### Pre-existing
+
+Identify a pre-existing defect separately when it is important context. Do not make it a blocker unless the current change worsens it or the task explicitly requires fixing it.
+
+Change size and file length are context, never verdicts. Review a large change in coherent slices and keep whole-system interactions in view; do not reject it merely because it is large.
+
+### 5. Make findings actionable and durable
+
+For each finding, provide:
+
+- a stable identifier such as `CR-001`
+- severity and category
+- the narrowest useful file and line reference
+- the observed evidence and concrete failure path
+- the violated criterion, contract, or invariant
+- the user or system impact
+- the required outcome, without over-prescribing an implementation when several fixes are valid
+
+Attempt to falsify each finding before publishing it. Prefer one root-cause finding over several comments on its symptoms.
+
+When the host output schema has no finding-id field, prefix the category or problem text with the stable identifier. Always preserve the host's required output contract.
+
+### 6. Make re-reviews converge
+
+On every re-review:
+
+1. Load all prior findings and the fixer evidence.
+2. Mark each prior finding as resolved, unresolved, or invalidated.
+3. Inspect the repair delta and the surrounding interactions needed to detect regressions.
+4. Do not reopen a resolved finding under new wording.
+5. Suppress new nits and optional redesign requests.
+6. Add a new blocker only when it is verified, materially important, and introduced or exposed by the repair. For unchanged code, add one only when concrete new evidence proves a task-scope defect that would make approval unsafe; explain the new evidence.
+7. Approve as soon as all acceptance criteria are evidenced and no verified blockers remain.
+
+Do not restart a fresh architectural audit on every revision. CAS or the host system owns retry and scheduling policy; this skill must not prescribe a fixed review-cycle limit, stop autonomous work because of the number of attempts, or refuse a review because of change size.
+
+## Structural Quality Standards
+
+Evaluate maintainability seriously, using evidence rather than aesthetic preference:
+
+- Prefer direct, boring code over brittle or magical behavior.
+- Keep logic in the canonical owning layer and reuse established helpers.
+- Flag ad-hoc branches, nullable modes, casts, or loosely shaped data when they obscure a real invariant or create a demonstrated failure risk.
+- Question wrappers and abstractions that add indirection without clarifying ownership or behavior.
+- Prefer explicit boundary parsing and typed contracts.
+- Check that independent work is not needlessly serialized and related updates cannot leave material partial state.
+- Look for simpler designs that delete concepts and branches, but keep them non-blocking unless the current structure creates a concrete regression or violates a documented invariant.
+
+A maintainability finding may block when the diff demonstrably makes a supported behavior unsafe, violates a documented boundary, duplicates conflicting sources of truth, or introduces complexity with a concrete correctness or ownership failure. "I would design this differently" is not enough.
+
+## Approval Standard
+
+Approve when:
+
+- the implementation satisfies the explicit acceptance criteria
+- relevant verification passes or equivalent evidence establishes the required behavior
+- no verified blocking findings remain
+- the change does not demonstrably regress supported behavior, safety, data integrity, or documented architectural invariants
+
+The code does not need to be perfect. Non-blocking improvements may remain. Favor approval once the change is a verified improvement and is safe within its stated contract.
+
+## Output Expectations
+
+Lead with the verdict and a concise evidence summary. Order findings as:
+
+1. blocking findings
+2. unresolved prior findings
+3. non-blocking findings
+4. pre-existing observations
+
+For an initial review, include all verified blockers rather than a deliberately small subset. For a re-review, show the disposition of prior blockers and report only qualifying new blockers. Do not flood the author with cosmetic notes.
+
+Respect the host's required format, fields, and verdict semantics. Do not substitute this skill's prose format for a platform-mandated JSON or command-based review contract.
diff --git a/thermos/skills/thermo-nuclear-code-quality-review/SKILL.md b/thermos/skills/thermo-nuclear-code-quality-review/SKILL.md
deleted file mode 100644
index ac76a2bc..00000000
--- a/thermos/skills/thermo-nuclear-code-quality-review/SKILL.md
+++ /dev/null
@@ -1,192 +0,0 @@
----
-name: thermo-nuclear-code-quality-review
-description: Run an extremely strict maintainability review for abstraction quality, giant files, and spaghetti-condition growth. Use for a thermo-nuclear code quality review, thermonuclear review, deep code quality audit, or especially harsh maintainability review.
-disable-model-invocation: true
----
-
-# Thermo-Nuclear Code Quality Review
-
-Use this skill for an unusually strict review focused on implementation quality, maintainability, abstraction quality, and codebase health.
-
-Above all, this skill should push the reviewer to be **ambitious** about code structure. Do not merely identify local cleanup opportunities. Actively search for "code judo" moves: restructurings that preserve behavior while making the implementation dramatically simpler, smaller, more direct, and more elegant.
-
-## Core Prompt
-
-Start from this baseline:
-
-> Perform a deep code quality audit of the current branch's changes.
-> Rethink how to structure / implement the changes to meaningfully improve code quality without impacting behavior.
-> Work to improve abstractions, modularity, reduce Spaghetti code, improve succinctness and legibility.
-> Be ambitious, if there is a clear path to improving the implementation that involves restructuring some of the codebase, go for it.
-> Be extremely thorough and rigorous. Measure twice, cut once.
-
-## Non-Negotiable Additional Standards
-
-Apply the baseline prompt above, plus these explicit review rules:
-
-0. **Be ambitious about structural simplification.**
-   - Do not stop at "this could be a bit cleaner."
-   - Look for opportunities to reframe the change so that whole branches, helpers, modes, conditionals, or layers disappear entirely.
-   - Prefer the solution that makes the code feel inevitable in hindsight.
-   - Assume there is often a "code judo" move available: a re-organization that uses the existing architecture more effectively and makes the change dramatically simpler and more elegant.
-   - If you see a path to delete complexity rather than rearrange it, push hard for that path.
-
-1. **Do not let a PR push a file from under 1k lines to over 1k lines without a very strong reason.**
-   - Treat this as a strong code-quality smell by default.
-   - Prefer extracting helpers, subcomponents, modules, or local abstractions instead of letting a file sprawl past 1000 lines.
-   - If the diff crosses that threshold, explicitly ask whether the code should be decomposed first.
-   - Only waive this if there is a compelling structural reason and the resulting file is still clearly organized.
-
-2. **Do not allow random spaghetti growth in existing code.**
-   - Be highly suspicious of new ad-hoc conditionals, scattered special cases, or one-off branches inserted into unrelated flows.
-   - If a change adds "weird if statements in random places", treat that as a design problem, not a stylistic nit.
-   - Prefer pushing the logic into a dedicated abstraction, helper, state machine, policy object, or separate module instead of tangling an existing path.
-   - Call out changes that make the surrounding code harder to reason about, even if they technically work.
-
-3. **Bias toward cleaning the design, not just accepting working code.**
-   - If behavior can stay the same while the structure becomes meaningfully cleaner, push for the cleaner version.
-   - Do not rubber-stamp "it works" implementations that leave the codebase messier.
-   - Strongly prefer simplifications that remove moving pieces altogether over refactors that merely spread the same complexity around.
-
-4. **Prefer direct, boring, maintainable code over hacky or magical code.**
-   - Treat brittle, ad-hoc, or "magic" behavior as a code-quality problem.
-   - Be skeptical of generic mechanisms that hide simple data-shape assumptions.
-   - Flag thin abstractions, identity wrappers, or pass-through helpers that add indirection without buying clarity.
-
-5. **Push hard on type and boundary cleanliness when they affect maintainability.**
-   - Question unnecessary optionality, `unknown`, `any`, or cast-heavy code when a clearer type boundary could exist.
-   - Prefer explicit typed models or shared contracts over loosely-shaped ad-hoc objects.
-   - If a branch relies on silent fallback to paper over an unclear invariant, ask whether the boundary should be made explicit instead.
-
-6. **Keep logic in the canonical layer and reuse existing helpers.**
-   - Call out feature logic leaking into shared paths or implementation details leaking through APIs.
-   - Prefer existing canonical utilities/helpers over bespoke one-offs.
-   - Push code toward the right package, service, or module instead of normalizing architectural drift.
-
-7. **Treat unnecessary sequential orchestration and non-atomic updates as design smells when the cleaner structure is obvious.**
-   - If independent work is serialized for no good reason, ask whether the flow should run in parallel instead.
-   - If related updates can leave state half-applied, push for a more atomic structure.
-   - Do not over-index on micro-optimizations, but do flag avoidable orchestration complexity that makes the implementation more brittle.
-
-## Primary Review Questions
-
-For every meaningful change, ask:
-
-- Is there a "code judo" move that would make this dramatically simpler?
-- Can this change be reframed so fewer concepts, branches, or helper layers are needed?
-- Does this improve or worsen the local architecture?
-- Did the diff add branching complexity where a better abstraction should exist?
-- Did a previously cohesive module become more coupled, more stateful, or harder to scan?
-- Is this logic living in the right file and layer?
-- Did this change enlarge a file or component past a healthy size boundary?
-- Are there repeated conditionals that signal a missing model or missing helper?
-- Is the implementation direct and legible, or does it rely on special cases and incidental control flow?
-- Is this abstraction actually earning its keep, or is it just a wrapper?
-- Did the diff introduce casts, optionality, or ad-hoc object shapes that obscure the real invariant?
-- Is this logic living in the canonical layer, or did the diff leak details across a boundary?
-- Is this orchestration more sequential or less atomic than it needs to be?
-
-## What to Flag Aggressively
-
-Escalate findings when you see:
-
-- A complicated implementation where a cleaner reframing could delete whole categories of complexity.
-- Refactors that move code around but fail to reduce the number of concepts a reader must hold in their head.
-- A file crossing 1000 lines due to the PR, especially if the new code could be split out.
-- New conditionals bolted onto unrelated code paths.
-- One-off booleans, nullable modes, or flags that complicate existing control flow.
-- Feature-specific logic leaking into general-purpose modules.
-- Generic "magic" handling that hides simple structure and makes the code harder to reason about.
-- Thin wrappers or identity abstractions that add indirection without simplifying anything.
-- Unnecessary casts, `any`, `unknown`, or optional params that muddy the real contract.
-- Copy-pasted logic instead of extracted helpers.
-- Narrow edge-case handling implemented in the middle of an already busy function.
-- Refactors that technically pass tests but make the code less modular or less readable.
-- "Temporary" branching that is likely to become permanent debt.
-- Bespoke helpers where the codebase already has a canonical utility for the job.
-- Logic added in the wrong layer/package when it should live somewhere more central.
-- Sequential async flow where obviously independent work could stay simpler and clearer with parallel execution.
-- Partial-update logic that leaves state less atomic than necessary.
-
-## Preferred Remedies
-
-When you identify a code-quality problem, prefer suggestions like:
-
-- Delete a whole layer of indirection rather than polishing it.
-- Reframe the state model so conditionals disappear instead of getting centralized.
-- Change the ownership boundary so the feature becomes a natural extension of an existing abstraction.
-- Turn special-case logic into a simpler default flow with fewer exceptions.
-- Extract a helper or pure function.
-- Split a large file into smaller focused modules.
-- Move feature-specific logic behind a dedicated abstraction.
-- Replace condition chains with a typed model or explicit dispatcher.
-- Separate orchestration from business logic.
-- Collapse duplicate branches into a single clearer flow.
-- Delete wrappers that do not meaningfully clarify the API.
-- Reuse the existing canonical helper instead of introducing a near-duplicate.
-- Make type boundaries more explicit so the control flow gets simpler.
-- Move the logic to the package/module/layer that already owns the concept.
-- Parallelize independent work when that also simplifies the orchestration.
-- Restructure related updates into a more atomic flow when partial state would be harder to reason about.
-
-Do not be satisfied with "maybe rename this" feedback when the real issue is structural.
-Do not be satisfied with a merely cleaner version of the same messy idea if there is a plausible path to a much simpler idea.
-
-## Review Tone
-
-Be direct, serious, and demanding about quality.
-Do not be rude, but do not soften major maintainability issues into mild suggestions.
-If the code is making the codebase messier, say so clearly.
-If the implementation missed an opportunity for a dramatic simplification, say that clearly too.
-
-Good phrases:
-
-- `this pushes the file past 1k lines. can we decompose this first?`
-- `this adds another special-case branch into an already busy flow. can we move this behind its own abstraction?`
-- `this works, but it makes the surrounding code more spaghetti. let's keep the behavior and restructure the implementation.`
-- `this feels like feature logic leaking into a shared path. can we isolate it?`
-- `this abstraction seems unnecessary. can we just keep the direct flow?`
-- `why does this need a cast / optional here? can we make the boundary more explicit instead?`
-- `this looks like a bespoke helper for something we already have elsewhere. can we reuse the canonical one?`
-- `i think there's a code-judo move here that makes this much simpler. can we reframe this so these branches disappear?`
-- `this refactor moves complexity around, but doesn't really delete it. is there a way to make the model itself simpler?`
-
-## Output Expectations
-
-Prioritize findings in this order:
-
-1. Structural code-quality regressions
-2. Missed opportunities for dramatic simplification / code-judo restructuring
-3. Spaghetti / branching complexity increases
-4. Boundary / abstraction / type-contract problems that make the code harder to reason about
-5. File-size and decomposition concerns
-6. Modularity and abstraction issues
-7. Legibility and maintainability concerns
-
-Do not flood the review with low-value nits if there are larger structural issues.
-Prefer a smaller number of high-conviction comments over a long list of cosmetic notes.
-
-## Approval Bar
-
-Do not approve merely because behavior seems correct.
-The bar for approval is:
-
-- no clear structural regression
-- no obvious missed opportunity to make the implementation dramatically simpler when such a path is visible
-- no unjustified file-size explosion
-- no obvious spaghetti-growth from special-case branching
-- no obviously hacky or magical abstraction that makes the code harder to reason about
-- no unnecessary wrapper/cast/optionality churn obscuring the real design
-- no clear architecture-boundary leak or avoidable canonical-helper duplication
-- no missed opportunity for an obvious decomposition that would materially improve maintainability
-
-Treat these as presumptive blockers unless the author can justify them clearly:
-
-- the PR preserves a lot of incidental complexity when there is a plausible code-judo move that would delete it
-- the PR pushes a file from below 1000 lines to above 1000 lines
-- the PR adds ad-hoc branching that makes an existing flow more tangled
-- the PR solves a local problem by scattering feature checks across shared code
-- the PR adds an unnecessary abstraction, wrapper, or cast-heavy contract that makes the design more indirect
-- the PR duplicates an existing helper or puts logic in the wrong layer when there is a clear canonical home
-
-If those conditions are not met, leave explicit, actionable feedback and push for a cleaner decomposition.
diff --git a/thermos/skills/thermos/SKILL.md b/thermos/skills/thermos/SKILL.md
index e7aeeafd..0f9a0600 100644
--- a/thermos/skills/thermos/SKILL.md
+++ b/thermos/skills/thermos/SKILL.md
@@ -1,21 +1,20 @@
 ---
 name: thermos
-description: "Launch both thermo-nuclear review subagents in parallel, then synthesize their findings. Use for thermos, double thermo review, or combined bug/security and code-quality branch audits."
-disable-model-invocation: true
+description: "Launch both rigorous review subagents in parallel, then synthesize their findings. Use for thermos, double thermo review, or combined bug/security and code-quality branch audits."
 ---
 
 # Thermos
 
-Run the two thermo review passes as async background subagents in parallel, then synthesize their results.
+Run the two rigorous review passes as async background subagents in parallel, then synthesize their results.
 
 ## Workflow
 
 1. Determine the review scope from the user request, PR, current branch, or relevant changed files.
 2. Gather the diff and any file/context excerpts needed for reviewers to evaluate the change without guessing.
 3. Launch both subagents in the same message with `run_in_background: true`:
-   - `subagent_type: "thermo-nuclear-review-subagent"` for bugs, breakages, security, devex regressions, feature-flag leaks, and other branch-audit risks.
-   - `subagent_type: "thermo-nuclear-code-quality-review-subagent"` for maintainability, structure, file-size growth, spaghetti, abstractions, and codebase-health risks.
-4. Pass each subagent the same scoped diff/file context and ask it to return prioritized findings with file references and evidence.
+   - `subagent_type: "deep-code-review-subagent"` for bugs, breakages, security, devex regressions, feature-flag leaks, and other branch-audit risks.
+   - `subagent_type: "rigorous-code-quality-review-subagent"` for evidence-backed acceptance, regression, maintainability, abstraction, and codebase-health risks.
+4. Pass each subagent the task contract, scoped diff/file context, and prior findings when re-reviewing. Ask it to return prioritized findings with file references and evidence.
 5. After both finish, synthesize the results with findings first, deduplicated across reviewers. Weight overlapping findings more heavily, resolve disagreements with your own judgment, and keep summaries brief.
 
 If individual background summaries are already visible to the user, do not restate them wholesale. Surface the unified verdict, the highest-signal findings, and any remaining uncertainty.