onsystem@0.5.0

Minor Changes

• #73 cd4cbce Thanks @dgesteves! - onsystem is packaged for more agents, each pinned to the same release: npx skills add dgesteves/onsystem installs the skill in any agent with Agent Skills; an Agent Plugins 1.0 package (plugins/onsystem-agent, for GitHub Copilot CLI and other clients of the standard) and a Cursor plugin (plugins/onsystem-cursor) carry the MCP server and the skill; and Codex and VS Code install the plugin from the same marketplace as Claude Code. The skill has one source, copied into each package by scripts/sync-plugins.mjs, and a test fails when a copy drifts. The skill no longer says every agent has the Claude Code hook.

• #74 bbde609 Thanks @dgesteves! - An ESLint plugin, onsystem/eslint, with the same rules for ESLint 9 and 10 (flat config): add onsystem.configs.recommended to eslint.config.mjs. Each file is checked as check checks it, against its own project's design system with that project's config and suppression comments, with the same messages, positions and fixes; settings.onsystem.root and config point it elsewhere. The design system loads once in a worker thread and is refreshed while an editor keeps ESLint running. The real-world corpus runs through it too (pnpm corpus eslint) and reports the same findings as check. The docs page "ESLint plugin" shows how to use it alongside @shadcn/lint.

• #72 9aebe5a Thanks @dgesteves! - A GitHub Action: uses: dgesteves/onsystem@v0 runs check on a pull request, honours the baseline, and reports only the findings on the lines the pull request changed, as annotations and in the job summary, failing on errors (fail-on sets the level, only-changed-lines: false reports every line). It runs in merge queues too, and each release of the action runs the CLI of the same version. The new docs page "Make it a required check on agent pull requests" has the workflow, how to require the check, and what to know for pull requests from Copilot, Codex and Claude.

• #71 d085878 Thanks @dgesteves! - check --format sarif prints a SARIF 2.1.0 log for GitHub code scanning (github/codeql-action/upload-sarif) and other SARIF tools: each rule with its description and a link to its docs, and each finding with its level, message, location and a stable fingerprint. Paths are relative to the repository root, wherever check runs from, and baseline findings are left out.

Patch Changes

• #78 9717f7d Thanks @dgesteves! - check --format github names files relative to the repository root, so annotations land on the right files when check runs in a folder of the repository (working-directory: apps/web, or cd apps/web && npx onsystem check); before, the paths were relative to that folder and GitHub could not place them. The root is GITHUB_WORKSPACE or the git top-level, whichever is the innermost folder holding the file, so a repository checked out in a folder of the workspace (actions/checkout with path:) works too; a file under neither keeps its path relative to the working directory. --format sarif, which already used the git top-level, now falls back to GITHUB_WORKSPACE where git is missing or refuses the checkout, and so does the GitHub Action's annotation path outside pull requests.

• #69 8151e7a Thanks @dgesteves! - Every MCP tool now states all four annotation hints, adding destructiveHint: false to readOnlyHint, idempotentHint and openWorldHint. The spec defaults a missing destructiveHint to true, and some clients and directories reject tools that leave a hint out.

• #77 6bcb5a5 Thanks @dgesteves! - The MCP server finds the project when a client starts it outside one and reports no roots, as some Agent Plugins hosts and plugin setups do (the server runs in the home or the plugin's folder). Each tool call's project is then found from the absolute path it names, path or, for check_ui with code, filename: the nearest folder at or above it with a package.json, components.json or config, or the monorepo root above that (never the home folder or the filesystem root), served as if the server had been started there and kept for later calls. Since a prompt can choose that path, such a project loads a JSON config only: a JavaScript or TypeScript config there (or in a project of a monorepo root found that way) is not run, and the tools return an error that names it and says to start the server in the project or use onsystem.config.json. A call without a path answers from the project found so far, when there is one; before then, the tools return an error that says to pass the absolute path of the file being edited. Before, the server served the folder it was started in, and found no design system. A server started in a project, with --root or a config, or given roots by the client works as before. check_ui also applies the config's overrides to a filename given as an absolute path in the project.

• #76 29f65dc Thanks @dgesteves! - The website moved to onsystem.vercel.app. Messages, rule links in SARIF and ESLint output, the README, the plugin manifests and the MCP Registry entry now point there. The old address redirects, so links in earlier versions keep working.