Marketplace Publishing — Sharing Skills and Agents with the Community

About 10 minutes

Those who understand all harness components (CLAUDE.md, Settings, Rules, Commands, Skills, Agents, Hooks, Plugins, Memory, Testing) and want to share self-made skills and agents with the community.

The structure of `shared/agents/` and `shared/skills/`, and basics of repository management on GitHub

The harness components (skills, agents, commands) can be shared with the community through GitHub. This page covers through hands-on exercises: package structure requirements, README templates, the publishing flow, and installation procedures.

What Is the Marketplace?

The Marketplace is a mechanism for sharing Claude Code skills, agents, and commands with the community. Currently, public repositories on GitHub are the main distribution channel. In the future, the development of official registration and search functionality is planned.

Using the Marketplace makes the following possible.

Skills and agents you have built can be reused by other teams and individuals
Skills published by the community can be added to your harness
Harness design patterns can be referenced as concrete code

What Can Be Published

Type	Description	File Path
Skills	Claude behavior definitions via SKILL.md	`skills/<name>/SKILL.md`
Agents	Sub-agent specs	`agents/<name>.md`
Commands	Slash command definitions	`commands/<name>.md`
Entire harness	A package containing all of the above	Entire harness repository

The granularity can be chosen according to the use case, from sharing individual skills to harness-wide templates. For a first publication, it is recommended to start with one skill or one agent.

How It Works: Package Structure Requirements

The recommended directory structure for a publishing repository is as follows.

my-claude-skill/
├── README.md          # Required: skill description, usage, and installation method
├── SKILL.md           # For standalone skill publishing, place at repository root
├── skills/            # When bundling multiple skills
│   └── my-skill/
│       └── SKILL.md
├── agents/            # Agent files
│   └── my-agent.md
├── commands/          # Command files
│   └── my-command.md
└── package.json       # Version management (optional)

The only required file is README.md. As long as there are skill, agent, and command files, add directories as needed for the purpose. package.json can be used for version management but is not required.

Required Items in README.md

README.md is the only document from which users can understand “what this skill does” and “how to install it.” Write using the following template.

# Skill Name

## Overview
What this skill does (2–3 sentences). Clearly state the target audience and use cases.

## Installation

1. Clone this repository
   ```bash
   git clone https://github.com/<your-name>/<repo-name>

Copy the skill file to shared/skills/<name>/

cp <repo-name>/SKILL.md shared/skills/<name>/SKILL.md

Run npm run harness:sync

npm run harness:sync && npm run harness:check

Usage

When you type “do X” in Claude Code, this skill is automatically triggered.

Configuration

[List any required environment variables and prerequisites here]

Verified Environment

Claude Code: 1.x or later
OS: macOS / Linux

License

MIT


---

## Best Practices

### Write the README from the User's Perspective

Show installation instructions one command at a time, at a granularity where someone using it for the first time won't be confused. If harness knowledge is required, such as "proceeding with the assumption that a `shared/` directory exists," explicitly state it as a prerequisite.

### Manage Versions with Git Tags

```bash
git tag v1.0.0
git push origin v1.0.0

By cutting tags, users can reference and pin specific versions. Recording the installed version in README.md makes the diff clear when updating later.

Never Include Secrets

Do not write API keys, tokens, or personal information in SKILL.md, agents/, or commands/. Design them to be passed as environment variables from outside, and only list the required environment variable names in the README.

Explicitly State the License

Place a LICENSE file at the repository root and list the license type in the README. Skills without a clear license cannot be used confidently by teams or companies. MIT or Apache-2.0 are common choices.

Start Simple

Start your first publication with one skill or one agent. Complex packages have longer READMEs and become harder to install. Making it in a state where someone can use it is the top priority.

Hands-on Exercise

Step 1: Create a Directory for Publishing

Package the security-review agent built in this repository for publishing. Create a publishing directory at the same level as the project root.

mkdir -p ../my-security-review-agent/agents

✅ Verify: Run ls ../my-security-review-agent/ to confirm the agents/ directory is displayed.

Step 2: Copy the Agent File and Create the README

Copy shared/agents/security-review.md to the publishing directory.

cp shared/agents/security-review.md ../my-security-review-agent/agents/

Then, create ../my-security-review-agent/README.md using the template above as a reference. Fill in the overview, installation instructions, usage, and license sections.

✅ Verify: Run ls ../my-security-review-agent/ to confirm that both agents/ and README.md are displayed, and the packaging preparations are complete.

Step 3: Manually Install in Another Project and Verify Operation

In another project (or a temporary directory for testing), install the created package and verify its operation.

# Run at the root of the test destination project
cp path/to/my-security-review-agent/agents/security-review.md ./shared/agents/
npm run harness:sync && npm run harness:check

Launch Claude Code and confirm that the security-review agent is recognized.

✅ Verify: If harness:check passed is displayed and the agent can be referenced in Claude Code, the operational verification is complete.

Step 4: Publish on GitHub

After completing the operational verification, publish it as a public repository on GitHub.

cd ../my-security-review-agent
git init
git add .
git commit -m "Initial release: security-review agent"
git remote add origin https://github.com/<your-name>/claude-security-review-agent
git push -u origin main
git tag v1.0.0
git push origin v1.0.0

✅ Verify: If agents/security-review.md and README.md are displayed on the GitHub repository page, and the v1.0.0 tag is attached, the publication is complete.

Summary

This page covered the procedures for sharing harness components of Claude Code with the community. The key points of publishing are summarized below.

The minimum unit of publication is README.md and any one of a skill, agent, or command file
Never include secrets, explicitly state the license, and manage versions with tags are the basic principles of publication
Write the README from the user’s perspective and show commands one line at a time
Start the first publication with one skill, prioritizing simplicity

Overall Summary of the Harness Building Section

Through this section “Building a Claude Code Harness,” you learned the entire process of harness design, implementation, validation, and sharing through 11 topics.

Topic	What I Learned
Overview	The three-layer structure (CLAUDE.md, shared/, .claude/) and the purpose of the harness
CLAUDE.md Hierarchy Design	Entry point design and how to declare Non-Negotiable Rules
Settings JSON Design	Configuration of permissions, hooks, and MCP, and safe allow list management
Rules File Design	Declaration of safety and quality rules and naming conventions
Custom Commands Deep Dive	Design patterns for reusable commands
Skills Design Patterns	SKILL.md format and the one-skill-one-responsibility principle
Agents Spec Design	Defining sub-agent roles, constraints, and tool restrictions
Hooks Implementation	Automation and validation using lifecycle hooks
MCP Plugins Integration	Configuration of local and remote MCP servers and credential management
Memory System Design	Design guidelines for 4 memory types and the MEMORY.md index
Harness Testing and Validation	Automation of drift detection and CI validation
Marketplace Publishing (this page)	Packaging skills and agents and publishing on GitHub

A harness is not something you configure once and you’re done — it is a mechanism to grow alongside the project. By making regular harness:check runs, rule reviews, and skill updates a habit, Claude Code continues to follow along with project changes.

Next Steps

Check the official Claude Code documentation for the latest ecosystem information
Share the skills you have created with the Claude Code community (Discord, etc.) to get feedback
Roll out the harness design to other team members and establish a collaborative maintenance structure

Frequently Asked Questions

Q: Does a Marketplace officially exist at this point?

A: As of May 2026, an official centralized marketplace (with review and search functionality) has not been established. Currently, public repositories on GitHub are the main distribution channel. Check the official Claude Code documentation and Discord channels for the latest information.

Q: How can I safely use a skill published by someone else?

A: Always check the contents of SKILL.md before installing. Since skill files function as prompts to Claude, they may contain malicious instructions. Use repositories from trusted publishers, or scrutinize the contents with the same approach as a code review before installing. After installation, confirm the integrity of the configuration with harness:check.

Q: When I update a published skill, how can users get the latest version?

A: If they have cloned the Git repository, they can get the latest version with git pull and then re-execute the installation procedure. If version tags have been cut, a specific version can be specified with git checkout v2.0.0. Listing the update contents in the change history section of the README makes it easier for users to judge the impact of the update.

Q: Are there any risks in publishing the entire harness?

A: Always check that secrets in settings.json, personal memory files, and project-specific rules are not included. Set .gitignore to exclude files that should be excluded, and confirm the publishing targets with git diff before pushing. If secrets are included, GitHub’s secret scanning feature may detect them, but prior checking is the best countermeasure.

See the references for the external specifications and background sources used on this page.[1][2]

References

Anthropic, Claude Code documentation
Anthropic, Claude API documentation

Quiz

Codex Features & Product Lineup

Harness Testing and Validation — Drift Detection and CI Validation