tacticaldoll/nlp-agent-skills

Assay

Verwenden Sie dieses Skill, um eine lokale, gate-basierte statische Code-Review durchzuführen. Die Überprüfung öffnet Qualitäts-Gates in Reihenfolge; ein Fehler auf einem niedrigeren Gate blockiert höhere Gates, da spätere Beurteilungen nicht sinnvoll sind, wenn grundlegende Hygiene, Benennung oder Fehlerbehandlung bereits fehlerhaft sind.

Dieses Skill ruft keine Remote-Dienste auf, postet keine Kommentare, genehmigt keinen Code oder ändert keine Dateien. Es überprüft lokale oder eingefügte Eingaben und erstellt einen strukturierten Bericht.

Workflow

Phase 0: Lokale Eingabe auflösen

Normalisieren Sie die Eingabe des Benutzers in einen Überprüfungsbereich:

Eingabe	Auflösung
Eingefügter Code oder Diff	Überprüfen Sie den bereitgestellten Inhalt direkt
Lokale Dateipfade	Vollständigen Dateiinhalt lesen; kein Diff-Kontext, sofern nicht verfügbar
Lokaler Git-Diff	Geänderte Dateien und Hunks überprüfen
Commit-Hash oder -Bereich	Lokalen Git-Diff verwenden, wenn verfügbar
Branch-Name	Lokalen Merge-Base-Diff verwenden, wenn verfügbar
Mehrdeutige Anfrage	Nach Dateien, Diff, Commit/Bereich, Branch oder eingefügtem Code fragen

Rufen Sie keine MR/PR-Daten ab, keine Remote-APIs und erfordern Sie keine Authentifizierung. Wenn Remote-Kontext benötigt wird, bitten Sie den Benutzer, einen lokalen Diff oder eingefügten Inhalt bereitzustellen.

Phase 1: Überprüfungstiefe kalibrieren

Wählen Sie, wie viele Gates geöffnet werden sollen. Standardmäßig Gates 1-5 für normale lokale Änderungen.

Kontext	Gate-Bereich
Entwurf, WIP, explorativer Code	Gates 1-3
Normales Feature oder internes Tool	Gates 1-5
Gemeinsam genutzte Bibliothek, Produktionspfad oder öffentliche API	Gates 1-7
Sicherheitskritischer Code, Authentifizierung, Kryptografie, Befehlsausführung oder Benutzereingabegrenze	Gates 1-8

Bei Mehrdeutigkeit fragen, welches Ziel oder welches Risikoniveau der Code hat.

Phase 2: Große Umfänge triagieren

Wenn der Überprüfungsbereich mehr als 5 Dateien enthält, führen Sie vor der detaillierten Prüfung eine schnelle Triage durch. Bei 5 oder weniger Dateien überspringen Sie die Triage und fahren Sie mit der strukturellen Extraktion fort.

Triage-Prüfungen:

#	Prüfung	Fehlersignal
1	Toter Code	Auskommentierter Code, ungenutzte Importe, Debug-Ausgabe
2	Benennungsklarheit	Öffentliche Namen sind vage oder irreführend
3	Verschachtelungstiefe	Verschachtelung tiefer als 3 Ebenen
4	Funktionenlänge	Funktionen sind lang genug, um mehrere Verantwortlichkeiten zu verbergen
5	Fehlerschlucken	Leeres catch/except oder ignorierter Fehler
6	Domänenvermischung	I/O und Geschäftslogik in einer Einheit gemischt
7	Rohe Feldzusammenstellung	Komplexe Bedingungen fehlen semantische Helfer
8	Duplikationsgeruch	Ähnliche Logik tritt wiederholt auf
9	Sicherheitsgeruch	Geheimnisse, unsichere Interpolation, sensible Logs, ungeprüfte gefährliche Eingaben

Dateien klassifizieren:

Klasse	Kriterium	Nächster Schritt
Rot	3 oder mehr Prüfungen fehlgeschlagen	Vollständige Gate-Inspektion
Gelb	1-2 Prüfungen fehlgeschlagen	Ziel-Gate und alle niedrigeren Gates inspizieren
Grün	0 Prüfungen fehlgeschlagen	Bestehen, es sei denn, speziell angefordert

Sicherheitsgeruch ist zweigleisig: Melden Sie ihn als Triage-Alarm, auch wenn Gate 8 durch ein niedrigeres Gate blockiert ist.

Phase 3: Strukturelle Extraktion

Extrahieren Sie vor dem Öffnen der Gates für jede überprüfte Funktion, Klasse, Modul oder relevante Code-Einheit die Struktur. Verwenden Sie die Extraktion, um die Gate-Überprüfung zu leiten; verlassen Sie sich nicht nur auf den rohen Diff-Text.

Notieren Sie:

• Closures, Callbacks oder verschachtelte Funktionen.
• Inline-Objekte oder lokale Entitäten mit Verhalten.
• I/O-Operationen und externe Nebeneffekte.
• Tiefste Verschachtelung und der Grund dafür.
• Domänenverteilung: Infrastruktur, Geschäftslogik, Präsentation oder gemischt.
• Lebenszyklus: einmalig, persistent oder gemischt.
• Erfasste Variablen und versteckte Abhängigkeiten.
• Offensichtliche Anomalien, die während der Extraktion entdeckt wurden.
• Verfügbare Wahrheitsquelle für Gate 6: Lokalisieren Sie ein Spec oder Governance-Dokument (openspec/, PROJECT.md, AGENTS.md, ADRs, ein verknüpftes Issue), um die Logik zu beurteilen, oder notieren Sie, dass keines gefunden wurde.

Phase 4: Sequenzielle Gate-Überprüfung

Lesen Sie references/gates.md für Gate-Definitionen.

Öffnen Sie die Gates in der Reihenfolge. Wenn ein Gate fehlschlägt, öffnen Sie keine höheren Gates für diese Datei oder diesen Überprüfungsbereich. Erfinden Sie keine Befunde. Stille bedeutet Konformität für Detailabschnitte; das Gate-Index zeichnet weiterhin auf, welche Gates geöffnet, bestanden, fehlgeschlagen oder blockiert wurden.

Phase 5: Bericht

Erstellen Sie einen Bericht in diesem Format:

## Überprüfungsprotokoll

**Quelle**: [Eingabereferenz]
**Kalibrierung**: Gates 1-[N] ([Grund])
**Triage**: [übersprungen | Rot M / Gelb N / Grün K]
**Urteil**: [BESTANDEN | FEHLGESCHLAGEN bei Gate N]

### Gate-Index

| Gate | Fokus | Status |
|---:|---|---|
| 1 | Formatierung & Syntax-Hygiene | [bestanden | fehlgeschlagen | blockiert | nicht geprüft] |
| 2 | Benennung & Lesbarkeit | [bestanden | fehlgeschlagen | blockiert | nicht geprüft] |
| 3 | Fehlerbehandlung & Beobachtbarkeit | [bestanden | fehlgeschlagen | blockiert | nicht geprüft] |
| 4 | Kontrollfluss & strukturelle Klarheit | [bestanden | fehlgeschlagen | blockiert | nicht geprüft] |
| 5 | Verantwortung & Grenzen | [bestanden | fehlgeschlagen | blockiert | nicht geprüft] |
| 6 | Geschäftslogik-Integrität | [bestanden | fehlgeschlagen | blockiert | nicht geprüft] |
| 7 | Deduplizierung & Komposition | [bestanden | fehlgeschlagen | blockiert | nicht geprüft] |
| 8 | Sicherheit & Parameter-Integrität | [bestanden | fehlgeschlagen | blockiert | nicht geprüft] |

### Sicherheits-Triage-Alarm

[Nur einschließen, wenn Triage-Prüfung 9 fehlschlägt.]

### Gate N: [Name]

| # | Ort | Verstoß | Korrektur |
|---|---|---|---|
| 1 | `datei:zeile` | Gate N: spezifischer verletzter Standard | Konkrete Korrektur |

### Struktureller Anhang

[Zusammenfassungen für Code-Einheiten im Zusammenhang mit Befunden einschließen.]

Phase 6: Optionaler Korrekturplan

Erstellen Sie einen Korrekturplan nur, wenn der Benutzer danach fragt.

Korrekturplan-Regeln:

• Ein Verstoß pro Korrektur.
• Korrekturreihenfolge folgt der Gate-Reihenfolge.
• Innerhalb desselben Gates nach Datei und Zeile ordnen, es sei denn, logische Abhängigkeiten erfordern eine andere Reihenfolge.
• Keine opportunistischen Korrekturen.
• Jede Korrektur enthält Überprüfungskriterien.

Regeln

• Nur überprüfen; Code nicht ändern.
• Nur lokale oder eingefügte Eingaben verwenden; keine Remote-PR/MR-APIs aufrufen.
• Gates sequenziell öffnen und beim ersten fehlgeschlagenen Gate anhalten.
• Sicherheits-Triage-Alarme melden, auch wenn die tiefgehende Sicherheitsprüfung blockiert ist.
• Konkrete Korrekturen geben; vage Vorschläge wie "Verbesserung in Betracht ziehen" vermeiden.
• Wenn alle geöffneten Gates bestanden werden, ist der Gate-Index der Bericht; keine Befunde erfinden.
• Erwähnen, wenn Tests, Builds oder Laufzeitprüfungen nicht durchgeführt wurden.
• Im eigenen Bereich bleiben; an der Grenze übergeben. Dieses Skill ist eine statische, lokale Überprüfung. Für Laufzeit-/Verhaltenskorrektheit auf verify verweisen; für tiefgehende Sicherheitsanalyse über die Oberflächenprüfungen von Gate 8 hinaus auf security-review verweisen. Die Übergabe benennen, anstatt die Aufgabe des anderen Skills halb zu erledigen.