Building Systems
Package a complete operational framework — your methodology, tools, and configurations wired together as a single install. Not one component. The whole way of working.
Package a complete operational framework — your methodology, tools, and configurations wired together as a single install. Not one component. The whole way of working.
Systems are the most ambitious product category on MyClaude. Where a Skill teaches Claude Code one technique, a System installs an entire operating model. A buyer doesn't get a better tool for one task — they get a transformed way of working across everything they do. A product development system. A research methodology. A startup operating framework. A content production machine.
If you've developed a way of working that's reproducible, teachable, and genuinely better than the default — a System is how you package and distribute it.
What is a System?
A System is a multi-file package installed into .claude/skills/. It typically combines a CLAUDE.md (behavioral configuration), skills (tactical capabilities), workflows (process automation), and documentation into a coherent whole.
| Concept | What it means for you |
|---|---|
| CLAUDE.md | The behavioral layer — how Claude thinks in this system |
| Skills | The tactical layer — what Claude can do in this system |
| Configs | The setup layer — tools, environment, preferences |
| Documentation | The understanding layer — why the system works the way it does |
vault.yaml | The manifest — name, price, version, metadata |
.claude/skills/ | Where it installs on the buyer's machine |
The difference between a System and a Skill: a Skill is one capability. A System is an integrated methodology where each component reinforces the others. Remove one piece and the whole is diminished. That interdependence is the System's value.
Who creates Systems?
You don't need to be a developer. You need to have developed a way of working worth replicating.
- Methodology creators — package proprietary frameworks: research protocols, decision systems, project management approaches
- Agency owners — distribute the operating model that makes their agency work
- Coaches and consultants — sell the complete system they teach clients, now installable
- Technical leads — package the engineering culture and standards of their team
- Domain experts — create field-specific operating systems for practitioners
- Productivity designers — build thinking environments optimized for specific types of work
If you've helped someone transform how they work — not just one task, but the whole practice — you have the material for a System.
Create your first System
Let's build a product development system. Concrete, complete, immediately operational.
Scaffold the project
$ myclaude init product-development-system --type systems
$ cd product-development-systemThe scaffold creates your directory structure and a starter vault.yaml. This is where you'll build the full framework.
Structure your System
A System is a directory, not a single file. Structure it to reflect the layers of your methodology:
product-development-system/
├── vault.yaml # MyClaude manifest
├── INSTALL.md # How to get started — read this first
├── SYSTEM.md # Overview of the methodology
├── .claude/
│ └── CLAUDE.md # Claude's behavioral configuration
├── skills/
│ ├── discovery.md # User research and problem definition
│ ├── prioritization.md # Feature scoring and sequencing
│ ├── spec-writing.md # Product spec generation
│ ├── user-story-mapping.md # Story map creation and refinement
│ └── retrospective.md # Sprint retrospective facilitation
├── workflows/
│ ├── sprint-planning.md # End-to-end sprint planning workflow
│ ├── product-review.md # Product review process
│ └── launch-checklist.md # Pre-launch verification
├── templates/
│ ├── prd-template.md # Product Requirements Document
│ ├── user-story.md # Standard user story format
│ └── decision-log.md # Decision tracking template
└── docs/
├── philosophy.md # Why this system works the way it does
└── customization.md # How to adapt it to your contextWrite the CLAUDE.md layer
This is the cognitive core — how Claude thinks while operating in your system:
# Product Development System — Claude Behavioral Configuration
You are operating as a product development partner within the Product
Development System. This is not generic project assistance. You follow
specific protocols, use consistent frameworks, and uphold the product
standards this system is built around.
## Core philosophy
**Outcomes over outputs.** Features are hypotheses. Every feature starts
with a problem statement and ends with a measurable outcome, not a
delivery date.
**User decisions, not assumption decisions.** When a decision lacks
user evidence, name that explicitly. Don't proceed as if assumptions
are validated until they are.
**Small loops, fast learning.** Prefer a working prototype in two days
over a complete specification in two weeks. Reality over theory.
## How you operate in this system
1. Every new feature request: ask for the problem statement first.
Never spec a feature until the problem is clearly articulated.
2. When writing PRDs: use the provided template (`templates/prd-template.md`)
every time, without exception.
3. When prioritizing: apply the RICE scoring framework (Reach × Impact
× Confidence ÷ Effort). Don't substitute personal judgment for the system.
4. When a decision is made: log it in `decision-log.md` with date, context,
options considered, and rationale.
## What you never do
- Never recommend building something without a defined success metric
- Never let "it's obvious" substitute for written requirements
- Never skip the retrospective workflow, even for small sprints
- Never present one option when tradeoffs exist — always show the alternatives
## Communication in this system
- Lead with the question, not the answer. ("What problem are we solving?"
before "Here's how we could solve it.")
- Use the system's vocabulary: "hypothesis," "signal," "validated,"
"assumption" — not generic product language
- Reference the appropriate skill or workflow by name when applying itWrite your skills
Each skill file encodes a specific capability. Keep them focused:
# skills/discovery.md
## User Discovery Protocol
Use this skill when starting any new feature or initiative that lacks
validated user evidence.
### When to invoke
- New feature requested without stated user problem
- Conflicting opinions about user needs
- Post-launch metrics suggest feature isn't working as expected
### Discovery questions (always in this order)
**1. Problem clarity**
- Who specifically is experiencing this problem?
- How do they currently solve it without this feature?
- How painful is that workaround — on a scale of "minor annoyance"
to "reason they might switch products"?
**2. Frequency and breadth**
- How often does this problem occur?
- What percentage of our users face this?
**3. Signal gathering**
- Where can we find real evidence? (Support tickets, user interviews,
analytics, NPS comments)
- What would it take to run a 30-minute discovery call?
### Outputs
- Problem statement (one sentence, user-centric)
- Evidence summary (what we know vs. what we're assuming)
- Confidence rating (low / medium / high) with justification
- Recommended next step (build, test, or learn more)Wire vault.yaml
name: product-development-system
version: 1.0.0
type: systems
title: "Product Development System — Outcomes-Driven Framework"
description: "A complete product development operating model. CLAUDE.md configuration, discovery and prioritization skills, sprint workflows, PRD templates, and decision logging — all wired together as one install."
price: 79.99
tags:
- product-management
- methodology
- discovery
- prioritization
- sprint
- frameworksTest locally
Install your System and run through a complete product development cycle:
$ mkdir -p .claude/skills/product-development-system
$ cp -r . .claude/skills/product-development-system/Start a new Claude Code session. Ask Claude to help you spec a new feature. Does it follow the discovery protocol? Does it ask for the problem statement first? Does it reference the correct skill files? If the behavior feels consistent and principled — your System is working.
Publish
$ myclaude validate
$ myclaude publishYour System is now live on MyClaude.
What makes a great System
The difference between a System that transforms how people work and one that creates confusion:
| Mediocre | Great |
|---|---|
| A collection of files with no clear integration | Every file references and reinforces the others |
| CLAUDE.md that says "be helpful" | Specific behavioral rules with explicit constraints |
| Skills that could work in any context | Skills calibrated to the methodology's vocabulary |
| No philosophy documentation | Clear explanation of why the system works this way |
| Works for the creator, mysteriously | Works for anyone who installs it |
| No onboarding path | INSTALL.md that tells buyers where to start |
Systems succeed through coherence. Each layer — CLAUDE.md, skills, workflows, templates — should feel like it comes from the same school of thought. When a buyer works with your System, they should feel a consistent philosophy in every interaction, not a collection of loosely related files.
Advanced: Composable Systems
Design your System so its layers can be adopted progressively. Not everyone will implement the full methodology on day one. Document which layers are foundational and which are additive:
# SYSTEM.md — Layer Guide
## Layer 1 (Foundation — start here)
- `.claude/CLAUDE.md` — install first, shapes everything else
- `skills/spec-writing.md` — immediate value for any product work
## Layer 2 (Core workflow)
- `skills/discovery.md` — start using once CLAUDE.md is working
- `workflows/sprint-planning.md` — introduces full sprint cadence
## Layer 3 (Full methodology)
- All remaining skills and workflows
- Templates for decision logging and retrospectivesThis structure respects that behavior change takes time. Buyers who can start with one layer and add more become loyal customers who leave strong reviews.
Common questions
How is a System different from a Bundle?
A Bundle is a curated collection of independently useful products. A System is an integrated methodology where the components are designed to work together. A Bundle's value is convenience. A System's value is coherence — the whole is greater than the sum of its parts.
How detailed should my methodology documentation be?
Write for someone who has never seen your system before and is implementing it on their own. If you'd have to explain it in a call, write it in docs/philosophy.md. Buyers who understand why a system works trust it more and implement it better.
Can I include my own existing products in a System?
Yes. Reference your published skills or workflows by slug in your vault.yaml documentation, and include the core files directly in the System package. This gives buyers everything they need in one install while acknowledging the broader ecosystem.
What price range works for Systems?
Systems command premium pricing because they deliver comprehensive value. Most well-documented Systems on MyClaude are priced between $49 and $149. Price based on the transformation you're delivering, not the number of files.
Related pages
- Building Minds — the cognitive layer that often anchors a System
- Writing Skills — build the skills that compose your System
- Building Workflows — process automation for your System
- vault.yaml Reference — every field explained
- Monetization — pricing systems appropriately
Building Applications
Publish complete, deployable applications built with Claude Code. From boilerplates to production-ready tools — your app becomes an installable product that buyers launch in minutes.
Building Statuslines
Create persistent terminal widgets that surface what matters — build health, test coverage, deploy state, open issues. Real-time project intelligence, visible at a glance.