diff --git a/docs/explanation/module-configuration.md b/docs/explanation/module-configuration.md index dd3612d..371ae7d 100644 --- a/docs/explanation/module-configuration.md +++ b/docs/explanation/module-configuration.md @@ -5,7 +5,7 @@ description: How BMad modules handle user configuration through a setup skill, w BMad modules register their capabilities with the help system and optionally collect user preferences. Multi-skill modules use a dedicated **setup skill** for this. Single-skill standalone modules handle registration themselves on first run. -When you create your own custom module, you can choose to either add a configuration skill, or you could just add the feature to every skill following the standalone pattern. for modules with more than 1-2 skills, it would be recommended to just have a setup skill. +When you create your own module, you can either add a configuration skill or embed the feature in every skill following the standalone pattern. For modules with more than 1-2 skills, a setup skill is the better choice. ## When You Need Configuration @@ -32,7 +32,7 @@ Module registration serves two purposes: ### Why Register with the Help System? -The `bmad-help` skill reads `module-help.csv` to understand what capabilities are available, detect which ones have been completed (by checking output locations for artifacts), and recommend next steps based on the dependency graph. Without registration, `bmad-help` cannot discover or recommend your module's capabilities beyond what it knows basically from skill headers. the help provides richer potential info such as args, relationship to other skills, inputs and outputs, and any other relevant authored information. also if you have a skill with multiple capabilities, they each have their own help entry. +The `bmad-help` skill reads `module-help.csv` to understand what capabilities are available, detect which ones have been completed (by checking output locations for artifacts), and recommend next steps based on the dependency graph. Without registration, `bmad-help` cannot discover or recommend your module's capabilities beyond what it knows basically from skill headers. The help system provides richer detail: arguments, relationships to other skills, inputs and outputs, and any other authored metadata. If a skill has multiple capabilities, each one gets its own help entry. ### Two Registration Paths @@ -82,7 +82,7 @@ Variables with a `prompt` field are presented to the user during setup. The `def ## Help Registration Without Configuration -You may not need any configurable values but still want to register your module with the help system. This is worth doing when: +You may not need any configurable values but still want to register your module with the help system. Registration is still worthwhile when: - The skill description in SKILL.md frontmatter cannot fully convey what the module offers while staying concise - You want to express capability sequencing, phase constraints, or other metadata the CSV supports diff --git a/docs/explanation/progressive-disclosure.md b/docs/explanation/progressive-disclosure.md index f9c33d7..8a35244 100644 --- a/docs/explanation/progressive-disclosure.md +++ b/docs/explanation/progressive-disclosure.md @@ -3,7 +3,7 @@ title: 'Progressive Disclosure in Skills' description: How to structure skills so they load only the context needed at each moment — from frontmatter through dynamic routing to step files --- -Progressive disclosure is the technique that separates basic skills from powerful ones. The core idea: never load more context than the agent needs _right now_. This keeps token usage low, prevents context pollution, and makes skills survive long conversations. +Progressive disclosure is what separates basic skills from powerful ones. The core idea: never load more context than the agent needs _right now_. This keeps token usage low, prevents context pollution, and lets skills survive long conversations. ## The Four Layers diff --git a/docs/explanation/scripts-in-skills.md b/docs/explanation/scripts-in-skills.md index ed68c06..40b97eb 100644 --- a/docs/explanation/scripts-in-skills.md +++ b/docs/explanation/scripts-in-skills.md @@ -3,7 +3,7 @@ title: 'Scripts in Skills' description: Why deterministic scripts make skills faster, cheaper, and more reliable — and the technical choices behind portable script design --- -Scripts are the reliability backbone of a well-built skill. They handle work that has clear right-and-wrong answers — validation, transformation, extraction, counting — so the LLM can focus on what it does best: judgment, synthesis, and creative reasoning. +Scripts handle work that has clear right-and-wrong answers — validation, transformation, extraction, counting — so the LLM can focus on judgment, synthesis, and creative reasoning. ## The Problem: LLMs Do Too Much @@ -17,7 +17,7 @@ The pattern shows up everywhere: skills that try to LLM their way through struct ## The Determinism Boundary -The core design principle is **intelligence placement** — put each operation where it belongs. +The design principle is **intelligence placement**: put each operation where it belongs. | Scripts Handle | LLM Handles | | ---------------------------------- | ------------------------------------------------ | @@ -92,7 +92,7 @@ import yaml When a skill invokes this script with `uv run scripts/analyze.py`, the dependency (`pyyaml` in this example) is automatically resolved. The user never sees an install prompt, never needs to manage a virtual environment, and never pollutes their global Python installation. -**Why this matters for skill authoring:** Without PEP 723, skills that needed libraries like `pyyaml` or `tiktoken` would force users to run `pip install` — a jarring, trust-breaking experience that makes users hesitate to adopt the skill. +Without PEP 723, skills that need libraries like `pyyaml` or `tiktoken` would force users to run `pip install` — a jarring experience that makes people hesitate to adopt the skill. ## Graceful Degradation @@ -124,4 +124,4 @@ Look for these signal verbs in a skill's requirements — they indicate script o | "compare", "diff", "match against" | Comparison | | "scan for", "find all", "list all" | Pattern scanning | -The builders guide you through script opportunity discovery during the build process. The key insight: if you find yourself writing detailed validation logic in a prompt, it almost certainly belongs in a script instead. +The builders guide you through script opportunity discovery during the build process. If you find yourself writing detailed validation logic in a prompt, it almost certainly belongs in a script instead. diff --git a/docs/explanation/skill-authoring-best-practices.md b/docs/explanation/skill-authoring-best-practices.md index 455c067..8dcaa44 100644 --- a/docs/explanation/skill-authoring-best-practices.md +++ b/docs/explanation/skill-authoring-best-practices.md @@ -103,7 +103,7 @@ Graceful degradation: if subagents are unavailable, the main agent does a single ### Graceful Degradation -Every subagent-dependent feature should have a fallback path. Skills run across different platforms, models, and configurations. A skill that hard-fails without subagents is fragile. A skill that gracefully falls back to sequential processing is robust everywhere. +Every subagent-dependent feature should have a fallback path. Skills run across different platforms, models, and configurations. A skill that hard-fails without subagents is fragile. One that falls back to sequential processing works everywhere. ### Verifiable Intermediate Outputs diff --git a/docs/explanation/subagent-patterns.md b/docs/explanation/subagent-patterns.md index 85f4b9a..757ad79 100644 --- a/docs/explanation/subagent-patterns.md +++ b/docs/explanation/subagent-patterns.md @@ -3,7 +3,7 @@ title: 'Subagent Orchestration Patterns' description: Six patterns for using subagents effectively — from simple data delegation through persona-driven parallel reasoning to evolutionary systems --- -Subagents are isolated LLM instances that a parent skill spawns to handle specific tasks. They have their own context window, receive instructions, and return results. Used well, they keep the parent context small while enabling massive parallel work. +Subagents are isolated LLM instances that a parent skill spawns to handle specific tasks. Each gets its own context window, receives instructions, and returns results. Used well, they keep the parent context small while enabling parallel work at scale. All patterns share one principle: **the filesystem is the single source of truth**. Parent context stays tiny (file pointers + high-level plan). Subagents are stateless black boxes — instructions in, response out, isolated context. @@ -101,7 +101,7 @@ The most powerful pattern for quality. Spawn diverse specialists in parallel — ## Pattern 6: Evolutionary & Emergent Systems -These turn stateless subagents into something that feels alive. All use the filesystem blackboard as connective tissue. +These turn stateless subagents into something that feels alive. All build on the filesystem blackboard. | Variant | How It Works | Best For | | ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------- | @@ -114,9 +114,9 @@ These turn stateless subagents into something that feels alive. All use the file The single most important thing to get right with subagent patterns is **preventing the parent from reading the data it is delegating**. If the parent reads all the files before spawning subagents, the entire pattern is defeated — you have already spent the tokens, bloated the context, and lost the isolation benefit. -This happens more often than you might expect. You write a skill that should spawn subagents to each read a document and return findings. You run it. The parent agent helpfully reads every document first, then passes them to subagents, then collects distilled summaries. The subagents still provide fresh perspectives (a real benefit), but the context savings — the primary reason for the pattern — are gone. +This happens often. You write a skill that should spawn subagents to each read a document and return findings. You run it. The parent agent helpfully reads every document first, then passes them to subagents, then collects distilled summaries. The subagents still provide fresh perspectives, but the context savings — the primary reason for the pattern — are gone. -**The fix is defensive language in your skill.** You need to explicitly tell the parent agent what it should and should not do. The key is being specific without being verbose. +**The fix is defensive language in your skill.** Explicitly tell the parent agent what it should and should not do. Be specific without being verbose. :::note[Example from the BMad Quality Optimizer] The optimizer's instructions say: **"DO NOT read the target skill's files yourself."** It then tells the parent exactly what it _should_ do: run scripts (which return structured JSON), spawn subagents (which do the reading), and synthesize from their outputs. The parent never touches the raw files. @@ -131,7 +131,7 @@ The optimizer's instructions say: **"DO NOT read the target skill's files yourse | **Use pre-pass scripts** | Run a lightweight script that extracts metadata (file names, sizes, structure) so the parent can plan without reading | | **Be explicit about the boundary** | "Your role is ORCHESTRATION. Scripts and subagents do all analysis" | -**Testing is how you catch this.** Run your skill and watch what actually happens. If you see the parent reading files it should be delegating, tighten the language. This is normal iteration — the builders are tuned with these patterns, but different models and tools may need more explicit guidance. Review the existing BMad quality optimizer prompts (`prompts/quality-optimizer.md`) and scanner agents (`agents/quality-scan-*.md`) for working examples of this defensive language in practice. +**Test and watch what actually happens.** If the parent reads files it should be delegating, tighten the language. This is normal iteration — the builders are tuned with these patterns, but different models and tools may need more explicit guidance. Review the BMad quality optimizer prompts (`prompts/quality-optimizer.md`) and scanner agents (`agents/quality-scan-*.md`) for working examples of this defensive language. ## Choosing a Pattern diff --git a/docs/explanation/what-are-bmad-agents.md b/docs/explanation/what-are-bmad-agents.md index eb34b24..83d7830 100644 --- a/docs/explanation/what-are-bmad-agents.md +++ b/docs/explanation/what-are-bmad-agents.md @@ -15,7 +15,7 @@ Every skill in the BMad ecosystem is ultimately a skill file, but agents carry t | **Capabilities** | Actions the agent can perform, either as internal prompt commands or by calling external skills | | **Memory** | A sidecar directory where the agent stores what it learns about you, your preferences, and past interactions | -Together these create something that feels less like running a command and more like talking to a specialist who already knows you. +Together, they make the interaction feel less like running a command and more like talking to a specialist who already knows you. ## How Memory Works @@ -55,6 +55,6 @@ If you are unsure, start with a workflow. You can always wrap it inside an agent ## Building Agents -The **BMad Agent Builder** (`bmad-agent-builder`) walks you through a six-phase conversational discovery process — from intent through capabilities, requirements, drafting, building, and quality optimization. It produces a ready-to-use skill folder you can drop into your tools' skills directory. +The **BMad Agent Builder** (`bmad-agent-builder`) walks you through six phases of conversational discovery — intent, capabilities, requirements, drafting, building, and quality optimization — and produces a ready-to-use skill folder you can drop into your tools' skills directory. See the [Builder Commands Reference](/reference/builder-commands.md) for details on the build process phases and capabilities. diff --git a/docs/explanation/what-are-modules.md b/docs/explanation/what-are-modules.md index bcb4892..324b6c5 100644 --- a/docs/explanation/what-are-modules.md +++ b/docs/explanation/what-are-modules.md @@ -18,7 +18,7 @@ The `.claude-plugin/` convention originates from Claude Code, but the format wor The Module Builder generates the appropriate `marketplace.json` during the Create Module (CM) step - but you will want to verify it lists the proper relative paths to the skills you want to deliver with your module. -This is very powerful also if you want to include remote URL skills in your own module to combine them. +This also means you can include remote URL skills in your own module to combine them. ## What a Module Contains @@ -43,7 +43,7 @@ The first architecture decision when planning a module is whether to use a singl | **Hybrid** | Some capabilities need persistent persona/memory while others are procedural | Best of both worlds but more skills to build and maintain | :::tip[Agent-First Thinking] -Many users default to building multiple single-purpose agents. Consider whether one agent with rich internal capabilities and routing would serve users better. A single agent accumulates context, maintains memory across interactions, and provides a more seamless experience. +Many users default to building multiple single-purpose agents. Consider whether one agent with rich internal capabilities and routing would serve users better. A single agent accumulates context, maintains memory across interactions, and provides a smoother experience. ::: ## Multi-Agent Modules and Memory @@ -103,7 +103,7 @@ When a module has external dependencies, the setup skill should check for their Modules can include user interfaces — dashboards, progress views, interactive visualizations, or even full web applications. A UI skill might show shared progress across the module's capabilities, provide a visual map of how skills relate, or offer an interactive way to navigate the module's features. -Not every module needs a UI. But for complex modules with many capabilities, a visual layer can make the experience significantly more accessible. +Not every module needs a UI. But for complex modules with many capabilities, a visual layer makes the experience much more accessible. ## Building a Module diff --git a/docs/explanation/what-are-workflows.md b/docs/explanation/what-are-workflows.md index bc83829..e2d0899 100644 --- a/docs/explanation/what-are-workflows.md +++ b/docs/explanation/what-are-workflows.md @@ -3,7 +3,7 @@ title: 'What Are BMad Workflows?' description: How workflows guide users through structured processes, how they differ from agents and simple skills, and when to build one --- -BMad Workflows are skills that guide users through a **structured process** to produce a specific output. They are the workhorses of the BMad ecosystem — focused, composable, and generally stateless. +BMad Workflows are skills that guide users through a **structured process** to produce a specific output. They do most of the heavy lifting in the BMad ecosystem — focused, composable, and generally stateless. ## What Makes a Workflow a Workflow @@ -64,6 +64,6 @@ Workflows are also excellent as the **internal capabilities** of an agent. Build ## Building Workflows -The **BMad Workflow Builder** (`bmad-workflow-builder`) uses the same six-phase conversational discovery as the Agent Builder — intent, classification, requirements, drafting, building, and quality optimization. It produces a ready-to-use skill folder. +The **BMad Workflow Builder** (`bmad-workflow-builder`) uses the same six-phase conversational discovery as the Agent Builder — intent, classification, requirements, drafting, building, and quality optimization — and produces a ready-to-use skill folder. See the [Builder Commands Reference](/reference/builder-commands.md) for details on the build process phases and capabilities. diff --git a/docs/how-to/distribute-your-module.md b/docs/how-to/distribute-your-module.md new file mode 100644 index 0000000..fd89dd6 --- /dev/null +++ b/docs/how-to/distribute-your-module.md @@ -0,0 +1,195 @@ +--- +title: 'Distribute Your Module' +description: Set up a GitHub repository to share your BMad module so others can install it +--- + +Set up a GitHub repository so others can install your BMad module with a single command. + +## When to Use This + +- You have built a module and want to share it publicly or within your organization +- You want others to install your module through the BMad installer +- You want to host one or multiple modules from a single repository + +## When to Skip This + +- You are building a module for personal use in a single project — just keep the skills in your project +- You are still iterating on the module — distribute after it is stable + +:::note[Prerequisites] + +- A completed, validated BMad module — see **[Build Your First Module](/tutorials/build-your-first-module.md)** +- A GitHub account with a repository for your module +- Git installed locally +::: + +## Step 1: Understand the Plugin Format + +The BMad installer discovers modules through a `.claude-plugin/marketplace.json` manifest at the repository root. The Module Builder generates this file during the Create Module (CM) step, but you need to verify and complete it before publishing. + +Even if you are not targeting Claude specifically, this is the standard format that allows installing to any skills-capable platform. + +A minimal manifest for a single module: + +```json +{ + "name": "my-module", + "owner": { "name": "Your Name" }, + "license": "MIT", + "homepage": "https://github.com/your-github/my-module", + "repository": "https://github.com/your-github/my-module", + "keywords": ["bmad", "your-domain"], + "plugins": [ + { + "name": "my-module", + "source": "./", + "description": "What your module does in one sentence.", + "version": "1.0.0", + "author": { "name": "Your Name" }, + "skills": [ + "./skills/my-agent", + "./skills/my-workflow" + ] + } + ] +} +``` + +| Field | Purpose | +| ----- | ------- | +| **name** | Package identifier — lowercase, hyphenated | +| **plugins[].source** | Path from repo root to the module's skill folder parent | +| **plugins[].skills** | Array of relative paths to each skill directory | +| **plugins[].version** | Semantic version — bump on each release | + +For repositories that ship multiple modules, add additional entries to the `plugins` array. Each entry points to its own set of skill directories. + +## Step 2: Structure Your Repository + +Organize the repository so the installer can locate skills relative to `marketplace.json`. + +### Single-module repository + +``` +my-module/ +├── .claude-plugin/ +│ └── marketplace.json +├── skills/ +│ ├── my-agent/ +│ │ ├── SKILL.md +│ │ ├── prompts/ +│ │ └── scripts/ +│ ├── my-workflow/ +│ │ ├── SKILL.md +│ │ └── prompts/ +│ └── bmad-mymod-setup/ # Generated by Create Module (CM) +│ ├── SKILL.md +│ ├── assets/ +│ │ ├── module.yaml +│ │ └── module-help.csv +│ └── scripts/ +│ ├── merge-config.py +│ ├── merge-help-csv.py +│ └── cleanup-legacy.py +├── README.md +└── LICENSE +``` + +### Standalone single-skill module + +``` +my-skill/ +├── .claude-plugin/ +│ └── marketplace.json +├── skills/ +│ └── my-skill/ +│ ├── SKILL.md +│ ├── assets/ +│ │ ├── module-setup.md +│ │ ├── module.yaml +│ │ └── module-help.csv +│ ├── references/ +│ └── scripts/ +│ ├── merge-config.py +│ └── merge-help-csv.py +├── README.md +└── LICENSE +``` + +### Multi-module marketplace repository + +``` +my-marketplace/ +├── .claude-plugin/ +│ └── marketplace.json # Multiple entries in plugins[] +├── skills/ +│ ├── module-a/ +│ │ ├── skill-one/ +│ │ ├── skill-two/ +│ │ └── bmad-moda-setup/ +│ └── module-b/ +│ └── standalone-skill/ +├── README.md +└── LICENSE +``` + +:::caution[Skill Paths Must Match] +The `skills` array in `marketplace.json` must match the actual directory paths relative to the repository root. If you reorganize your folders, update the manifest. +::: + +## Step 3: Verify the Manifest + +Before publishing, confirm the manifest is accurate. + +### Check skill paths + +Every path in the `skills` array must point to a directory containing a `SKILL.md` file. + +### Check module registration files + +For multi-skill modules, verify the setup skill contains `assets/module.yaml` and `assets/module-help.csv`. For standalone modules, verify these files exist in the skill's own `assets/` folder. + +### Run Validate Module + +``` +"Validate my module at ./skills" +``` + +The Validate Module (VM) capability checks structural integrity, missing files, orphan entries, and description quality. Fix any findings before publishing. + +## Step 4: Publish to GitHub + +Push your repository to GitHub. The module is installable as soon as it is accessible. + +### Public modules + +Anyone can install with: + +```bash +npx bmad-method install --custom-content https://github.com/your-org/my-module +``` + +### Private or organization modules + +Users with access can install the same way. The installer respects GitHub authentication configured on the machine. + +### Versioning + +Tag releases with semantic versions. Users installing from GitHub get the default branch unless they specify a tag or branch. + +## What You Get + +After publishing, users can: + +- Install your module through the BMad installer with `--custom-content` +- Run the setup skill to register capabilities with `bmad-help` +- Discover your module's capabilities through the help system +- Receive configuration prompts defined in your `module.yaml` + +## Tips + +- Include a `README.md` that explains what the module does, how to install it, and any external dependencies +- Add a `LICENSE` file — MIT is common for open-source BMad modules +- Keep `marketplace.json` version in sync with your release tags +- If your module has external dependencies (CLI tools, MCP servers), document them in the README and handle detection in your setup skill +- Run `Validate Module (VM)` before each release to catch regressions diff --git a/docs/index.md b/docs/index.md index 4bfd180..de44f37 100644 --- a/docs/index.md +++ b/docs/index.md @@ -9,7 +9,7 @@ description: BMad Builder - Build More, Architect Dreams ## The Dream -Imagine AI that truly knows you — a fitness coach that remembers every PR, a writing partner that knows your characters better than you do, a research assistant that learns your preferences. +What if your AI remembered everything? A fitness coach that tracks every PR. A writing partner that knows your characters better than you do. A research assistant that already knows how you work. BMad Builder lets you create: @@ -70,7 +70,7 @@ See the [Builder Commands Reference](/reference/builder-commands.md) for all cap ## Design Patterns -Build better skills with these guides distilled from real-world BMad development. +Build better skills with these guides, distilled from real-world BMad development. | Guide | What You'll Learn | | ------------------------------------------------------------------------------------ | -------------------------------------------------------------------- | diff --git a/docs/reference/builder-commands.md b/docs/reference/builder-commands.md index ff0c1f6..3dc962b 100644 --- a/docs/reference/builder-commands.md +++ b/docs/reference/builder-commands.md @@ -119,7 +119,7 @@ Critical issues block completion. Warnings are noted but don't block. ## Quality Optimize (QO) -Comprehensive validation and optimization for existing skills. Runs deterministic lint scripts for instant structural checks and LLM scanner subagents for judgment-based analysis, all in parallel. +Validation and optimization for existing skills. Runs deterministic lint scripts for instant structural checks and LLM scanner subagents for judgment-based analysis, all in parallel. ### Pre-Scan Checks @@ -182,7 +182,7 @@ Not every suggestion should be applied. The optimizer communicates these decisio ## Convert (CW) -One-command conversion of any existing skill into a BMad-compliant, outcome-driven equivalent. This is the fastest path for taking a non-conformant skill — whether it's bloated, poorly structured, or just doesn't follow BMad best practices — and producing a clean version that does. Unlike the Build Process's edit/rebuild modes, `--convert` always runs headless and produces a visual comparison report. +One-command conversion of any existing skill into a BMad-compliant, outcome-driven equivalent. Takes a non-conformant skill — bloated, poorly structured, or just not following BMad practices — and produces a clean version. Unlike the Build Process's edit/rebuild modes, `--convert` always runs headless and produces a visual comparison report. ### Usage @@ -238,7 +238,7 @@ The Module Builder (`bmad-module-builder`) handles module-level planning, scaffo ### Ideate Module (IM) -A facilitative brainstorming session that helps you envision your module from scratch. The builder acts as a creative collaborator — drawing out ideas, exploring possibilities, and guiding you toward the right architecture. +A brainstorming session that helps you plan your module from scratch. The builder acts as a creative collaborator — drawing out ideas, exploring possibilities, and guiding you toward the right architecture. | Aspect | Detail | | --------------- | ----------------------------------------------- | diff --git a/docs/tutorials/build-your-first-module.md b/docs/tutorials/build-your-first-module.md index 6d13018..5bedaf9 100644 --- a/docs/tutorials/build-your-first-module.md +++ b/docs/tutorials/build-your-first-module.md @@ -3,7 +3,7 @@ title: 'Build Your First Module' description: Create a complete BMad module from idea to installable package using the Module Builder --- -Walk through the complete module lifecycle — from brainstorming an idea to scaffolding an installable BMad module with help registration and configuration. +This tutorial walks through the full module lifecycle — from brainstorming an idea to scaffolding an installable BMad module with help registration and configuration. ## What You'll Learn @@ -141,11 +141,11 @@ Run Validate Module (VM) to check that everything is wired correctly. Fix any findings and re-validate until clean. -## What You've Accomplished +## What You've Built Your module is now a complete, distributable BMad module. For multi-skill modules, users run the setup skill to install. For standalone modules, the skill self-registers on first run. -Either way, the module's capabilities are now discoverable through `bmad-help`, configuration is collected and persisted, and the module works within the BMad ecosystem. +Either way, the module's capabilities are discoverable through `bmad-help`, configuration is collected and persisted, and the module works within the BMad ecosystem. ## Quick Reference @@ -183,5 +183,5 @@ Yes. During ideation or creation, specify that your module is an expansion. Your - **[Discord](https://discord.gg/gk8jAdXWmj)** — Community support :::tip[Key Takeaways] -Plan first with Ideate Module (IM), build individual skills with the Agent and Workflow Builders, package with Create Module (CM), and verify with Validate Module (VM). For multi-skill modules, a setup skill handles registration. For single skills, registration is built in — no extra infrastructure needed. +Plan with Ideate Module (IM), build individual skills with the Agent and Workflow Builders, package with Create Module (CM), and verify with Validate Module (VM). For multi-skill modules, a setup skill handles registration. For single skills, registration is built in — no extra infrastructure needed. :::