thermo-nuclear-code-quality-review

Sterne3

Forks0

Aktualisiert19. Juli 2026 um 22:56

Run the harshest band of code review — an extremely strict maintainability pass focused on abstraction quality, file-size growth, and spaghetti-condition creep. Use when the user asks for a "thermo-nuclear review", "thermonuclear code review", "deep code quality audit", or an especially harsh / strict maintainability review.

Installation

Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.

In Manus ausführen

Quelle

shinaBR2

shinaBR2/sworld

GitHub-Repository öffnen Creator-Repositorys ansehen

Download

In Manus ausführen

Verwandte BerufeSOC

Basierend auf der SOC-Berufsklassifikation

Softwarequalitätssicherungsanalysten und -testerInformatik- und Mathematikberufe·SOC 15-1253

SKILL.md

readonly

name	thermo-nuclear-code-quality-review
description	Run the harshest band of code review — an extremely strict maintainability pass focused on abstraction quality, file-size growth, and spaghetti-condition creep. Use when the user asks for a "thermo-nuclear review", "thermonuclear code review", "deep code quality audit", or an especially harsh / strict maintainability review.

Thermo-Nuclear Code Quality Review

This is the thermo-nuclear band of self-review, not a separate review.

Load self-review and run it at that band: Step 2 defines the band, and Step 4 — Maintainability carries the bar it applies.

Mehr aus diesem Repository

gleiches Repository

ci-loop

shinaBR2/sworld

The post-PR CI gate loop — a strict sequential state machine that drives an open PR to settled: merge status → conflicts → unresolved review threads → CI checks, fixing/pushing/waiting/restarting until every gate is green, then reporting ready (never auto-merging). Use whenever the user says "do the loop", "run the loop", "the CI loop", "check the PR", or invokes /ci-loop. On merge it runs `cleanup` for teardown. It does NOT do the pre-PR self-review (that's `parallel-workflow`'s gate) and never touches issue status (that's the tracker's — see `task-tracker`).

2026-07-213

parallel-workflow

shinaBR2/sworld

Enforces the parallel subtask workflow using tracker issues, git worktrees, and PRs. Auto-triggers when working with git, branches, worktrees, PRs, tracker issues/tasks, codegen, or CI.

2026-07-203

task-tracker

shinaBR2/sworld

The single source of truth for WHICH task tracker we use and HOW to talk to it. Load this whenever you need to create, read, update, relate, or comment on a task/issue/project, or whenever another skill says "the task tracker", "the tracker issue", "the issue's state", or points at `task-tracker`. It owns the tool (Linear, via the `linear` CLI — never the Linear MCP), auth, the SWorld team and `SWO` key, the project-is-an-app model, the Backlog→Todo→In Progress→In Review→Done lifecycle, and the exact issue/relation/document command forms. Reach for it any time a workflow step runs a `linear …` command or names a tracker concept, even when the triggering skill refers to "the issue" only generically.

2026-07-203

dev-environment-gotchas

shinaBR2/sworld

Known traps in the sworld local dev/build tooling — stale package dists, turbo cache masking bundle changes, Node version pinning, pnpm's dependency cooldown, CodeGraph setup, and bundle-size vs error-tracking tradeoffs. Auto-triggers when a dev server fails to resolve a core/ui subpath, a build "works" but the change isn't visible, adding/upgrading a dependency, or trimming bundle size for perf.

2026-07-203

analyze

shinaBR2/sworld

The audit pass on an already-scoped ticket and its sub-issue breakdown, run BEFORE any code. Use it as the first move whenever picking up, starting, resuming, or "analysing" a non-trivial tracker issue — especially a large-feature parent with sub-issues — to catch missing requirements and a breakdown that has drifted out of sync before you build against it. Reach for it the moment you're about to start an issue, when a plan "looks done" but nobody has re-checked it, or when the user says "analyse this issue / take a look at this breakdown / is this plan right". This is the backward/audit direction on a *spec* — distinct from `product-planning`/`grill-me` (forward, idea → breakdown) and `self-review` (analysing *code*). Not needed for a trivial, single-issue bug or a one-line change with no breakdown to audit.

2026-07-193

architecture

shinaBR2/sworld

Enforces frontend architecture patterns including server state management, data transformation, and GraphQL conventions. Auto-triggers when working with API calls, data fetching, react-query, GraphQL, or data transformations.

2026-07-193