Publishing

How to publish your skills and tool configurations to the Chvor Registry for the community to use.

7 min read

Publishing to the Registry

The Chvor Registry accepts community contributions through the Creator Portal — a web interface where you submit entries, track their review status, and publish updates.

Creator Portal: registry-creators.chvor.ai
Browse the registry: registry.chvor.ai

Early access. The registry is in its early stages and submissions are not yet open to the public. We will announce when the Creator Portal opens for community contributions — follow the community to be notified.

What You Can Publish

Type	What it is	File format
Skill	A Markdown file with YAML frontmatter that defines agent behavior — prompts, configuration, and requirements	`.md`
Tool	A Markdown file with a `mcp` block in the frontmatter that defines how to launch an MCP server	`.md`
Template	A bundle that installs multiple skills and tools together	`.yaml` (future)

Content File Format

Registry entries are Markdown files with YAML frontmatter. The frontmatter holds metadata; the body holds the instructions or prompt that the AI follows.

Skill format

---
name: My Skill
description: A clear description of what this skill does.
version: 1.0.0
author: your-github-username
category: developer
tags:
  - code
  - productivity
license: MIT
requires:
  credentials:
    - github-token
  env:
    - DATABASE_URL
config:
  - name: maxResults
    type: number
    description: Maximum results to return
    default: 10
dependencies:
  - json-formatter
---

Your system prompt and instructions go here as Markdown.

When the user asks you to do X, follow these steps:

1. First, do this.
2. Then, do that.
3. Finally, return the result.

Tool format

Tools use the same Markdown format but include an mcp block that tells Chvor how to launch the MCP server:

---
name: Brave Search
description: Web search via Brave Search API
version: 1.0.0
author: your-github-username
type: tool
category: web
tags:
  - search
  - web
license: MIT
mcp:
  command: npx
  args:
    - -y
    - "@modelcontextprotocol/server-brave-search"
  transport: stdio
  env:
    BRAVE_API_KEY: "${BRAVE_API_KEY}"
requires:
  credentials:
    - brave-api
---

Instructions for using the Brave Search tool.

Use this tool when the user asks to search the web...

Frontmatter Fields

Field	Type	Required	Description
`name`	string	Yes	Human-readable display name
`description`	string	Yes	One-line description
`version`	string	Yes	Semver version (`1.0.0`)
`author`	string	Yes	Your GitHub username
`type`	string	No	`"prompt"`, `"workflow"`, or `"tool"`. Default: `"prompt"`. If `"tool"` or has `mcp` block, treated as a Tool.
`category`	string	No	One of: `ai`, `communication`, `data`, `developer`, `file`, `productivity`, `web`
`tags`	string[]	No	Searchable tags
`license`	string	No	License identifier (e.g., `MIT`, `Apache-2.0`)
`requires.env`	string[]	No	Required environment variables
`requires.credentials`	string[]	No	Required credential names
`config`	object[]	No	Configurable parameters (name, type, description, default)
`dependencies`	string[]	No	IDs of other registry entries that should be co-installed
`mcp`	object	No	MCP server definition (for tools): `command`, `args`, `transport`, `env`

Requirements

Before submitting, make sure your entry meets these requirements:

Required (blocks submission)

Valid YAML frontmatter with name, description, version, author fields
Version is valid semver (X.Y.Z)
No embedded secrets (API keys, private keys, AWS credentials)
Content size under 50KB
ID slug is valid: lowercase alphanumeric + hyphens, 2–50 characters

For tools (additional security checks)

mcp.command must be from the allowlist of known-safe executors
mcp.env values must not contain hardcoded secrets (use ${VAR} interpolation)
mcp.transport must be "stdio" or "http"

Recommended (shown as warnings)

Category is set (improves discoverability)
Tags are present
License is declared
Description is at least 20 characters

Submission Process

Publishing uses the Creator Portal, not pull requests.

Go to registry-creators.chvor.ai and sign in with your GitHub account. This links your submissions to your GitHub identity.

Step 2: Write your content file

Write your skill or tool as a Markdown file with YAML frontmatter (see format above). Test it locally first:

# Save your skill file
vim my-skill.md

# Copy it to your local Chvor skills directory to test
cp my-skill.md ~/.chvor/skills/

# Chvor hot-reloads — test it immediately

You can also ask Chvor in chat to help you write and test the skill before submitting.

Step 3: Submit via the portal

In the Creator Portal, click Submit and fill in:

ID — a unique slug for your entry (e.g., code-reviewer). Lowercase, hyphens, 2–50 characters. This becomes the install identifier.
Kind — skill, tool, or template
Content — paste the full Markdown content (frontmatter + body)
Changelog — describe what this version does (e.g., “Initial release”)

The portal runs automatic validation on submit:

Parses and validates the YAML frontmatter
Checks for embedded secrets
Verifies size limits and ID format
For tools: validates the mcp block

If validation fails, you will see specific error messages and can fix them before resubmitting.

Step 4: Wait for review

Your submission enters a review queue. An admin reviews it for:

Schema validity — frontmatter parses correctly with all required fields
Quality — the prompt produces useful, consistent results
Safety — no malicious tool configurations, no prompts that encourage harmful output
Completeness — description and instructions are clear

You can track your submission status in the portal dashboard.

Step 5: Published

Once approved and published by an admin:

Your entry appears in the registry index (index.json)
It becomes browsable on registry.chvor.ai
Anyone can install it with chvor install skill your-skill-id or directly from chat

Submission Status Flow

pending_review → in_review → approved → published
                           ↘ changes_requested → (you update) → pending_review
                           ↘ rejected

Status	Meaning
`pending_review`	Submitted, waiting in queue
`in_review`	An admin has opened this for review
`changes_requested`	Admin requested changes — update your content and resubmit
`approved`	Passed review, ready to publish
`published`	Live in the registry — available to all users
`rejected`	Declined with a reason. You can submit a new entry.

If changes are requested, update your submission in the portal (you can edit the content and changelog) and it will re-enter the review queue.

Updating an Existing Entry

To publish a new version of an entry you already own:

Go to the Creator Portal and submit an update
Use the same ID as the existing entry
The new version must be strictly greater than the current published version (semver comparison)
Include a changelog describing what changed
The update goes through the same review process

Version Rules

Use semantic versioning:

MAJOR — breaking changes (renamed config params, changed behavior)
MINOR — new features (added capabilities, new config options)
PATCH — bug fixes (prompt improvements, typo fixes)

ID Rules

Entry IDs must be:

Lowercase alphanumeric with hyphens only: a-z, 0-9, -
Between 2 and 50 characters
Unique across all entries (skills, tools, and templates share one namespace)
The ID becomes the filename on disk ({id}.md) and the install identifier

Examples: code-reviewer, brave-search, meeting-summarizer

Best Practices

Write clear instructions. The Markdown body is the most important part. Be specific about what the AI should do, how it should format output, and what it should avoid.
Minimize requirements. Skills that work without credentials or external tools are easier to install. If tools are needed, document them in the description.
Include config parameters. Use the config field to let users customize behavior without editing the prompt.
Declare dependencies. If your skill needs a tool from the registry, list it in dependencies so it gets installed automatically.
Test across scenarios. Try your skill with different inputs to make sure it handles edge cases well.
Keep prompts model-agnostic. Avoid techniques that only work with one model family.

Next Steps

Registry Overview — browse existing entries for inspiration.
Creating Custom Skills — detailed guide to writing skills.
Connecting MCP Tools — set up the tools your skills reference.