CommunityCodierung & Entwicklunggithub.com

MaDxCRaZY/antigravity-skills

Aktiviert den Kolosseum-Kampfmodus von Antigravity. Lässt zwei rivalisierende Unteragenten in isolierten verzweigten Arbeitsbereichen gegeneinander antreten, testet konkurrierende Implementierungen unter Stress mit einem gegnerischen Schiedsrichter und führt die siegreiche Lösung zusammen.

Was ist antigravity-skills?

Diese Fähigkeit implementiert ein Kolosseum-Kampfmodus-Protokoll, das die Entscheidungen eines einzelnen Agenten durch einen adversarialen Wettbewerb zwischen zwei konkurrierenden Implementierungen ersetzt. Sie ist nützlich für Entwickler und KI-Agenten, die robustere und besser getestete Lösungen anstreben, indem sie zwei rivalisierende Unteragenten parallel in isolierten Git-Worktrees arbeiten lässt. Der Workflow beginnt mit dem Befehl `/battle`, der zwei konkurrierende Arme erzeugt: Arm Alpha optimiert auf Sicherheit und Korrektheit, Arm Beta auf minimale Komplexität und Durchsatz. Nach Abschluss wird ein adversarialer Schiedsrichter (`critic@colosseum`) eingesetzt, der Fuzzing, Grenztests, Edge-Case-Angriffe und Benchmarks durchführt, um versteckte Fehler aufzudecken und konkrete Bestehen/Durchfallen-Metriken zu liefern. Die siegreiche Implementierung wird dann in den Hauptarbeitsbereich übernommen, während die unterlegene verworfen wird. Diese Fähigkeit eignet sich besonders für Plattformen wie Claude Code, Cursor oder Codex, die Multi-Agent-Workflows unterstützen, und ist ideal für kritische Code-Reviews, Architekturvergleiche und Optimierungsaufgaben.

Funktioniert mit~Claude Code~Codex CLI~Cursor✓Antigravity
npx skills add https://github.com/MaDxCRaZY/antigravity-skills/tree/HEAD/skills/battle

Installed? Explore more Codierung & Entwicklung skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation

Kolosseum-Kampfmodus-Protokoll

Der /battle-Befehl aktiviert eine adversarialen Arena zwischen zwei konkurrierenden Implementierungen, anstatt sich auf die Codeentscheidungen eines einzelnen Agenten zu verlassen.


Arena-Architektur

                       [Benutzereingabe]
                             │
            ┌────────────────┴────────────────┐
            ▼                                 ▼
   [Wettbewerber Arm Alpha]          [Wettbewerber Arm Beta]
   Arbeitsbereich: 'branch' (Arm A)  Arbeitsbereich: 'branch' (Arm B)
            │                                 │
            └────────────────┬────────────────┘
                             │
                             ▼
                 [Kolosseum-Schiedsrichter / Kritiker]
                 Rolle: critic@colosseum
                 (Adversarialer Falsifikator + Benchmark)
                             │
                             ▼
                     [Siegerkranz & Zusammenführung]

Ausführungsroutine

Wenn der Benutzer /battle aufruft:

Schritt 1: Forken der konkurrierenden Arme

Zwei rivalisierende Unteragenten werden gleichzeitig in isolierten Git-Worktrees mit Workspace='branch' erzeugt:

  1. Wettbewerber Arm Alpha:
    {
      "TypeName": "self",
      "Role": "Competitor Arm Alpha",
      "Workspace": "branch",
      "Prompt": "Design and implement Approach A for the user's objective. Optimize for safety, correctness, and clean abstraction."
    }
    
  2. Wettbewerber Arm Beta:
    {
      "TypeName": "self",
      "Role": "Competitor Arm Beta",
      "Workspace": "branch",
      "Prompt": "Design and implement an alternative Approach B for the user's objective. Optimize for minimal complexity, throughput, and directness."
    }
    

Schritt 2: Prüfung durch den Kolosseum-Schiedsrichter (critic@colosseum)

Sobald beide Arme ihre Implementierungen abgeschlossen haben:

  1. Ein adversarialer Schiedsrichteragent wird entsandt:
    {
      "TypeName": "self",
      "Role": "critic@colosseum",
      "Workspace": "inherit",
      "Prompt": "Compare Arm Alpha and Arm Beta. Run fuzzing, boundary tests, edge-case attacks, and empirical benchmarks against both branches. Identify hidden flaws, memory overhead, and unhandled failure modes."
    }
    
  2. Der Schiedsrichter führt beide Testpakete headless aus und zeichnet konkrete Bestehen/Durchfallen-Metriken auf.

Schritt 3: Krönung des Siegers

  1. Das Urteil des Schiedsrichters wird überprüft.
  2. Der siegreiche Branch wird per Fast-Forward oder Merge in den Hauptarbeitsbereich übernommen.
  3. Der unterlegene Branch wird verworfen und die vollständige vergleichende Ergebnisaufschlüsselung dem Benutzer präsentiert.

Individual skills in this repo

This repo contains 3 individual skills — each has its own dedicated page.

Verwandte Skills