Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/evanca/flutter-ai-rules/code-reviewnpx skills add evanca/flutter-ai-rules --skill code-reviewgit clone --depth 1 https://github.com/evanca/flutter-ai-rulesWhat 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 | $0.00027 | $0.02152 |
| Opus 5 | $0.00014 | $0.01076 |
| Sonnet 5 | $0.00005 | $0.00430 |
| Haiku 4.5 | $0.00003 | $0.00215 |
Grade A, and why
code-review scanned grade A with 1 finding 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 2d 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.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
> **Token safety.** The token is a secret. You may check whether it **exists** and report its **length** to confirm it's configured, but **never read, echo, log, print, or otherwise reveal the token value** — not in chat How it starts
The opening of the file, as written. The whole thing — 171 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Code Review Skill
Perform structured, objective code reviews for Flutter/Dart projects following a repeatable checklist.
When to Use
Use this skill when:
- Asked to review a pull request, merge request, or branch.
- Evaluating changed, added, or deleted files for correctness and quality.
- Auditing a diff before merging.
- Checking whether new code meets project standards.
Review Workflow
Step 1 — Validate branch and merge target
- Confirm the current branch is a feature, bugfix, or PR/MR branch — not the project's primary branch (e.g.
main,master,develop). - Verify the branch is up-to-date with the target branch (no unresolved conflicts).
- Identify the target branch for the merge.
Checkpoint: If the branch is behind the target, flag it before proceeding.
Step 2 — Discover changes
- List all changed, added, and deleted files.
- For each change, look up the commit title and review how connected components are implemented.
- Analyze the change: is it clear why the change was made? If not, dig into the connected methods and files until it is. When you report, name which connected files/methods you analyzed and why — this shows the change was understood, not assumed.
- Never assume a change is correct without investigating the implementation.
- If a change remains unclear after investigation, note this explicitly in the report.
Step 3 — Review each file
Iterate through each changed file. For every file, verify the following:
| Area | What to verify |
|---|---|
| Understand the change | Why was it made? Review connected methods/files; note which ones you analyzed and why |
| Location | File is in the correct directory |
| Naming | File name follows project naming conventions |
| Responsibility | The file's responsibility is clear; reason for change is understandable |
| Readability | Variable, function, and class names are descriptive and consistent |
| Logic & correctness | No logic errors or missing edge cases |
| Code smells | Scan for the smells in Code Smells Reference below |
| Maintainability | Code is modular; no unnecessary duplication |
| Error handling | Errors and exceptions are handled appropriately |
| Security | No input validation gaps; no secrets committed to code |
| Performance | No obvious inefficiencies (e.g., unnecessary rebuilds, O(n^2) loops on large lists) |
| SOLID principles | Adherence assessed without forcing unnecessary boilerplate or over-abstraction |
| Flutter/Dart/ patterns | Match against the project's loaded guidelines and conventions |
| Documentation | Public APIs, complex logic, and new modules are documented |
| Test coverage | New or changed logic has sufficient tests (see Step 4) |
| Style | Code matches the project's style guide and linting rules |
| Existing code | If the new changes look fine, also review surrounding existing (unchanged) code for smells and suggest refactors where relevant |
What ships with it
3 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 2d ago First seen · 171 lines · 27 tokens per session scan A 722f24fa2a63
code-review is a skill published in the GitHub repository evanca/flutter-ai-rules (622 stars, last pushed 4d ago), licensed MIT. It adds 27 tokens to every session and 2,152 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
base-pattern-documentation
Creates comprehensive documentation for base pattern skills following Flutter architecture conventions. Use when documenting new base classes, view patterns, state management patterns, or architectural components that serve as foundations for other code.
signals-migration-6-to-7
Detailed guidelines, patterns, and rules for migrating codebases from signals.dart version 6.x to version 7.x.
jaspr-js-interop
Effectively integrate with Javascript when building Jaspr web applications. Use this skill when wrapping an existing JS library, accessing browser-native APIs, or bridging code safely across environments.
multi-agent-handoff
Plan and document handoffs, parent lane contracts, and parallel batch contracts between specialized AI agents (foreman, workers, reviewers). Use for multi-agent workflows, subagents, original goal preservation, native gates, claim ceilings, terminal states, baton passes, or guild-style agent coordination.
flutter-mcp-toolkit-control
Drive a running Flutter app — tap, scroll, type, fill forms, hot-reload, navigate. Use when you need to interact with the UI.
harness-engineering-lifecycle
Design, implement, and integrate generalized validation harnesses across a producer-consumer boundary after a local harness contract exists. Use when refactoring custom validation CLIs/MCPs for large polyrepos, extending Steward across sibling repos, or deploying a local tool to a consumer project for dogfooding and…