Support project-specific CLI commands in skills and the command reference generator

[ArkTarusov]

Problem

com.unity.pipeline lets a project register its own editor commands — they show up in unity command alongside the built-in ones. The plugin, however, only ships a reference for the official command set: skills/unity-pipeline/references/editor-commands.md, generated by the Roslyn tool in tools/command-ref-gen from the com.unity.pipeline sources.

This leaves project-specific commands invisible to the skill: an agent doesn't know they exist, and their argument schemas have to be rediscovered every session via unity --json command.

Worse, the obvious workaround — hand-editing editor-commands.md to add custom commands — breaks plugin updates: any regeneration or upgrade overwrites or conflicts with the user's edits.

Proposed direction (starting point, not a decision)

A separate per-project command reference file that lives in the user's project, outside the plugin. The user (or an agent) generates it — ideally with the same command-ref-gen tool pointed at the project's sources. The plugin's skills mention that such a project-level reference may exist and where to look for it.

Open questions

• Convention for the project file: name and location (project repo root? .claude/? elsewhere?) so agents find it predictably.
• How the skill references a file that may not exist — wording in SKILL.md that doesn't break the no-custom-commands case.
• command-ref-gen support: can it already take arbitrary source directories? Does it need a "project commands only" mode that skips the official set to avoid duplication?
• Recommended workflow: who runs the generator, when to regenerate, how to detect drift between the generated file and the live unity --json command output.
• Update resilience: the project file shouldn't be invalidated by every generator change — either stabilize the output format or document regeneration as a routine step.
• User-facing docs: a "my project has custom commands — what do I do" section.

Definition of done

A documented approach (ADR note or README section) where:

• an agent working in a project with custom commands learns about them from a reference file;
• plugin updates never touch the project-level file;
• generating/updating that file is reproducible with a single command.