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 skills add evanca/flutter-ai-rules --skill code-reviewgit clone --depth 1 https://github.com/evanca/flutter-ai-rulesWrote 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/evanca/flutter-ai-rules/code-review)<a href="https://agentmods.dev/skills/evanca/flutter-ai-rules/code-review"><img src="https://agentmods.dev/badge/skills/evanca/flutter-ai-rules/code-review/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/evanca/flutter-ai-rules/code-review"><img src="https://agentmods.dev/badge/skills/evanca/flutter-ai-rules/code-review.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to high
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- high Privilege Escalation · line 162 Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.Fix: Remove references to credential paths. Use environment variables or secrets managers. For docs, use placeholder paths (e.g., /path/to/config). Never load .env or token files in production code paths.
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.00027 | $0.02152 |
| Opus 5.5 | $0.00011 | $0.00861 |
| Sonnet 5.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 1mo 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.
- 1mo 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 (652 stars, last pushed 7d ago), licensed MIT. It adds 27 tokens to every session and 2,152 once invoked, about $0.0001 per session on Opus 5.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
flutter-mcp-boundary-audit
Generic contract/schema boundary audit across authoring, discovery, validation, and execute—detecting split-brain between listings and invoke paths, gateway divergence, and permissive placeholders. Use when changing tool registration, RPC/plugin registries, dynamic tools, MCP or WebMCP surfaces, CLI exec aliases…
review-rfc
Review an implemented RFC in a fresh context against its acceptance criteria, RULES.md and the test plan, and save the review to reviews/.
dart-expert
Expert-level Dart, Flutter, mobile development, and cross-platform apps. Use when the user mentions Flutter, mobile, cross platform, or widgets, or when the task involves Dart Language or Flutter Framework.
security-review
Review authorized application code, configuration, designs or artifacts for concrete authorization, data exposure, injection, secret, dependency and LLM/tool security risks. Use for a requested security review or a change affecting a trust boundary.
code-review
Review PR, branch, commit or working-tree changes for concrete defects and fidelity to intended behavior. Also use when explicitly asked to independently challenge a prepared plan, diagnosis or verification claim.
dart-sdk-changelog
Authoritative guide for Dart SDK language specifications, syntax availability, minimum SDK constraints (minSdk), and version changelogs from Dart 1.x through Dart 3.x. Use this skill whenever authoring or refactoring Dart code, inspecting pubspec.yaml sdk constraints, writing control flow (switch statements, pattern…