Gryz Skill Library

Named, versioned instructions your agent loads by name — writing style, review checklists, PR conventions, and more. Connect once, your agent writes like Gryz; upgrade to make it write like you.

Gryz skills are SKILL.md body + text references — script bundles are coming. Every plan can use these skills; Pro can fork and edit them, and Pro Plus can create your own from scratch.

• Clear writingwriting

  Edit text for plain, direct language: cut hedging words ("perhaps", "in order to", "it should be noted that"), shorten sentences, prefer active voice and concrete nouns over abstractions. Use when the user asks to "tighten this up", "make this clearer", "cut the fluff", or pastes a draft blog post, email, or announcement for a plain-language pass. Do NOT use for legal, medical, or technical reference text where precise qualifying language is load-bearing — cutting a hedge there can change the meaning, not just the style.

  v1 · authored by Gryz

• Code reviewengineering

  Review a code diff or pull request for minimal blast radius, scope discipline, security-sensitive domains (auth, billing, admin, secrets), and test coverage on new logic. Use when the user asks to "review this PR/diff", "does this change look safe to merge", or pastes a patch for feedback before merging. Do NOT use for reviewing prose, product specs, or non-code documents — use editorial-review for those.

  v1 · authored by Gryz

• Editorial reviewwriting

  Review a draft document for structure, clarity, completeness, and audience fit, then return prioritized findings the author can act on — not a line-by-line copy edit. Use when the user asks to "review this draft", "what's missing from this doc", or "is this ready to publish/send". Do NOT use for a quick grammar/typo pass on a short piece of text — use clear-writing for that; this skill is for a whole document's structure and argument.

  v1 · authored by Gryz

• PR & commit conventionsengineering

  Write commit messages and PR descriptions that follow a consistent team convention: imperative subject under 72 characters, explain what changed and why (not how), branch-naming prefixes (feature/fix/chore), and one logical change per PR. Use when the user asks to "write a commit message for this", "draft a PR description", or is about to open a PR. Do NOT use to decide WHETHER a change should be split into multiple PRs on code-quality grounds — use code-review for that judgment.

  v1 · authored by Gryz

• Publish to Gryzwriting

  Draft the requested content, then publish it as a Gryz document or note using publish_document or create_note, and return the resulting link. Use when the user asks to "publish this to Gryz", "post this as a doc", or "save this and give me a link to share". Do NOT use when the user only wants the draft and has not asked for it to be published or saved anywhere — drafting and publishing are two separate steps; only take the second if asked.

  v1 · authored by Gryz

• Structured doc draftingwriting

  Take a rough request and draft it into a named document structure — a PRD, RFC, or changelog — filling in each section rather than writing one long undifferentiated block of prose. Use when the user asks to "draft a PRD for X", "write up an RFC for this", or "turn these notes into a proper doc". Do NOT use for a single paragraph, email, or short note — use clear-writing or just write it directly; this skill is for multi-section structured documents.

  v1 · authored by Gryz