STOP. LESEN SIE DIESES SKILL.MD VOLLSTÄNDIG, BEVOR SIE EINEN ENDPUNKT AUFRUFEN.
Was macht assess?
Treten Sie einen Schritt zurück und nehmen Sie eine kritische Neubewertung des Projektzustands vor. Bietet interaktive Anleitung (Human-in-the-Loop) und programmatische Analyse (automatisierte Pipelines). Spezialisiert auf Dokumentationsbereinigung und Dokumentations-Code-Abgleich.
CLI-Nutzung
# Strukturierte JSON-Bewertung für Pipelines
.pi/skills/assess/assess.py run . --output assessment.json
# Alle Abbildungen aus der Bewertung generieren
create-figure from-assess --input assessment.json --output-dir ./figures/
Bewertungsablauf
1. Bewertungsumfang festlegen
Klaren Umfang ("Auth-Modul bewerten") → direkt fortfahren. Offenen Umfang ("Schritt zurücktreten") → fragen: Bedenken? Codequalität vs. Docs? Bekannte Probleme überspringen? Dokumentationsbereinigung ("Dokumentation bereinigen") → fragen: Veraltete Funktionen? Fehlende Docs? Ausrichtung?
2. Projektstammverzeichnis finden & Ökosystem erkennen
Erkennung über Markierungsdateien (pyproject.toml, package.json, Cargo.toml, go.mod). Ökosystemspezifische Metadaten lesen, dann universelle Dokumentation (README.md, CONTEXT.md, AGENTS.md).
3. Skill-Manifest laden (Route-gesteuert)
Laden Sie .pi/skills-manifest.json für Bewertungen, die zu Empfehlungen wie "wir sollten X bauen" führen könnten. Überspringen für Statusprüfungen und reine Dokumentationsüberprüfungen.
cat .pi/skills-manifest.json | python3 -c "
import json, sys
data = json.load(sys.stdin)
print(f'Skills: {data[\"skill_count\"]} (generiert: {data[\"generated\"]})')
"
Warnung, wenn Manifest >7 Tage alt ist. Fallback: ls .pi/skills/ | wc -l.
4. Schnellscan → Rückmeldung einholen → Tiefenanalyse
- Projektmetadaten, README lesen, nach Struktur global suchen
- 2-3 erste Beobachtungen notieren, mit Benutzer abstimmen
- Tiefenanalyse basierend auf Benutzerführung — für jede Feststellung: blockierend? bekannt? Änderungskomplexität?
5. Kollaborativer Bericht
Feststellungen präsentieren und fragen, welche behoben werden sollen. /create-figure zur Visualisierung anbieten.
Bewertungskategorien
1. Dokumentations-Code-Abgleich
- README-Behauptungen vs. Implementierung
- Kreuzreferenzvalidierung (interne Links, Codebeispiele)
- Platzhalter und veraltete Informationen
- Veraltete Funktionen: Docs für entfernte Funktionalität
2. Angestrebt vs. Implementiert
- Stubs (
pass,raise NotImplementedError), Platzhalternotizen - Funktionen in der Codestruktur ohne Logik, ungenutzte Abhängigkeiten
3. Spröder Code
- Hartcodierte Werte, fehlende Fehlerbehandlung, anfällige Regex/Parsing
4. Nicht funktionierender Code
- Tote Codepfade, stilles Verschlucken von Ausnahmen, defekte Integrationen
5. Überengineerter Code
- Abstraktionen mit einzelner Implementierung, Konfiguration für hypothetische Flexibilität
6. Testabdeckung (Nicht verhandelbar)
Überprüfen Sie jedes Feature/Modul auf Testdateien, bestehende Tests, Randfälle.
Kennzeichnen Sie pytest.mark.skip ohne Grund, "0 tests collected", Tests ohne Behauptungen.
Aufgabendatei-Prüfung: Stellen Sie sicher, dass jede Aufgabe eine Definition of Done mit spezifischem Test/Behauptung enthält. Blockieren Sie die Ausführung, wenn Implementierungsaufgaben keine Definition of Done haben.
7. Gut funktionierend
Solide Codes anerkennen, um die Bewertung zu kalibrieren.
Ausgabeformat
# Bewertung: <Projektname>
## Zusammenfassung
<2-3 Sätze: Gesamtzustand, Hauptergebnisse>
## Feststellungen
### Dokumentations-Code-Abgleich
| Behauptung | Realität | Aktion? |
### Gefundene Probleme
1. **datei.py:123** - [Problem] — Schweregrad: H/M/N — Vorgeschlagene Korrektur: [kurz]
### Testabdeckung
| Feature | Teststatus | Erforderliche Aktion |
### Gut funktionierend
- [Solider Code zum Anerkennen]
## Empfohlene nächste Schritte
1-4 priorisierte Aktionen. Fragen, womit begonnen werden soll.
Richtlinien
- Standardmäßig schreibgeschützt — niemals Dateien ohne explizite Zustimmung schreiben
- Zuerst drucken, dann mit Zustimmung schreiben — vorgeschlagenen Inhalt anzeigen, dann Schreiben anbieten
- Zusammenarbeiten — Bewertung ist Dialog, kein Monolog
- Vor Ausführung fragen — Erlaubnis einholen vor Tests, Builds, kostenpflichtigen Diensten
- Klug eskalieren —
/review-codefür komplexe/kritische Probleme vorschlagen - Spezifisch sein — Dateipfade und Zeilennummern
- Handlungsorientiert sein — jede Feststellung schlägt nächste Schritte vor
- Testabdeckung ist nicht verhandelbar — fehlende Tests als Blockierer kennzeichnen
Externe Recherche
Verfügbar bei Bedarf (vor kostenpflichtigen Diensten fragen):
/context7— Bibliotheksdokumentation (kostenlos)/brave-search— allgemeines Web (kostenlos)/perplexity— tiefgehende Recherche (kostenpflichtig)
Häufige Fehler
# FALSCH: Alle Bewertungsergebnisse als blockierende Probleme behandeln
# → Agent fügt automatisch Docstrings zu 12 privaten Helfern hinzu. Unnötige Aufblähung.
# RICHTIG: Ergebnisse mit Benutzer durchgehen. Komplexe Probleme an /review-code eskalieren.
# FALSCH: /assess nach größeren Änderungen überspringen
# → README-Beispiele verwenden alte Funktionssignatur. Benutzer stoßen auf Fehler.
# RICHTIG: assess --focus "doc-code-alignment" nach Bearbeitung von Kern-APIs ausführen
# FALSCH: /assess ausführen und auf veraltete Ergebnisse reagieren
# → Bewertung war von vor 3 Tagen. Codebasis seitdem geändert.
# RICHTIG: assess immer erneut ausführen; Ergebnisse niemals über Sitzungen hinweg zwischenspeichern