BIGboss248/nextjs-wordpress

Antigravity-Anpassungstool (ag-customizer)

Verwende diesen Skill, um Anpassungen für Google Antigravity in Arbeitsbereichs- und globalen Geltungsbereichen eigenständig zu entwerfen, zu erstellen, zu konfigurieren, zu migrieren und zu validieren.

---

Entscheidungsmatrix für die Schnellnavigation

Bestimme, welcher Anpassungsmechanismus das Problem am besten löst:

Anforderung	Mechanismus	Dateispeicherort	Referenzhandbuch
Dem Agenten ein mehrschrittiges Runbook, eine Prozedur oder einen Slash-Befehl beibringen	Skill	.agents/skills/<name>/SKILL.md oder ~/.gemini/antigravity/skills/<name>/SKILL.md	skills-guide.md
Dauerhafte Einschränkungen, Codierungsstandards oder Stilregeln durchsetzen	Regel	.agents/rules/<name>.md, AGENTS.md oder ~/.gemini/GEMINI.md	rules-guide.md
Externe Dienste, lokale Datenbanken oder benutzerdefinierte Tools anbinden	MCP-Server	.agents/mcp_config.json oder ~/.gemini/config/mcp_config.json	mcp-guide.md
In Lebenszyklus-Ereignisse eingreifen (Befehle steuern, Prompts injizieren, Watchdog stoppen)	Lifecycle-Hook	.agents/hooks.json oder ~/.gemini/config/hooks.json	hooks-guide.md
Skills, Regeln, Hooks und MCP in einem gemeinsam nutzbaren Paket bündeln	Plugin	.agents/plugins/<name>/ oder ~/.gemini/config/plugins/<name>/	plugins-and-configs.md
Nicht standardmäßige Pfade registrieren oder Anpassungen über VCS teilen	JSON-Konfiguration	.agents/skills.json oder .agents/plugins.json	plugins-and-configs.md
Veraltete Workflows in moderne Slash-Command-Skills upgraden	Workflow-Migration	.agents/workflows/*.md -> .agents/skills/<name>/SKILL.md	workflows-migration.md

---

Betriebsabläufe

1. Einen neuen Skill hinzufügen

1. Geltungsbereich bestimmen:
   • Arbeitsbereich: .agents/skills/<name>/ (für die Teamnutzung ins Repository eingecheckt).
   • Global: ~/.gemini/antigravity/skills/<name>/ (projektübergreifend verfügbar).
2. Verzeichnisstruktur aufbauen:

   <customization_root>/skills/<skill-name>/
   ├── SKILL.md             # Erforderlich: Einstiegspunkt mit YAML-Frontmatter
   ├── scripts/             # Optional: Hilfsskripte (mit --help-Muster ausführen)
   ├── references/          # Optional: Bereitgestellte Handbücher und umfangreiche Dokumentation
   └── examples/            # Optional: Beispielcode oder Ausgabereferenzen
   

3. Frontmatter entwerfen:
   • name: Kleinbuchstaben, mit Bindestrichen (z. B. nextjs-otel, docker-deploy). Dies registriert auch einen Slash-Befehl (/<name>).
   • description: 1–3 Sätze in dritter Person, die explizit was der Skill tut und spezifische Auslöser/Szenarien angeben, bei denen der Agent ihn aktivieren soll.
4. Progressive Offenlegung anwenden:
   • Halte das Haupt-SKILL.md eng auf die Abfolge der betrieblichen Schritte und die Abschlusskriterien fokussiert.
   • Lagere tiefgehendes Referenzmaterial in references/<topic>.md-Dateien aus und verlinke relativ darauf.
   • Siehe skills-guide.md für Strukturvorlagen.
5. Obsidian-Spiegelprüfung:
   • Wenn du Skills in diesem Arbeitsbereich aktualisierst oder erstellst, spiegele den Skill-Ordner gemäß den Repository-Richtlinien nach d:/Scripts/Obsidian/skills/<name>/.

---

2. Eine Regel erstellen

1. Geltungsbereich und Format bestimmen:
   • Arbeitsbereichsregel: .agents/rules/<rule-name>.md oder AGENTS.md im Projektstammverzeichnis.
   • Globale Regel: ~/.gemini/GEMINI.md.
2. Aktivierungsmodus wählen (für .agents/rules/*.md):
   • always_on: Wird bedingungslos in jede Runde eingefügt. Sparsam verwenden, um Kontext zu schonen.
   • model_decision: Wird offengelegt, wenn der Agent die Relevanz anhand der Beschreibung bestimmt.
   • glob: Wird automatisch aktiviert, wenn passende Dateien berührt oder geöffnet werden (z. B. *.tsx, src/api/**/*.ts).
   • manual: Wird nur geladen, wenn es explizit über @mention im Chat aufgerufen wird (z. B. @my-rule.md).
3. Inhalt verfassen:
   • Halte dich an das 12.000-Zeichen-Budget pro Datei.
   • Beschreibe Zielverhalten positiv („Mach X“, „Strukturiere Y immer“) anstatt durch Verbote.
   • Verwende @dateiname, um bei Bedarf auf zugehörige Kontextdateien zu verlinken.
   • Siehe rules-guide.md für die vollständige Syntax und das Aktivierungs-Frontmatter.

---

3. Einen MCP-Server konfigurieren

1. Dateispeicherort bestimmen:
   • Arbeitsbereich: <workspace>/.agents/mcp_config.json
   • Global: ~/.gemini/config/mcp_config.json
2. Transport auswählen:
   • stdio (Lokale ausführbare Datei):

     {
       "mcpServers": {
         "my-server": {
           "command": "npx",
           "args": ["-y", "@modelcontextprotocol/server-sqlite", "app.db"],
           "env": { "SQLITE_READONLY": "true" }
         }
       }
     }
     

   • Remote (SSE / Streamable HTTP):

     [!IMPORTANT] Verwende immer den Schlüssel serverUrl. Die veralteten Schlüssel url oder httpUrl werden nicht unterstützt.

     {
       "mcpServers": {
         "my-remote": {
           "serverUrl": "https://api.example.com/mcp/",
           "headers": { "Authorization": "Bearer YOUR_TOKEN" }
         }
       }
     }
     

3. Authentifizierung:
   • Google Application Default Credentials: "authProviderType": "google_credentials" (erfordert gcloud auth application-default login).
   • OAuth: "oauth": { "clientId": "...", "clientSecret": "..." } mit Redirect-URI https://antigravity.google/oauth-callback.
4. Tool-Filterung:
   • Deaktiviere Tools vorübergehend, ohne den Server zu entfernen: "disabledTools": ["destructive_command"].
   • Siehe mcp-guide.md für vorgefertigte Konfigurationen.

---

4. Lifecycle-Hooks einrichten

1. Zieldatei: .agents/hooks.json (oder ~/.gemini/config/hooks.json).
2. Unterstützte Ereignisse:
   • PreToolUse: Vergleiche Toolnamen (run_command, write_to_file, *), um die Ausführung zu steuern (allow, deny, ask, force_ask) oder Argumente flach zu überschreiben.
   • PostToolUse: Überprüfe die Ausgabe, führe Linter aus oder formatiere Code nach Abschluss des Tools.
   • PreInvocation: Füge Kontext oder Systemanweisungen (injectSteps mit ephemeralMessage) ein, bevor das Modell die Runde verarbeitet.
   • PostInvocation: Erzwinge Fortsetzung (terminationBehavior: "force_continue") oder Stopp.
   • Stop: Überprüfe den Aufgabenabschluss (terminationReason, fullyIdle) und gib decision: "continue" mit reason zurück, um vorzeitigen Abbruch zu verhindern.
3. Vertragsregeln:
   • Die Ausführung übergibt Kontext über stdin und erhält die Antwort über stdout.
   • Alle JSON-Payload-Schlüssel verwenden camelCase (conversationId, stepIdx, toolCall usw.).
   • Befehle werden synchron ausgeführt und blockieren die Agentenschleife bis zum Timeout (Standard 30 s).
   • Siehe hooks-guide.md für Vorlagen in Python, PowerShell und Bash.

---

5. Ein Plugin oder eine VCS-freigegebene Konfiguration packen

1. Plugin-Paket:
   • Gruppiere verwandte Skills, Regeln, Hooks und MCP-Server in .agents/plugins/<plugin-name>/.
   • Füge ein plugin.json-Manifest hinzu ({"name": "my-plugin"}).
   • Verwalte den Aktivierungsstatus in config.json unter "plugins": { "<plugin-name>": { "enabled": true } }.
2. JSON-Konfigurationen (skills.json / plugins.json):
   • Registriere externe Verzeichnisse oder gemeinsame Team-Repositories.
   • Unterstütze entries (Pfade) und inherits (andere Konfigurationen) mit include_only- und exclude-Regex-Filtern.
   • Siehe plugins-and-configs.md für vollständige Manifestbeispiele.

---

6. Legacy-Workflows modernisieren

1. Überprüfe auf veraltete .agents/workflows/*.md oder ~/.gemini/config/workflows/*.md.
2. Extrahiere betriebliche Anweisungen und erstelle ein entsprechendes SKILL.md mit korrektem YAML-Frontmatter.
3. Archiviere die Originaldatei als <name>.md.bak (sichere Aufbewahrung).
4. Siehe workflows-migration.md für das automatisierte Migrations-Runbook.

---

Validierungs- und Überprüfungs-Checkliste

Bevor eine Anpassung als abgeschlossen betrachtet wird:

• JSON-Syntax: Stelle sicher, dass alle .json-Dateien sauber ohne Syntaxfehler oder Kommentare geparst werden können.
• Frontmatter-Prüfung: Stelle sicher, dass SKILL.md gültiges YAML-Frontmatter mit name und einer beschreibenden description enthält.
• Zeichenbudget: Stelle sicher, dass die Regel-Markdown-Dateien innerhalb des Limits von 12.000 Zeichen liegen.
• MCP-Verbindung: Stelle sicher, dass Befehlsbinärdateien oder Remote-URLs existieren und authentifiziert werden können.
• Hook-Vertrag: Stelle sicher, dass Hook-Skripte camelCase-JSON auf stdin akzeptieren und gültiges JSON auf stdout zurückgeben.
• Obsidian-Spiegelung: Synchronisiere für Skills in diesem Arbeitsbereich den erstellten Skill-Ordner nach d:/Scripts/Obsidian/skills/<name>/.