Skip to content

feat: label CLI invocations with caller and skill (blocked on CLI-951) - #31

Open
ziyiunity wants to merge 1 commit into
mainfrom
feat/attribute-cli-invocations
Open

feat: label CLI invocations with caller and skill (blocked on CLI-951)#31
ziyiunity wants to merge 1 commit into
mainfrom
feat/attribute-cli-invocations

Conversation

@ziyiunity

Copy link
Copy Markdown
Collaborator

Do not merge yet. The two flags this adds do not exist in the CLI, and unity command rejects unknown options: error: unknown option '--caller' (Did you mean --all?). Merging before the CLI accepts them would make every CLI invocation in these six skills fail. This is blocked on CLI-951.

What this does

Labels every unity command invocation with who produced it, so plugin-driven CLI usage can be told apart from a user typing the same command, and broken down by which skill drove it.

unity command eval --caller plugin --skill optimize-web --code '<snippet>'

Six skills carry the flags: unity-cli, optimize-web, urp-postprocessing, optimize-audio, audio-setup-mixers, sprite-editor. Eight lines in total, since three of them repeat the canonical invocation in a reference file.

unity-cli also gains an explicit rule, because it is the skill others delegate to:

Pass --caller plugin --skill <name> on every unity command invocation. --skill is the skill whose instructions produced the call, so a task skill that sends you here passes its own name rather than unity-cli.

Why flags in the skill text rather than an environment variable

The marker has to reach the unity command process. A plugin manifest can set env only on an MCP server it declares, which covers unity mcp, not unity command. This plugin ships skills only and declares no MCP server, so there is no environment-variable path to the invocations that need marking.

Flags work because the skill text is the thing that produces the invocation. It also cannot be forgotten at runtime the way a prose instruction can.

What these numbers will and will not show

Worth stating here, because per-skill counts are easy to over-read.

A skill's trigger is not observable. Triggering happens inside the agent and touches no Unity process. What gets counted is that a skill ran and reached its CLI step. A skill that triggers and then skips that step produces nothing, so the numbers undercount, and undercount most in the runs that went wrong.

Three skills will read as zero. new-unity-project, unity-package-management and initialize-ai-navigation make no CLI calls of their own; they delegate the mechanics to unity-cli, with 8, 3 and 1 references respectively and 0 own invocations. Their work will be attributed to unity-cli, which will look correspondingly inflated. Anyone reading this data as "most used skill" would get unity-cli at the top and new-unity-project at zero, which is backwards: the latter is the one a new user is most likely to reach first.

Fixing that needs the originating skill's label to survive a delegation, which skill text cannot do on its own. Out of scope here.

Not changed

CHANGELOG.md and SECURITY.md in unity-cli also mention unity command eval, and references/integration-advanced.md carries several examples. Those document the CLI rather than instructing the agent, so adding two flags to each would add noise without changing behavior.

Checked

  • Structural gate passes; claude plugin validate passes.
  • The flags are rejected today, verified against the installed CLI, which is why this is held.

@ziyiunity
ziyiunity requested a review from a team as a code owner August 25, 2026 20:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant