Dart's Skills CLI 1.0: Your Flutter Packages Can Now Ship Their Own AI Instructions

If you've used an AI coding agent on a Flutter project built after your model's training cutoff, you already know the problem. The agent confidently writes code against an API that changed three versions ago. You correct it, it apologizes, and it makes the same mistake in the next file.

Dart just shipped a tool aimed directly at that problem: the skills CLI, now at version 1.0 and maintained by the Dart team itself. It was originally built by Serverpod, and as of this release it's an official part of the Dart tooling story.

What "skills" actually means here

Agent Skills are small instruction bundles, usually a SKILL.md file plus supporting docs, that tell an AI agent how to use something correctly. They're not a Dart invention. The concept has been circulating since late 2025 as a way to hand an agent focused, current context instead of relying on whatever it learned during training. A skill for a networking package, for example, can spell out "always catch NetworkException, never let a raw timeout crash the UI" in a way the agent picks up automatically.

Until now, distributing these to a Flutter project meant cloning a Git repo by hand or reaching for npx skills. That works, but it means installing Node.js on a Dart project just to run one CLI command. It also has a real gap: nothing ties the skill you install to the exact package version you're actually using. You could end up with instructions describing an API your pubspec.yaml doesn't even reference anymore.

The part that matters: skills ship inside the package

The interesting design decision isn't the CLI itself, it's where skills live. A package author drops a skills/ directory at the top level of their repo, next to pubspec.yaml:

my-project/
├── src/
├── skills/      <--- skills
├── pubspec.yaml
└── README.md

That means the skill travels with the package version. If you're on networking: ^2.3.0, the skill you pull describes networking: ^2.3.0, not whatever the maintainer wrote a year ago or a community fork improvised. That solves the version-drift problem that plain Git-hosted skills never could.

Installing skills as a consumer

From your project root:

bash

dart run skills@ get

This scans your immediate dependencies for bundled skills/ folders, lists what it finds, and lets you pick which ones to install. Run it again later and it only shows what changed: new skills, updated ones, removed ones, or ones you previously skipped. If you don't want to review each one, --all installs everything at once.

The dart run skills@ syntax (note the trailing @ with nothing after it) always pulls the latest published version of the CLI as a global tool, so you're not stuck manually bumping it. dart install works too if you'd rather manage the version yourself, but then it's on you to keep it updated.

Shipping a skill if you maintain a package

If you publish a package on pub.dev, you can add a skill without touching your public API. Inside skills/, create a directory prefixed with your package name to avoid collisions with other packages' skills, then add a SKILL.md following the standard Agent Skills format:

markdown

---
name: networking-error-handling
description: >-
  Use when the user is making network requests using the networking APIs
  to ensure safe patterns.
---

# Networking Error Handling

## Guidelines

- Operations must always be wrapped in a try/catch block.
- You must catch `NetworkException` specifically
  to handle retries and log diagnostics.
- Provide fallback UI state in the event of a timeout.

## Examples

```dart
try {
  final response = await NetworkingClient.fetchData();
} on NetworkException catch (e) {
  Logger.log(e.context);
  return FallbackData();
}
```

The value here isn't the YAML frontmatter, it's that this is the same guidance you'd otherwise repeat in every code review or Stack Overflow answer about your package, except now the agent enforces it before the PR even exists. If you maintain an internal design-system package at your company, this is arguably more useful than the public README, because it's the thing that actually gets read by whatever tool your team is coding with.

Skills that aren't tied to a package

Not every skill maps to a specific dependency. The add command installs from any Git repository directly:

bash

dart run skills@ add https://github.com/my-org/custom-ai-skills.git

This is also how you pull from skills.sh, the general skill aggregator site that isn't Dart-specific. You just swap npx skills for dart run skills@ and the same repos work. So a team can mix package-bundled skills with general-purpose ones (testing conventions, commit message rules, whatever) through one tool instead of juggling npx for some and manual cloning for others.

Should you bother with this right now

If you maintain a published package, yes, and it costs you almost nothing. A SKILL.md describing common misuse of your API is cheap to write and directly reduces the kind of bug reports that turn out to be "you're using this wrong." A few packages are already shipping skills, including Jaspr, Serverpod, Flutter Scene, and GenUI, so you can see the format in a real codebase before writing your own.

If you're just consuming packages in a Flutter app, running dart run skills@ get costs one command and you can ignore anything it finds that isn't relevant. The bigger question is whether your agent of choice actually reads these files the way Claude Code or Cursor do. That part depends on your tooling, not on Dart, so check your agent's docs before assuming installed skills are being picked up automatically.

What this doesn't do is fix agents that ignore instructions or hallucinate APIs regardless of context. A skill file is guidance, not a guardrail. It narrows the gap between "the agent knows about your package" and "the agent knows about the version you're actually running," and for teams shipping fast against packages that change often, that gap has been a real source of wasted review cycles.

To learn more and explore skills in action:

• Documentation: Read the Package skills guide or the Flutter package skills doc.

• Package authors: Follow our guide on how to ship skills with packages.

• CLI tool: View package:skills on pub.dev.

• Examples: See skills already shipping in packages like Jaspr, Serverpod, Flutter Scene, and GenUI.