Borrowing it
Nothing to install: this file belongs to flutter/dart-intellij-third-party. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/flutter/dart-intellij-third-party/main/.agents/skills/implement-dart-language-feature/SKILL.mdgit clone --depth 1 https://github.com/flutter/dart-intellij-third-partyWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/flutter/dart-intellij-third-party/implement-dart-language-feature)<a href="https://agentmods.dev/skills/flutter/dart-intellij-third-party/implement-dart-language-feature"><img src="https://agentmods.dev/badge/skills/flutter/dart-intellij-third-party/implement-dart-language-feature/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/flutter/dart-intellij-third-party/implement-dart-language-feature"><img src="https://agentmods.dev/badge/skills/flutter/dart-intellij-third-party/implement-dart-language-feature.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00024 | $0.00528 |
| Opus 5 | $0.00012 | $0.00264 |
| Sonnet 5 | $0.00005 | $0.00106 |
| Haiku 4.5 | $0.00002 | $0.00053 |
Grade A, and why
implement-dart-language-feature scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 9d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 37 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Dart Language Feature Guidelines
Use this skill when implementing support for a new Dart language feature (e.g., primary constructors, macros, records) or when reviewing code/PRs that modify the Dart grammar and parser.
1. Implementation Guidelines
When modifying the grammar and parser to support new syntax, adhere to the following principles:
- Permissive over Restrictive: Be permissive when modifying the grammar. Trust that the Dart analyzer will produce the necessary diagnostics on invalid code. We do not need to strictly enforce language semantics at the parser level if it overcomplicates the grammar.
- Reuse Existing Productions: Strive to reuse existing grammar productions rather than introducing new ones. If an existing production almost works, explore and document the pros and cons of broadening it before creating a new one.
- Simplicity: Opt for simplicity wherever possible. Complex grammar rules are brittle and hard to maintain.
- Discrete Steps: Break the work into discrete, logical steps. (e.g., 1. Syntax/Grammar declarations, 2. AST node creation, 3. Parser logic, 4. Formatting/Highlighting).
2. Verification and Testing Protocol
It is critical that we have high confidence that the feature is complete and does not break existing functionality.
Before concluding the implementation, you must provide a Verification Report to the user containing:
- Testing Strategy: Explain how you intend to verify the feature and test it.
- Current Test State: Explain how the current tests work, what they validate, and what specific edge cases or sub-features are not covered.
- Proposed Improvements: Propose new tests to cover the new syntax.
- Manual Verification: Detail what manual verification steps are left for the user to perform (e.g., testing in a live IDE instance).
Note: Run tests iteratively as you go to verify that your changes have not broken anything.
3. Code Review Mode
If the user asks you to review an implementation of a language feature, evaluate the code against the implementation guidelines above:
- Critique the Grammar: Did they introduce a new production where an existing one could be broadened? Is the grammar overly restrictive?
- Check the Tests: Did they provide sufficient test coverage? Ask them to explain what is not covered.
- Assess Simplicity: Point out any areas where the parsing logic could be simplified.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 9d ago First seen · 37 lines · 24 tokens per session scan A 4f299f16531a
implement-dart-language-feature is a skill published in the GitHub repository flutter/dart-intellij-third-party (25 stars, last pushed yesterday), licensed BSD-3-Clause. It adds 24 tokens to every session and 528 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
matlab
Build, review, migrate, and safely plan MATLAB or GNU Octave numerical workflows, including arrays, tabular/time data, tests, projects, graphics, MAT files, and explicit Python interoperability.
ast-grep
Guide for writing ast-grep rules to perform structural code search and analysis. Use when users need to search codebases using Abstract Syntax Tree (AST) patterns, find specific code structures, or perform complex code queries that go beyond simple text search. This skill should be used when users ask to search for…
platform-detection
Identify a .NET project's test platform, framework, command mode, and SDK-style vs classic project system. Use only for "which test platform/framework?", "VSTest or MTP?", or "what runner does this project use?", including bridge settings, UseVSTest opt-outs, and incompatible or conflicting VSTest/MTP configuration.…
unity-version-split
Split a C# file into Unity 6.5+ and pre-Unity 6.5 variants. Use when a file needs different implementations for different Unity versions due to API changes (e.g., EntityId vs int, GetEntityId vs GetInstanceID).
omh-rust
This is a Hermes-native rust workflow skill.
axiom-concurrency
Use when writing ANY async code, actors, threads, or seeing ANY concurrency error. Covers Swift 6 concurrency, @MainActor, Sendable, data races, async/await patterns.