Skip to content
Gryz Docs
User Skills

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_key Agent 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_skills returns your resolved active skill set (names and descriptions only, not full bodies) — or the public Library catalog with mode: "catalog".
  • get_skill returns 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. Supports format to emit the body as native skill-md, an AGENTS.md/CLAUDE.md fragment, or a Cursor .mdc rule, so a skill authored once loads natively in whichever client asks for it.
  • fork_skill copies a readable skill (Library or otherwise visible to you) into your own editable row.
  • update_skill writes a new version of a skill you own — it never mutates a prior version, so every edit is diffable and reversible. Pass rollback_to_version to revert to an earlier version as a new version.
  • create_skill starts a skill from a blank slate — Pro Plus only.
  • delete_skill soft-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.md fragment, or Cursor .mdc text to copy.
  • Export everything — from My Docs → Skills, download all your skills as one JSON file or as a .zip of SKILL.md folders (one per skill).
  • Import — upload a JSON export or a .zip of SKILL.md folders 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

PlanUse Library skillsFork and editCreate from scratchDistinct projects
FreeNoNoNo0
StarterYesNoNo0
ProYesYesNo3
Pro PlusYesYesYesUnlimited

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.

Was this page helpful?