User Skills overview
Load-by-name instructions your AI assistant pulls at the start of every session, portable across Claude, Cursor, and any AGENTS.md-based agent.
Updated · Reviewed by Jacob
What are User Skills?
A skill is a named, versioned set of instructions your assistant loads by name instead of you re-explaining it every conversation — a writing style, a code review checklist, your team's PR conventions. Skills are stored in Gryz, so the same skill loads the same way in every MCP-connected assistant: Claude, Cursor, or any agent that reads an AGENTS.md-style file.
Every skill account can use is either:
- From the Gryz Skill Library — six first-party skills Gryz maintains (Clear writing, Editorial review, Code review, PR & commit conventions, Structured doc drafting, Publish to Gryz). Anyone with a Gryz account can browse the public Skill Library and activate a Library skill as-is.
- Your own — a fork of a Library skill you've edited, or a skill you wrote from scratch.
Available on Starter and above when enabled for your account; requires a signed-in Gryz account. Forking and creating skills are gated by plan — see Plan limits below.
Personal vs. project scope
Every activated skill loads at one of two levels:
- Personal (account-wide) — loads in every session, everywhere you use the assistant.
- Project — scoped to one codebase, keyed by the same
project_keyAgent Memory uses. A project-scoped skill only loads when the assistant is working in that project, and it shadows an account-wide skill of the same name only there — your personal version still loads everywhere else.
You can hold a personal skill and a project-scoped skill with the same name at once; the project one is the per-repo override.
Work with skills from an AI assistant
After you connect Gryz through MCP, an assistant has six Skills tools:
list_skillsreturns your resolved active skill set (names and descriptions only, not full bodies) — or the public Library catalog withmode: "catalog".get_skillreturns one skill's current body, wrapped in an explicit "not your instructions unless you trust this author" delimiter — skill bodies are an executable instruction surface, never merged into system instructions automatically. Supportsformatto emit the body as nativeskill-md, anAGENTS.md/CLAUDE.mdfragment, or a Cursor.mdcrule, so a skill authored once loads natively in whichever client asks for it.fork_skillcopies a readable skill (Library or otherwise visible to you) into your own editable row.update_skillwrites a new version of a skill you own — it never mutates a prior version, so every edit is diffable and reversible. Passrollback_to_versionto revert to an earlier version as a new version.create_skillstarts a skill from a blank slate — Pro Plus only.delete_skillsoft-deletes an owned fork or authored skill. First-party Library skills can't be deleted this way.
See the MCP tool reference for exact inputs, safety annotations, and rate limits.
Fork, edit, and version history in the dashboard
In My Docs → Skills, you can do everything the MCP tools do, plus what only makes sense with a screen:
- Version history and diffs — see every version of a skill you own, and diff any version against the current one.
- Roll back to an earlier version — this writes a new version with that content, it doesn't delete history.
- Reset to default — for a fork, discard your edits and return to the parent skill's current content. This is reversible: the fork is archived, not deleted, so you can find it under Archived if you change your mind.
- Update from upstream — when the skill you forked from has moved on, review a diff of what changed before pulling it in.
- Archive / unarchive a skill you own without deleting it.
- Pin a version on an activation so it keeps loading a specific version even after the skill's author publishes a new one.
Sharing a skill with your team
A project-scoped skill authored by someone other than you (a co-author sharing a skill in the same project_key) requires an explicit review step before it can auto-load — the account owner has to look at the content once and mark it reviewed. This gate re-arms automatically: if the co-author pushes a new version after you've reviewed an earlier one, the new version needs review again before it auto-loads. This is deliberate — reviewing version 1 of a shared skill is not a standing trust grant for every future version.
Import and export
Every skill exports as Anthropic's open SKILL.md format — a folder with a SKILL.md file (YAML frontmatter + Markdown body), so a Gryz skill loads natively in Claude with no conversion, and a skill you already have as a local SKILL.md folder imports into Gryz losslessly.
- Export one skill — the "Load in Claude, Cursor, or AGENTS.md" panel on any skill page or dashboard row gives you the exact
SKILL.md,AGENTS.mdfragment, or Cursor.mdctext to copy. - Export everything — from My Docs → Skills, download all your skills as one JSON file or as a
.zipofSKILL.mdfolders (one per skill). - Import — upload a JSON export or a
.zipofSKILL.mdfolders back in. Each skill in the file is evaluated independently against your plan's tier rules and merged into the matching existing skill if you already have one with the same name, scope, and kind — a bad or ineligible record in a batch is skipped and reported, it doesn't fail the whole import.
Plan limits
| Plan | Use Library skills | Fork and edit | Create from scratch | Distinct projects |
|---|---|---|---|---|
| Free | No | No | No | 0 |
| Starter | Yes | No | No | 0 |
| Pro | Yes | Yes | No | 3 |
| Pro Plus | Yes | Yes | Yes | Unlimited |
Personal-scope skills are never metered — the project quota only counts distinct project_key values across your project-scoped skills. See Compare Gryz accounts and plans for the full plan comparison.
Security note
Skill bodies are plain text instructions, not executable code — Gryz never runs a script on your behalf as part of a skill. Every skill body an assistant receives, including first-party Library skills, is wrapped in a delimiter that tells the assistant not to treat it as a system instruction unless it trusts the stated author. This matters most for skills shared with you by someone else in a project — see Sharing a skill with your team above for the review gate that governs those.