CtrlK
BlogDocsLog inGet started
Tessl Logo

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.

55

Quality

69%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

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
SKILL.md
Quality
Evals
Security

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 executable and well-organized with precise semantics for all three modification surfaces, but it is weighed down by ~155 lines of inline JSON schema, offers no worked example with real payloads, and lacks any post-modification verification step for a state-changing operation. Moving schemas to a reference file, adding one filled-in example, and closing with a verification step would lift all four dimensions.

Suggestions

Move the Input/Output JSON schemas into a references/schema.md file and keep only a one-line pointer plus the parameter table in SKILL.md.

Replace the placeholder call with one complete worked example, e.g. a pathPatches payload setting a field to a value via SerializedMember, so the envelope format is unambiguous.

Add a verification step to the workflow: after modifying, re-run gameobject-component-get to confirm the change, and check 'Success'/'Logs' in the response before proceeding.

DimensionReasoningScore

Conciseness

There is no over-explanation of concepts Claude already knows, but ~155 lines of inline JSON schema dominate the body, and key details (path syntax, component-ref semantics) are stated twice — once in the Input table and again in the schema. Mostly efficient, but it could be tightened by deduplicating or splitting the schemas out.

3 / 5

Actionability

The CLI invocation is fully executable with three concrete variants (inline JSON, --input-file, stdin heredoc), plus real troubleshooting ('npm install -g unity-mcp-cli', npx fallback), and the three modification surfaces are described with precise semantics including application order. Not 5 because the only call example uses '"string_value"' placeholders and there is no worked example with an actual patch payload.

4 / 5

Workflow Clarity

This is a destructive (modify) operation with no validation/verification step — nothing tells the reader to confirm the change afterwards (e.g. re-run gameobject-component-get) or how to react to 'Success: false' beyond the Logs field. Per the rubric guideline, missing verification in destructive workflows caps this at 3; the sequence (inspect first, then modify) is present only implicitly via the description.

3 / 5

Progressive Disclosure

Section headers (surfaces, path syntax, how to call, troubleshooting, input, output) provide reasonable structure, but the two large JSON schemas are inlined in SKILL.md where a references/ file would keep the overview lean. No bundle files exist, so the entire API reference lives in the overview, matching the 'content that should be separate is inline' anchor.

3 / 5

Total

13

/

20

Passed

Description

66%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 specific and domain-fluent with concrete named modification surfaces and good distinctiveness from sibling tools, but it lacks any explicit 'when to use this' trigger clause, which both caps completeness and weakens its utility for skill selection. Adding a 'Use when...' sentence would move it to the top band.

Suggestions

Add an explicit trigger clause, e.g. 'Use when the user asks to change, set, or update a field, property, or value on a Component of a GameObject or Prefab.'

Include a couple of natural user synonyms (e.g. 'Inspector value', 'SerializedField', '.prefab') to broaden trigger coverage without adding length.

Keep the pointer to 'gameobject-component-get' but move it after the trigger clause so the what/when/sequence read in order.

DimensionReasoningScore

Specificity

Names the domain ('Component on a GameObject in opened Prefab or in a Scene') and concrete capabilities: 'direct modification of component fields and properties' plus three named modification surfaces (componentDiff, pathPatches, jsonPatch). Not 5 because the action coverage is essentially one verb (modify) with parameter-level detail rather than multiple comprehensive actions.

4 / 5

Completeness

The 'what' is clearly stated ('Modify a specific Component... Allows direct modification of component fields and properties'), but there is no 'Use when...' clause or equivalent trigger guidance; 'Use gameobject-component-get first' is sequencing advice, not a when-to-use trigger. Per the rubric guideline, a missing 'Use when' clause caps this at 3.

3 / 5

Trigger Term Quality

Natural Unity vocabulary a user would say is present: 'Component', 'GameObject', 'Prefab', 'Scene', 'fields', 'properties'. A few natural terms and synonyms are missing (e.g. 'Inspector', 'SerializedField', '.prefab'), so it falls just short of the comprehensive-synonyms anchor.

4 / 5

Distinctiveness Conflict Risk

Clear niche (modifying component fields/properties) explicitly distinguished from the sibling inspection tool ('gameobject-component-get') and from generic GameObject operations. Minor overlap risk remains with closely related tools in the same gameobject-component family, so it is mostly distinct rather than minimal-conflict.

4 / 5

Total

15

/

20

Passed

Validation

100%

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
Reviewed

Table of Contents

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.