Development tools such as Claude Code, Codex, GLM, OpenCode, and Cursor quickly accumulate skills, MCP servers, subagents, commands, hooks, and rules. Each one is useful on its own, and together they turn into a pile nobody can account for six months later: where a given file came from, and whether it still does anything.
Onplate brings these resources together in one local application. It shows what is installed, where each resource came from, and when it was last used.
Why Onplate exists
The same skill can appear in several places: globally in an AI client, inside one project, or as part of a package. Versions may differ, instructions may conflict, and unused resources continue consuming model context.
Onplate indexes the files and settings and shows:
- which resources are stored in Onplate;
- what is installed in every supported AI tool;
- which resources are global and which belong to one project;
- where conflicts, stale versions, or external changes appeared;
- how much context the configuration consumes;
- which skills and subagents were invoked during the last 30 days.
Without this inventory, the same information has to be collected manually from each client’s and project’s configuration directories.
What Onplate does
One place for managed resources
Skills, MCP servers, subagents, and packages all come under management. A resource is stored once and installed into supported AI tools according to each tool’s formats and limitations.
A skill can sit in the Onplate library and still be invisible to Claude Code and Codex, so the interface shows those two states apart.
Security checks before installation
A skill or subagent contains instructions for an AI system, so it should not be treated as an ordinary text file. Malicious content can try to obtain secrets, execute destructive commands, download untrusted code, or alter an agent’s behavior.
The scanner looks for prompt injection, secret exfiltration, dangerous shell commands, hidden characters, and suspicious external addresses. A finding includes the relevant line, severity, and explanation. Adding a dangerous resource requires an explicit confirmation and a comment.
Context cost visibility
Metadata for installed skills can enter every AI session before the first task is sent. A large global configuration therefore has a permanent cost.
Context usage is estimated separately for each AI tool, with the always-present part kept apart from the maximum added when resources activate. A large global skill can then be moved to the projects that actually need it.
Actual usage analysis
Local journals from supported AI tools say which skills and subagents were actually invoked. A resource with no calls during the last 30 days may be unnecessary or may have a description that never triggers correctly.
The analysis stays local. Onplate records the invocation, its time, and the related project, but it does not store conversation content.
Versions, updates, and rollback
Managed resources have version history. You can inspect changes, compare versions, update a resource, or return to a previous state. The operation journal records when a change happened and where it came from.
Synchronization with the existing disk state
Starting from an empty environment is not required. Existing installations in AI tool directories are discovered by the scan, presented as external resources, and can be brought into managed storage. Changes made outside Onplate remain visible.
The scanner checks supported home directories, project configurations, and folders explicitly selected by the user, all collected in a “Where to look” list. Nothing has to be classified in advance: Onplate opens the folder and reports what it turned out to be, a skill directory, a tool folder such as .opencode, or a directory holding several projects. When a better candidate sits nearby, a project root one level up for instance, both outcomes are shown with their counts and the choice stays with the user.
Results are grouped by their origin. Every group shows its location, Git repository when available, and the number of skills and subagents. An unwanted result can be hidden and the scan stops returning it, but the hidden count and a restore action stay in view, so hiding something does not turn into losing it.
A separate “Where we looked” report lists every inspected directory, including the paths that do not exist on disk. It answers the question of whether a folder was examined at all, which nothing else can confirm. Alongside it the report names what else lives in those folders: commands, rules, and hooks. Onplate does not manage them and says so plainly rather than leaving them unmentioned.
Project configurations are read on equal terms with the home ones: skills and subagents from tool directories inside the project, MCP servers from .mcp.json at its root.
Between scans Onplate can watch the same locations and suggest that a rescan is due. Watching starts only after explicit consent to read local directories, and it answers one question, whether anything changed. Reading the contents is the scan itself, and the user starts it.
Multiple AI tools with different rules
Claude Code, Codex, GLM, OpenCode, and Cursor use different paths and formats. There is no single installation rule that covers all of them, so Onplate carries the differences explicitly.
Some tools accept project MCP configuration while others do not. Some recognize more than one skill directory name. Native plugin support also varies. Onplate only offers combinations supported by the selected client and explains missing capabilities.
The shared .agents/skills convention is supported as well. It is not an AI tool by itself, but several tools can read skills from that directory.
Reusable launch modes
An AI client starts with choices about the model, reasoning effort, permissions, tools, and visible directories. Keeping a safe combination in shell history is inconvenient and error-prone.
A mode is a launch configuration prepared in advance. The exact command is shown before the button is pressed, so it can be read, copied, and run by hand. Whatever a given client will not understand is named separately: Cursor and OpenCode have no reasoning-effort setting of their own, and tool allowlists are understood only by Claude Code and GLM. Instead of quietly losing part of the configuration, the user sees up front what will not reach the client.
Launching a mode changes nothing on disk. When the configuration is needed outside Onplate as well, a mode can be written into the client’s settings file: the exact changes are shown before the write, and a copy of the previous file is kept next to it.
The no-confirmation level is a decision of its own. Before launch Onplate states plainly that at that level the client will ask nothing before editing or deleting files and nothing before running commands.
Testing whether a skill really triggers
A model decides whether to use a skill largely from its description. A poorly described skill can consume context without ever activating.
This is tested by experiment: the selected AI tool gets a normal task related to the skill, and the run shows whether it reaches for the skill at all. The run uses a temporary copy of the environment and does not modify user files or settings. Results include a verdict, duration, and estimated token use.
Runs are stored for comparison. A skill may start triggering after a description change, stop after an update, or behave differently with the same version. The last outcome reflects model nondeterminism and is reported as such.
Git repositories as sources
A regular Git repository can provide resources alongside marketplaces. Onplate discovers skills in public, private, personal, or team repositories and checks for updates on a selected schedule. Private sources can authenticate with a token or SSH, with credentials stored locally in encrypted form.
Disconnecting a source removes its local clone and credentials. Imported resources remain in storage but stop receiving updates from that source.
Conflicts, history, and reversibility
Two skills can contain contradictory instructions, while an MCP server or subagent may collide with an existing installation. The resource conflict view explains suspicious pairs. A false positive can be dismissed with a note, for example when resources belong to different projects.
Every managed installation, update, rollback, or removal enters the operation journal. Deleted resources and versions first move to a trash area where they can be restored. Reversibility matters because a broken AI configuration may only become visible several sessions later.
Marketplace integration
Marketplaces make skills, MCP servers, and subagents easier to discover, but direct installation from an external catalog hides important questions about content and trust.
A marketplace here only supplies the resource; installing it is a later, separate step. The user reviews the content and the local security findings first. Only then does the resource enter managed storage with versions, provenance, and controlled installation.
One catalog for several resource types
The Marketplace section covers skills, MCP servers, and subagents, and the path is the same for all three: search, preview, scan, then add to local storage.
Skill marketplaces
SkillsMP support is built in. Search can be narrowed by sorting, categories, and profession where the marketplace offers them, and the interface also shows the remaining request quota and roughly when it refreshes.
Before anything is added, SKILL.md is downloaded and shown in full. The scanner marks dangerous and suspicious lines inside the text itself and explains each finding below it. A link to the original resource page is available too.
A skill judged dangerous can still be imported, but Onplate asks for a comment justifying the risk. Skills already in storage are marked in the results, so nobody creates a duplicate by accident.
One built-in marketplace is not the limit. A custom catalog can be added over its API with a name, a base URL, and an access key. When the JSON response does not follow the expected shape, field mapping is configurable: name, author, description, rating, category, content address, and source link.
The API key is stored locally in encrypted form, and after saving the interface shows only a mask of the value.
The official MCP registry
For MCP servers Onplate uses the official Model Context Protocol registry. Results carry the name, description, version, transport, and a security rating.
A server description from the registry turns into a local configuration: a URL and headers for a remote server, a startup command with arguments and environment variables for a local one.
Secret fields are marked separately. Tokens, keys, and sensitive header values never arrive from the registry and are never filled in automatically. The user enters them locally, and Onplate keeps them encrypted.
An internal or private source can be added next to the official registry. Both the MCP registry schema and the mcpServers format are supported, and the format is detected automatically. Internal and public servers go through the same review and installation screen.
Subagent catalogs
The Subagents tab lists pluggable catalogs of roles and helpers. A preview carries the system prompt, the allowed tool list, and the security findings.
A custom JSON catalog pointing at Markdown definitions can be connected, with an access token for a closed source. Updates to installed subagents are checked as well and can be applied one at a time.
After import
Once imported, marketplace resources follow the same managed workflow as local ones:
- content inspection and storage;
- security analysis;
- installation into compatible AI tools;
- project or global scope;
- version and update control;
- provenance tracking;
- usage and context analysis.
Finding a resource never installs it: a skill is not pushed into every project, and an MCP server gets no secrets without the user typing them in.
Local operation and privacy
There is no required account, no telemetry, and no cloud backend. Configuration scanning, security checks, context estimates, and local journal analysis run on the user’s computer.
Network access is used only when an action requires it, such as marketplace search, Git sources, MCP registries, or update checks. AI session history does not need to leave the machine.
Who Onplate is for
Onplate is intended for developers who already use skills and MCP servers, teams that share project AI configuration, and people working across several AI clients.
Installation is only one operation. The main view answers more practical questions: what is connected, how much context it consumes, whether conflicts exist, and whether the resource is used at all.
Onplate: onplate.tsymbal.dev · documentation