A Skill is a set of instructions that an AI client refers to. It is not loaded while it only sits inside the package, so you install it into the project (a Skill installed from the window is rewritten to the new version automatically when the package is updated).
Open Tsukimi MCP from the TsukimiCode menu in Unity and press the main button to install (it is written together with the client configuration; the window as a whole is covered in MCP server).
| Location | What it does |
|---|
| Skill row | The installation state. Every client reads the same Skill |
| Main button | Installs the bundled Skill into 2 places, .agents/skills/ and .claude/skills/. It is installed regardless of the client checkboxes |
| Add under Note in AGENTS.md in More | Adds a short note to the one file that is always read, whatever the task |
| Text | Meaning |
|---|
up to date · shared by every client | The current version of the Skill is installed |
out of date · shared by every client | An earlier version of the Skill is installed. A Skill installed from a window older than 0.9.0 also shows this |
out of date (changed by hand) · shared by every client | An earlier version of the Skill is installed, and some files were changed by hand after installation |
not installed · shared by every client | Not installed |
source not found | The source files of the Skill are missing from the package |
| |
|---|
| File | 19 bundled files written to 2 places, so 38 files |
| When a file of the same name already exists | Files that are still as they were when last installed are overwritten as they are. Files changed since installation are listed for confirmation before they are overwritten |
| Record | A .tsukimi-installed.json is placed in each install location, holding the installed version and a fingerprint of each file’s contents. The rewrite after a package update is decided from this record |
| When it takes effect | Clients read them only at startup. Restart after pressing |
| Case | What happens |
|---|
| When | When Unity loads scripts (at startup, or after the package is updated). Only when the version recorded in the install location differs from the current version; nothing happens for the same version |
| Files that are still as they were installed | Rewritten to the contents of the new version |
| Files that no longer exist in the new version | Deleted if they are still as installed. Kept if they were changed by hand |
| Files changed by hand after installation | Left as they are, and named in a warning in the Console. To replace them, press the main button in the window |
| Installs with no record | Not rewritten automatically. A Skill installed from a window older than 0.9.0 has no record, so reinstall it once with the main button (if the contents match the current version, only the record is created) |
| After rewriting | One line appears in the Console. Restart the client |
AGENTS.md is a file that is always read, whatever the task. What is added is two things: “this language is not in the training data, so run inspect before deciding an error is a bug”, and when to refer to each of the next 3 Skills.
| |
|---|
| How to add | Open More in the window and press Add under Note in AGENTS.md |
| What it changes | Only the region between the markers. Anything you wrote yourself in the same file stays |
| How it differs from a Skill | A Skill is read only when the task matches it, while AGENTS.md is always read |
| After updating the package | It is not rewritten automatically. Press Add again and only the region between the markers becomes the text of the current version |
| Skill | When it is read |
|---|
tsukimi | When writing, fixing, or reviewing T# code. When a TUKI diagnostic or a compile error appears. Before answering whether a given form can be written, and before saying that a form is impossible or that this looks like a compiler bug |
tsukimi-porting | When moving existing code written for UdonSharp over to T#. A whole world, a single Behaviour, or a fragment lifted from a guide |
mochi | When writing, fixing, or reviewing a MoCHI file (.mochi.xml). When a MoCHI diagnostic appears. Before saying that something cannot be placed in MoCHI |
| |
|---|
| Its premise | This language isn’t in the training data, so it doesn’t write from memory: inspect decides |
| What it asks for | Send what you wrote to inspect, and don’t call it done until test is green |
| How to read a diagnostic | Sort by the cause category (origin). subset is an intended error, and rewriting the form makes it compile (MCP server) |
| When you may report it | The steps to take before saying that something looks like a compiler bug are laid down |
| What you check yourself | Whether the completion report comes with inspect and test results |
It carries 6 reference files.
| File | Contents |
|---|
before-writing.md | What to decide before you start writing. Only the decisions that force a rewrite when you get them wrong |
beyond-csharp.md | Features with no plain-C# counterpart. The side you can’t think of unless you know it exists |
synchronization.md | Synchronization, and everything none of it guarantees |
testing.md | The difference between compiles being true and behaving as intended |
reporting.md | When something may be reported as a compiler bug, and how to write it up |
reference-index.md | An index of every page of this reference, one line per page on what it covers. A copy of the index as it stood when the package was built |
| |
|---|
| What it covers | What to measure before moving, what order to clear the diagnostics in, and the changes that alter meaning |
| What to do first | Measure with inspect before making any changes |
| How changes are classified | Separates the forms that need changing from the ones that don’t |
| The most expensive decision | What holds the data (an array, or a row of Behaviours) |
It carries 2 reference files.
| File | Contents |
|---|
already-works.md | Forms that work as-is. A form you avoided emits no diagnostic, so the belief that it can’t be done never clears on its own |
rewrites.md | Forms that need changing. Every one was actually compiled before being written down |
| |
|---|
| Its premise | MoCHI is not in the training data, so it doesn’t write from memory: the result of inspect decides |
| How to check | Pass the mochi argument to the same inspect used for T#. It reads files from disk, so have the file saved first. Have unsaved text passed in text and files (MoCHI Reference (experimental)) |
| How to read a diagnostic | As with T#, sort by the cause category (origin) |
What inspect cannot tell you | How it looks, how the light falls, and how it feels to walk around. It asks you to check these in Unity |
It carries 8 reference files.
| File | Contents |
|---|
markup.md | The accepted elements, attributes, and values. Anything not listed here is an error, with a diagnostic that names what is accepted instead |
components-audio.md | The attributes, types, and default values of the audio components |
components-other.md | The same contents for the components that fall under no other category |
components-physics.md | The same contents for the physics components |
components-rendering.md | The same contents for the rendering components |
components-textmeshpro.md | The same contents for the TextMeshPro components |
components-ui.md | The same contents for the UI components |
components-vrchat.md | The same contents for the VRChat components |