tap-capability-authoring

Generate Octomind capability and dep script definitions for the octomind-tap registry.

3|Updated Mar 14, 2026
One-click install
npx skills add https://github.com/Muvon/octomind-tap --skill tap-capability-authoring
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: tap-capability-authoring
Source: https://github.com/Muvon/octomind-tap/tree/main/skills/tap-capability-authoring
Command: npx skills add https://github.com/Muvon/octomind-tap --skill tap-capability-authoring

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It solves the friction of creating correct Octomind capability wiring and dependency scripts by providing a structured, end-to-end checklist that prevents common registry and validation mistakes.

Core Features & Use Cases

  • Capability format guidance: Defines how capabilities declare deps, MCP server references, and allowed tool patterns so agents can request tools consistently.
  • Provider + symlink pattern: Explains how to structure provider implementations and ensure default.toml is a symlink to the active provider (with safe exceptions for built-ins).
  • Dep script + companion docs requirements: Standardizes dep script structure and enforces that every .sh has a matching .md with the right sections.
  • Registry integration steps: Covers updating setup-symlinks.sh, running the symlink setup and lint scripts, and validating capability correctness before use.

Quick Start

Create a new capability folder under capabilities/<name>/, add your <provider>.toml and required dep script plus companion .md (if deps are needed), then register and lint it by following the setup-symlinks.sh and lint script steps.

Frequently Asked Questions about tap-capability-authoring

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I create an Octomind capability that correctly references MCP server tools?

Octomind capability authoring requires creating a capabilities/<name>/ directory with a provider TOML file declaring deps, MCP server references, and allowed tool patterns. The default.toml must be a symlink to the active provider, with validation enforced by lint scripts.

Why does my Octomind capability validation fail during linting?

Capability validation fails during linting when required TOML sections are missing, default.toml symlink conventions are broken, or dep scripts lack matching companion .md documentation. The lint script enforces these structural rules before registry integration.

What is the required structure for Octomind dependency scripts?

Octomind dependency scripts require a file at deps/<org>/<tool>.sh paired with a matching companion .md file containing the required documentation sections. This standardization prevents registry validation errors and ensures agents access MCP-backed tools reliably.

Do I need to update setup-symlinks.sh when adding new Octomind capabilities?

Yes, adding new Octomind capabilities requires updating setup-symlinks.sh to register the new entries. You must then run the symlink setup script and execute the lint script to validate capability correctness before agents can access the MCP-backed tools.

Can I use a regular file instead of a symlink for default.toml in Octomind capabilities?

default.toml must be a symlink to the active provider implementation, with safe exceptions only for built-ins. Using a regular file instead of a symlink breaks the provider pattern and causes validation failures during the Octomind lint process.