gameobject-component-modify

Modify a specific Component on a GameObject in opened Prefab or in a Scene. Allows direct modification of component fields and properties without wrapping in GameObject structure. Use 'gameobject-component-get' first to inspect the component structure before modifying. Three modification surfaces are available (componentDiff, pathPatches, jsonPatch) — see the skill body for details.

Quality

66%

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/gameobject-component-modify/SKILL.md

Quality

Content

65%

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

The body is highly actionable with concrete CLI examples and documented schemas, and its prose is lean, but it embeds two verbose duplicated JSON schemas inline and omits a verification step for a mutating operation. Splitting the schemas into reference files and adding a verify step would lift conciseness, workflow clarity, and progressive disclosure.

Suggestions

Move the full input/output JSON schemas into reference files (e.g., references/input-schema.json) and link to them from the body to improve conciseness and progressive disclosure.

Add an explicit verification step after the call, such as checking the response 'Success' field and 'Logs' for warnings, or re-running gameobject-component-get to confirm the change.

De-duplicate the AIGD.ComponentRef definition that appears identically in both the input and output schemas to reduce token cost.

Dimension	Reasoning	Score
Conciseness	The prose sections are lean, but two fully expanded JSON schemas are embedded inline (~250 lines) with the AIGD.ComponentRef definition duplicated across input and output schemas; this could be tightened or offloaded, matching 'mostly efficient but could be tightened' rather than 'every token earns its place'.	2 / 3
Actionability	Provides fully executable, copy-paste-ready CLI invocations including the base command, --input-file, stdin pipe pattern, and a troubleshooting note, plus documented input fields and path syntax — meeting the level-3 anchor for executable code/commands.	3 / 3
Workflow Clarity	The multi-surface ordering is stated (jsonPatch → pathPatches → componentDiff) and the call structure is clear, but this mutating operation has no explicit validation/verification step (e.g., checking the response Success field or re-inspecting with gameobject-component-get), so per the guideline workflow clarity is capped at 2.	2 / 3
Progressive Disclosure	The file is well-sectioned but well over 50 lines with two large inline JSON schemas that could appropriately live in separate reference files; with no bundle files present this matches 'content that should be separate is inline' rather than a clean one-level-deep reference structure.	2 / 3
	Total	9 / 12 Passed

Description

67%

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 specific and distinctive, clearly naming the operation and its three modification surfaces, but it lacks an explicit 'Use when...' trigger clause and leans partly on internal API jargon rather than natural user phrasings. Adding a concrete trigger condition would raise completeness and trigger-term quality.

Suggestions

Add an explicit trigger clause such as 'Use when the user asks to change or update a component's fields/properties on a GameObject in a Prefab or Scene' to satisfy the 'when' half of completeness.

Lead with natural phrasings users would say (e.g., 'change', 'update', 'set component values') before the internal surface names (componentDiff, pathPatches, jsonPatch) to improve trigger-term coverage.

Consider trimming the parenthetical about the three surfaces in the description since it points to the body, keeping the description focused on capability + trigger.

Dimension	Reasoning	Score
Specificity	Lists multiple concrete actions — 'Modify a specific Component on a GameObject', 'direct modification of component fields and properties', and three named modification surfaces (componentDiff, pathPatches, jsonPatch) — matching the level-3 anchor for multiple specific concrete actions.	3 / 3
Completeness	The 'what' is clearly stated, but the 'when' is only implied; 'Use gameobject-component-get first' is a prerequisite ordering, not an explicit trigger clause, so per the guideline a missing 'Use when...' clause caps completeness at 2.	2 / 3
Trigger Term Quality	Natural Unity terms appear ('Component', 'GameObject', 'Prefab', 'Scene', 'fields', 'properties') but the latter half leans on internal API names (componentDiff, pathPatches, jsonPatch) and lacks a spread of common natural variations, so it sits at 'some relevant keywords but missing common variations' rather than full coverage.	2 / 3
Distinctiveness Conflict Risk	Targets a clear niche — modifying a specific component's fields/properties — and is distinguished from the sibling 'gameobject-component-get', making it unlikely to trigger for the wrong skill.	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: IvanMurzak/Unity-MCP
Path: Unity-MCP-Plugin/.claude/skills/gameobject-component-modify/SKILL.md
Commit: e0a24ef

Reviewed: about 12 hours 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.