Skills System

Camel-Kit’s skills are composable Markdown instructions that guide AI agents through complex integration tasks. Built on progressive disclosure — only load what you need, when you need it.

13 Skills in Four Tiers

Skill Structure

---
name: camel-brainstorm
description: Design and plan Camel integrations through collaborative dialogue.
user_invocable: false
---

# Camel Brainstorm — Phase 1 Orchestrator

## Step 1: Detect Invocation Mode
Determine whether this is a new design or an amendment...

## Step 2: Run Interview
Read guides/greenfield-interview.md...

## Step 3: MCP Verification
For each component, call camel_catalog_component_doc...

Migration and upgrade requests route to camel-migrate instead.

Progressive Disclosure

Request → /camel-start → matching pipeline stage or utility

User: "Design a Kafka-to-PostgreSQL integration"
  → Agent matches "design" → loads /camel-brainstorm/SKILL.md
  → Follows step-by-step instructions

SKILL.md says: "Read guides/greenfield-interview.md"
  → Agent loads the interview guide
  → Conducts adaptive project, per-flow, conditional, and cross-cutting discovery for unresolved requirements

Target Generation

One shared skill set is adapted for eight current AI targets. Legacy IBM Bob 1 replaces seven pipeline SKILL.md files with self-contained monolithic gates and mode switching, so those files have a separate source architecture:

# /camel-brainstorm
## Step 1: Detect project type
## Step 2: Run interview
## Step 3: Verify components via MCP

Codex discovers the shared skills directly under .agents/skills/. Users inspect them with /skills and invoke the router as $camel-start; generated skill-to-skill references use native $camel-* mentions, and Camel-Kit does not generate .codex/commands/ wrappers. Generated custom-agent roles support focused and parallel dispatch, with inline execution as the fallback when a role is unavailable.

Agent Traits

In addition to per-agent generators, Camel-Kit uses agent traits — agent-specific instruction fragments appended to shared skill files during camel-kit init. Traits bridge the gap between the shared-skill equalization layer and agent-specific capabilities.

How it works: DefaultGenerator.applyTraits() reads .append.md files from templates/traits/{agent}/ and appends them to the corresponding skill files with idempotent HTML comment sentinels. Re-running init does not duplicate trait content.

Two levels:

• SKILL.md traits (strategy) — e.g., Claude’s camel-execute.append.md adds parallel subagent dispatch via the Agent tool
• Guide traits (tactics) — e.g., Claude’s implementer-context.append.md adds run_in_background: true guidance for wave-based execution

Each agent gets trait content tailored to its capabilities. Bob 2 reserves built-in explore for factual discovery, generates camel-worker for implementation, test, fix, and verification work from broad orchestration modes, and generates a read/MCP-only camel-reviewer for catalog research, knowledge research, and independent judgment. The parent supplies the selected complete role text from .bob/personas/ to each scoped preset. Standalone restricted implement and test modes keep mutations inline; test retains its path-scoped edit restriction. Independent calls in one parent turn run in parallel, and fork_context is used only when prior conversation decisions are needed. Qwen keeps slash-command workflow orchestration in the primary session so questions, approval, arguments, and handoffs remain available; it generates bounded implementer, reviewer, tester, and validator leaves, with the read-only reviewer receiving complete research and review roles from .qwen/camel-kit-personas/. OpenCode keeps the other command stubs in the calling primary session, while its execute command selects the generated primary executor; that executor can dispatch only its allowlisted bounded leaves, and each leaf denies further delegation. Researcher and reviewer leaves receive complete roles from .opencode/camel-kit-personas/. Bob 1 retains its legacy mode-switching gates. Report ownership follows the same pattern: the Gemini, Qwen, and Copilot validators return complete reports to the primary session, which owns the report write, while the OpenCode validator writes the report only when the executor’s prompt assigns it.

Next Steps

• MCP Integration — How skills invoke MCP tools for catalog verification
• Forage Catalog — How infrastructure properties are selected and verified
• Architecture Overview — Four-layer architecture
• Commands Reference — Full command list