AnpingWhale/skills

Setup Anping Skills – Projektstarter

Initialisiert das aktuelle Repository als Projektumgebung für die langfristige Zusammenarbeit mit Codex. Dieses Skill ist prompt-gesteuert, kein deterministisches Installationsskript: Zuerst wird erkundet, dann gefragt, dann ein Entwurf gezeigt und schließlich geschrieben.

Ziel ist es, nicht alle Skills zu installieren, sondern nach Projektbedarf zu kombinieren:

• Anping-eigene Skills, z.B. multi-agent-orchestrator, transfer-codex-sessions.
• Externe gute Skills, z.B. Matt Pococks Engineering Skills.
• Projektspezifische Regel- und Wissensdateien, z.B. AGENTS.md, CONTEXT.md, CONTEXT-MAP.md, docs/agents/, docs/adr/.

Ausführungsprinzipien

• Vor Beginn die Ausführungsumgebung klären. Langfristige oder mehrteilige Initialisierungen sollten den Multi-Agent-Orchestrierungsregeln des aktuellen Projekts folgen; falls die Tool-Richtlinie keine Delegation erlaubt, wird ein gestaffeltes Fallback verwendet.
• Es wird immer nur ein Teil des Problems auf einmal abgefragt. Nicht alle Entscheidungen auf einmal an den Benutzer übergeben.
• Jedes empfohlene Skill muss dessen Zweck, Quelle und Eignung für das aktuelle Projekt erläutern.
• Quellcode von Drittanbieter-Skills wird nicht als Vendor integriert. Externe Skills werden nur über Installationsquellen oder Referenzverzeichnisse angebunden.
• Vor dem Schreiben werden die zu ändernden Dateien, relevante Blöcke und die Standardauswahl gezeigt; erst nach Bestätigung durch den Benutzer wird geschrieben.
• Vorhandene Inhalte von AGENTS.md, README.md, CONTEXT.md oder docs/agents/* werden nicht überschrieben; bestehende Blöcke werden aktualisiert, doppelte Anhänge vermieden.

Arbeitsablauf

1. Vorkontrolle der abhängigen Skills

Zunächst wird geprüft, ob in der aktuellen Sitzung und in ~/.codex/skills/ bereits wichtige Skills vorhanden sind. references/skill-catalog.md wird gelesen, um basierend auf dem Projektbedarf zu entscheiden, welche Skills erforderlich, empfohlen oder optional sind:

• Skill-Auswahl und Zielklärung: ask-matt, grill-with-docs.
• Domänenmodellierung und Wissensdokumentation: domain-modeling.
• Hauptthread-Orchestrierung: multi-agent-orchestrator.
• Engineering-Projektkonfiguration: setup-matt-pocock-skills.

Fehlende Skills werden nicht automatisch installiert. Zuerst wird der Benutzer über fehlende Skills, deren Quelle, Zweck und Empfehlungsstufe informiert. Nach Bestätigung werden sie per skill-installer oder der empfohlenen Methode des Anbieters installiert.

2. Projekt erkunden

Der aktuelle Repository-Status wird schnell ausgelesen, dem Benutzer wird nur eine kurze Zusammenfassung gegeben, ohne voreilige Schlüsse zu ziehen:

• git remote -v und .git/config: Ob es sich um ein GitHub-/GitLab-/lokales Projekt handelt.
• Stammverzeichnis AGENTS.md, CLAUDE.md: Ob bereits Agentenregeln oder Abschnitte zu Agent skills vorhanden sind.
• Stammverzeichnis README.md: Ist das Projektziel bereits klar beschrieben?
• Stammverzeichnis CONTEXT.md, CONTEXT-MAP.md.
• docs/agents/, docs/adr/, src/*/docs/adr/.
• .scratch/: Existiert bereits eine lokale Markdown-Issue-Konvention?
• ~/.codex/skills/ oder verfügbare Skills der aktuellen Sitzung: Welche eigenen und externen Skills sind installiert?

3. Ergebnisse präsentieren

Dem Benutzer wird mit einer kurzen Liste mitgeteilt:

• Um welchen Projekttyp es sich grob handelt.
• Bereits vorhandene KI-Kollaborationsdateien.
• Fehlende, aber potenziell wertvolle Dateien.
• Installierte/nicht installierte wichtige Skills.
• Welche Entscheidungen als Nächstes schrittweise abgefragt werden.

4. Schrittweise Abfragen

Jeder Abschnitt erklärt zunächst in 1-3 Sätzen Zweck und Auswirkungen, gibt dann eine Standardempfehlung und wartet auf die Antwort des Benutzers, bevor zum nächsten Abschnitt übergegangen wird.

A. Projektziel

Falls das Projektziel unklar ist, wird zuerst ask-matt verwendet, um einen geeigneten Prozess auszuwählen; wenn eine begleitende Dokumentation während des Interviews erforderlich ist, wird grill-with-docs verwendet. Nach Einigung über das Ziel wird gefragt, ob die Projektbeschreibung in README.md geschrieben oder aktualisiert werden soll.

B. Hauptthread-Orchestrierungsmodus

Gefragt wird, ob multi-agent-orchestrator aktiviert werden soll. Erläutert werden die Vorteile: Kontextverwaltung, unabhängige Validierung und Reduzierung von Selbstvalidierung; der Nachteil: kurze Aufgaben könnten die Gesamt-Token erhöhen. Nach Zustimmung des Benutzers wird weiter gefragt, ob eine projektweite Delegationsgenehmigung geschrieben werden soll: Der Hauptthread darf in Übereinstimmung mit System-/Entwickler-/Tool-Richtlinien, Repository-Regeln und Genehmigungsanforderungen eigenständig Subagenten / Rollenagenten mit einem für den Benutzer sichtbaren Codex-Thread erstellen oder verwenden. Nach Bestätigung werden die Hauptthread-Orchestrierungsregeln und die Genehmigung in AGENTS.md geschrieben, wobei bevorzugt die Vorlage des installierten Skills verwendet wird.

C. Kontextlayout

Der Benutzer kann wählen:

• Single-context: Ein CONTEXT.md im Stammverzeichnis und docs/adr/. Standard für die meisten Repositories.
• Multi-context: Ein CONTEXT-MAP.md im Stammverzeichnis, das auf mehrere Kontextverzeichnisse verweist, geeignet für Monorepos oder Multi-Produkt-Repositories.

Wenn konkrete Dateien geschrieben werden müssen, wird references/project-files.md gelesen.

D. Projektwissensdatenbank

Gefragt wird, ob eine für Menschen und KI lesbare Projektwissensdatenbank erstellt werden soll. Standardempfehlung:

• docs/agents/anping-skills.md: Liste der in diesem Projekt aktivierten Skills, deren Zweck und Aufrufgrenzen.
• docs/agents/project-knowledge.md: Regeln für die Wissensdokumentation im Projekt.
• docs/adr/README.md: Anleitung zur Verwendung von ADRs. Standardmäßig werden ADRs auf Chinesisch verfasst, es sei denn, der Benutzer wünscht explizit Englisch oder Zweisprachigkeit.

E. Einbindung externer Skills

Je nach Projekttyp werden externe Skills empfohlen. Standardmäßig werden nicht alle installiert; nur die für das aktuelle Projekt relevanten Kombinationen werden empfohlen. Vor der Installation von Drittanbieter-Skills werden Quelle und Begründung erläutert und eine Bestätigung eingeholt.

5. Entwurf präsentieren und bestätigen lassen

Vor dem Schreiben werden präsentiert:

• Liste der zu ändernden oder zu erstellenden Dateien.
• Zusammenfassung der in AGENTS.md hinzuzufügenden/zu aktualisierenden Abschnitte, einschließlich der Frage, ob eine Delegation Authorization geschrieben wird.
• Liste der in docs/agents/anping-skills.md zu dokumentierenden Skills.
• Layout von CONTEXT.md oder CONTEXT-MAP.md.
• Hinweis, ob externe Skills installiert oder zur Installation empfohlen werden.

Nach Bestätigung durch den Benutzer werden die Dateiänderungen vorgenommen.

6. Projektkonfiguration schreiben

Entsprechend der Benutzerauswahl wird geschrieben:

• Abschnitt zur Anping/Codex-Kollaboration in AGENTS.md oder einer vorhandenen Agentenregeldatei.
• docs/agents/anping-skills.md.
• docs/agents/project-knowledge.md.
• CONTEXT.md oder CONTEXT-MAP.md.
• docs/adr/README.md.
• Sicherheitsausschlüsse in .gitignore, z.B. codex_sessions/, falls das Projekt Sitzungsmigration verwendet.

Falls das Projekt auch setup-matt-pocock-skills verwendet, wird ein inhaltlich gleicher Agent skills-Block nicht doppelt geschrieben; vorhandene Abschnitte werden aktualisiert oder zusammengeführt.

7. Verifikation

Nach dem Schreiben wird eine leichte Verifikation durchgeführt, bevor der Abschluss gemeldet wird:

• Die geänderten Schlüsselabschnitte werden erneut gelesen, um sicherzustellen, dass der Inhalt in den erwarteten Dateien landet.
• Es wird geprüft, dass keine doppelten Blöcke zu Anping / Agent skills / Multi-Agent Orchestrator vorhanden sind.
• Es wird bestätigt, dass die zu erstellenden Dateien existieren, z.B. docs/agents/anping-skills.md, CONTEXT.md oder CONTEXT-MAP.md, docs/adr/README.md.
• Falls YAML-, TOML-, JSON- oder andere parsebare Konfigurationen geändert wurden, wird die Formatierung mit einem lokalen Parser validiert.
• Falls eine Auswahl nicht umgesetzt wurde, werden der Grund und das verbleibende Risiko dokumentiert.

8. Abschluss

Abschließend wird berichtet:

• Welche Fähigkeiten aktiviert wurden.
• Welche Dateien geändert wurden.
• Welche Skills installiert und welche nur empfohlen wurden.
• Wie der Benutzer später mit einem Satz diese Fähigkeiten auslösen kann.
• Verbleibende Risiken, z.B. nicht installierte externe Skills, nicht verfügbare GitHub-Anmeldeinformationen oder noch unklares Projektziel.

Es wird nicht automatisch committet, gepusht oder öffentlich hochgeladen, es sei denn, der Benutzer fordert dies ausdrücklich.