A skill or MCP server alone says little about where and why it is needed. The Projects section connects AI resources to a folder and shows the environment an agent receives while working with that code.

A project can be a Git repository or an ordinary local folder. Adding it does not install anything, create files, run commands, or send data elsewhere. Onplate stores the path and builds a local snapshot of its state.

What becomes visible after adding a project

A project profile is derived from evidence in the files: languages, frameworks, services, containers, and launch commands. Every detected fact traces back to a file and a line.

In an unfamiliar repository, every detected technology or launch command points back to its source file instead of relying on assumptions about the directory layout.

Discovered commands are never executed: they can be inspected and copied, and the potentially dangerous ones carry a scanner warning.

Regular projects, monorepositories, and workspaces

Not every directory has the same shape, and a few forms keep coming up:

  • a regular project with one folder and one profile;
  • a monorepository with shared Git history and parts such as backend and frontend;
  • a workspace containing several independent repositories;
  • a directory containing many unrelated projects.

This distinction affects resource placement. A backend-specific skill does not necessarily belong at the monorepository root. Repositories within a workspace may use different branches, profiles, and AI resources.

Project and global resources

Resources are separated by scope and origin.

A project resource is available only inside the selected folder. A global one belongs to an AI tool and may be visible in every project. Some arrive with the repository itself, even though Onplate never installed them.

The project page displays these states separately:

  • installed through Onplate;
  • stored in the repository as part of the code;
  • available globally through an AI tool.

This explains why an agent can see a particular skill, who manages the files, and whether that resource is part of the team’s shared setup.

Repository-owned resources are discovered automatically: skills and subagents in project-level AI directories, plus MCP servers from .mcp.json. Each external resource can be inspected, scanned, imported into managed storage, or left as it is.

How much context the AI receives

For each supported AI tool, Onplate calculates the context available in the selected project. The estimate includes project resources, global resources, and rule files read by the agent.

Permanent cost is separated from the maximum added during activation. This highlights cases where a broad set of global skills is too expensive for a small repository. Some resources can be moved to project scope instead of entering every unrelated session.

AI configuration status

Project configuration is summarized in a single status:

  • “Synchronized” when local configuration matches the expected state;
  • “Action required” when unapplied changes or differences exist;
  • “Blocked” when a folder is inaccessible, a profile is invalid, or a conflict prevents synchronization.

The interface includes a concrete reason instead of a generic warning. It may show that a team profile requires a resource missing from the current machine, or that the local version differs from the agreed version.

Project profiles and teamwork

The project profile lives in .onplate/profile.json beside the source code. It records required skills, MCP servers, and subagents, together with versions and target AI tools.

The file can be reviewed in a Git diff, discussed in a pull request, and applied on another computer. New team members receive a versioned configuration rather than an informal list of links.

Secret values never enter the profile. MCP definitions store only the names of required secrets; every developer provides actual credentials locally.

Commits are never created automatically and nothing is fetched: publishing profile changes stays an explicit user decision.

Project launch modes

An agent session is defined not only by resources, but also by its model, reasoning effort, permissions, tools, and visible directories. Projects tend to repeat a few combinations: repository exploration, everyday implementation, or a one-off task with broader permissions.

Onplate calls such a combination a mode. Every project includes starter modes and can define custom ones. The interface shows the exact command, the resources and helpers entering context, the selected permissions, and a compatibility table explaining which settings each client understands.

Launching a mode opens a session without modifying files. Persisting compatible settings is a separate action with a visible diff and a backup of the old configuration.

What was configured and what actually ran are shown apart, because they are known differently. Onplate counts the sessions it launched itself, so that number is exact. Which models did the work is read out of the clients’ own local journals, and the model name there is whatever the client wrote down.

Custom modes can be exported to .onplate/modes.json and reviewed in a pull request. Modes arriving from a repository are not activated automatically. Settings that expand permissions, including no-confirmation operation or access outside the project, require separate consent.

Team registries and roles

A project profile covers one repository. A team-wide set of resources can live in a separate Git registry that defines roles and the packages each role needs.

Users select a role and synchronization mode: disabled, notifications only, or automatic installation of missing resources. Onplate reports what is absent, stale, outside the profile, or unavailable in the registry. Multiple registries can be configured and selected explicitly.

Changes and local Git context

A project can change outside Onplate. Branch switches, new resources, profile edits, monorepository changes, and new AI sessions appear in the change view.

Local Git information includes uncommitted files, conflicts, branch divergence, linked worktrees, and profile history. A configuration difference may turn out to be an unfinished branch switch rather than an Onplate issue.

Between scans a file watcher can notice relevant changes and mark the displayed snapshot as stale. Project composition is then recalculated from the files, which changes nothing on disk. Accepting a newly discovered skill is still up to the user, and watching starts only after explicit access to local directories.

Sessions and resource usage

Local AI sessions are matched to projects by their working directories. The project page shows the client, creation time, model, and resources actually invoked during a session.

A project-specific skill that never triggers is worth a second look: usually the description is too weak to match, or it was installed at the wrong scope.

Reviewing several projects

The All Projects view shows active folders, projects requiring attention, archived entries, groups, and local tags. Two projects can be compared by their AI tools, versions, installation state, and context weight.

The same screen shows configuration drift, recent working directories, and the projects that need review first.

What this changes in daily work

The Projects section exists to answer a single question: what will the agent receive when it starts in this folder? The profile can be reviewed in a pull request and applied on another machine, while differences between repositories remain visible without comparing directories by hand.

Onplate: onplate.tsymbal.dev · documentation