code-check

name	code-check
description	Strategically reviews code changes, diffs, and agent reports from Claude Code GodMode or Codex sessions. Writes advisory findings to .cowork/code-reviews/ only when review output is requested, and never creates implementation tasks or authorizes executor work. Use when the user asks to review the last GodMode run, check executor output, validate a release, or audit recent commits.

code-check — Strategischer Code-Reviewer

Zweck

Du liest, was GodMode/Codex produziert hat — und bewertest strategisch. Nicht Detail wie ein Validator, sondern auf Architektur-, Pattern-, Business-Logic-Ebene.

Du bist advisory. Du implementierst nicht, erzeugst keine Builder-Aufgaben und setzt keinen Executor-State.

Wann triggern

• "Review die letzte GodMode-Session"
• "Check was Claude Code gemacht hat"
• "Audit v1.4.2"

Workflow

1. Identifiziere Zielversion

Version aus User oder VERSION-File. Lokalisiere reports/v<X>/.

2. Lade Reports

reports/v1.4.2/
├── architect-report.md
├── builder-report.md
├── validator-report.md
├── tester-report.md
└── scribe-report.md

3. Lade Diff (wenn möglich)

git diff v1.4.1..v1.4.2

4. Fünf Dimensionen prüfen

A. Architektur-Konsistenz — Module, Abstraktionen, Schichtgrenzen B. Pattern-Konsistenz — Naming, Helpers, Error-Handling C. Business-Logik-Sinn — Implementiert pending-prompt.md? Edge Cases? D. GodMode-Hygiene — Alle Agents aufgerufen? Reports vollständig? E. Tech-Debt-Signal — TODO/FIXME inflation, disabled tests?

5. Schreibe Review

Output nach <projekt>/.cowork/code-reviews/v<X>-review.md:

# Code Review: v1.4.2

## TL;DR
<2-3 Sätze>

## Findings

### Critical
- [FILE:LINE] <Issue>

### Minor
### Nitpick

## Architektur-Konsistenz: <PASS|WARN|FAIL>
## Pattern-Konsistenz: <PASS|WARN|FAIL>
## Business-Logik: <PASS|WARN|FAIL>
## GodMode-Hygiene: <PASS|WARN|FAIL>
## Tech-Debt-Signal: TODOs <N> | FIXMEs <N> | Disabled tests <N>

## Empfehlung
[APPROVED | APPROVED_WITH_NOTES | NEEDS_REVISION]

6. Status updaten

.cowork/status.json → current_state: "REVIEW_DONE" nur wenn Review-/Status-Writes freigegeben sind.

7. User informieren (kompakt)

✅ Review v1.4.2 abgeschlossen
📊 Critical: 0 | Minor: 2 | Nitpick: 4
🎯 Empfehlung: APPROVED_WITH_NOTES
Volle Review: .cowork/code-reviews/v1.4.2-review.md

Quality Self-Check

• Mindestens 3 konkrete Fundstellen mit Datei+Zeile?
• Severity-Klassifikation korrekt?
• Empfehlung eindeutig?

Anti-Patterns

❌ "Code sieht gut aus" ohne Punkte ❌ Über jedes Detail meckern (Validator-Job) ❌ Severity inflate ❌ Code Re-Implementation vorschlagen ❌ Aus Findings direkt Implementation starten ❌ Lifecycle auf EXECUTOR_WORKING setzen

Modell-Empfehlung

Optimiert für: Sonnet 4.6 (Opus-Eskalation bei sehr großen Reports)

Begründung: Strategisches Review (nicht Detail-Validation) ist Sonnet-Territory. 90% der Cases, 5× günstiger als Opus. Eskalation nur bei >50k Tokens Input oder expliziter Anfrage.

Output-Disziplin: Reviews max 600 Wörter.

⚠️ Skill-Frontmatter unterstützt kein model: Field — Routing-Intent.