porting-tools-to-fluent

Guide for porting Babylon.js tools from legacy shared-ui-components to Fluent UI using MakeModularTool. Use when: port to fluent, migrate to fluent, fluent migration, porting tool UI.

Quality

85%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Quality

Content

82%Weight 40%Scale 1-5

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 high-quality, actionable porting guide with executable code, mapping tables, and a clear sequenced workflow including validation. Its main weaknesses are length (some general material could be offloaded to references) and references to files not present in the bundle.

Suggestions

Move general icon conventions and makeStyles/token rules fully into fluent.instructions.md and keep only migration-specific deltas inline, to tighten conciseness.

Integrate explicit validate-then-fix-then-retry feedback loops into the 10-step summary (not just the end-of-phase Verify checklist) to raise workflow clarity.

Ship the referenced files (fluent.instructions.md, design-guidelines.md, port-to-fluent.md) in the bundle so the progressive-disclosure split is verifiable and navigation is complete.

Dimension	Reasoning	Score
Conciseness	The body is dense and information-rich, assumes Claude's competence (no explanations of what Fluent UI, React, or makeStyles are), and every section carries concrete value. It is not a 5 because at ~580 lines it is very long, and some general material (icon conventions, makeStyles basics) could live entirely in the referenced fluent.instructions.md rather than being summarized inline.	4 / 5
Actionability	Provides copy-paste-ready code for MakeModularTool config, service definitions, makeStyles, and a detailed legacy-to-Fluent component mapping table with exact import paths and icon mappings, covering the common porting cases.	5 / 5
Workflow Clarity	A numbered 10-step porting order, a phased execution plan that keeps the build green per phase, and a dedicated 'Verify' checklist (clean build, no legacy imports, light/dark rendering) provide validation for the destructive cleanup steps, so it is not capped at 3. It is not a 5 because the main 10-step sequence lacks inline feedback loops (validate -> fix -> retry) within the steps themselves.	4 / 5
Progressive Disclosure	Well-organized into numbered sections with clearly signaled one-level-deep references (fluent.instructions.md for general rules, design-guidelines.md for the design system, port-to-fluent.md for the full large-editor plan). It is not a 5 because the referenced files are not present in the bundle, so the split cannot be verified against actual bundle structure.	4 / 5
	Total	17 / 20 Passed

Description

87%Weight 40%Scale 1-5

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 strong: third-person voice, explicit what-and-when, specific framework and source/target, and natural trigger phrases with synonyms. Minor room to broaden trigger term variation beyond the repeated 'fluent' keyword.

Dimension	Reasoning	Score
Specificity	Names the domain ('porting Babylon.js tools'), the framework ('MakeModularTool'), and the from/to transition ('legacy shared-ui-components to Fluent UI'), giving several concrete specifics around a single porting action. It is not a 5 because the action verb is essentially one (port/migrate) rather than multiple distinct concrete actions.	4 / 5
Completeness	Explicitly answers both 'what' ('Guide for porting Babylon.js tools from legacy shared-ui-components to Fluent UI using MakeModularTool') and 'when' ('Use when: port to fluent, migrate to fluent, fluent migration, porting tool UI') with concrete trigger phrases, matching the top anchor.	5 / 5
Trigger Term Quality	Includes natural trigger phrases a user would say — 'port to fluent', 'migrate to fluent', 'fluent migration', 'porting tool UI' — with port/migrate synonyms. It is not a 5 because the terms are repetitive (all contain 'fluent') and miss common variations like 'Fluent UI' or 'convert to fluent'.	4 / 5
Distinctiveness Conflict Risk	Targets a clear niche (Babylon.js tools, MakeModularTool, Fluent UI migration) with distinct triggers, making overlap with unrelated skills unlikely.	5 / 5
	Total	18 / 20 Passed

Validation

87%

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 — 14 / 16 Passed

Validation for skill structure

Criteria	Description	Result
skill_md_line_count	SKILL.md is long (584 lines); consider splitting into references/ and linking	Warning
relative_links	Relative link issues: 2 missing, 1 suspicious	Warning

	Total	14 / 16 Passed

Repository: BabylonJS/Babylon.js
Path: .github/skills/porting-tools-to-fluent/SKILL.md
Commit: 787eedf

Reviewed: 4 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.