agent-skills - Sammlung produktionsreifer Engineering-Skills für AI-Coding-Agenten

• Open Source, mit dem Google-Cloud-AI-Direktor Addy Osmani Workflows auf Senior-Engineer-Niveau als strukturierte Skills paketiert hat, um das Problem zu lösen, dass AI-Coding-Agenten Spezifikation, Tests und Security-Reviews überspringen
• Besteht aus 7 Slash-Commands und 19 Skills, die den gesamten Entwicklungslebenszyklus abdecken (Definition → Planung → Build → Verifikation → Review → Deployment)
  • /spec definiert, was gebaut werden soll: "Spezifikation vor Code"
  • /plan plant die Umsetzung: "in kleine atomare Tasks"
  • /build für schrittweise Implementierung: "jeweils nur ein Slice auf einmal"
  • /test beweist das Verhalten: "Tests sind Belege"
  • /review als Qualitäts-Gate vor dem Merge: "Code Health verbessern"
  • /code-simplify vereinfacht Code: "Klarheit vor Cleverness"
  • /ship für das Production-Deployment: "Je schneller, desto sicherer"
• Je nach Situation wird der passende Skill automatisch aktiviert. Beispiel: bei API-Design api-and-interface-design, bei UI-Implementierung frontend-ui-engineering usw.
• Zentrale Prinzipien der Google-Engineering-Kultur (Hyrum's Law, Beyonce Rule, Chesterton's Fence, Shift Left usw.) sind direkt in die Workflows der einzelnen Phasen eingebaut

Vollständige Liste der 19 Skills

• Define (klären, was gebaut werden soll)

  • idea-refine: strukturiert divergentes/konvergentes Denken, um vage Ideen in konkrete Vorschläge zu überführen
  • spec-driven-development: erstellt vor dem Schreiben von Code ein PRD, das Ziele, Befehle, Struktur, Code-Stil, Tests und Grenzen umfasst

• Plan (zerlegen)

  • planning-and-task-breakdown: zerlegt die Spezifikation in kleine, überprüfbare Tasks mit Akzeptanzkriterien und Abhängigkeitsreihenfolge

• Build (Code schreiben)

  • incremental-implementation: implementiert, testet, validiert und committet im Stil dünner vertikaler Slices; unterstützt Feature Flags und rollback-freundliche Änderungen
  • test-driven-development: setzt Red-Green-Refactor, die Testpyramide (80/15/5), DAMP statt DRY und die Beyonce Rule ein
  • context-engineering: stellt dem Agenten die richtigen Informationen zum richtigen Zeitpunkt bereit (Rules-Dateien, Context Packing, MCP-Integration)
  • frontend-ui-engineering: Komponentenarchitektur, Design-System, State-Management, Responsive Design, WCAG-2.1-AA-Barrierefreiheit
  • api-and-interface-design: Contract-First-Design, Hyrum's Law, One-Version Rule, Fehlersemantik, Boundary-Validierung

• Verify (Verhalten beweisen)

  • browser-testing-with-devtools: Echtzeit-Runtime-Daten über Chrome DevTools MCP (DOM-Inspektion, Konsolenlogs, Netzwerk-Traces, Performance-Profiling)
  • debugging-and-error-recovery: 5-stufige Triage (reproduzieren → lokalisieren → reduzieren → beheben → absichern), Stop-the-Line-Regel

• Review (Qualitäts-Gate vor dem Merge)

  • code-review-and-quality: Review über 5 Achsen, Änderungsgröße (~100 Zeilen), Schweregrad-Labels (Nit/Optional/FYI), Maßstäbe für Review-Geschwindigkeit
  • code-simplification: Chesterton's Fence, Rule of 500, reduziert Komplexität bei unverändert korrektem Verhalten
  • security-and-hardening: Prävention der OWASP Top 10, Authentifizierungsmuster, Secret-Management, Dependency-Audits, dreistufiges Boundary-System
  • performance-optimization: messungsorientierter Ansatz, Ziele für Core Web Vitals, Profiling-Workflow, Bundle-Analyse

• Ship (ausrollen)

  • git-workflow-and-versioning: Trunk-Based Development, atomare Commits, Änderungsgröße (~100 Zeilen), Commit-as-Savepoint-Muster
  • ci-cd-and-automation: Shift Left, Faster is Safer, Feature Flags, Pipeline mit Qualitäts-Gates
  • deprecation-and-migration: Mindset „Code as Debt“, zwingende/empfohlene Deprecation-Methoden, Entfernen von Zombie-Code
  • documentation-and-adrs: Architecture Decision Records, API-Dokumentation, Standards für Inline-Dokumentation (das „Warum“ dokumentieren)
  • shipping-and-launch: Pre-Launch-Checkliste, Lebenszyklus von Feature Flags, schrittweiser Rollout, Rollback-Verfahren, Monitoring-Setup

Agenten-Personas

• Für gezielte Reviews sind 3 Experten-Personas vorkonfiguriert
  • code-reviewer: Perspektive eines Senior Staff Engineers, 5-achsiges Code-Review mit dem Maßstab „Würde ein Staff Engineer das freigeben?“
  • test-engineer: Perspektive eines QA-Experten, Teststrategie, Coverage-Analyse, Prove-It-Pattern
  • security-auditor: Perspektive eines Security Engineers, Schwachstellenerkennung, Threat Modeling, OWASP-Bewertung

Referenz-Checklisten

• Vier Schnellreferenzen, auf die Skills bei Bedarf zugreifen
  • testing-patterns.md: Teststruktur, Benennung, Mocking, React/API/E2E-Beispiele, Anti-Patterns
  • security-checklist.md: Checks vor dem Commit, Authentifizierung, Eingabevalidierung, Header, CORS, OWASP Top 10
  • performance-checklist.md: Ziele für Core Web Vitals, Frontend-/Backend-Checklisten, Messbefehle
  • accessibility-checklist.md: Tastaturnavigation, Screenreader, visuelles Design, ARIA, Test-Tools

Prinzipien des Skill-Designs

• Prozess, nicht Prosa: Skills sind Workflows, denen der Agent folgt; sie enthalten Schritte, Checkpoints und Abschlusskriterien und sind keine Referenzdokumente
• Schutz vor Rationalisierung: In alle Skills sind typische Ausreden eingebaut, mit denen Agenten Schritte überspringen wollen ("Ich füge Tests später hinzu"), plus Gegenargumente
• Verifikation ist nicht verhandelbar: Alle Skills enden mit Evidenzanforderungen (bestandene Tests, Build-Output, Runtime-Daten); „scheint zu funktionieren“ reicht nicht
• Schrittweise Offenlegung: SKILL.md ist der Einstiegspunkt, unterstützende Referenzen werden nur bei Bedarf geladen, um den Token-Verbrauch zu minimieren

Installation (unterstützte Tools)

• Claude Code (empfohlen): nach /plugin marketplace add addyosmani/agent-skills dann /plugin install agent-skills@addy-agent-skills
  • Lokale Entwicklung: nach git clone dann claude --plugin-dir /path/to/agent-skills
• Cursor: beliebige SKILL.md nach .cursor/rules/ kopieren oder das gesamte Verzeichnis skills/ referenzieren
• Gemini CLI: gemini skills install https://github.com/addyosmani/agent-skills.git
• Windsurf: Skill-Inhalte in die Windsurf-Rules-Konfiguration einfügen
• GitHub Copilot: Agentendefinitionen aus agents/ als Copilot-Personas verwenden, Skill-Inhalte in .github/copilot-instructions.md nutzen
• Codex und andere Agenten: Da die Skills einfaches Markdown sind, sind sie mit allen Agenten kompatibel, die System-Prompts oder Instruction-Dateien unterstützen

[xguru]

Es wirkt so, als wäre es in letzter Zeit fast ein Trend geworden, die eigenen Skill-Sets zu veröffentlichen.

Da es letztlich nur Markdown-Dateien sind, muss man sowieso nicht alles unverändert übernehmen.
Je mehr es werden, desto höher ist nur der Token-Verbrauch.
Es ist besser, dem eigenen Agenten zu sagen: "Analysier das und nimm nur das mit, was nötig ist."

So baut man sich nach und nach sein eigenes Harness auf.

[thestackai]

Stimmt. Ich denke, das ist die beste Methode, um mit der Flut an Open Source umzugehen.

[yangeok]

Scheint wohl so etwas wie speckit zu sein.

[blacksocks]

Bei uns intern kam die Anweisung, die Entwicklung nur mit Vibe Coding auszuprobieren, also habe ich dies und das angewendet. Als ich es tatsächlich gemacht habe, habe ich gemerkt, dass herausragende Entwicklungs-Skills nicht automatisch hohe Qualität garantieren. Vielmehr scheint die Fähigkeit entscheidend zu sein, den von der KI erzeugten Code zu prüfen und zu verstehen. Je besser die Werkzeuge werden, desto wichtiger wird paradoxerweise die „Kraft des Lesens und Urteilens“.

[ragingwind]

Der Leiter des Google-Chrome-Teams, Addy Osmani, ist als Director zu Google Cloud AI gewechselt.

[xguru]

Huch, wann ist das denn umgezogen? Ich bin die ganze Zeit davon ausgegangen. Ich habe es korrigiert.

[ragingwind]

Ich kenne im Chrome-Team inzwischen auch nur noch Paul Kinlan (Chrome DevRel Lead). Wie die Zeit vergeht.