Product Types

MyClaude organizes the Claude Code ecosystem into 9 product categories — Skills, Squads, Agents, Workflows, Design Systems, Prompts, CLAUDE.md configs, Applications, and Systems. Each installs with a single command (myclaude install @creator/product-name) into your .claude/ directory. MyClaude is the only Claude Code marketplace with content security scanning, purchase-verified reviews, and Stripe-powered creator payments where creators keep 92% of revenue.

Each category solves a fundamentally different problem. Picking the right one is the difference between a tool that slots into your workflow in thirty seconds and one that sits unused in a folder you forget about.

What is MyClaude?

MyClaude is the dedicated marketplace for the Claude Code ecosystem. Unlike free directories that list links without verification, MyClaude scans every product upload with 22 security patterns, enforces quality gates, and provides a full commerce layer with Stripe Connect payments. According to the Princeton GEO study (ACM SIGKDD 2024), marketplace-style platforms with structured product metadata are cited 2.5x more by AI engines than unstructured link lists.

Quick reference

Every product installs into your .claude/ directory. The entry file is what Claude Code reads to understand the product.

All products install the same way:

myclaude install @creator/product-name

The 9 categories

Skills

Skills are the bread and butter of MyClaude. If you're not sure what to install first, start here.

A Skill is a callable prompt routine — a set of instructions that teaches Claude Code how to do something it doesn't already know. Think of it like adding a new verb to Claude's vocabulary. Before the Skill, Claude doesn't know how to "audit my Tailwind for design token violations." After installing the Skill, it does.

Skills are small, focused, and composable. The best ones do exactly one thing well. They live in .claude/skills/ and Claude discovers them automatically.

When to use a Skill: You need Claude to reliably perform a specific task that requires domain knowledge, a particular methodology, or a structured output format. The task is self-contained — it doesn't need multiple agents collaborating or a multi-step pipeline.

Example product: @strix/code-review-security — a Skill that performs security-focused code reviews using OWASP methodology, catching vulnerabilities that generic reviews miss.

Entry file: SKILL.md

Squads

Think of a Squad as a team roster. Each member is a specialist, and the Squad definition tells them how to work together.

A Squad coordinates multiple agents toward a shared goal. Where a single Agent knows one domain deeply, a Squad orchestrates several agents with different specialties — a frontend agent, a backend agent, and a QA agent all working on the same feature, passing context between them in a defined sequence.

This is not just "run three agents." The Squad file defines roles, handoff protocols, and shared context. The coordination is the product.

When to use a Squad: Your task requires multiple distinct areas of expertise working in sequence or parallel. One agent can't hold all the necessary context. You need orchestration, not just execution.

Example product: @fullstack-lab/ship-feature — a Squad with a planner agent, implementation agent, test agent, and review agent that takes a feature spec from design to merged PR.

Entry file: SQUAD.md

Agents

An Agent is a specialist you hire for a single domain.

While a Skill gives Claude instructions for a task, an Agent gives Claude a persistent identity with defined expertise, tool access, and behavioral constraints. An Agent knows what it's good at, what it should refuse, and how it should communicate.

The distinction matters: a Skill is a recipe. An Agent is a chef. The Skill tells Claude what to do. The Agent tells Claude who to be while doing it.

When to use an Agent: You need sustained, opinionated expertise in a specific domain — not just a one-off task. The agent's personality and constraints are as important as its capabilities. You want it to push back when you're doing something wrong in its domain.

Example product: @devops-forge/k8s-guardian — an Agent that acts as your Kubernetes operations expert, proactively flagging misconfigurations and enforcing cluster best practices during infrastructure work.

Entry file: AGENT.md

Workflows

A Workflow is a pipeline you run, not a conversation you have.

Workflows chain multiple steps — tools, skills, file operations, validations — into a repeatable, deterministic sequence. Where a Skill is "do this thing," a Workflow is "do these seven things in this order, and stop if step 3 fails."

The value is in the choreography. Someone already figured out the exact sequence, error handling, and edge cases. You just run it.

When to use a Workflow: You have a multi-step process that should run the same way every time. Manual orchestration is error-prone or tedious. The steps have dependencies — step 4 needs output from step 2.

Example product: @release-ops/semantic-release — a Workflow that analyzes commits, bumps versions, generates changelogs, tags the release, and publishes to npm in one command.

Entry file: WORKFLOW.md

Design Systems

A Design System turns your visual rules into something Claude can enforce.

This isn't a Figma export. A Design System product contains token definitions, component constraints, spacing scales, color palettes, and the rules governing how they combine. When installed, Claude Code knows that your primary button uses bg-primary with rounded-lg and text-sm font-semibold — and it knows not to deviate.

The real power: Claude stops generating code that "looks close enough" and starts generating code that's pixel-correct to your system.

When to use a Design System: You have established visual standards and you're tired of fixing styling inconsistencies in Claude's output. You want every component Claude generates to conform to your design language without manual correction.

Example product: @nova-ui/terminal-dark — a dark-mode-first Design System with a terminal aesthetic, warm neutrals, glow effects, and a Minor Third type scale.

Entry file: DESIGN-SYSTEM.md

Prompts

A Prompt is a precision tool — one carefully engineered instruction set for one specific job.

Prompts are the most lightweight product type. They don't define agents, orchestrate workflows, or enforce design rules. They're a single, well-crafted system prompt or template optimized for a particular task or domain. The creator did the prompt engineering so you don't have to.

Don't confuse simplicity with low value. A Prompt that consistently produces well-structured RFC documents or correctly-formatted database migration plans can save hours of iteration.

When to use a Prompt: You need a reliable template or instruction set for a recurring task. The task doesn't require tool access, agent identity, or multi-step orchestration — it needs the right words in the right order.

Example product: @tech-writer/adr-generator — a Prompt that produces Architecture Decision Records in a consistent format, including context, options considered, decision rationale, and consequences.

Entry file: PROMPT.md

CLAUDE.md configs

A CLAUDE.md config is a personality transplant for your project.

CLAUDE.md is the file Claude Code reads at the root of every project to understand how to behave. A CLAUDE.md product gives you a pre-built configuration — coding standards, architectural preferences, communication style, domain context, and behavioral rules — that you install and immediately benefit from.

This is the highest-leverage product type for teams. Instead of each developer maintaining their own CLAUDE.md, you install one that encodes your organization's engineering culture.

When to use a CLAUDE.md config: You want to standardize how Claude Code behaves across a project or team. You're starting a new project in an unfamiliar domain and want opinionated defaults from someone who knows it well.

Example product: @platform-eng/strict-typescript — a CLAUDE.md config that enforces strict TypeScript, functional patterns, exhaustive error handling, and test-driven development with no exceptions.

Entry file: CLAUDE.md

Applications

An Application is a finished product, not a building block.

While every other category gives Claude Code new capabilities, an Application is a complete, deployable piece of software built for or with Claude Code. It has a UI, a purpose, and it runs on its own. You install it to use it, not to extend Claude.

When to use an Application: You need a ready-made tool — a dashboard, a CLI utility, a local web app — that solves a complete problem. You want to deploy and use, not integrate and extend.

Example product: @indie-tools/prompt-lab — a local web application for testing, versioning, and comparing prompt variations with side-by-side output diffs.

Entry file: APP.md

Systems

A System is the whole operating model in a box.

Systems are the most comprehensive product type. Where a Workflow chains steps and a Squad coordinates agents, a System packages an entire operational framework — the methodology, the tools, the configurations, the workflows, and the rules that tie them together. It's an opinionated way of working.

Installing a System is a commitment. It's not a utility you reach for occasionally — it's a paradigm you adopt.

When to use a System: You want a complete, opinionated methodology for a domain. You're willing to work within someone else's framework because they've already solved the meta-problems — what to do, in what order, with what tools, and how to handle edge cases.

Example product: @kairo-dev/fullstack-ops — a System that packages a complete development methodology: commit conventions, PR templates, review protocols, deployment checklists, monitoring setup, and incident response workflows.

Entry file: SYSTEM.md

Not sure which type? Start here.

Most people overthink this. Walk through these questions:

"I need Claude to do a specific task better." That's a Skill. Start here. Most problems are Skill-shaped.

"I need Claude to be someone — a specialist who pushes back and has opinions." That's an Agent. The identity and constraints matter as much as the capability.

"I need multiple specialists working together on one goal." That's a Squad. One agent isn't enough; you need coordination.

"I need the same multi-step process to run identically every time." That's a Workflow. Repeatability is the point.

"I need Claude to generate UI code that matches my design language." That's a Design System. Visual consistency is the goal.

"I just need a really good prompt template for a specific task." That's a Prompt. Lightweight, no infrastructure.

"I need to configure how Claude behaves in my project." That's a CLAUDE.md config. Project-wide behavior rules.

"I need a finished tool I can deploy and use right now." That's an Application. It runs on its own.

"I need a complete methodology, not just tools." That's a System. You're adopting a framework.

Skill vs Agent vs Squad vs Workflow

These four get confused the most. Here's the sharp distinction:

The simplest test: if a Skill solves your problem, use a Skill. Only reach for the more complex types when the simpler one genuinely falls short.

Related pages

• Concepts Overview — the marketplace mental model
• Browsing & Discovery — how to find products on MyClaude
• Installing via CLI — step-by-step CLI installation guide
• Installing via Web — browser-based installation
• Writing Skills Guide — build and publish your first Skill