Org-Audit in Aufgaben
Die manuelle Version davon dauerte einen halben Tag: ein langes Audit lesen, entscheiden, was zusammengehört, jede Aufgabe mit Priorität und Definition of Done schreiben und sie dann in den Tracker eingeben. Dieses Skill übernimmt das Lesen und das Eintippen. Das Entscheiden bleibt beim Menschen.
Schritt 1: Vor dem Handeln fragen
In einer Nachricht fragen und warten:
- Welche Org (CLI-Alias)? Bestätigen, dass es sich nicht um eine Kunden-Produktionsorg handelt, es sei denn, das Engagement erlaubt schreibgeschützte Scans dort.
- Wohin sollen die Aufgaben? ClickUp (welche Liste) oder GitHub (welches Repo). Prüfen, ob der passende MCP-Server verbunden ist; wenn nicht, anhalten und erklären, wie man ihn verbindet.
- Wem gehören die Aufgaben? Namen der Beauftragten oder unzugewiesen lassen.
- Gibt es etwas auszuschließen? Manche Befunde sind bekannt und akzeptiert. Das jetzt zu sagen, spart später Lärm.
Schritt 2: Audit
node audit.js --org <alias> --out ./out
Schreibt out/findings.md und out/findings.json. Schreibgeschützt: Jeder Aufruf ist eine Abfrage oder eine Auflistung.
Schritt 3: Aufgaben formen
node to-tasks.js out/findings.json
Schreibt out/tasks.json: eine Aufgabe pro Befundtyp und Schweregrad, jede betroffene Komponente als Checklistenpunkt, große Gruppen in Batches von 25 aufgeteilt, mit Priorität, Aufwand, Labels und Akzeptanzkriterien.
Schritt 4: Mit der Person überprüfen
Die Aufgabenliste als Tabelle anzeigen: Schlüssel, Titel, Priorität, Aufwand, Anzahl der Checklisten. Dann das Urteilsvermögen anwenden, das das Skript nicht hat:
- Zusammenführen oder aufteilen, wo die Gruppierung nicht zur Arbeitsweise des Teams passt.
- Befunde fallen lassen, die die Person in Schritt 1 ausgeschlossen hat.
- Dinge hervorheben, die klein aussehen, es aber nicht sind (ein Integrationsbenutzer mit „Alle Daten ändern“ ist ein Sicherheits- und ein Change-Control-Befund).
- Akzeptanzkriterien umschreiben, wenn das Team eine eigene Definition of Done hat.
Erst etwas erstellen, wenn die Person sagt, die Liste sei richtig.
Schritt 5: Erstellen
Jede genehmigte Aufgabe über den verbundenen MCP-Server erstellen, oder für GitHub mit node create-issues.js --repo owner/name (zuerst mit --dry-run eine Vorschau anzeigen), mit Titel, Beschreibung, Priorität, Labels, Checkliste (ClickUp-Checkliste oder eine GitHub-Aufgabenliste im Textkörper) und Akzeptanzkriterien. Die URL jeder erstellten Aufgabe zurück in out/tasks.json unter url eintragen.
Dann berichten: wie viele Aufgaben erstellt wurden, wo, und die Zeit von Schritt 2 bis zur letzten erstellten Aufgabe.
Regeln
- Das Audit schreibt nie in die Org.
- Es wird keine Aufgabe ohne Genehmigung der Liste erstellt.
- Keine Kundennamen in etwas, das den Engagement-Ordner verlässt.
- Wenn ein Aufgabensystem-Aufruf fehlschlägt, anhalten, melden, was erstellt wurde und was nicht, und nicht blind wiederholen.