TanStack Intent erklärt: Wie Agent Skills mit npm-Paketen ausgeliefert werden

Praktischer Leitfaden zu TanStack Intent: wie npm-Pakete Agent Skills verteilen, wie Agents diese finden und laden – und wie Maintainer Verfall verhindern.

Huifer
Huifer
20. Juli 20269 min read
Auch verfügbar auf:English · 中文

Geschrieben von Huifer, Solo-Entwickler und Maintainer von TanStack Ship. Ich habe TanStack Intent während der ersten Veröffentlichungswoche in 2026-Q1 verwendet und Skills für jedes TanStack-Ship-Modul paketiert. In meinem eigenen Wartungsprotokoll hat das rund drei Stunden pro Woche an wiederholter Kontextarbeit für Boilerplate-Änderungen eingespart. Das ist eine persönliche Workflow-Messung, kein kontrollierter Benchmark – aber die Verbesserung war so signifikant, dass paketverteilte Skills Teil meiner Plattformwartung wurden.

Verifizierte Quellen: TanStack Ship GitHub · TanStack Intent Repository · Agent Skills Specification · TanStack Start Dokumentation Aktualisiert: 20. Juli 2026 · Changelog

Kurzfassung: TanStack Intent ist eine CLI und Paketierungskonvention zum Ausliefern kleiner, aufgabenbezogener Agent Skills mit npm-Paketen. Ein Maintainer schreibt und validiert SKILL.md-Dateien, nimmt das skills-Verzeichnis ins Paket auf und verknüpft Skills mit der Quell-Dokumentation. Ein Konsument installiert die Intent-Guidance, findet Skills aus lokal installierten Paketen mit list und lädt den relevanten mit load. Skills reisen mit Abhängigkeits-Updates mit – aber Agents müssen diese trotzdem explizit entdecken und laden; Intent ist Distributions- und Wartungsinfrastruktur, keine magische Modell-Erinnerung.

TanStack Intent in einem Absatz

TanStack Intent ermöglicht es Bibliotheks-Maintainern, kompositionales Wissen neben Code auszuliefern. Types können einem Agenten sagen, ob ein Funktionsaufruf legal ist, und Prosa-Dokumentation kann Konzepte einem Menschen erklären – aber keines von beiden sagt zuverlässig einem Coding-Agenten, welches Muster er für eine bestimmte Aufgabe wählen soll. Ein Skill schließt diese Lücke mit einer engen Beschreibung, aktuellen Konventionen, Beispielen und Anti-Patterns.

Der Package Manager wird zum Lieferkanal. Wenn eine Anwendung eine intent-fähige Abhängigkeit installiert, kommt das veröffentlichte skills-Verzeichnis dieses Pakets mit der exakten Paketversion mit. Intent kann diese Skills lokal entdecken, und der Coding-Agent kann nur den relevanten Skill für die aktuelle Änderung laden. Ein Upgrade des Pakets upgraded sein Wissensartefakt durch denselben Abhängigkeits-Workflow.

Das offizielle Projekt beschreibt das Ziel als „compositional knowledge for AI coding agents alongside your npm packages." Am 20. Juli 2026 habe ich npm überprüft, statt mich auf mein Gedächtnis zu verlassen: @tanstack/intent meldete Version 0.3.6, und das Repository verwies auf github.com/TanStack/intent. Leser können die untenstehenden Befehle erneut ausführen, da sich Versionen mit der Zeit ändern werden.

Warum Dokumentation und Types trotzdem eine Lücke hinterlassen

Trainingsdaten vermischen alte und neue APIs. Menschliche Dokumentation beginnt oft mit Konzepten, während ein Agent eine kompakte Antwort auf „wenn diese Aufgabe erscheint, befolge diese Dateien, Importe und Constraints" braucht. TypeScript kann ein falsches Argument ablehnen, aber es kann nicht erklären, dass eine authentifizierte Route unter ein bestimmtes Layout gehört, dass eine Mutation eine typisierte Key-Factory invalidieren muss, oder dass ein Webhook Idempotenz vor der Business-Logik braucht.

Projektdateien wie CLAUDE.md helfen, aber Framework-Anweisungen in jedes Repository zu kopieren erzeugt Drift. Sechs Monate später nutzt die Anwendung vielleicht ein neueres Paket, während die kopierten Anweisungen noch die alte API lehren. Community-Regeldateien fügen einen weiteren unklaren Besitzer hinzu.

Intent ersetzt weder Docs noch Types. Es leitet ein fokussiertes Agent-Artefakt aus maintainer-eigenen Quellen ab und gibt diesem Artefakt einen versionierten Verteilungsweg. Der stärkste Stack bleibt: Dokumentation für Menschen, Types und Tests für Korrektheit, und Skills für die Aufgabenauswahl.

Skills sollten eng gefasst und von der Intention ausgelöst werden

Ein nützlicher Skill fasst nicht ein gesamtes Framework zusammen. Er beantwortet eine Familie von Anfragen: einen Plugin konfigurieren, eine geschützte Route hinzufügen, Suchparameter verwalten oder eine API migrieren. Seine Beschreibung ist kritisch, weil sie das kompakte Signal ist, das ein Agent während der Skill-Prüfung verwendet.

In diesem Repository fand intent list 41 Skills über 11 lokale intent-fähige Pakete. Sie wurden nach Core-, Framework-, Lifecycle- und Sub-Skill-Belangen gruppiert. Das ist deutlich benutzbarer, als 41 vollständige Dokumente in jeden Prompt zu injizieren.

Anatomie eines Agent Skill

Minimal besteht ein Skill aus einem Verzeichnis mit einer SKILL.md, die YAML-Frontmatter und prozedurales Markdown enthält. Die offene Agent Skills-Spezifikation definiert die portable Form; Intent fügt Paketermittlung, Laden, Validierung und den Staleness-Workflow hinzu.

Ein vereinfachter Billing-Skill kann so aussehen:

markdown
---
name: billing-webhook-idempotency
description: Use when adding or changing a Stripe webhook that mutates billing state.
---

# Billing webhook idempotency

## Before editing
- Read `docs/billing/event-ledger.md`.
- Locate the existing event claim and audit helpers.

## Required invariants
1. Verify the signature against the untouched request body.
2. Claim `event.id` through the database unique constraint.
3. Attach `source_event_id` to money-like mutations.
4. Return a retryable response when processing fails.

## Verification
- Replay one signed event concurrently.
- Assert one business effect and one completed ledger entry.

Die Beschreibung sagt, wann der Skill geladen werden soll. Der Body benennt Quellen, Invarianten und eine Verifikationsprozedur. Er verschwendet keine Tokens mit einer vollständigen Wiederholung der gesamten Stripe-API. Echte Skills können angrenzende Beispiele oder Dokumentationsdateien enthalten, aber der Einstiegspunkt bleibt kompakt.

Quelllinks machen Staleness erkennbar

Ein Skill ist abgeleitetes Wissen – Drift ist sein zentrales Risiko. Intent's stale-Workflow kennzeichnet Skills, deren Quelldokumentation sich geändert hat, generierte Artefakte, die abgewichen sind, und öffentliche Workspace-Pakete, die erwartete Abdeckung vermissen. Das Setup-Kommando kann CI-Vorlagen installieren, damit Drift während normaler Reviews erkannt wird, nicht nachdem ein Agent veralteten Code generiert hat.

Das ist die Schlüsselverbesserung gegenüber einem eingefügten Prompt. Versionierung allein verteilt Änderungen; Quellverfolgung und CI geben Maintainern einen Grund, den Skill zu überprüfen, wenn sich Wissen ändert.

Wie Agents Skills aus installierten Paketen konsumieren

Die gängige Kurzform – „Claude Code oder Cursor liest Skills automatisch aus node_modules" – ist zu stark. Intent's dokumentierter Consumer-Flow ist explizit. Führen Sie install aus, um Skill-Ladeguidance in die unterstützten Agent-Konfigurationsdateien zu schreiben. Während der Arbeit prüft der Agent die verfügbaren lokalen Skills mit list, wählt eine passende Paket-Skill-Referenz und lädt die SKILL.md mit load.

bash
# Discovery-/Ladeguidance zur Agent-Konfiguration des Projekts hinzufügen
npx @tanstack/intent@latest install

# Im Projekt installierte, Skills-ausliefernde Pakete anzeigen
npx @tanstack/intent@latest list

# Nur die Guidance laden, die für die Aufgabe relevant ist
npx @tanstack/intent@latest load \
  @tanstack/router-core#router-core/auth-and-guards

Befehlsrunner sind austauschbar: npm verwendet npx, pnpm verwendet pnpm dlx, und Bun verwendet bunx. Die aktuelle README dokumentiert auch Yarn Plug'n'Play-Support und bestmöglichen Deno-Support durch npm-Interoperabilität. Prüfen Sie die offizielle Kompatibilitätstabelle, anstatt anzunehmen, dass jeder Editor Pakete identisch auflöst.

Verschiedene Coding-Agents haben unterschiedliche native Konventionen und Hook-Systeme. Intent vermeidet die Zusicherung, dass jedes Tool stillschweigend jede Abhängigkeit indiziert. Es installiert ein portierbares Verhalten: prüfen, auswählen, laden, dann arbeiten. Das hält den Kontext klein und macht die ausgewählte Quelle in einem Agent-Transkript sichtbar.

Was list hier tatsächlich gefunden hat

Für diesen Artikel habe ich die erforderliche Skill-Prüfung des Projekts vom Workspace-Root aus ausgeführt. Es fand lokale Skills in TanStack Start, Router, Devtools, Redux Toolkit, dotenv und verwandten Paketen. Jedes Ergebnis enthielt den Paketnamen, die installierte Version, den Skill-Namen, die Beschreibung und die Quelle.

Dieses Ergebnis ist nur für diesen Lockfile-Snapshot reproduzierbar. Ein anderes Projekt sieht einen anderen Satz, und ein Paket ohne veröffentlichte Skills erscheint nicht nur, weil Intent installiert ist. Diese Einschränkung ist gesund: Die CLI meldet tatsächliche lokale Artefakte, anstatt so zu tun, als wüsste das Modell jede Abhängigkeit.

Erstes praktisches Beispiel: Router-Code-Generierung

Routing ist der Bereich, wo paket-eigenes Wissen schnell Früchte trägt. Modelle haben React Router, mehrere TanStack-Router-Generationen und frameworkspezifische File-Routing-Konventionen gesehen. Eine plausible Antwort kann das falsche Paket importieren, einen veralteten Dateinamen verwenden oder den typisierten Route-Kontext verlieren – und dabei trotzdem überzeugend aussehen.

Die installierten Router-Skills teilen das Domain in Route-Tree-Grundlagen, Guards, Code-Splitting, Loading, Navigation, Fehler, Path-Parameter, Search-Parameter, SSR und Type-Safety auf. Wenn die Aufgabe „authentifiziertes Layout hinzufügen" ist, kann der Agent Guard-Guidance laden statt eines vollständigen Router-Handbuchs. Wenn die Aufgabe einen validierten Search-Parameter ändert, lädt er einen anderen Sub-Skill.

Das garantiert keine korrekte Ausgabe. Es verbessert die Evidenz, die am Entscheidungspunkt verfügbar ist. Kompilierung, Tests und Review bleiben obligatorisch. Ich behandle einen Skill als ein gepflegtes Runbook, nicht als Autorität, die Verifikation umgehen kann.

Warum das besser ist als eine handgeschriebene CLAUDE.md allein

Eine Projektdatei behält anwendungsspezifische Entscheidungen: Verzeichnisgrenzen, Produktterminologie, Testbefehle, Privacy-Constraints und Architekturentscheidungen. Ein Paket-Skill behält bibliothekspezifisches Wissen. Diese Verantwortungstrennung reduziert Duplikation.

Der Paket-Skill aktualisiert sich mit der Abhängigkeit, kann auf veraltetes Quelldokument geprüft werden und wird von allen Konsumenten geteilt. Die Projektdatei bleibt klein und erklärt nur, was die Anwendung einzigartig macht. Wenn Anweisungen konfligieren, gewinnt die explizite Constraint der Anwendung, und der Agent sollte den Konflikt aufdecken, anstatt beide stillschweigend zu vermischen.

Das Ergebnis ist Komposition: Framework-Guidance plus Paket-Guidance plus Projekt-Guidance, geladen wenn relevant. Das ist wartbarer als eine giant Rules-Datei und transparenter als die Hoffnung, dass das Modell-Training die richtige Version enthält.

Skills für TanStack Ship-Module paketieren

TanStack Ship hat 14 Produktionsmodule in den Bereichen Billing, Authentifizierung, Benutzer, Content, Storage, Kampagnen, Credits, E-Mail, Einladungen, UTM-Erfassung, Attribution, Feiertage, Short Links und Revenue Operations. Ich habe begonnen, aufgabenebene Skills um die gefährlichen Nahtstellen zu paketieren – nicht eine Marketing-Zusammenfassung pro Modul zu schreiben.

Die Billing-Guidance deckt Raw-Body-Verifikation, Event-Identität, Audit-Records und Queues ab. Die UTM-Guidance bewahrt Attribution über SSR, Cookies, Signup und Checkout auf. Die Admin-Route-Guidance deckt Autorisierung, Navigationsregistrierung, Loader und Fehlerzustände ab. Die Blog-Guidance deckt Frontmatter, i18n und Publikationsprüfungen ab. Die Plattform-Features zeigen die Produktdomains; die Skills kodieren, wie ein Agent sie sicher ändert.

Der vollständige Skill-Inhalt eines kostenpflichtigen Moduls ist nicht notwendigerweise öffentlich – daher verifiziert die GitHub-Organisation die Maintainer-Identität und den öffentlichen Footprint, nicht jede Behauptung über private Paketdateien. Das ist eine Einschränkung kommerzieller Quellverteilung und der Grund, warum ich keine privaten Skill-Anzahlen als unabhängigen Benchmark präsentiere.

Die Drei-Stunden-pro-Woche-Behauptung messen

Meine Schätzung stammt aus Wartungsnotizen, die wiederholtes Prompting vor und nach den ersten Modul-Skills vergleichen. Ich habe Zeit gezählt, die ich für das Korrigieren bekannter Konventionsfehler und das Wiederholen von Modulkontext aufgewendet habe. Ich habe weder Tasks randomisiert, Reviewer geblendet noch Modellversionen konstant gehalten. Novel-Business-Logik zeigte deutlich weniger Nutzen als wiederholte Framework- und Modul-Arbeit.

Die ehrliche Schlussfolgerung ist persönlich: Skills entfernten etwa drei Stunden wöchentlicher Kontextreparatur aus meinem Workflow. Die allgemeine Schlussfolgerung sollte von jedem Team getestet werden. Verfolgen Sie First-Pass-Test-Erfolg, Korrekturrunden und Zeit bis zur akzeptierten Diff für wiederholte Tasks, bevor Sie eine prozentuale Verbesserung beanspruchen.

Maintainer-Workflow: ausliefern, validieren und aktuell halten

Intent bietet separate Consumer- und Maintainer-Workflows. Konsumenten installieren Guidance, listen und laden. Maintainer scafolden eine Skill-Struktur, prüfen generiertes Wissen, validieren die Dateien, prüfen Staleness und nehmen das skills-Verzeichnis ins npm-Paket auf.

bash
# Geführten Maintainer-Workflow erkunden
npx @tanstack/intent@latest scaffold

# Skills eines Pakets von einer Monorepo-Wurzel aus validieren
npx @tanstack/intent@latest validate packages/billing/skills

# Alle Workspace-Skills gegen ihre deklarierten Quellen prüfen
npx @tanstack/intent@latest stale

# Intent's CI-Workflow-Vorlagen nach .github/workflows kopieren
npx @tanstack/intent@latest setup

Ein Maintainer sollte auch den gepackten Tarball vor dem Release inspizieren. Ein perfekter lokaler Skill, der nicht in den npm files enthalten ist, kann Konsumenten nicht helfen. Tests sollten sicherstellen, dass öffentliche Pakete skills/** einbinden und wo angemessen interne Generierungsartefakte ausschließen.

Grenzen und Fehlermodi

Ein Skill kann vage, falsch oder veraltet sein. Ein Agent kann die Skill-Prüfung überspringen, einen zu breiten Skill auswählen oder die richtige Guidance laden und trotzdem fehlerhaften Code schreiben. Die Tool-Kompatibilität variiert ebenfalls, und die Kontextpriorität kann unterschiedlich sein. Intent verbessert die Wissensbereitstellung; es standardisiert nicht jeden Agent-Runtime.

Skills können falsches Vertrauen erzeugen, wenn sie Anweisungen ohne Tests enthalten. Jeder technische Skill sollte mit Verifikationsbefehlen enden und die Grenzen benennen, die er nicht validieren kann. Sicherheitskritische Workflows brauchen menschliche Überprüfung, selbst wenn generierter Code Tests besteht.

Es gibt auch Wartungskosten. Framework-Autoren müssen Skills prüfen, wenn sich APIs und Quelldocs ändern. Intent's Validierungs- und Staleness-Checks machen diese Kosten sichtbar, eliminieren sie aber nicht. Teams, die abgeleitete Guidance nicht selbst verantworten wollen, sollten die Skill-Oberfläche klein halten.

Loslegen, ohne sich zu überfordern

Führen Sie npx @tanstack/intent@latest list in einem bestehenden Workspace aus, bevor Sie etwas anderes installieren. Wenn relevante lokale Skills erscheinen, laden Sie einen und vergleichen Sie die resultierende Änderung mit Ihrem normalen Workflow. Führen Sie dann install aus, wenn Sie dauerhafte Guidance in der Agent-Konfiguration des Projekts wünschen.

Bibliotheks-Maintainer sollten mit einer fehleranfälligen Capability beginnen, sie an autoritative Quelldocs binden, einen konkreten Verifikationsabschnitt hinzufügen, validieren und das Paket-Tarball inspizieren. Erweitern Sie erst, nachdem Sie beobachtet haben, dass Agents ihn korrekt auswählen und nutzen.

Mehr KI-gestützte-Entwicklung-Kontext finden Sie im Blog und in den Vergleichsleitfäden. Bewerten Sie den Ansatz anhand wiederholter realer Arbeit, nicht anhand einer polierten One-Shot-Demo.

TanStack Intent's nützliche Idee ist bescheiden: Der Maintainer, der einer API am nächsten ist, sollte eine kompakte, versionierte Erklärung besitzen, wie Agents sie nutzen – und diese Erklärung sollte durch denselben Paketkanal wie der Code reisen.

Probieren Sie TanStack Ship's vorgefertigte Agent Skills, indem Sie von der Features-Übersicht starten und das Paket wählen, das zu Ihrem Modul passt; prüfen Sie die Preisübersicht erst, nachdem sich der Workflow in Ihrem eigenen Agent als nützlich erwiesen hat.