frb-dev-env

Use when the user wants Docker-based FRB development or Tart-based iOS Simulator validation.

Quality

76%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./.claude/skills/frb-dev-env/SKILL.md

Quality

Content

77%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is a highly actionable, well-sequenced operational guide with strong validation checkpoints and concrete commands for Docker, Android, Tart, and VMware workflows. Its main weaknesses are length/repetition (conciseness) and a large amount of inline content that overlaps with the referenced source-of-truth files (progressive disclosure).

Suggestions

Tighten conciseness by removing the verbatim-duplicated iOS integration test command (keep one concrete example instead of the generic + identical concrete pair) and condensing the credential preflight prose.

Split the long VMware (and optionally Android/Tart) sections into referenced reference files, keeping SKILL.md as an overview that points to tools/vmware_windows/README.md and the frb-*-prepare skills to improve progressive_disclosure.

In the description, replace abstract actions ("development", "validation") with concrete capability verbs (e.g., run Rust/Dart/web tests, generate code, lint, build) and add common trigger phrasings alongside the FRB/Tart jargon.

Dimension	Reasoning	Score
Conciseness	The body avoids explaining concepts Claude already knows and is dense with project-specific operational detail, but at ~410 lines it includes repetition (e.g., the iOS integration test command is shown verbatim twice) and verbose credential-handling prose that could be tightened; not level 3 because not every token earns its place, not level 1 because it is not padded with basic concept explanations.	2 / 3
Actionability	Provides abundant concrete, copy-paste-ready bash commands with specific flags, environment variables, paths, and expected outputs across every environment workflow; not level 2 because the guidance is fully executable rather than pseudocode or vague direction.	3 / 3
Workflow Clarity	Each environment workflow is clearly sequenced with explicit validation checkpoints (First Checks git/submodule status, credential preflight that "fails before running release commands", "Verify Docker-local ADB can see the host emulator", simctl bootstatus, container-label validation before delete) and feedback loops; not level 2 because checkpoints are explicit rather than implicit.	3 / 3
Progressive Disclosure	Has a clear overview ("Choosing an Environment", "Principles") and well-signaled one-level-deep references to sibling skills and tools/vmware_windows/README.md, but substantial content is inline (the long VMware section even restates material whose source of truth is the referenced README); not level 3 because content that could be separate remains inline, not level 1 because references are clearly signaled and not deeply nested.	2 / 3
	Total	10 / 12 Passed

Description

75%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description is a concise, third-person trigger with an explicit "Use when..." clause and a clear, distinctive niche. It is strong on completeness and distinctiveness but weaker on specificity and trigger-term quality because its actions ("development", "validation") are abstract and it relies on project jargon (FRB, Tart).

Dimension	Reasoning	Score
Specificity	Names the domains ("Docker-based FRB development", "Tart-based iOS Simulator validation") and activities but uses abstract actions like "development" and "validation" rather than listing concrete actions; not level 3 because no multiple specific concrete actions are given, not level 1 because domains are clearly named.	2 / 3
Completeness	Explicitly answers when with "Use when the user wants..." and what with the two named workflows; the explicit Use-when clause satisfies the cap rule, so it reaches level 3 rather than 2.	3 / 3
Trigger Term Quality	Contains relevant keywords (Docker, FRB, iOS Simulator, validation) but leans on project jargon ("FRB", "Tart") and misses common user phrasings; not level 3 due to jargon and missing variations, not level 1 because several natural terms are present.	2 / 3
Distinctiveness Conflict Risk	Targets a clear FRB-project niche combining Docker-based development and Tart-based iOS Simulator validation, with distinct triggers unlikely to fire for unrelated skills; not level 2 because the Docker/FRB + Tart/iOS-Simulator combination is distinctive.	3 / 3
	Total	10 / 12 Passed

Validation

100%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: fzyzcjy/flutter_rust_bridge
Path: .claude/skills/frb-dev-env/SKILL.md
Commit: 1d5348b

Reviewed: 5 days ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.