Communitygithub.com

golang-testing

Go-Testmuster inklusive tabellengesteuerter Tests, Subtests, Benchmarks, Fuzzing und Testabdeckung. Folgt der TDD-Methodik mit idiomatischen Go-Praktiken. Verwenden Sie dies beim Schreiben von Go-Tests – tabellengesteuerte Fälle, Subtests, Benchmarks, Fuzzing oder Coverage.

Was ist golang-testing?

Dieses Skill bietet eine umfassende Sammlung von Go-Testmustern, die Entwicklern helfen, zuverlässige und wartbare Tests nach der Test-Driven-Development (TDD)-Methodik zu schreiben. Es enthält detaillierte Anleitungen und Codebeispiele für tabellengesteuerte Tests, Subtests, Benchmarks, Fuzzing und Testabdeckung, die den idiomatischen Go-Praktiken folgen. Das Skill unterstützt die gängigsten Go-Testworkflows, einschließlich des RED-GREEN-REFACTOR-Zyklus und der Verwendung von Golden Files, Mocking mit Schnittstellen und HTTP-Handler-Tests. Es ist ideal für Entwickler, die mit Go, Agenten wie Claude Code, Cursor oder Codex arbeiten und ihre Testqualität und -effizienz verbessern möchten.

Funktioniert mit~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/affaan-m/ECC/tree/main/skills/golang-testing

In Ihrer bevorzugten KI fragen

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

Dokumentation

Go-Testmuster

Umfassende Go-Testmuster zum Schreiben zuverlässiger, wartbarer Tests, die der TDD-Methodik folgen.

Wann zu aktivieren

  • Beim Schreiben neuer Go-Funktionen oder -Methoden
  • Beim Hinzufügen von Testabdeckung zu vorhandenem Code
  • Beim Erstellen von Benchmarks für leistungskritischen Code
  • Beim Implementieren von Fuzz-Tests zur Eingabevalidierung
  • Beim Befolgen des TDD-Workflows in Go-Projekten

TDD-Workflow für Go

Der RED-GREEN-REFACTOR-Zyklus

RED     → Schreibe zuerst einen fehlschlagenden Test
GREEN   → Schreibe minimalen Code, um den Test zu bestehen
REFACTOR → Verbessere den Code, während die Tests grün bleiben
REPEAT  → Fahre mit der nächsten Anforderung fort

Schritt-für-Schritt-TDD in Go

// Schritt 1: Definiere das Interface/die Signatur
// calculator.go
package calculator

func Add(a, b int) int {
    panic("nicht implementiert") // Platzhalter
}

// Schritt 2: Schreibe fehlschlagenden Test (RED)
// calculator_test.go
package calculator

import "testing"

func TestAdd(t *testing.T) {
    got := Add(2, 3)
    want := 5
    if got != want {
        t.Errorf("Add(2, 3) = %d; want %d", got, want)
    }
}

// Schritt 3: Führe Test aus – überprüfe FEHLSCHLAG
// $ go test
// --- FAIL: TestAdd (0.00s)
// panic: nicht implementiert

// Schritt 4: Implementiere minimalen Code (GREEN)
func Add(a, b int) int {
    return a + b
}

// Schritt 5: Führe Test aus – überprüfe BESTANDEN
// $ go test
// PASS

// Schritt 6: Refaktoriere bei Bedarf, überprüfe, ob Tests noch bestehen

Tabellengesteuerte Tests

Das Standardmuster für Go-Tests. Ermöglicht umfassende Abdeckung mit minimalem Code.

func TestAdd(t *testing.T) {
    tests := []struct {
        name     string
        a, b     int
        expected int
    }{
        {"positive Zahlen", 2, 3, 5},
        {"negative Zahlen", -1, -2, -3},
        {"Nullwerte", 0, 0, 0},
        {"gemischte Vorzeichen", -1, 1, 0},
        {"große Zahlen", 1000000, 2000000, 3000000},
    }

    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            got := Add(tt.a, tt.b)
            if got != tt.expected {
                t.Errorf("Add(%d, %d) = %d; want %d",
                    tt.a, tt.b, got, tt.expected)
            }
        })
    }
}

Tabellengesteuerte Tests mit Fehlerfällen

func TestParseConfig(t *testing.T) {
    tests := []struct {
        name    string
        input   string
        want    *Config
        wantErr bool
    }{
        {
            name:  "gültige Konfiguration",
            input: `{"host": "localhost", "port": 8080}`,
            want:  &Config{Host: "localhost", Port: 8080},
        },
        {
            name:    "ungültiges JSON",
            input:   `{ungültig}`,
            wantErr: true,
        },
        {
            name:    "leere Eingabe",
            input:   "",
            wantErr: true,
        },
        {
            name:  "minimale Konfiguration",
            input: `{}`,
            want:  &Config{}, // Standardwerte-Konfiguration
        },
    }

    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            got, err := ParseConfig(tt.input)

            if tt.wantErr {
                if err == nil {
                    t.Error("Fehler erwartet, nil erhalten")
                }
                return
            }

            if err != nil {
                t.Fatalf("unerwarteter Fehler: %v", err)
            }

            if !reflect.DeepEqual(got, tt.want) {
                t.Errorf("got %+v; want %+v", got, tt.want)
            }
        })
    }
}

Subtests und Sub-Benchmarks

Organisation verwandter Tests

func TestUser(t *testing.T) {
    // Setup, der von allen Subtests gemeinsam genutzt wird
    db := setupTestDB(t)

    t.Run("Create", func(t *testing.T) {
        user := &User{Name: "Alice"}
        err := db.CreateUser(user)
        if err != nil {
            t.Fatalf("CreateUser fehlgeschlagen: %v", err)
        }
        if user.ID == "" {
            t.Error("Benutzer-ID sollte gesetzt sein")
        }
    })

    t.Run("Get", func(t *testing.T) {
        user, err := db.GetUser("alice-id")
        if err != nil {
            t.Fatalf("GetUser fehlgeschlagen: %v", err)
        }
        if user.Name != "Alice" {
            t.Errorf("Name %q erhalten; %q erwartet", user.Name, "Alice")
        }
    })

    t.Run("Update", func(t *testing.T) {
        // ...
    })

    t.Run("Delete", func(t *testing.T) {
        // ...
    })
}

Parallele Subtests

func TestParallel(t *testing.T) {
    tests := []struct {
        name  string
        input string
    }{
        {"fall1", "eingabe1"},
        {"fall2", "eingabe2"},
        {"fall3", "eingabe3"},
    }

    for _, tt := range tests {
        tt := tt // Bereichsvariable erfassen
        t.Run(tt.name, func(t *testing.T) {
            t.Parallel() // Subtests parallel ausführen
            result := Process(tt.input)
            // Behauptungen...
            _ = result
        })
    }
}

Test-Helfer

Hilfsfunktionen

func setupTestDB(t *testing.T) *sql.DB {
    t.Helper() // Markiert dies als Hilfsfunktion

    db, err := sql.Open("sqlite3", ":memory:")
    if err != nil {
        t.Fatalf("Fehler beim Öffnen der Datenbank: %v", err)
    }

    // Bereinigung, wenn der Test abgeschlossen ist
    t.Cleanup(func() {
        db.Close()
    })

    // Migrationen ausführen
    if _, err := db.Exec(schema); err != nil {
        t.Fatalf("Fehler beim Erstellen des Schemas: %v", err)
    }

    return db
}

func assertNoError(t *testing.T, err error) {
    t.Helper()
    if err != nil {
        t.Fatalf("unerwarteter Fehler: %v", err)
    }
}

func assertEqual[T comparable](t *testing.T, got, want T) {
    t.Helper()
    if got != want {
        t.Errorf("got %v; want %v", got, want)
    }
}

Temporäre Dateien und Verzeichnisse

func TestFileProcessing(t *testing.T) {
    // Temporäres Verzeichnis erstellen – automatisch bereinigt
    tmpDir := t.TempDir()

    // Testdatei erstellen
    testFile := filepath.Join(tmpDir, "test.txt")
    err := os.WriteFile(testFile, []byte("Testinhalt"), 0644)
    if err != nil {
        t.Fatalf("Fehler beim Erstellen der Testdatei: %v", err)
    }

    // Test ausführen
    result, err := ProcessFile(testFile)
    if err != nil {
        t.Fatalf("ProcessFile fehlgeschlagen: %v", err)
    }

    // Behauptung...
    _ = result
}

Golden Files

Testen gegen erwartete Ausgabedateien, die in testdata/ gespeichert sind.

var update = flag.Bool("update", false, "Golden-Dateien aktualisieren")

func TestRender(t *testing.T) {
    tests := []struct {
        name  string
        input Template
    }{
        {"einfach", Template{Name: "test"}},
        {"komplex", Template{Name: "test", Items: []string{"a", "b"}}},
    }

    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            got := Render(tt.input)

            golden := filepath.Join("testdata", tt.name+".golden")

            if *update {
                // Golden-Datei aktualisieren: go test -update
                err := os.WriteFile(golden, got, 0644)
                if err != nil {
                    t.Fatalf("Fehler beim Aktualisieren der Golden-Datei: %v", err)
                }
            }

            want, err := os.ReadFile(golden)
            if err != nil {
                t.Fatalf("Fehler beim Lesen der Golden-Datei: %v", err)
            }

            if !bytes.Equal(got, want) {
                t.Errorf("Ausgabe stimmt nicht überein:\ngot:\n%s\nwant:\n%s", got, want)
            }
        })
    }
}

Mocking mit Schnittstellen

Schnittstellenbasiertes Mocking

// Schnittstelle für Abhängigkeiten definieren
type UserRepository interface {
    GetUser(id string) (*User, error)
    SaveUser(user *User) error
}

// Produktionsimplementierung
type PostgresUserRepository struct {
    db *sql.DB
}

func (r *PostgresUserRepository) GetUser(id string) (*User, error) {
    // Echte Datenbankabfrage
}

// Mock-Implementierung für Tests
type MockUserRepository struct {
    GetUserFunc  func(id string) (*User, error)
    SaveUserFunc func(user *User) error
}

func (m *MockUserRepository) GetUser(id string) (*User, error) {
    return m.GetUserFunc(id)
}

func (m *MockUserRepository) SaveUser(user *User) error {
    return m.SaveUserFunc(user)
}

// Test mit Mock
func TestUserService(t *testing.T) {
    mock := &MockUserRepository{
        GetUserFunc: func(id string) (*User, error) {
            if id == "123" {
                return &User{ID: "123", Name: "Alice"}, nil
            }
            return nil, ErrNotFound
        },
    }

    service := NewUserService(mock)

    user, err := service.GetUserProfile("123")
    if err != nil {
        t.Fatalf("unerwarteter Fehler: %v", err)
    }
    if user.Name != "Alice" {
        t.Errorf("Name %q erhalten; %q erwartet", user.Name, "Alice")
    }
}

Benchmarks

Basis-Benchmarks

func BenchmarkProcess(b *testing.B) {
    data := generateTestData(1000)
    b.ResetTimer() // Setup-Zeit nicht zählen

    for i := 0; i < b.N; i++ {
        Process(data)
    }
}

// Ausführen: go test -bench=BenchmarkProcess -benchmem
// Ausgabe: BenchmarkProcess-8   10000   105234 ns/op   4096 B/op   10 allocs/op

Benchmark mit verschiedenen Größen

func BenchmarkSort(b *testing.B) {
    sizes := []int{100, 1000, 10000, 100000}

    for _, size := range sizes {
        b.Run(fmt.Sprintf("size=%d", size), func(b *testing.B) {
            data := generateRandomSlice(size)
            b.ResetTimer()

            for i := 0; i < b.N; i++ {
                // Eine Kopie erstellen, um das Sortieren bereits sortierter Daten zu vermeiden
                tmp := make([]int, len(data))
                copy(tmp, data)
                sort.Ints(tmp)
            }
        })
    }
}

Benchmarks zur Speicherzuweisung

func BenchmarkStringConcat(b *testing.B) {
    parts := []string{"hallo", "welt", "foo", "bar", "baz"}

    b.Run("plus", func(b *testing.B) {
        for i := 0; i < b.N; i++ {
            var s string
            for _, p := range parts {
                s += p
            }
            _ = s
        }
    })

    b.Run("builder", func(b *testing.B) {
        for i := 0; i < b.N; i++ {
            var sb strings.Builder
            for _, p := range parts {
                sb.WriteString(p)
            }
            _ = sb.String()
        }
    })

    b.Run("join", func(b *testing.B) {
        for i := 0; i < b.N; i++ {
            _ = strings.Join(parts, "")
        }
    })
}

Fuzzing (Go 1.18+)

Basisfuzztest

func FuzzParseJSON(f *testing.F) {
    // Seed-Korpus hinzufügen
    f.Add(`{"name": "test"}`)
    f.Add(`{"count": 123}`)
    f.Add(`[]`)
    f.Add(`""`)

    f.Fuzz(func(t *testing.T, input string) {
        var result map[string]interface{}
        err := json.Unmarshal([]byte(input), &result)

        if err != nil {
            // Ungültiges JSON ist für zufällige Eingaben zu erwarten
            return
        }

        // Wenn das Parsen erfolgreich war, sollte die Neucodierung funktionieren
        _, err = json.Marshal(result)
        if err != nil {
            t.Errorf("Marshal nach erfolgreichem Unmarshal fehlgeschlagen: %v", err)
        }
    })
}

// Ausführen: go test -fuzz=FuzzParseJSON -fuzztime=30s

Fuzztest mit mehreren Eingaben

func FuzzCompare(f *testing.F) {
    f.Add("hallo", "welt")
    f.Add("", "")
    f.Add("abc", "abc")

    f.Fuzz(func(t *testing.T, a, b string) {
        result := Compare(a, b)

        // Eigenschaft: Compare(a, a) sollte immer 0 ergeben
        if a == b && result != 0 {
            t.Errorf("Compare(%q, %q) = %d; want 0", a, b, result)
        }

        // Eigenschaft: Compare(a, b) und Compare(b, a) sollten entgegengesetzte Vorzeichen haben
        reverse := Compare(b, a)
        if (result > 0 && reverse >= 0) || (result < 0 && reverse <= 0) {
            if result != 0 || reverse != 0 {
                t.Errorf("Compare(%q, %q) = %d, Compare(%q, %q) = %d; inkonsistent",
                    a, b, result, b, a, reverse)
            }
        }
    })
}

Testabdeckung

Abdeckung ausführen

# Basisabdeckung
go test -cover ./...

# Abdeckungsprofil generieren
go test -coverprofile=coverage.out ./...

# Abdeckung im Browser anzeigen
go tool cover -html=coverage.out

# Abdeckung nach Funktion anzeigen
go tool cover -func=coverage.out

# Abdeckung mit Race-Erkennung
go test -race -coverprofile=coverage.out ./...

Abdeckungsziele

Code-TypZiel
Kritische Geschäftslogik100%
Öffentliche APIs90%+
Allgemeiner Code80%+
Generierter CodeAusschließen

Generierten Code von der Abdeckung ausschließen

//go:generate mockgen -source=interface.go -destination=mock_interface.go

// Im Abdeckungsprofil mit Build-Tags ausschließen:
// go test -cover -tags=!generate ./...

HTTP-Handler-Tests

func TestHealthHandler(t *testing.T) {
    // Request erstellen
    req := httptest.NewRequest(http.MethodGet, "/health", nil)
    w := httptest.NewRecorder()

    // Handler aufrufen
    HealthHandler(w, req)

    // Antwort überprüfen
    resp := w.Result()
    defer resp.Body.Close()

    if resp.StatusCode != http.StatusOK {
        t.Errorf("Status %d erhalten; %d erwartet", resp.StatusCode, http.StatusOK)
    }

    body, _ := io.ReadAll(resp.Body)
    if string(body) != "OK" {
        t.Errorf("Body %q erhalten; %q erwartet", body, "OK")
    }
}

func TestAPIHandler(t *testing.T) {
    tests := []struct {
        name       string
        method     string
        path       string
        body       string
        wantStatus int
        wantBody   string
    }{
        {
            name:       "Benutzer abrufen",
            method:     http.MethodGet,
            path:       "/users/123",
            wantStatus: http.StatusOK,
            wantBody:   `{"id":"123","name":"Alice"}`,
        },
        {
            name:       "nicht gefunden",
            method:     http.MethodGet,
            path:       "/users/999",
            wantStatus: http.StatusNotFound,
        },
        {
            name:       "Benutzer erstellen",
            method:     http.MethodPost,
            path:       "/users",
            body:       `{"name":"Bob"}`,
            wantStatus: http.StatusCreated,
        },
    }

    handler := NewAPIHandler()

    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            var bodyReader io.Reader
            if tt.body != "" {
                bodyReader = strings.NewReader(tt.body)
            }

            req := httptest.NewRequest(tt.method, tt.path, bodyReader)
            w := httptest.NewRecorder()
            handler.ServeHTTP(w, req)

            resp := w.Result()
            defer resp.Body.Close()

            if resp.StatusCode != tt.wantStatus {
                t.Errorf("Status %d erhalten; %d erwartet", resp.StatusCode, tt.wantStatus)
            }

            if tt.wantBody != "" {
                body, _ := io.ReadAll(resp.Body)
                if string(body) != tt.wantBody {
                    t.Errorf("Body %q erhalten; %q erwartet", body, tt.wantBody)
                }
            }
        })
    }
}

Testen von Goroutinen und Kanälen

func TestConcurrentProcess(t *testing.T) {
    // Timeout für hängende Tests
    ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
    defer cancel()

    results := make(chan Result, 10)

    // Goroutine starten
    go ConcurrentProcess(ctx, results)

    // Ergebnisse sammeln
    var collected []Result
    for r := range results {
        collected = append(collected, r)
    }

    if len(collected) == 0 {
        t.Error("erwartete Ergebnisse, aber keine erhalten")
    }
}

func TestChannelCommunication(t *testing.T) {
    msgs := make(chan string, 1)

    go func() {
        msgs <- "hallo"
    }()

    select {
    case msg := <-msgs:
        if msg != "hallo" {
            t.Errorf("Nachricht %q erhalten; %q erwartet", msg, "hallo")
        }
    case <-time.After(time.Second):
        t.Error("Timeout beim Warten auf Nachricht")
    }
}

Integrationstests

// +build integration

package integration

func TestDatabaseIntegration(t *testing.T) {
    if testing.Short() {
        t.Skip("Integrationstest in Kurztests übersprungen")
    }

    db, err := sql.Open("postgres", getTestDSN())
    if err != nil {
        t.Fatalf("Fehler beim Verbinden zur Datenbank: %v", err)
    }
    defer db.Close()

    // Migrationen durchführen
    err = runMigrations(db)
    if err != nil {
        t.Fatalf("Migrationen fehlgeschlagen: %v", err)
    }

    // Testlogik...
    _ = db
}

// Ausführen: go test -tags=integration ./...

Best Practices

  1. Testen Sie das Verhalten, nicht die Implementierung: Konzentrieren Sie sich auf das, was der Code tut, nicht darauf, wie er es tut.
  2. Ein Behauptung pro Test: Halten Sie Tests fokussiert. Verwenden Sie Subtests für verwandte Behauptungen.
  3. Vermeiden Sie Race Conditions: Verwenden Sie t.Parallel() angemessen. Erfassen Sie Bereichsvariablen.
  4. Verwenden Sie t.Helper(): Markieren Sie Hilfsfunktionen für klarere Fehlermeldungen.
  5. t.Cleanup() für Ressourcenbereinigung: Bevorzugen Sie dies gegenüber defer in Tests.
  6. Aussagekräftige Testnamen: Namen sollten das getestete Verhalten beschreiben.
  7. Testen Sie Fehlerfälle: Testen Sie sowohl Erfolgs- als auch Fehlerpfade.
  8. Halten Sie Tests unabhängig: Tests sollten isoliert ausgeführt werden können.
  9. Testen Sie die öffentliche API: Konzentrieren Sie sich auf Tests exportierter Funktionen und Typen.
  10. Verwenden Sie Build-Tags: Trennen Sie Einheits- von Integrationstests.

Fehlerbehebung bei häufigen Testproblemen

Testet nicht parallel

// Subtests laufen standardmäßig nacheinander
func TestSequential(t *testing.T) {
    t.Run("first", func(t *testing.T) {
        // Läuft zuerst
    })
    t.Run("second", func(t *testing.T) {
        // Läuft als zweites
    })
}

// Verwenden Sie t.Parallel(), um gleichzeitiges Ausführen zu ermöglichen
func TestParallelSubtests(t *testing.T) {
    t.Run("first", func(t *testing.T) {
        t.Parallel()
        // Läuft gleichzeitig mit anderen parallelen Subtests
    })
    t.Run("second", func(t *testing.T) {
        t.Parallel()
        // Läuft gleichzeitig mit anderen parallelen Subtests
    })
}

Race-Bedingungen in Tests

// Problem: Race-Bedingung mit gemeinsam genutztem Zustand
func TestRaceCondition(t *testing.T) {
    counter := 0
    for i := 0; i < 100; i++ {
        go func() {
            counter++ // Race-Bedingung!
        }()
    }
}

// Lösung: Synchronisation verwenden oder parallele Ausführung vermeiden
func TestFixedRace(t *testing.T) {
    var mu sync.Mutex
    counter := 0
    for i := 0; i < 100; i++ {
        i := i
        go func() {
            mu.Lock()
            defer mu.Unlock()
            counter++
            _ = i
        }()
    }
    // Warten, bis alle Goroutinen abgeschlossen sind
    time.Sleep(100 * time.Millisecond)
}

Nützliche Testflags

# Alle Flags beim Ausführen verfügbar:
go test -h

# Timing des Tests anzeigen
go test -v ./...

# Nur bestimmte Tests ausführen
go test -run TestName/SubtestName ./...

# Parallelität steuern
go test -parallel 4 ./...

# Mit Abdeckung und Race-Erkennung
go test -race -cover -count=1 ./...

# Kurze Tests ausführen (Integrationstests überspringen)
go test -short ./...

# Cache überspringen
go test -count=1 ./...

Individual skills in this repo

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

accessibility

Design, implement, and audit inclusive digital products using WCAG 2.2 Level AA. Use when building or auditing UI that must meet WCAG 2.2 Level AA, or when reviewing a change for keyboard, contrast, or screen-reader support.

affaan-m/content-engine

Create platform-native content systems for X, LinkedIn, TikTok, YouTube, newsletters, and repurposed multi-platform campaigns. Use when the user wants social posts, threads, scripts, content calendars, or one source asset adapted cleanly across platforms.

affaan-m/ECC

Multi-platform content distribution across X, LinkedIn, Threads, and Bluesky. Adapts content per platform using content-engine patterns. Never posts identical content cross-platform. Use when the user wants to distribute content across social platforms.

affaan-m/fal-ai-media

Unified media generation via fal.ai MCP — image, video, and audio. Covers text-to-image (Nano Banana), text/image-to-video (Seedance, Kling, Veo 3), text-to-speech (CSM-1B), and video-to-audio (ThinkSound). Use when the user wants to generate images, videos, or audio with AI.

affaan-m/manim-video

日本語翻訳:このファイルは manim-video 用の日本語翻訳が必要です

affaan-m/remotion-video-creation

Remotion のベストプラクティス - React で動画を作成する。3D、アニメーション、音声、字幕、チャート、トランジションなどをカバーするドメイン固有の29のルール。

affaan-m/video-editing

AI-assisted video editing workflows for cutting, structuring, and augmenting real footage. Covers the full pipeline from raw capture through FFmpeg, Remotion, ElevenLabs, fal.ai, and final polish in Descript or CapCut. Use when the user wants to edit video, cut footage, create vlogs, or build video content.

agent-architecture-audit

Full-stack diagnostic for agent and LLM applications. Audits the 12-layer agent stack for wrapper regression, memory pollution, tool discipline failures, hidden repair loops, and rendering corruption. Produces severity-ranked findings with code-first fixes. Essential for developers building agent applications, autonomous loops, or any LLM-powered feature. Use when an agent or LLM feature misbehaves and the failing layer is unknown, or before shipping an agent stack.

agent-eval

Head-to-head comparison of coding agents (Claude Code, Aider, Codex, etc.) on custom tasks with pass rate, cost, time, and consistency metrics. Use when choosing between coding agents, or when a change to an agent setup needs measured pass rate, cost, and time rather than an impression.

agent-harness-construction

Design and optimize AI agent action spaces, tool definitions, and observation formatting for higher completion rates. Use when defining or revising an agent

agentic-engineering

Operate as an agentic engineer using eval-first execution, decomposition, and cost-aware model routing. Use when planning or executing engineering work that agents will carry out end to end.

agentic-os

Build persistent multi-agent operating systems on Claude Code. Covers kernel architecture, specialist agents, slash commands, file-based memory, scheduled automation, and state management without external databases. Use when building a persistent multi-agent system on Claude Code with its own memory, commands, and scheduling.

agent-introspection-debugging

Structured self-debugging workflow for AI agent failures using capture, diagnosis, contained recovery, and introspection reports. Use when an agent run fails and you need a reproducible diagnosis instead of a retry.

agent-payment-x402

Add x402 payment execution to AI agents with per-task budgets, spending controls, and non-custodial wallets. Supports Base through agentwallet-sdk and X Layer through OKX Payments / OKX Agent Payments Protocol. Use when an agent must pay for something itself and needs per-task budgets, spending controls, and a non-custodial wallet.

agent-self-evaluation

Use after completing any non-trivial task. The agent self-rates its output on 5 axes — accuracy, completeness, clarity, actionability, conciseness — with concrete evidence per criterion. Produces a structured 1-5 scorecard with specific improvement suggestions.

agent-sort

Build an evidence-backed ECC install plan for a specific repo by sorting skills, commands, rules, hooks, and extras into DAILY vs LIBRARY buckets using parallel repo-aware review passes. Use when ECC should be trimmed to what a project actually needs instead of loading the full bundle.

ai-first-engineering

Engineering operating model for teams where AI agents generate a large share of implementation output. Use when setting team process, review gates, or ownership rules for a codebase largely written by agents.

ai-regression-testing

Regression testing strategies for AI-assisted development. Sandbox-mode API testing without database dependencies, automated bug-check workflows, and patterns to catch AI blind spots where the same model writes and reviews code. Use when adding regression coverage to AI-assisted code, or when the same model both wrote and reviewed a change.

android-clean-architecture

Clean Architecture patterns for Android and Kotlin Multiplatform projects — module structure, dependency rules, UseCases, Repositories, and data layer patterns. Use when structuring modules, layers, or data flow in an Android or KMP project.

angular-developer

Generates Angular code and provides architectural guidance. Trigger when creating projects, components, or services, or for best practices on reactivity (signals, linkedSignal, resource), forms, dependency injection, routing, SSR, accessibility (ARIA), animations, styling (component styles, Tailwind CSS), testing, or CLI tooling.

Verwandte Skills