Neuronz.ai

English

Français

English

Français

Skills & assets ​

Assets are the skills, slash commands and subagents you store in Neuronz.ai. You store one once, and the plugin adds it to every session of the profiles that can see it. An asset's status (active, draft or archived) controls whether it is delivered: only active assets are.

How it works ​

Three kinds. A stored asset is one of three kinds, and the kind decides which folder of your harness (the coding agent you use: Claude Code or Oh-My-Pi) it is placed in:

  • Skill — a capability the agent reaches for on its own when the work matches its description.
  • Command — a job a person invokes by name. Claude Code and Oh-My-Pi expose it as a /slash command.
  • Agent — a specialized subagent definition.

Placed at every session start. At session start, the plugin takes the profile's active assets and places each one in the matching harness folder, updating them every session so you always have the current version. It only ever touches the assets it placed — your own personal skills and commands are never modified. On harnesses that can reload skills mid-session, skills become usable in the current session. Other assets appear in the next session.

Placed in the repository you are in. A profile's assets belong to that profile, so they are placed in the repository the session's profile came from, in the folder the harness reads there, rather than in one folder shared by every session on the machine. One profile's assets therefore never appear in another profile's sessions. The asset files themselves stay outside the repository; only links to them are placed in it, and those links are listed in the repository's own .git/info/exclude, so they never show up in git status and can never be committed by accident. Each agent gets its own entries there, so two agents working in one repository, or two worktrees of it, keep each other's. Old links left in the machine-wide folders are cleaned up on the next session. One exception: if you start a Claude Code session in your home folder, its project folder and the machine-wide one are the same (~/.claude), so that profile's assets can also show up in Claude Code sessions in other folders until a later session cleans them up.

That cleanup is not limited to the agent you happen to start. Every session records where it placed assets, so a set left in a shared folder by an agent you have stopped using, or by a profile you no longer use, is removed by the next session that finds it — you do not have to run that agent again to get rid of it. Only shared folders are cleaned up this way. What another repository holds is left alone.

Removed assets are cleaned up on the same pass: the stored copy of anything you renamed, unshared or deleted is removed along with its link, so what sits on disk is always your active set. That applies inside a skill too — a file you drop from a skill is removed from the copy the agent reads. A session that could not reach Neuronz.ai removes nothing and keeps every copy it already has.

Re-syncing without restarting. Assets are placed once, when a session starts, so a session can end up holding a set you have already changed: you switched profile mid-session, you edited an asset in the dashboard, or a session in another repository cleaned up a shared folder this one was using. /neuronzai:reload-assets redoes that work now — it downloads the profile's assets again (ignoring any cached copy, so files damaged by hand are rewritten), updates the links, and cleans up other profiles' sets exactly as a session start would.

What the session then sees differs by harness, and the command tells you which case you are in. Claude Code re-scans skills immediately; its commands and subagents are read at startup and need a new session. On Oh-My-Pi, run /reload-plugins afterwards — it re-reads skills, commands and subagents without touching your conversation. /neuronzai:switch-profile places the new profile's assets on its own and reports the same way — on Claude Code its message asks you to run /neuronzai:reload-assets to pick the new skills up in place.

Every harness reads the assets from its own folder inside the repository: Claude Code from .claude, Oh-My-Pi from .omp. Both support all three asset kinds. See harness parity for the complete matrix.

A frontmatter block has to parse. Saving an asset refuses a body whose --- block does not parse, and names the offending line. A strict harness such as Oh-My-Pi discards the whole block when it does not parse, so the description and argument hint would be missing. A body with no frontmatter at all stays perfectly valid.

The construct that trips this most often is an argument hint written as several bracketed groups, argument-hint: [pr-url] [--confirm], which YAML reads as one finished list followed by the start of another. Quote it — argument-hint: "[pr-url] [--confirm]" — and every harness reads the same string.

Cheap when nothing changed, safe when things go wrong. Syncing is cached, so a session where nothing changed is a quick check rather than a full download. The cache follows the profile the session actually uses, so changing which profile a folder belongs to always re-syncs. If Neuronz.ai cannot be reached, you keep the assets you already have and keep working. If Neuronz.ai is up but no longer accepts your sign-in (for example, it expired or was revoked), the assets Neuronz.ai placed are removed until you sign in again with /neuronzai:login. Your own files are never touched.

When something does go wrong, the message says which thing: Neuronz.ai could not be reached at all, it was reached and answered with an error, or it answered with an asset list that could not be read.

Runs are recorded for you. Each time a stored skill or command runs and does real work, that execution is recorded automatically as a run, so you have a history of which capabilities were actually used, and when.

Where an asset is available: scope ​

Every asset has a scope that decides which sessions can see it. There are three choices:

  • The current profile (the default). Create an asset without saying anything about scope and it belongs to the profile you made it in — only sessions on that profile see it. This is the right default for a capability that only makes sense for one project.
  • Global — available everywhere. Mark an asset global and it is placed in every profile of your workspace. Use this for a skill or command you want in every project.
  • Shared across specific profiles. Give an asset an explicit list of profiles and it becomes available in exactly those. It is one asset, not copies: editing it updates every profile that shares it at the same time, so the versions can never drift apart the way hand-copied files do.

Overriding a global with a profile's own version ​

Because a global asset reaches everywhere, you will sometimes want one project to do things its own way. The rule is simple: a profile's own asset beats a global one that shares its name. Suppose there is a global skill called deploy, and one profile also has its own deploy skill. Sessions on that profile get the profile's version, while everywhere else the global one still applies.

You cannot create a true clash: two global assets of the same kind and name, or two profile-scoped assets that share both a profile and a name, are rejected. A global asset paired with a profile's own version is always allowed.

Using it ​

Author and manage assets from your agent over MCP with add_asset, get_asset, list_assets, update_asset, and delete_asset — pass kind as one of skill, command, or agent. To set the scope, pass global: true to make an asset available everywhere, or a profiles list to share it across specific profiles; omit both and it stays on the current profile. You can change an asset's scope later the same way with update_asset. You can also browse and edit everything in the Assets page of the dashboard, and set each asset's status there (only active assets are delivered).

A typical flow: you describe a reusable job — say a command that checks an alerting channel and files anything not yet tracked — and your agent writes the full asset and calls add_asset with kind: "command". It is saved as active and placed in the profile at the next session start. From then on you can run /your-command in Claude Code or Oh-My-Pi. Writing an asset and running it happen in separate sessions: you write it now, and a later session runs it.