Written by Huifer, solo developer and maintainer of TanStack Ship. I started using TanStack Intent during its first 2026-Q1 release week and packaged skills for each TanStack Ship module. In my own maintenance log, that removed roughly three hours per week of repeated context-setting for boilerplate changes. This is a personal workflow measurement, not a controlled benchmark, but the improvement was large enough that package-distributed skills became part of how I maintain the platform.
Verified sources: TanStack Ship GitHub · TanStack Intent repository · Agent Skills specification · TanStack Start documentation Updated: 2026-07-20 · Changelog
TL;DR: TanStack Intent is a CLI and packaging convention for shipping small, task-specific Agent Skills with npm packages. A maintainer writes and validates
SKILL.mdfiles, includes theskillsdirectory in the package, and ties skills to source documentation. A consumer installs Intent guidance, discovers skills from locally installed packages withlist, and loads the relevant one withload. Skills travel with dependency updates, but agents still need explicit discovery and loading; Intent is distribution and maintenance infrastructure, not magic model memory.
TanStack Intent in one paragraph
TanStack Intent lets library maintainers ship compositional knowledge alongside code. Types can tell an agent whether a function call is legal, and prose docs can explain concepts to a human, but neither reliably tells a coding agent which pattern to choose for a specific task. A skill fills that gap with a narrow description, current conventions, examples, and anti-patterns.
The package manager becomes the delivery channel. When an application installs an intent-enabled dependency, that dependency’s published skills directory arrives with the exact package version. Intent can discover those skills locally, and the coding agent can load only the one relevant to the current change. Upgrading the package upgrades its knowledge artifact through the same dependency workflow.
The official project describes the goal as shipping “compositional knowledge for AI coding agents alongside your npm packages.” On 2026-07-20, I checked npm rather than relying on memory: @tanstack/intent reported version 0.3.6, and its repository pointed to github.com/TanStack/intent. Readers can rerun the commands below because versions will move.
Why documentation and types still leave a gap
Training data mixes old and new APIs. Human documentation often begins with concepts, while an agent needs a compact answer to “when this task appears, follow these files, imports, and constraints.” TypeScript can reject a wrong argument, but it cannot explain that an authenticated route belongs under a particular layout, that a mutation must invalidate a typed key factory, or that a webhook needs idempotency before business logic.
Project-level files such as CLAUDE.md help, but copying framework instructions into every repository creates drift. Six months later, the application may use a newer package while its copied instructions still teach the old API. Community rule files add another unclear owner.
Intent does not replace docs or types. It derives a focused agent artifact from maintainer-owned sources and gives that artifact a versioned distribution path. The strongest stack is still documentation for humans, types and tests for correctness, and skills for task selection.
Skills should be narrow and triggered by intent
A useful skill does not summarize an entire framework. It answers one family of requests: configure a plugin, add a guarded route, manage search parameters, or migrate an API. Its description is critical because that is the compact signal an agent uses during the skill check.
In this repository, running intent list discovered 41 skills across 11 local intent-enabled packages. They were grouped into core, framework, lifecycle, and sub-skill concerns. That is more usable than injecting 41 full documents into every prompt.
Anatomy of an Agent Skill
At minimum, a skill is a directory containing SKILL.md with YAML frontmatter and procedural markdown. The open Agent Skills specification defines the portable shape; Intent adds the package discovery, loading, validation, and staleness workflow around it.
A simplified billing skill can look like this:
---
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.
The description says when to load the skill. The body names sources, invariants, and a verification procedure. It does not waste tokens retelling Stripe’s entire API. Real skills may include adjacent examples or documentation files, but the entry point remains compact.
Source links make staleness detectable
A skill is derived knowledge, so drift is its central risk. Intent’s stale workflow flags skills whose source documentation changed, generated artifacts that drifted, and public workspace packages missing expected coverage. The setup command can install CI templates so drift appears during normal review rather than after an agent generates obsolete code.
That is the key improvement over a pasted prompt. Versioning alone distributes changes; source tracking and CI give maintainers a reason to review the skill when knowledge changes.
How agents consume skills from installed packages
The common shorthand—“Claude Code or Cursor reads skills from node_modules automatically”—is too strong. Intent’s documented consumer flow is explicit. Run install to write skill-loading guidance into supported agent configuration files. During work, the agent checks available local skills with list, chooses a matching package-and-skill reference, and loads its SKILL.md with load.
# Add discovery/loading guidance to the project's agent configuration
npx @tanstack/intent@latest install
# See skills shipped by installed packages
npx @tanstack/intent@latest list
# Load only the guidance relevant to the task
npx @tanstack/intent@latest load \
@tanstack/router-core#router-core/auth-and-guards
Command runners are interchangeable: npm uses npx, pnpm uses pnpm dlx, and Bun uses bunx. The current README also documents Yarn Plug’n’Play support and best-effort Deno support through npm interoperability. Check the official compatibility table rather than assuming every editor resolves packages identically.
Different coding agents have different native conventions and hook systems. Intent avoids promising that every tool silently indexes every dependency. It installs a portable behavior: check, select, load, then work. This keeps context small and makes the selected source visible in an agent transcript.
What list actually discovered here
For this article I ran the project’s required skill check from the workspace root. It found local skills in TanStack Start, Router, Devtools, Redux Toolkit, dotenv, and related packages. Each result included the package name, installed version, skill name, description, and source.
That result is reproducible only for this lockfile snapshot. Another project will see a different set, and a package with no published skills will not appear merely because Intent is installed. This limitation is healthy: the CLI reports actual local artifacts rather than pretending the model knows every dependency.
First practical example: Router code generation
Routing is where package-owned knowledge pays off quickly. Models have seen React Router, multiple TanStack Router generations, and framework-specific file-routing conventions. A plausible response can import the wrong package, use a stale filename, or lose typed route context while still looking convincing.
The installed Router skills divide the domain into route-tree basics, guards, code splitting, loading, navigation, errors, path parameters, search parameters, SSR, and type safety. If the task is “add an authenticated layout,” the agent can load guard guidance instead of an entire router manual. If the task changes a validated search parameter, it loads a different sub-skill.
This does not guarantee correct output. It improves the evidence available at the decision point. Compilation, tests, and review remain mandatory. I treat a skill as a maintained runbook, not an authority that can bypass verification.
Why this beats a hand-written CLAUDE.md alone
A project file still owns application-specific choices: directory boundaries, product terminology, test commands, privacy constraints, and architectural decisions. A package skill owns library-specific knowledge. Keeping those responsibilities separate reduces duplication.
The package skill updates with the dependency, can be checked for stale source material, and is shared by all consumers. The project file stays small and explains only what makes the application distinct. When instructions conflict, the application’s explicit constraint should win, and the agent should surface the conflict rather than blend both silently.
The result is composition: framework guidance plus package guidance plus project guidance, loaded when relevant. That is more maintainable than a giant rules file and more transparent than hoping model training contains the right release.
Packaging skills for TanStack Ship’s modules
TanStack Ship has 14 production modules spanning billing, authentication, users, content, storage, campaigns, credits, email, invitations, UTM capture, attribution, holidays, short links, and revenue operations. I started packaging task-level skills around the dangerous seams, not writing one marketing summary per module.
Billing guidance covers raw-body verification, event identity, audit records, and queues. UTM guidance preserves attribution across SSR, cookies, signup, and checkout. Admin-route guidance covers authorization, navigation registration, loaders, and error states. Blog guidance covers frontmatter, i18n, and publication checks. The platform features show the product domains; the skills encode how an agent changes them safely.
A paid module’s complete skill content is not necessarily public, so the GitHub organization verifies the maintainer identity and public footprint, not every claim about private package files. That is a limitation of commercial source distribution and why I do not present private skill counts as an independent benchmark.
Measuring the three-hours-per-week claim
My estimate came from maintenance notes comparing repeated prompting before and after the first module skills. I counted time spent correcting known convention errors and restating module context. I did not randomize tasks, blind reviewers, or hold model versions constant. Novel business logic showed much less benefit than repeated framework and module work.
The honest conclusion is personal: skills removed about three hours of weekly context repair in my workflow. The general conclusion should be tested by each team. Track first-pass test success, correction turns, and time-to-accepted diff for repeated tasks before claiming a percentage improvement.
Maintainer workflow: ship, validate, and keep current
Intent exposes separate consumer and maintainer workflows. Consumers install guidance, list, and load. Maintainers scaffold a skill tree, review generated knowledge, validate the files, check staleness, and include the skills directory in the npm package.
# Explore the guided maintainer workflow
npx @tanstack/intent@latest scaffold
# Validate one package's skills from a monorepo root
npx @tanstack/intent@latest validate packages/billing/skills
# Check all workspace skills against their declared sources
npx @tanstack/intent@latest stale
# Copy Intent's CI workflow templates into .github/workflows
npx @tanstack/intent@latest setup
A maintainer should also inspect the packed tarball before release. A perfect local skill that is omitted from npm files cannot help consumers. Tests should verify that public packages include skills/** while excluding internal generation artifacts where appropriate.
Limits and failure modes
A skill can be vague, wrong, or stale. An agent may skip the skill check, select a broad skill, or load the right guidance and still write broken code. Tool compatibility also varies, and context priority can differ. Intent improves knowledge delivery; it does not standardize every agent runtime.
Skills can create false confidence if they contain instructions without tests. Every technical skill should end with verification commands and state the boundaries it cannot validate. Security-sensitive workflows need human review even when generated code passes tests.
There is also maintenance cost. Framework authors must review skills as APIs and source docs change. Intent’s validation and staleness checks make that cost visible, but they do not eliminate it. Teams unwilling to own derived guidance should keep the skill surface small.
Getting started without overcommitting
Run npx @tanstack/intent@latest list in an existing workspace before installing anything else. If relevant local skills appear, load one and compare the resulting change with your normal workflow. Then run install if you want durable guidance in the project’s agent configuration.
Library maintainers should begin with one error-prone capability, attach it to authoritative source docs, add a concrete verification section, validate it, and inspect the package tarball. Expand only after observing that agents select and use it correctly.
For more AI-assisted development context, browse the blog and comparison guides. Evaluate the approach on repeated real work, not a polished one-shot demo.
TanStack Intent’s useful idea is modest: the maintainer closest to an API should own a compact, versioned explanation of how agents use it, and that explanation should travel through the same package channel as the code.
Try TanStack Ship’s pre-bundled Agent Skills by starting from the features overview and choosing the package that matches the module you need; review pricing only after the workflow proves useful in your own agent.