Alle Notizen
7. Juni 202611 Min. Lesedaueragent-skillsai-engineeringcopilotclaude-codeengineeringorchestration

Agent Skills sind das günstigste ALM, das Ihr Team je kauft

Agent Skills sind das günstigste ALM, das Ihr Team je kauft

Ein Agent Skill ist eine Markdown-Datei, die einem KI-Coding-Assistenten sagt, wie Ihr Team arbeitet: wann eine Spezifikation geschrieben wird, wann sie in Tasks zerfällt, wann Tests laufen, wann gestoppt und nachgefragt wird. Die Datei lebt neben Ihrem Code, der Assistent liest sie bei Bedarf, und die Regeln überleben jeden Modellwechsel. Meine These: Dieser Ordner Markdown ist heute das günstigste Application Lifecycle Management (ALM), das Ihr Team je kauft, und für eine 5-bis-50-Personen-Engineering-Organisation schließt er den größten Teil der Disziplinlücke, die früher Jira, Confluence, einen Release-Manager und einen Prozessberater erforderte.

Kernaussagen

  • Ein 20-Personen-Team mit sieben Slash-Commands liefert näher an einer 200-Engineer-Organisation als an einem Größen-Peer aus.
  • Skills sind die Disziplinschicht über Ihren Werkzeugen, kein Ersatz für Tool Use oder MCP.
  • Anthropic hat Agent Skills als offene Spezifikation veröffentlicht; addyosmani/agent-skills ist die MIT-Referenz; beides ist kostenlos.
  • Die ALM-Kosten pro Sitz fallen von 30 bis 80 USD pro Entwickler pro Monat auf null, ohne Governance-Lücke.
  • Der Tradeoff ist Supply-Chain-Vertrauen: Skills laufen mit Modell-Privilegien, also wandert das PR-Gate nach .claude/skills/.

In diesem Artikel

Die Disziplinlücke, die kleine Teams nicht besetzen können

Der Stack Overflow Developer Survey 2025 zeigt, dass die KI-Tool-Adoption dem KI-Tool-Vertrauen weit vorausläuft, und der Abstand vergrößert sich Jahr für Jahr. Das ist die Disziplinlücke. Das Modell schreibt den Code; niemand hat Zeit, die Prozedur darum herum zu schreiben. Bei Google oder Microsoft lebt die Prozedur im Kopf eines Staff Engineers, in einer Release-Checkliste, in einer TDD-Kultur, in einem SRE-Runbook, in einem Security-Review-Board. In einem 35-Personen-Unternehmen lebt die Prozedur nirgendwo. Der Senior Engineer wird zum Engpass, oder die KI liefert, was sich an einem Dienstagnachmittag richtig anfühlt.

Für die meisten meiner Mittelstands-Kunden lautete die Antwort früher: eine ALM-Plattform kaufen und hoffen, dass der Workflow sich überträgt. Dieser Handel hat nie ausgezahlt. Die Plattform wurde von derselben Person konfiguriert, die ohnehin keine Zeit für Disziplin hatte; die Teams pflegten Tickets, um das Dashboard glücklich zu machen, und die KI-Werkzeuge generierten weiterhin Code in einem Paralleluniversum, dem nie jemand beigebracht hatte, wie das Team arbeitet.

Was sich in den letzten sechs Monaten geändert hat: Die Disziplin selbst wurde portabel. Anthropic hat Agent Skills im Dezember 2025 als offenen Standard veröffentlicht, mit einem strikten Frontmatter-Vertrag und Progressive Disclosure: Der Agent sieht nur Name und Beschreibung, bis eine Aufgabe matched; dann lädt er den Body, dann lädt er gebündelte Dateien nur, wenn er sie ausführt (Equipping agents for the real world with Agent Skills). Addy Osmanis Walkthrough auf dem Microsoft Developer Channel auf der Microsoft Build 2026 (LIVE150) ist der sauberste öffentliche Beweispunkt, den ich gesehen habe: ein 48,6k-Sterne MIT-Repository, das die gesamte Define-Plan-Build-Verify-Review-Ship-Schleife als Set von Markdown-Dateien plus sieben Slash-Commands codiert (addyosmani/agent-skills). Beides ist kostenlos.

Montag: Klonen Sie das Repo in einen Wegwerf-Branch Ihres Hauptprojekts, zeigen Sie Copilot oder Claude Code darauf, und bitten Sie einen Junior-Engineer, ein einzelnes Feature mit /spec, /plan, /build, /verify, /review in dieser Reihenfolge auszuliefern. Beobachten Sie, wo das Modell pusht. Dieses Pushback ist die Disziplin, für die Sie bisher eine Plattform bezahlt haben.

Was ein Agent Skill tatsächlich ist

Ein Skill ist eine SKILL.md-Datei mit zwei Pflichtfeldern im YAML-Frontmatter, name (max. 64 Zeichen, kebab-case) und description (max. 1024 Zeichen), und einem Anweisungsteil. Der Body kann einen Workflow beschreiben, einen Entscheidungsbaum codieren, definieren, wie „fertig" aussieht, Red Flags listen oder auf ausführbare Skripte zeigen. Skills leben in .claude/skills/ pro Projekt oder ~/.claude/skills/ global und laden mitten in der Session neu.

In Addys Repo richten sich die Skills am Software-Lebenszyklus aus. Der /spec-Command triggert einen Skill, der den Entwickler mit klärenden Fragen interviewt, bevor eine Zeile geschrieben wird: Wer ist der Nutzer, welchen Speicher bekommt der Browser, wie sieht Erfolg für das MVP aus. Der /plan-Command nimmt die Spezifikation und zerlegt sie in Phasen mit Akzeptanzkriterien und einer gezielten Dateiliste, sodass der Agent weiß, welche Dateien er anfassen darf. Der /build-Command schreibt zuerst einen failing Test, dann die Minimal-Implementierung, dann refactort er. Der /verify-Command startet den Dev-Server und treibt einen Headless-Browser durch die echte UI. Der /review-Skill macht einen Correctness-, Security- und Simplification-Pass, der XSS-Lücken und überflüssige Abstraktion fängt. Der /ship-Skill kümmert sich um Git-Hygiene und Release Notes.

Eine minimale Skill-Datei sieht so aus:

---
name: test-driven-build
description: Use when implementing a feature in an existing codebase with tests present. Writes a failing test first, then the minimum code to pass, then refactors. Stops to ask if no test framework is detected.
---

# Test-driven build

**When to use**
- The repo has a test runner already configured.
- The change adds a function, endpoint, or component with observable behavior.

**When not to use**
- Throwaway prototypes with a one-hour lifespan.
- Pure config or documentation changes.

**Red flags**
- The agent is about to delete an existing test "to make the build green".
- The agent has not run the test runner at least once before claiming done.

**Verification**
- New test exists and was observed failing before implementation.
- Test runner exits 0 after the change.
- No other tests regressed.

Diese Datei ist das ganze Artefakt. Sie ist dicht, meinungsstark und über jedes Projekt hinweg wiederverwendbar, das sie importiert. Montagshandlung: Wählen Sie den einen Workflow in Ihrem Team, den der Senior Engineer immer wieder per Hand nacharbeitet (Release Notes, PR-Reviews, die Art, wie Sie Tests schreiben, die Art, wie Sie ein Ticket schneiden) und schreiben Sie das als eine SKILL.md vor Feierabend. Committen Sie sie nach .claude/skills/ in einem Repo. Nutzen Sie sie eine Woche. Dann fördern Sie.

Warum das billiger ist als eine ALM-Plattform

Rechnen wir nach. Azure DevOps Basic kostet 6 USD pro Nutzer pro Monat, und das Test-Plans-Add-on, der Teil, der die strukturierte Testdisziplin kauft, 52 USD pro Nutzer pro Monat (Azure DevOps Services pricing). Die veröffentlichten Per-Sitz-Tiers von Atlassian Jira und Confluence stapeln darauf (Standard, Premium, Enterprise sind unten in den Ressourcen aufgeschlüsselt). Ein 35-Personen-Team mit Jira Premium plus Confluence plus GitHub Team plus einem einzelnen Test-Plans-Sitz liegt nördlich von 1.000 USD pro Monat, bevor ein einziger Berater die Box anfasst. Der Berater ist die Kost zweiter Ordnung, und die Konfigurations-Drift über die nächsten zwei Jahre ist die dritte.

addyosmani/agent-skills steht unter MIT, ist kostenlos und läuft im Coding-Assistenten, den das Team ohnehin bezahlt. Die Anthropic-Spezifikation ist kostenlos. Die Token-Kost für das Ausführen eines Skills ist ein Bruchteil der Tool-Definitions-Steuer, auf die ich im nächsten Abschnitt zurückkomme. Der Ersatz ist nicht perfekt: Skills geben Ihnen keine Ticket-Datenbank, kein Sprint-Board und keinen Compliance-Report. Aber sie codieren den Teil der Plattform-Investition, der ohnehin fast nie gelandet ist, nämlich die Disziplin, die die Daten produziert, die diese Dashboards anzeigen.

Die ehrliche Einrahmung: Eine ALM-Plattform ist eine Workflow-Engine mit angetackerter Datenbank. Für ein Mittelstandsteam ist der Datenbank-Anteil Overkill (Ihre GitHub-Issues reichen, Ihr Messaging-Tool routet Arbeit schon), und die Workflow-Engine bekam nie das kulturelle Buy-in, das sie brauchte. Skills drehen den Handel um: kostenlose Workflow-Engine, die dort lebt, wo die Arbeit passiert, keine Datenbank, kein Dashboard, keine Buy-in-Steuer. Wir behalten das leichtgewichtige Ticketing, das wir haben. Montag: kündigen Sie die Test-Plans-Sitze und die Confluence-Verlängerung, die im nächsten Quartal ansteht, und leiten Sie das Budget in eine Engineer-Woche um, in der die ersten zwölf Skills geschrieben werden.

Skills vs. MCP: der Ronacher-Vorbehalt

Jetzt zum Tradeoff, der entscheidet, ob dieses Argument Kontakt mit einem echten Engineering-Team überlebt. Armin Ronacher, CTO von Sentry und eine der glaubwürdigsten Stimmen im Python-Ökosystem, schrieb in seiner Analyse zu Skills versus MCP-Loadouts den Satz, der diesen ganzen Beitrag verankert:

💡 „Skills laden tatsächlich keine Tool-Definition in den Kontext. Die Tools bleiben dieselben: bash und die anderen Tools, die der Agent ohnehin hat." (Skills vs Dynamic MCP Loadouts, Armin Ronacher)

Lesen Sie diesen Satz sorgfältig, weil ihn die meisten Launch-Posts überspringen. Ein Skill gibt dem Agent keine neue Fähigkeit. Der Agent handelt weiterhin über bash, Dateieditierung und die MCP-Server, die Sie verdrahtet haben. Der Skill ist die Schicht, die entscheidet, welches dieser bestehenden Tools wann und mit welchen Gates aufgerufen wird. Skills sind die Prozedur; MCP ist die Aktionsfläche. Beide sind komplementär, nicht substitutiv.

Das zählt für die Kostengeschichte. Der oft zitierte Token-Vergleich fällt nur dort zugunsten der Skills aus, wo das Team die MCP-Tool-Definitions-Steuer ohnehin bezahlt hat. Anthropics eigene Analyse beobachtete in manchen Konfigurationen Tool-Definitionen mit 134K Tokens vor Optimierung, und Anthropic hat fortgeschrittenes Tool Use mit Deferred Loading ausgeliefert, das „eine 85%-Reduktion der Token-Nutzung bei vollem Zugriff auf die Tool-Bibliothek meldet, mit internen Tests, die Accuracy-Verbesserungen von 49% auf 74% auf Claude Opus 4 und von 79,5% auf 88,1% auf Opus 4.5 zeigen" (Introducing advanced tool use on the Claude Developer Platform). Diese Zahlen sind real, beschreiben aber den Abstand zwischen einem tool-lastigen MCP-Setup und Progressive Loading. Wenn Ihr Team nie einen 90-Tool-MCP-Server verdrahtet hat, schneidet der Wechsel zu Skills Ihre Token-Rechnung nicht, weil keine Rechnung zu schneiden war.

Was Skills sehr wohl schneiden, ist die Disziplinlücke. Die Token-Mathematik ist ein Seiteneffekt; die prozedurale Codierung ist der Punkt. Montag: Wenn Sie schon MCP fahren (work IQ, context7, GitHub MCP), behalten Sie es. Skills als Schicht darüber ergänzen. Wenn Sie noch kein MCP fahren, fügen Sie es nicht hinzu, nur um Skills daraufzulegen: Starten Sie mit Skills direkt auf den Datei-Edit- und Bash-Primitiven, die der Assistent ohnehin hat.

Ein KMU-Beispiel: Montagmorgen in einer 35-Personen-Fintech in Hamburg

Hier das Szenario, das ich im letzten Quartal tatsächlich gepitcht habe. Der Engineering Lead einer 35-Personen-Fintech in Hamburg führt ein Team aus acht Engineers, das ein B2B-Payments-Produkt liefert. Der Stack: GitHub plus GitHub Copilot Business plus Claude Code auf den Laptops der Senior Engineers. Kein Jira, kein Confluence, keine Test Plans. Es gibt einen Slack-Channel, eine Notion-Seite für die On-Call-Rotation und eine Release-Day-Tabelle, die der Lead per Hand pflegt. BaFin-reguliert, der Audit-Trail zählt also.

Die Montagsentscheidung des Leads: aufhören, Jira nachträglich einzubauen, stattdessen zwölf Skills schreiben. Tag eins: /spec (der Klärungsfragen-Skill für neue Features), /plan (Zerlegung in reviewbare PRs), /audit-log-write (der BaFin-spezifische Skill, der jede Änderung an geldbewegendem Code flaggt und ein strukturiertes Commit-Message-Format erzwingt, das der Lead zur Audit-Zeit aus git log ziehen kann) und /release-notes (auto-entworfen aus gemergten PRs mit manuellem Approval-Gate). Tag zwei bis fünf: der Rest des SDLC plus ein /security-review-Skill, der jede neue Abhängigkeit, jeden neuen Endpoint und jede Änderung am Kundendaten-Schema flaggt.

Messbares Ziel nach einem Quartal: PR-Zykluszeit von 3,2 Tagen auf 1,6 Tage (die bestehende Metrik des Leads aus GitHub Insights). KI-Spend stabil, weil die Copilot-Sitze ohnehin bezahlt waren. Audit-Vorbereitungszeit vor dem nächsten BaFin-Spotcheck: zuvor zwei Engineer-Wochen Commit-Historien-Durchforsten, Ziel ein Engineer-Tag, an dem der /audit-log-write-Skill rückwärts gegen die Commits des Quartals läuft und das strukturierte Log exportiert. Vermiedene Kosten: rund 22.000 EUR über zwölf Monate an Tooling-Spend, den der Lead in ihrer FY26-Budgetzeile bereits committet hatte, abdeckend Test-Plans-Sitze für die acht Engineers, Confluence Premium für das ganze Unternehmen und den Jira-Premium-Uplift, den sie zu finanzieren bereitstand. Keine dieser Zahlen hängt an einem Modell-Upgrade. Sie hängen daran, dass die Prozedur als Text im Repo codiert ist, wo jeder Engineer und jeder Assistent sie sehen und befolgen kann. Keiner unserer Mittelstands-Kunden kauft eine 200-Sitze-ALM-Plattform; alle können sich einen einwöchigen Skill-Schreib-Sprint leisten, den ihr existierender Senior Engineer leitet.

Wo die These verliert

Ich schulde dem Leser die Failure-Modes. Die These verliert an drei Stellen.

Erstens, Security und Supply Chain. Eine Skill-Datei sind ausführbare Anweisungen, die mit Modell-Vertrauen laufen. Wer in .claude/skills/ schreiben kann, kann lautlos ändern, was jeder Assistent in jeder Session als Nächstes tut. Für die BaFin-regulierte Fintech ist das keine Fußnote. Montagshandlung: .claude/skills/ als Produktionscode behandeln. PR-Review, Zwei-Personen-Freigabe für Änderungen, importierte Skill-Repos in CI auf einen geprüften Commit-SHA pinnen, niemals git pull von Skill-Packs beim Session-Start.

Zweitens, Governance-Reporting. Skills geben Ihnen Disziplin; sie geben Ihnen kein Dashboard, mit dem ein CTO dem Vorstand berichtet. Wenn das Business fordert „zeig mir Velocity, Sprint-Burndown und Cycle Time für den Quartalsreview", produziert ein Ordner Markdown das Artefakt nicht von allein. Die ehrliche Antwort: eine dünne Reporting-Schicht halten (GitHub Insights, eine simple SQL-Query gegen den Issue-Tracker oder ein einzelnes PostHog-Dashboard) und akzeptieren, dass Sie für den Report zahlen, nicht für den Workflow. Der Workflow ist die Skills; der Report ist der verbleibende ALM-Spend.

Drittens, Multi-Agent und menschliche Heterogenität. Skills setzen voraus, dass der lesende Agent kompetent genug ist, nuancierter Markdown zu folgen. Frontier-Modelle sind das; günstigere Modelle überspringen unter Last häufig den Red-Flag-Abschnitt. Es gibt außerdem einen dokumentierten Cognitive-Debt-Effekt: Entwickler, die sich auf KI-Hilfe stützen, schneiden in der Folge-Comprehension messbar schlechter ab als Peers, die die Arbeit unbegleitet erledigten. Die Lektion verallgemeinert sich. Disziplin als Text zu codieren verhindert nicht, dass Menschen die Entscheidung an das Modell delegieren und die Prozedur ganz überspringen. Der Skill schreibt die Regel; das Team muss sie lesen.

Ich halte den Tradeoff trotzdem für fast jedes Team zwischen 5 und 50 Engineers für wert. Sie geben das Dashboard auf, akzeptieren die Supply-Chain-Disziplin, behalten die prozedurale Codierung. Für die meisten Mittelstands-Kunden, die ich dieses Quartal beraten habe, ist das eine strikt günstigere, strikt schnellere und strikt langlebigere Antwort als die ALM-Plattform, die sie kaufen wollten.

Wenn Sie dieses Experiment in Ihrem eigenen Team fahren oder wenn Sie es probiert haben und es auf eine Weise gebrochen ist, die ich oben nicht beschrieben habe, melden Sie sich. Ich möchte Notizen vergleichen darüber, welche Skills den Kontakt mit einer echten Codebase überlebt haben und welche das Team nach zwei Wochen leise eingestellt hat.

Ressourcen