assets-modify

Modify an asset file in the project. Use 'assets-get-data' first to inspect the asset structure before modifying. Not allowed to modify asset files in the 'Packages/' folder — modify them in 'Assets/'. Three modification surfaces are available (content, pathPatches, jsonPatch) — see the skill body for details.

Quality

64%

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

Fix and improve this skill with Tessl

tessl review fix ./Unity-MCP-Plugin/.claude/skills/assets-modify/SKILL.md

Quality

Content

57%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 well-organized tool documentation with executable CLI commands and precise semantics for all three modification surfaces. Its main weaknesses are duplicated parameter documentation (table + schema), placeholder-only call examples, no verification workflow for a modifying operation, and bulk schema content inlined rather than split out.

Suggestions

Add a validation/verification step to the workflow, e.g., "After modifying, call assets-get-data to confirm the change landed" — currently a write operation ships with no feedback loop.

Replace the all-placeholder call example with one real worked example (e.g., a pathPatches payload setting a Material field via 'nested/field' syntax) so the common case is copy-paste ready.

Move the full input JSON schema (and its $defs) into a references/ file and keep only the parameter table plus one compact example in SKILL.md, eliminating the verbatim table/schema duplication.

Dimension	Reasoning	Score
Conciseness	The Input table descriptions ("Reference to UnityEngine.Object asset instance...", "List of path-scoped patches routed through Reflector.TryModifyAt") are duplicated verbatim inside the ~120-line inline JSON schema, doubling the same parameter documentation and inflating token cost.	3 / 5
Actionability	Concrete runnable commands are given (unity-mcp-cli run-tool with --input, --input-file, and stdin pipe patterns) plus precise path syntax, but the primary call example uses "string_value" placeholders for every parameter and no worked example with real pathPatches or jsonPatch values is shown.	4 / 5
Workflow Clarity	The surface execution order is explicit ("jsonPatch → pathPatches → content... At least one is required") but this write/destructive operation has no post-modify verification step (e.g., re-inspect with assets-get-data), and the "inspect first" prerequisite appears only in the description, capping this dimension at 3.	3 / 5
Progressive Disclosure	Sections are clearly headed and navigable, but the full input JSON schema (~120 lines, including nested $defs) is inlined wholesale — bulk reference material that belongs in a separate reference file given no bundle files exist.	3 / 5
	Total	13 / 20 Passed

Description

53%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 technically precise about the tool's constraint model (surface types, folder rules, prerequisite skill) but reads as tool documentation rather than a trigger-oriented skill description. It lacks a "Use when..." trigger clause and natural-language synonyms that would let a user's request reliably match it.

Suggestions

Add an explicit trigger clause such as "Use when the user asks to modify, edit, or change a Unity asset (Material, ScriptableObject, Prefab, or any file in Assets/)."

Include natural synonyms and asset-type keywords (edit, change, Prefab, Material, ScriptableObject, .asset) alongside the technical surface names.

Keep the folder-constraint rule but move the "see the skill body for details" pointer out of the description so the description stays self-contained.

Dimension	Reasoning	Score
Specificity	"Modify an asset file in the project" plus "Three modification surfaces are available (content, pathPatches, jsonPatch)" names the domain with a concrete action, named surfaces, and a prerequisite workflow, but only covers a single action rather than several distinct capabilities.	3 / 5
Completeness	The "what" is clear ("Modify an asset file in the project") but there is no "Use when..." clause or equivalent explicit trigger guidance, which caps completeness at 3 per the judging guidelines.	3 / 5
Trigger Term Quality	Relevant keywords like "asset file", "Assets", and "Packages" are present, but common variations users would say are missing — no "edit" or "change" synonyms and no asset-type terms (Prefab, Material, ScriptableObject) or extensions.	3 / 5
Distinctiveness Conflict Risk	Naming the sibling skill 'assets-get-data', folder constraints ('Packages/' vs 'Assets/'), and the three surfaces makes it mostly distinct from sibling asset tools; the generic phrase "modify an asset file" still carries minor overlap risk, so it does not reach the clear-niche anchor of 5.	4 / 5
	Total	13 / 20 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: IvanMurzak/Unity-MCP
Path: Unity-MCP-Plugin/.claude/skills/assets-modify/SKILL.md
Commit: 4c8056f

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