Camel-Kit Command Reference

This document is the reference for all Camel-Kit commands: the camel-kit CLI, slash commands used inside most AI coding assistants, and native project skills used by Codex CLI and GitHub Copilot CLI.

The --ai bob2 target exposes the nine public workflows through native skills: $camel-* in Bob Shell and /camel-* in Bob IDE. Legacy command stubs remain installed for compatibility. See Bob Shell setup and upgrading existing workspaces if only $camel-start appears in /skills. Arguments follow the skill name, and $camel-ship retains its single CLI invocation with the supplied options.

CLI Commands
Slash Commands
Command Cheat Sheet

CLI Commands

This guide describes Camel Kit 0.4.1. The standalone CLI and the 0.4.1 Camel JBang plugin provide the equivalent camel-kit and camel kit command forms. Development continues at 0.4.2-SNAPSHOT; see installation for release and development channels.

These commands are run in your terminal.

camel-kit init

Initialize a new Camel-Kit project.

Usage:

camel-kit init <project-name> [options]
camel-kit init --here [options]
camel kit init <project-name> [options]
camel kit init --here [options]

Arguments:

Argument	Description
`project-name`	Name of the project directory to create

Options:

Option	Default	Description
`--ai`, `-a`	`bob2`	AI coding assistant to configure (`bob2` for IBM Bob 2, `antigravity`, `claude`, `codex`, `copilot`, `pi`, `qwen`, `opencode`)
`--citrus-version`	`5.0.1`	Citrus Framework version for test schemas and generated test dependencies
`--here`	`false`	Initialize in current directory
`--no-fetch`	`false`	Skip external catalog fetching
`-p`, `--property`	--	Override a config property (repeatable). Example: `-p "camel.main.version=4.18.4"`
`-c`, `--config`	`~/.camel-kit/config.properties`	Path to a custom config properties file
`--source-platform`	`auto`	Source platform for migration: `mulesoft`, `camel`, `biztalk`, `auto`
`--force`	`false`	Overwrite existing project without prompting (skips overwrite detection)
`--silent`	`false`	Suppress all output (no banner, no TUI, no progress, no summary) -- useful for CI/scripted environments
`-V`, `--version`	--	Print camel-kit version and exit

Examples:

# Create new project for IBM Bob 2 (default)
camel-kit init my-integration

# Create new project for IBM Bob 2
camel-kit init my-integration --ai bob2

# Create new project for Google Antigravity
camel-kit init my-integration --ai antigravity

# Create new project for Claude Code
camel-kit init my-integration --ai claude

# Create new project for OpenAI Codex CLI
camel-kit init my-integration --ai codex
camel kit init my-integration --ai codex

# Create new project for GitHub Copilot CLI
camel-kit init my-integration --ai copilot

# Create new project for Pi
camel-kit init my-integration --ai pi

# Create new project for Qwen
camel-kit init my-integration --ai qwen

# Create new project for OpenCode
camel-kit init my-integration --ai opencode

# Initialize in current directory with the default IBM Bob 2 target
camel-kit init --here

# Override config properties via CLI
camel-kit init my-integration --ai claude -p "camel.main.version=4.18.4"

# Override multiple properties
camel-kit init my-integration --ai claude -p "camel.quarkus.version=4.18.3" -p "quarkus.platform.version=3.33.3.2"

# Use a custom config file
camel-kit init my-integration --ai claude -c /path/to/my-config.properties

# Explicitly declare MuleSoft source platform
camel-kit init my-integration --ai claude --source-platform mulesoft

# Explicitly declare BizTalk source platform
camel-kit init my-integration --ai claude --source-platform biztalk

# Skip catalog fetch (faster)
camel-kit init my-integration --no-fetch

# Overwrite an existing project
camel-kit init my-integration --ai claude --force

# Check version
camel-kit --version

Prerequisite check:

On startup, init checks for required tools and reports their status:

Prerequisites:
  Java 17+          ✓ (21.0.3)
  JBang             ✓ (0.136.0)
  Camel JBang       ✓ (4.18.1)
  Camel test plugin ✗ (not found — runtime verification will skip Citrus test phase)

The check is non-blocking -- it warns but never fails the init. Design and planning work without Camel JBang; only execution and verification need it.

Overwrite detection:

If the target directory already contains AGENTS.md or .camel-kit/, init warns and exits:

⚠ Project already initialized
  Directory: /path/to/my-integration
  Found:     AGENTS.md
  Found:     .camel-kit/

  To overwrite: --force
  Example:      camel-kit init my-integration --ai claude --force

Use --force to overwrite an existing project.

TUI experience:

On terminals that support a native image protocol (Kitty, iTerm2, Sixel), camel-kit init displays a split-screen TUI while the project is being created: the logo on the left, a live task list with animated spinners and green ticks on the right. The TUI exits automatically when all tasks complete. Falls back to coloured inline output on unsupported terminals.

Configuration Override:

camel-kit init reads configuration from a 3-layer cascade. Later layers override earlier ones:

Priority	Source	Description
1 (lowest)	Built-in `distribution.properties`	Bundled defaults inside the camel-kit JAR
2	`~/.camel-kit/config.properties` (or `-c path`)	User-level config file. Created manually by the user; not required. Override the default path with `-c`.
3 (highest)	`-p key=value` CLI flags	Per-invocation overrides. Repeatable.

Any property from distribution.properties can be overridden at layers 2 or 3. Common overrides:

Property	Default	Description
`camel.main.version`	`4.22.1`	Apache Camel version for Camel Main / JBang projects
`camel.springboot.version`	`4.22.1`	Apache Camel version for Spring Boot projects
`springboot.bom.version`	`4.22.1`	Spring Boot BOM version
`camel.quarkus.version`	`4.18.3`	Apache Camel version for Quarkus projects
`quarkus.platform.version`	`3.33.3.2`	Quarkus platform BOM version
`camel.mcp.version`	See `distribution.properties`	Camel MCP server version
`knowledge.mcp.version`	`0.0.2`	Knowledge MCP server version
`citrus.version`	`5.0.1`	Citrus test schema and dependency version
`citrus.mcp.version`	`5.0.1`	Citrus MCP server artifact version

Output:

The tree below is a union reference. init creates the shared project files plus only the agent-native assets selected by --ai; it does not generate all target layouts together.

Creates the following structure:

my-integration/
├── mvnw                         # Maven Wrapper (Unix)
├── mvnw.cmd                     # Maven Wrapper (Windows)
├── .mvn/wrapper/                # Maven Wrapper config
├── test/                        # Generated Citrus tests
│   └── data/                    # Test data files
├── schemas/                     # JSON/XML schemas
├── docs/
│   └── flows/                   # Flow definitions
├── .camel-kit/
│   ├── config.properties        # Project configuration
│   ├── project-graph.json       # Auto-detected project graph
│   ├── .cache/                  # Downloaded catalogs and schemas
│   │   ├── components-{version}.json
│   │   ├── kamelets-{version}.json
│   │   ├── camelYamlDsl-{version}.json
│   │   └── citrus/{version}/    # Citrus JSON schemas
│   └── templates/               # Reference templates
├── .mcp.json                    # Claude Code or Pi MCP configuration
├── .bob/mcp.json                # IBM Bob MCP configuration
├── .agents/mcp_config.json      # Google Antigravity MCP configuration
├── AGENTS.md                    # Antigravity, Codex CLI, Pi, or OpenCode project instructions
├── .agents/skills/              # Antigravity or Codex CLI project skills
├── .codex/config.toml           # Codex CLI project MCP configuration
├── .codex/agents/               # Codex CLI custom agents
├── .github/mcp.json             # GitHub Copilot CLI MCP configuration
├── .github/copilot-instructions.md
├── .github/agents/              # GitHub Copilot CLI custom agents
├── .github/skills/              # GitHub Copilot CLI project skills
├── .github/hooks/               # GitHub Copilot CLI safety hooks
├── .pi/                         # Pi skills, prompt templates, and guard extension
├── .qwen/settings.json          # Qwen MCP configuration
└── opencode.json                # OpenCode MCP configuration

The MCP configuration file created depends on the --ai option chosen.

For OpenAI Codex CLI, Camel-Kit generates AGENTS.md, native project skills under .agents/skills/, eight custom agents under .codex/agents/, and the camel, camel-knowledge, and citrus MCP servers in .codex/config.toml. It does not create .codex/commands/; after trusting the repository, start with $camel-start, use /skills to inspect skills, and use /mcp to inspect servers. Codex skips project config and any project hooks until the repository is trusted. The three generated MCP servers use exact tool allowlists and default_tools_approval_mode = "prompt". Existing valid, unrelated project configuration is preserved; invalid TOML or conflicting managed server tables cause init to fail without changing the existing config file. Camel-Kit does not change global Codex configuration or authentication and does not install project hooks.

For GitHub Copilot CLI, Camel-Kit also generates .github/copilot-instructions.md, project skills under .github/skills/, custom agents under .github/agents/, and a conservative .github/hooks/camel-kit-safety.json hook that denies destructive or secret-sensitive shell commands while leaving normal Copilot permission prompts intact. Copilot users should start by asking Copilot to “Use the /camel-start skill.” Run /skills list to inspect available project skills.

For Pi, Camel-Kit generates AGENTS.md, project skills under .pi/skills/, prompt templates under .pi/prompts/, .mcp.json for pi-mcp-adapter, and .pi/extensions/camel-kit-guard.ts plus a JSON guard policy. Install the adapter with pi install npm:pi-mcp-adapter@2.11.0, trust the project with /trust, then run /skill:camel-start. Headless checks must use pi -a.

camel-kit doctor

Validate a generated Camel-Kit workspace and report actionable findings.

Usage:

camel-kit doctor [options]
camel kit doctor [options]

Use camel-kit doctor for the standalone CLI. Use camel kit doctor when Camel-Kit is installed as a Camel JBang plugin.

Options:

Option	Default	Description
`--project-dir`	`.`	Workspace directory to validate
`--json`	`false`	Print machine-readable JSON output for automation

Examples:

# Check the current workspace
camel-kit doctor
camel kit doctor

# Check another workspace
camel-kit doctor --project-dir /path/to/order-processing

# Produce JSON for automation
camel-kit doctor --json
camel kit doctor --json

Checks:

For Bob 2, doctor reports a FAIL for each public skill hidden by an effective user-invocable: false value and names the affected file with regeneration guidance. It honors metadata.user-invocable before the top-level field, as Bob does; the four internal helpers remain hidden. Empty public skill files and unparseable metadata also fail validation.

doctor validates .camel-kit/config.properties, selected agent command stubs when that target uses them, skill directories and SKILL.md files, registered workspace templates, user-invocable command exposure, runtime-supported MCP filtering and permission fields, graph availability, command prefix configuration, Java/Maven/JBang prerequisites, and common stale references in active generated files. For Codex, it parses .codex/config.toml, checks all three exact MCP allowlists and prompt approval modes, and verifies that every generated custom-agent TOML file declares name, description, and developer_instructions. For Qwen it checks includeTools and prompt-preserving trust; for OpenCode it checks the generated server-tool ask patterns. Legacy Qwen/OpenCode configurations that predate those fields produce upgrade warnings rather than failures, while malformed current configurations fail. Internal skills such as camel-verify must exist as skills, but must not be exposed as user command stubs.

Findings are printed as PASS, WARN, or FAIL. Missing external prerequisites are warnings so automated checks do not depend on the local machine having every optional tool installed. Broken generated workspace artifacts are failures and produce a non-zero exit code.

camel-kit graph

Project graph analysis and query commands. The project graph is automatically detected during camel-kit init and stored in .camel-kit/project-graph.json. It contains nodes (routes, components, services, artifacts, properties, processors) and edges (dependencies, references, configurations) extracted from source code, build files, and configuration files.

Usage:

camel-kit graph <subcommand> [options]

Subcommands:

Subcommand	Description
`stats`	Show graph statistics (node counts by type, edge counts by type)
`find <query>`	Find nodes by name, type, or pattern
`neighbors <nodeId>`	Show direct neighbors of a node
`impact <nodeId>`	Show all downstream dependencies of a node
`route-topology <routeId>`	Show the topology of a specific route
`project-norms`	Analyze project-wide patterns and conventions
`project-context`	Collect comprehensive project context for analysis
`route-context <routeId>`	Collect route-specific context with component details
`migration-context <routeId>`	Collect migration context for a route with expanded graph traversal

migration-context command:

The migration-context command performs a bounded, bidirectional BFS expansion from a route, including interface-boundary expansion. It reads only the local project graph, defaults to depth 3, and returns at most 50 expanded nodes; it is not a complete dependency map.

camel-kit graph migration-context <routeId> [--depth N]

Parameters:

Parameter	Default	Description
`<routeId>`	required	Route ID to analyze (without `route:` prefix)
`--depth N`	`3`	BFS expansion depth for graph traversal

Output format:

Returns structured JSON for the nodes reached within those bounds:

{
  "route": "processOrders",
  "runtime": "spring-boot",
  "components": ["kafka", "http", "bean"],
  "routes": [
    {
      "id": "route:processOrders",
      "from": "kafka:orders",
      "file": "src/main/resources/routes/orders.camel.yaml"
    }
  ],
  "services": [
    {
      "class": "com.example.OrderService",
      "bean": true,
      "beanName": "orderService"
    }
  ],
  "artifacts": [
    {
      "groupId": "org.apache.camel",
      "artifactId": "camel-kafka",
      "version": "4.14.4"
    }
  ],
  "properties": [
    {
      "key": "camel.component.kafka.brokers",
      "value": "localhost:9092",
      "edgeType": "CONFIGURES",
      "target": "component:kafka"
    }
  ],
  "warnings": [
    {
      "type": "synthetic-node",
      "name": "UnknownService",
      "reason": "Node was inferred, not parsed from source"
    }
  ]
}

The command reports reached routes, endpoint schemes, bean classes, Maven artifacts, configuration properties, and synthetic-node warnings. runtime comes from project.runtime in .camel-kit/config.properties, or is unknown when that value is unavailable. The command makes no MCP calls; callers that need documentation or security context must query the Knowledge MCP separately.

Example:

# Analyze the processOrders route with default depth
camel-kit graph migration-context processOrders

# Expand to depth 5 for complex route dependencies
camel-kit graph migration-context processOrders --depth 5

camel-kit nextId

Generate the next sequential pipeline ID and create the pipeline directory.

Usage:

camel-kit nextId <slug>

Arguments:

Argument	Required	Description
`<slug>`	Yes	Pipeline slug — lowercase alphanumeric with hyphens (e.g., `order-processing`)

Behavior:

Scans docs/camel-kit/ for existing NNN-* directories
Finds the maximum NNN value (or 0 if none exist)
Creates docs/camel-kit/<NNN+1>-<slug>/ directory
Prints the generated pipeline ID to stdout

Examples:

# First pipeline in a project
$ camel-kit nextId order-processing
001-order-processing

# Subsequent pipelines
$ camel-kit nextId inventory-sync
002-inventory-sync

Exit Codes:

Code	Meaning
0	Success — pipeline ID generated and directory created
1	Error — invalid slug or directory creation failure

camel-kit doc

Pipeline document staleness management. Replaces the text-marker-based staleness system with deterministic YAML frontmatter operations.

Usage:

camel-kit doc <subcommand> [options]

Subcommands:

Subcommand	Description
`init --by <skill> [--from <source>] <file>`	Add generation frontmatter; omit `--from` for root artifacts
`check <file>`	Query document staleness status — outputs JSON to stdout
`stale --reason "..." [--cascade] <file>`	Mark a document as stale
`unstale <file>`	Clear staleness from a document

Frontmatter Schema:

Each pipeline artifact carries YAML frontmatter with two namespaced blocks:

---
staleness:
  stale: false
  since: null
  reason: null
generated:
  at: "2026-05-13T09:00:00Z"
  by: camel-plan
  from: design-spec.md
---

staleness — mutable, written by doc stale and doc unstale
generated — immutable after creation, written by doc init when the pipeline skill produces the artifact
generated.from enables data-driven cascade without hardcoded pipeline topology

doc check output:

{
  "file": "docs/camel-kit/007/implementation-plan.md",
  "stale": true,
  "since": "2026-05-13T10:00:00Z",
  "reason": "design-spec.md was refined",
  "generated": {
    "at": "2026-05-13T09:00:00Z",
    "by": "camel-plan",
    "from": "design-spec.md"
  }
}

Exit code 0 for successful execution regardless of staleness. Non-zero for errors only. Documents without frontmatter return {"stale": false, ...null fields}.

doc stale options:

Option	Required	Description
`--reason "..."`	Yes	Reason for marking the document stale (audit trail)
`--cascade`	No	Propagate staleness to downstream artifacts via `generated.from` chain

Cascade behavior:

doc stale always marks its target. When --cascade is used, the command also walks sibling files in the same directory. For each file whose generated.from matches the target filename, it marks that file stale and recursively continues down the chain. After regenerating a design, do not target the fresh design-spec.md; mark each existing direct child separately. Migration designs have two such children: migration-runbook.md and implementation-plan.md.

doc init options:

Option	Required	Description
`--by <skill>`	Yes	Skill that generated this artifact (e.g., `camel-plan`)
`--from <source>`	No	Actual source artifact this was generated from; omit for root artifacts

doc init is idempotent — if the file already has frontmatter, it is preserved unchanged. This makes it safe to call unconditionally after every save.

Examples:

# Add provenance metadata after generating an artifact
camel-kit doc init --by camel-plan --from design-spec.md docs/camel-kit/001-order-processing/implementation-plan.md

# Record the independent migration runbook branch
camel-kit doc init --by camel-migrate --from design-spec.md docs/camel-kit/002-legacy-orders/migration-runbook.md

# Initialize a root artifact with no upstream document
camel-kit doc init --by camel-brainstorm docs/camel-kit/001-order-processing/design-spec.md

# Check if a document is stale
camel-kit doc check docs/camel-kit/001-order-processing/implementation-plan.md

# After amending a migration design, stale each existing direct child separately
camel-kit doc stale --reason "design spec was amended" --cascade docs/camel-kit/002-legacy-orders/migration-runbook.md
camel-kit doc stale --reason "design spec was amended" --cascade docs/camel-kit/002-legacy-orders/implementation-plan.md

# Clear staleness after regeneration
camel-kit doc unstale docs/camel-kit/001-order-processing/implementation-plan.md

Exit Codes:

Code	Meaning
0	Success — command completed (for `check`: regardless of staleness)
1	Error — file not found, I/O failure, or invalid arguments (e.g., blank `--reason`)

Slash Commands

These commands are used inside your AI coding assistant after project initialization. The entry point is /camel-start, which routes to the right pipeline skill. Skills are organized into tiers:

The machine-readable source of truth for command names, generated stubs, skill visibility, pipeline stages, transitions, artifacts, and MCP tool filters is camel-kit-core/src/main/resources/workflow/camel-kit-workflow.yaml. Generated command stubs and consistency tests read that manifest; update it before changing this reference text or any skill frontmatter.

Tier 1 — Pipeline: /camel-brainstorm, /camel-migrate, /camel-plan, /camel-execute, /camel-validate — five skills implementing a four-stage pipeline, with brainstorm and migrate as alternative Design-stage entries. Invoke them via the /camel-start decision tree or directly via slash command.

Tier 2 — Standalone utilities: /camel-ship, /camel-knowledge, /camel-debug — can be invoked at any point. Ship delegates to a separate local controller and does not use the manual pipeline state as its run state.

Internal skill libraries: camel-implement, camel-verify, camel-test, camel-design — invoked automatically by pipeline skills, using isolated subagents where supported and same-session execution otherwise. Not exposed as direct slash-command stubs.

/camel-start

Purpose: Route an integration request to the first applicable Camel-Kit skill.

The router evaluates the request in this order:

Existing MuleSoft, BizTalk, Fuse, or Camel 2.x/3.x source → /camel-migrate
Approved design spec → /camel-plan
Implementation plan ready to execute → /camel-execute
Generated routes needing static quality analysis → /camel-validate
Build, startup, or runtime failure outside a pipeline → /camel-debug
New or unclear integration work → /camel-brainstorm

Greenfield and migration pipelines then converge on plan → execute → validate. Runtime verification (camel-verify) runs inside execute rather than as a separate pipeline stage.

/camel-brainstorm

Purpose: Interactive design session that turns integration ideas into fully formed design specs through collaborative dialogue.

When to use: Starting any new integration project. For migrations, use /camel-migrate instead.

Produces:

docs/camel-kit/<PIPELINE_ID>/business-requirements.md
docs/camel-kit/<PIPELINE_ID>/design-spec.md
docs/constitution.md

Examples:

# Start a new design (chained mode — auto-invokes plan after approval)
/camel-brainstorm

# Start a new design in standalone mode (if design-spec.md does not exist)
/camel-brainstorm 001-order-processing

# Amend an existing design spec (if design-spec.md already exists)
/camel-brainstorm 001-order-processing

Standalone and amend mode:

When invoked with a <PIPELINE_ID> argument:

If design-spec.md does not exist → runs the full interview in standalone mode (no auto-transition to plan)
If design-spec.md already exists → enters amend mode: loads the existing spec, lets you modify it, marks downstream artifacts stale, then stops

How it works:

Detect invocation mode -- check for <PIPELINE_ID> argument and existing design spec
Detect project type -- greenfield or migration (based on keywords like “create”, “build” vs “migrate”, “convert”)
Load context -- reads docs/constitution.md and .camel-kit/config.properties if they exist
Run interview or discovery -- Socratic interview (one question at a time) for greenfield; artifact scanning and confirmation for migration
Select Camel version -- presents available versions for selection
Design flows -- for each flow, verifies components, EIPs, data formats, and languages against the MCP catalog. Asks conditional questions only when relevant:
- Circuit breaker configuration (if HTTP components detected)
- Idempotent consumer (if message broker components detected)
- Transaction boundaries (if multiple sinks detected)
Assemble design spec -- compiles the full business requirements and flow designs into the active design spec
Self-review -- scans for placeholders, contradictions, unverified components
User approval -- presents the spec and waits for explicit approval
Transition -- in chained mode, invokes /camel-plan automatically after approval. In standalone/amend mode, writes output and stops.

MCP tools used:

camel_catalog_component_doc -- verify component exists
camel_catalog_eip_doc -- verify EIP exists
camel_catalog_dataformat_doc -- verify data format exists
camel_catalog_language_doc -- verify expression language exists

/camel-plan

Purpose: Create a detailed implementation plan from an approved design spec.

When to use: After /camel-brainstorm has produced an approved design spec. Usually invoked automatically by /camel-brainstorm, but can also be run directly if a design spec already exists.

Produces:

docs/camel-kit/<PIPELINE_ID>/implementation-plan.md

Example:

/camel-plan

How it works:

Scope check -- if the spec covers many independent subsystems (10+ flows), suggests breaking into separate plans
Load task template -- selects the appropriate template (greenfield, migration, or testing)
Decompose into tasks -- breaks the spec into bite-sized implementation tasks, each with:
- Exact file paths to create or modify
- Structured yaml plan-metadata for wave analysis
- Guide files to load and MCP tools to call
- Two-stage review specification (spec compliance, then code quality)
- Verification commands with expected output
Self-review -- checks spec coverage, scans for placeholders, validates guide references
Write plan -- saves the reviewed implementation plan
Automatic transition -- in chained mode, invokes /camel-execute without a second approval gate; standalone mode stops after writing the plan

The plan is a recipe, not the meal -- it contains instructions on how to generate code, not the generated code itself.

Structured metadata contract: implementation plans include a fenced YAML block with the exact info string yaml plan-metadata. camel-kit plan analyze reads this block before falling back to Markdown parsing. Each task entry uses:

tasks:
  - id: 1
    title: Order ingestion route
    files:
      creates:
        - src/main/resources/camel/order-ingestion.camel.yaml
    provides:
      routes:
        - order-ingestion
      endpoints:
        - direct:validate-order
    consumes:
      properties:
        - orders.input.dir
    dependsOn: []

id matches ### Task N; files may group creates, modifies, reads, deletes, tests, or references. provides and consumes support logical dependency keys such as routes, endpoints, properties, schemas, testData, beans, externalServices, and routeContracts. dependsOn lists explicit task IDs that must complete first. Markdown-only plans remain supported for older artifacts.

/camel-execute

Purpose: Execute the implementation plan produced from an approved design, with isolated implementation and review where the selected agent supports it.

When to use: After /camel-plan has produced an implementation plan. Usually invoked automatically by /camel-plan, but can also be run directly if a plan already exists.

Produces:

Route YAML files (*.camel.yaml)
application.properties
pom.xml dependencies
XSLT/DataMapper transformations
Docker Compose files (if external services needed)
Citrus test files
Execution and verification reports

Example:

/camel-execute

How it works:

Analyze plan and environment -- derives dependency waves and probes the target environment before implementation, automatically repairing mechanical failures or re-planning bounded architectural failures
Catalog research -- batch-verifies the Camel artifacts needed by each wave before implementers run
Per-task loop (autonomous, uninterrupted -- design approval authorizes downstream work):
- Dispatch implementer -- fresh subagent where supported, with full task context, guide paths, and the catalog summary
- Adversarial code review -- independent moderator and critic contexts where supported, or a same-session sequential critic-lens fallback on single-conversation targets such as Pi, review the implementation with fixes and up to three cycles
- Spec compliance review -- verifies the generated artifacts match the design spec exactly
- Code quality review -- checks constitution rules, security, and anti-patterns
- If review fails, the implementer fixes and re-submits until both reviews pass
Cross-cutting review -- after all tasks complete, reviews all generated routes together for consistency
Verification phase -- dispatches /camel-verify internally (build, Citrus tests, report). Verification failures are reported but do not block completion
Completion summary -- writes the execution report and reports task, review, and verification outcomes

After /camel-execute completes, the pipeline continues to /camel-validate as the final quality gate.

Agent-specific execution:

Agent	Execution Model
Claude Code	Dispatches fresh subagents per task (isolated context)
IBM Bob 2	Uses native `spawn_subagent` plus Bob custom modes and shared skills
Google Antigravity, Qwen, OpenCode	Use their native agent/delegation models with shared Camel-Kit skills
Pi	Runs the same implementation and review roles sequentially inline and records unavailable fresh-context isolation

Orchestrated internal skills:

During execution, /camel-execute dispatches these internal skills as needed. They are never invoked directly by the user:

Internal Skill	Role
`camel-implement`	Generate Camel YAML DSL routes from the approved design spec and implementation plan
`/camel-verify`	Runtime verification loop: build, start, diagnose errors, apply fixes
`camel-test`	Generate Citrus integration tests

/camel-migrate

Purpose: Migrate an existing integration from another platform to Apache Camel.

When to use: When you have an existing MuleSoft, Camel 2.x/3.x, JBoss Fuse, or BizTalk project to migrate.

Produces: Business requirements, an evidence-qualified migration analysis, an active design spec, and an operational migration runbook tailored to the migration. In direct mode, produces route files, properties, support artifacts, and a MIGRATION.md note instead of the four-document design package.

Example:

/camel-migrate
/camel-migrate --direct

Supported source platforms:

Platform	Versions	Detection method
MuleSoft Mule	3.x, 4.x	XML namespace `mulesoft.org`, `pom.xml` groupId `org.mule` / `com.mulesoft`
Apache Camel	2.x, 3.x	`pom.xml` with `org.apache.camel` dependencies (older version)
JBoss Fuse	6.x, 7.x	`pom.xml` with `org.jboss.fuse` or `fuse-` BOMs
Microsoft BizTalk	3.x, 4.x	XML namespace `schemas.microsoft.com/BizTalk`, `.odx` / `.btm` / `.btp` files

Graph-accelerated analysis:

MuleSoft migrations benefit from automatic project graph analysis. The graph detects MuleSoft XML files via namespace sniffing (mulesoft.org/schema/mule) and parses all flows, sub-flows, connectors, endpoints, transforms, error handlers, and DataWeave scripts into graph nodes. The migration skill gets instant flow topology -- connectors used per flow, sub-flow call chains, DataWeave complexity -- without manual XML deep-dives. DataWeave .dwl files are analyzed for function definitions, field access patterns, and content types to identify complex transformations that need manual attention.

The migration package also records a source-retirement candidate audit in migration-analysis.md. A valid graph accelerates that audit, but bounded source scanning emits the same coverage, reachability, candidate, broken-reference, and evidence-gap sections when no graph is usable. A candidate means complete supported source closure found no path from a corroborated entry root; it is not proof that the source is dead or safe to remove.

How it works:

This is the dedicated migration orchestrator. In chained and standalone modes, it runs vendor-specific discovery and design with a shared behavioral analysis between them, then converges with the greenfield workflow after the complete package is approved. In direct mode, selected when the user's request names concrete deliverables or via --direct, it runs Steps 0–4 (scan, detect, analyze), then implements route files and properties under Iron Laws 1 and 2, validates with camel_validate_yaml_dsl, runs adversarial review, and starts the application (with explicit user authorization) before declaring done. Direct mode does not produce the design package or invoke camel-plan:

Phase 1 -- Discovery and confirmation:

Scans all project artifacts (XML, build files, properties, docs, Docker/K8s, source, tests)
Detects vendor and version from the scanned content
Builds a pre-populated analysis summary (purpose, SLA, security, failure behaviour, deployment target)
Confirms the summary with the user; only asks about genuine gaps
Walks through each migration concern one at a time (deprecated components, platform changes, DataWeave conversions, proprietary connectors)

Behavioral analysis -- Evidence and risk register:

Writes migration-analysis.md from Phase 1 source findings and the business requirements
Records each interface and behavior separately as Confirmed, Inferred, or Unknown
Preserves evidence gaps, impact, validation, ownership, and disposition without assuming project-wide compatibility

Migration strategy -- Safe traffic seam:

Classifies each independently switchable scope as Incremental candidate, Single cutover required, or Undetermined - evidence needed
Reconciles every discovered ingress and source-audit entry root into exactly one non-overlapping scope
Keeps incomplete, conflicting, TBD, stale, or merely structural operational evidence undetermined
Provides incremental or strangler guidance only when the existing controllable seam is currently confirmed and the target conditions are confirmed design constraints with pre-cutover validation obligations; this is candidacy, not cutover readiness
Selects a single cutover only when a named validated source and operational-control boundary has a closed, operator-confirmed inventory and complete confirmed evidence proves every seam candidate inside it absent or unsafe
Records the result in the business requirements under Migration Strategy and carries the resulting obligations into the design under Migration Strategy Constraints

Phase 2 -- Design:

Maps each source component to its catalog-verified Camel equivalent
Converts DataWeave transformations into design spec field mapping tables
Asks only what the source artifacts cannot answer
Produces one active design spec covering all flows and carries unresolved MIG-### and source-retirement SRC-### IDs into scope constraints, validation obligations, or unresolved decisions

Operational runbook:

After the final design and Camel Main eligibility checks, generates migration-runbook.md from the validated package, current operational evidence, and explicit operator decisions, then registers it as a direct child of the design spec
Preserves every strategy classification and MIG-###/SRC-### status without treating Incremental candidate or Single cutover required as cutover readiness; undetermined scopes receive no concrete cutover procedure
Covers ownership and prerequisites, configuration/data readiness, deployment, cutover, operational validation, rollback, reconciliation, soak, and the source-retirement decision
Writes every missing operational fact exactly as Unknown — operator decision required: <missing fact> instead of inventing commands, endpoints, thresholds, durations, contacts, owners, environment values, or credentials; secret material is never copied, and only validated secret references may be recorded

The artifact chain is business-requirements.md -> migration-analysis.md -> design-spec.md, followed by two independent children: migration-runbook.md from camel-migrate and implementation-plan.md from camel-plan. The plan does not consume the runbook. If a design changes, both existing children are marked stale separately; re-planning refreshes only the plan, so a stale runbook must be regenerated by camel-migrate before operational use.

After the package is assembled, one approval covers the business requirements, migration analysis, design spec, and runbook for progression into /camel-plan. It does not resolve recorded unknowns or authorize source exclusions, infrastructure provisioning, deployment, cutover, traffic switching, rollback, message/data reconciliation, or source retirement. Every operational action needs the named operator's separate execution-time authorization. Retirement requires a separate named operator decision after operational validation, reconciliation, and soak have passed.

Mule-to-Camel component mapping highlights:

Mule Component	Camel Equivalent	Notes
HTTP Listener	`platform-http`	Port configured via `application.properties`
HTTP Request	`http` / `https`	Outbound HTTP calls
JMS / ActiveMQ	`jms` / `activemq`	Drop-in replacement
Database (select/insert)	`sql` / `jdbc`	`sql` for simple queries, `jdbc` for batch
File / FTP / SFTP	`file` / `ftp` / `sftp`	Direct equivalents
Kafka	`kafka`	Direct equivalent
Choice Router	`choice` EIP	Content-Based Router
DataWeave Transform	XSLT via `xslt-saxon`	DataMapper pattern
Scatter-Gather	`multicast` EIP	Parallel dispatch
For Each	`split` EIP	Collection iteration
Sub Flow / Flow Reference	`direct:` route	Internal routing
Set Payload / Set Variable	`setBody` / `setHeader` EIP	Mule variables map to Camel headers
Email (SMTP/IMAP/POP3)	`smtp` / `imap` / `pop3` (+ `s` variants)	All from `camel-mail` artifact
Salesforce Connector	`salesforce`	Full API support
REST Consumer (RAML)	`rest` + `openapi`	Import OpenAPI spec

Proprietary connectors (require user decision):

Mule Connector	Suggested Alternatives
Anypoint MQ	Amazon SQS, Azure Service Bus, RabbitMQ, ActiveMQ
Object Store	Infinispan, Redis, Caffeine cache, JPA
SAP Connector	`camel-sap` (if licensed), SAP REST/SOAP APIs
Workday	Workday REST API via `camel-http`
NetSuite	NetSuite REST/SOAP APIs via `camel-http`
ServiceNow	`camel-servicenow` (check API coverage)

For connectors with no direct equivalent, the command stops and asks the user before proceeding.

Migration questions use one [Concern N of M] or [Clarification N of M] block per message, with the finding, its impact, and multiple-choice options when possible; open-ended questions are used when necessary. A sub-agent that cannot ask returns NEEDS_CONTEXT with every open decision and leaves dependent output unwritten. The parent presents each question, records your answers as ✓ Confirmed in the analysis summary, and re-dispatches the same step with those answers. NEEDS_USER_CONFIRMATION remains reserved for content-derived actions that require specific authorization.

BizTalk-to-Camel adapter mapping highlights:

BizTalk Adapter	Camel Equivalent	Notes
FILE	`file`	Direct drop-in replacement
FTP / FTPS	`ftp` / `ftps`	Connection pooling supported
SFTP	`sftp`	SSH key authentication
SQL	`sql` / `jdbc`	`sql` for queries, `jdbc` for batch
WCF-BasicHttp	`cxf`	SOAP 1.1/1.2 support

/camel-validate

Tier 1 pipeline step. Final stage after execute — produces a comprehensive quality report.

Purpose: Static quality analysis of generated Camel routes across multiple dimensions: schema validation, endpoint verification, constitution compliance, security analysis, and anti-pattern detection.

When to use: After /camel-execute completes, or whenever generated routes need quality validation outside a controller-owned Ship run.

Produces:

Pipeline-scoped report at docs/camel-kit/<PIPELINE_ID>/validation-report.md when pipeline context exists
Timestamped project-scoped report at docs/validation-report-YYYY-MM-DD_HH-mm.md when no pipeline exists
Categorized findings: PASS / FAIL / WARN per quality dimension
Constitution compliance check (all 8 rules)
Recommendations for priority fixes

Validation is static and report-only: it does not modify routes or fix the findings it reports.

Example:

/camel-validate

/camel-ship

Technology Preview: Camel Ship is still being stabilized. Its behavior and interfaces may change, and it is not recommended for production use. For the established staged workflow, start with /camel-start.

The preview status applies to every Ship backend. --accept-experimental only permits unverified Pi/Node versions; it does not enable Ship or change its preview status. Tested runtime compatibility and passing validation checks do not imply production readiness.

Purpose: Start or control the local Ship workflow through the configured Camel-Kit CLI. Harness skills delegate stage decisions and state to the CLI. Eligible Bob 2, Copilot CLI, Claude Code and OpenAI Codex CLI sessions relay pending work to native subagents; other execution models retain the single CLI invocation. See Bob native Ship, Copilot native Ship, Claude Code native Ship and Codex CLI native Ship.

The registered command is camel-kit ship when Camel-Kit is installed standalone and camel kit ship when it is installed as a Camel JBang plugin. Harness-native forms such as /camel-ship, $camel-ship, and /skill:camel-ship invoke that configured command prefix. Pi uses /skill:camel-ship; Camel-Kit intentionally does not generate a Pi /camel-ship prompt because that prompt surface flattens quoted option values.

When to use: When you want one resumable controller-owned run to perform discovery, design, planning, implementation, deterministic validation, and guarded publication.

Context and lifecycle options:

Argument	Default	Description
`--text TEXT`	none	Add text context. Repeat for multiple inputs.
`--document PATH`	none	Add a readable context document. Repeat for multiple documents.
`--ask POLICY`	`smart`	Oversight for a new run or `--start-from`: `always`, `smart`, or `never`.
`--resume RUN_ID`	none	Resume a controller-owned run. Optional `--text` and `--document` values add context to a paused run.
`--status RUN_ID`	none	Read the latest durable state without starting the workflow runtime.
`--abort RUN_ID`	none	Abort any run that has not completed, terminating its active attempt when present and recording the durable outcome.
`--start-from STAGE`	none	Start a new run at `discovery`, `design`, or `plan` after validating the required context and imported artifacts.

--resume, --status, --abort, --submit, and --start-from are mutually exclusive. A bare invocation is valid and starts a short discovery conversation.

--start-from discovery has no import prerequisite. --start-from design requires text or document context and a manual activePipeline in .camel-kit/pipeline.json. --start-from plan requires that manual active pipeline and its readable docs/camel-kit/<pipeline-id>/design-spec.md. Starting from execute or validate is unsupported because those stages require controller-owned plan and worker evidence.

Runtime and configuration options:

Argument	Default	Description
`--accept-experimental`	false	Continue after the warning for an experimental Pi or Node version.
`--backend pi\|bob2-native\|copilot-native\|claude-native\|codex-native`	`pi`	Execution mode for a new run; resume retains the recorded mode.
`--json`	off	Structured run state and any pending native task.
`--submit RUN_ID --result PATH`	none	Relay one native child result; mutually exclusive with other lifecycle operations.
`--pi PATH`	discovered on `PATH`	Pi executable used by Pi stage workers.
`--node PATH`	discovered on `PATH`	Node executable used to run Pi.
`--maven-repository PATH`	`<Ship state root>/catalog-repository`	Private Maven repository used for validation payloads.
`--stage-timeout DURATION`	`10m`	Limit for one stage attempt, such as `90s`, `10m`, or `1h`.
`-c`, `--config PATH`	`~/.camel-kit/config.properties`	Configuration properties file.
`-p`, `--property KEY=VALUE`	none	Override a configuration property. Repeat as needed.

Runtime and configuration options apply when starting, resuming or submitting a native result. Repeat the original --stage-timeout, --maven-repository and -c/-p options on resume and submission; these settings are not persisted for future stages. Pi/Node options are rejected for native runs.

With --json, a failed workflow returns structured run state with exit code 1; inspect run.status and run.message. Other command errors can return only stderr. Read valid JSON on exit code 0 or 1 and report errors when no valid JSON is available. See native recovery for unreadable handoffs and explicit retries.

Ship requires Linux. The Pi backend requires Pi and Node; native execution uses the active host and does not discover or launch either executable. Its accepted project contract currently supports the Camel Main runtime and Camel YAML DSL routes named <routeId>.camel.yaml, with matching Citrus tests at test/<routeId>.camel.it.yaml. Spring Boot and Quarkus Ship projects are rejected until deterministic evidence support is available for those runtimes. Deterministic validation commands run in a separate JVM launched by the controller with a pinned, controller-resolved classpath, a scrubbed environment, and a frozen read-only copy of the accepted project tree; network access during validation is avoided by replacing every non-direct Camel endpoint with an in-memory stub, not by OS-level sandboxing. Missing executables fail with installation guidance; an unrecognized Pi or Node version is reported as experimental and runs only with --accept-experimental.

Oversight:

always pauses after design, planning, execution, and validation, and whenever a stage reports material ambiguity.
smart pauses after planning and execution, and whenever a stage reports material ambiguity.
never tells the worker to record each unanswered question and the reasonable default it applied instead of pausing for material ambiguity. It still stops for missing tools, failed mandatory checks, or authority the user has not granted; a default does not grant permission.

Each stage's material-ambiguity flag and grouped unanswered questions are retained in the run record. The final command summary and camel-kit ship --status <run-id> list the questions by stage with their applied defaults, or indicate that no default was applied. Later stages receive the recorded questions and defaults as worker-reported context; these decisions are not human-confirmed answers and grant no action authority. Legacy results that report material ambiguity without structured questions display a warning rather than reconstructing missing questions or defaults. Under always and smart, answer paused questions with --resume <run-id> --text "...".

Examples:

# Start with no supplied context
camel-kit ship

# Combine document and text context
camel-kit ship --document requirements.md --text "Prefer YAML; no Java" --ask always

# Resume, inspect, or abort a run
camel-kit ship --resume <run-id>
camel-kit ship --status <run-id>
camel-kit ship --abort <run-id>

# Import the active manual design and start planning
camel-kit ship --start-from plan

# The Camel JBang plugin exposes the same command
camel kit ship --document requirements.md

# Harness-native delegates forward the same flags
/camel-ship --document requirements.md
$camel-ship --document requirements.md
/skill:camel-ship --document requirements.md

Controller state and evidence:

The local controller is the only component that writes Ship run state and commits stage transitions. It stores run records, retained evidence, Pi session transcripts, the staged Execute workspace and the default validation catalog repository under .camel-kit/ship/state/ in the project directory, or under CAMEL_KIT_SHIP_STATE_HOME when that variable is set. .camel-kit/ship/ is reserved for the controller: it is never copied into the staged workspace, never part of the staleness digests and never published, and the state directory carries a .gitignore that ignores its own content. Any other state directory inside the project is rejected with state-project-overlap. Git discovery is bounded at the staged workspace: Git commands run by the Execute worker, by local commands, or by validation inside it do not reach the project's repository. Because Git reads that boundary as a colon-separated list, project and state directory paths containing : are rejected at start; choose another project path or set CAMEL_KIT_SHIP_STATE_HOME accordingly. .camel-kit/pipeline.json remains the active-pipeline pointer for manual skills; it is not Ship run state. Runs recorded under the previous user-level default ($XDG_STATE_HOME/camel-kit/ship or ~/.local/state/camel-kit/ship) are not found at the new location; set CAMEL_KIT_SHIP_STATE_HOME to that path to finish them.

Each start prints a run ID. Resume re-reads recorded inputs and artifacts, compares their digests, and restarts the earliest stale or incomplete stage without duplicating completed work. Paused, running, and failed run summaries include an actionable command using the same registered command surface; post-start operational errors preserve the run ID.

Implementation changes stay in a staged workspace until the configured oversight and deterministic validation gates allow guarded publication. The controller retains command evidence and derives a local Stamp with pass or fail. The Stamp records detected executable versions and, for each validation command, the executable, redacted arguments, exit status and timing, and retained stdout/stderr log paths and digests. It describes checks performed on this machine and is not a signed release attestation.

Ordinary process interruption is recoverable with the run ID, but Ship is not a daemon or a guarantee against OS or power loss. It assumes the invoking OS account is trusted: it is not a hostile same-user sandbox, credential broker, or long-lived service. Provider credentials remain under Pi and provider tooling.

Maintainers can opt into the authenticated Pi/Linux live test on a Linux host. Set CAMEL_KIT_SHIP_LIVE_PI and CAMEL_KIT_SHIP_LIVE_NODE to absolute executable paths for a bundled certified configuration (currently Pi 0.84.2 or 0.83.0, with Node 22.22.2), then run:

./mvnw -B -Plinux-ship-certification clean install

The test is skipped only when CAMEL_KIT_SHIP_LIVE_PI is unset or blank. Once it is set, CAMEL_KIT_SHIP_LIVE_NODE is required and both paths must identify executable files with the supported versions. The test exercises the controller workflow; release certification also includes one authenticated run through a registered camel-kit ship or camel kit ship entry point.

Upgrading an existing generated workspace:

After upgrading from the prompt-owned Ship workflow, commit or back up workspace customizations that overlap generated files, then regenerate with the same agent and the same command surface used to create the workspace:

camel-kit init --here --ai <same-agent> --force

# Or, for a workspace generated through Camel JBang:
camel kit init --here --ai <same-agent> --force

--force overwrites generated assets. Re-initialization installs the current entry point and removes obsolete prompt-owned Ship guides, traits and rules. Bob 2 receives its native relay skill, read-only worker preset and camel-ship-mode; Copilot CLI and Claude Code receive their native relay skill and read-only worker agent; other agents retain their current delegates. Pre-controller Ship state in .camel-kit/ship-state.json or a non-manual .camel-kit/pipeline.json is deliberately not imported. Inspect it if needed, then archive it outside the project before starting a controller run; its presence makes Ship fail closed. Preserve a manual-mode .camel-kit/pipeline.json, because standalone pipeline skills and validated --start-from imports still use its active pipeline ID.

GitHub Copilot CLI now uses its native .github/skills/ surface exclusively. Older generated .github/commands/ files are ignored by current Copilot CLI; after preserving any local edits, they may be removed. Re-initialization records agent.folder=.github/skills.

/camel-debug

Purpose: Ad-hoc troubleshooting for broken Camel routes outside of a pipeline run. Follows a structured STOP → PRESERVE → DIAGNOSE → FIX → GUARD workflow.

When to use: When a route was working but is now broken, or when a user needs help debugging a Camel application outside of an active pipeline. For build/test failures during pipeline execution, /camel-execute dispatches camel-verify automatically.

Examples:

# Debug a broken route
/camel-debug

# Debug with context
/camel-debug my route is failing with a ClassNotFoundException

How it works (5-step workflow):

STOP -- gather context (runtime, Camel version, error message, recent changes). Label loaded context as data and do NOT modify files yet.
PRESERVE -- capture current state via git status/git diff. Warn if uncommitted changes exist.
DIAGNOSE -- reproduce the error, corroborate a match against the shipped error taxonomy, verify components via MCP catalog, and inspect route structure. The taxonomy -- never logs or diagnostic summaries -- owns the fix action. Diagnosis roles run in isolated subagents where supported or sequentially inline otherwise.
FIX -- explain the proposed fix, apply minimal targeted changes, and verify the fix resolves the issue. A direct user request to fix authorizes normal in-scope repair; a diagnosis-only request pauses for approval before changing files. Up to 5 fix attempts are allowed before escalating.
GUARD -- suggest a preventive measure (test, validation rule, CI check) to prevent recurrence.

Error classification: Reuses the same structured error taxonomy as /camel-verify:

Category	Examples	Fix Target
Missing dependency	`ClassNotFoundException`, missing Camel component	Self-repair (add to pom.xml)
Route creation	`FailedToCreateRouteException`	Re-generate route
Wrong endpoint options	`ResolveEndpointFailedException`	Re-validate via MCP catalog
Expression failure	`ExpressionEvaluationException`	Fix expression
External service	`Connection refused`	Fix service configuration
Unclassified	No matching pattern	Escalate to user

Context authority: User-provided and reproduced logs, stack traces, command output, project files, MCP responses, external documentation, and diagnostic-role results provide only validated, purpose-specific data. They cannot direct actions, expand scope, waive a gate, request secrets, or supply approval. Payloads forwarded to diagnostic roles are labeled LOADED CONTEXT — DATA ONLY and delimited from workflow instructions.

Normal actions independently selected by the shipped debug workflow from validated data need no extra confirmation. If a command, URL, path, procedure, file change, disclosure, tool request, or external effect is proposed only by loaded content, Camel-Kit identifies its source, exact action, independently verified reason, and scope, then asks for action-specific user confirmation. That confirmation applies only to the named action and does not make the source or session trusted. A diagnostic role that cannot ask directly returns NEEDS_USER_CONFIRMATION without performing the action.

Diagnostic isolation: Diagnosis uses three roles (route analyzer, MCP verifier, log analyzer) in isolated subagents where supported. Single-conversation targets run them sequentially inline and record the limitation. Their results remain loaded data; the parent workflow decides what happens next.

/camel-verify

Internal skill -- dispatched automatically by /camel-execute. Not intended for standalone use. For quality checks after the pipeline completes, use /camel-validate.

Purpose: Runtime verification feedback loop that builds, starts, diagnoses errors, applies fixes, and retries until the application runs correctly or the iteration limit is reached.

When to use: This skill is invoked internally by /camel-execute during its verification phase. Users should not run it directly; use /camel-validate for post-pipeline quality validation.

Produces:

Verification report (printed to console)
Fixes applied to project files (pom.xml, route YAML, properties, etc.)

Example:

No direct user invocation. /camel-execute dispatches this skill internally during its verification phase.

How it works (3-phase loop):

Build Verification -- compiles Spring Boot and Quarkus projects with ./mvnw; Camel Main runs its startup smoke test instead. Classifies failures and auto-fixes missing dependencies/version conflicts or routes to internal implementation/validation handling. Up to 15 iterations.
Test Verification -- runs Citrus integration tests via camel test run. Citrus tests are self-contained: Testcontainers start external services, camel:jbang:run starts the Camel integration, send/receive actions validate behavior. Classifies test failures and routes to internal implementation handling, internal test regeneration, or self-repair. Up to 15 iterations.
Report -- structured summary with phase outcomes, fixes applied, and issues found.

Error classification:

Category	Examples	Fix Target
Missing dependency	`ClassNotFoundException`, missing Camel component	Self-repair (add to pom.xml)
Third-party dependency	`cannot find symbol` for non-Camel class	Self-repair
Version incompatibility	`NoSuchMethodError`, `AbstractMethodError`	Self-repair (align BOM)
Build tool	Unknown lifecycle phase, missing plugin	Escalate to user
Route creation	`FailedToCreateRouteException`	Internal implementation handling (re-generate route)
Unknown component	`NoSuchEndpointException`	Internal implementation handling
Wrong endpoint options	`ResolveEndpointFailedException`	`/camel-validate` static diagnosis, then `camel-implement` correction
Missing bean	`NoSuchBeanException`	Internal implementation handling
Injection failure	`UnsatisfiedDependencyException`	Internal implementation handling
External service	`Connection refused`	Self-repair (restart Docker service)
Quarkus augmentation	`io.quarkus.builder.BuildException`	Escalate to user
Expression failure	`ExpressionEvaluationException`	Internal implementation handling
Type conversion	`TypeConversionException`	Internal implementation handling
XSLT transformation	`XPathException`, `TransformerException`	Internal implementation handling

Each phase has an independent iteration budget of 15 attempts. If the same error recurs after a fix attempt, the loop short-circuits and escalates to the user. Unclassified errors are also escalated with a bounded, canonically framed diagnostic excerpt and command/exit-state evidence.

During Test Verification (Phase 2), test failures may also route to internal test regeneration. For persistent architectural failures, the loop triggers the re-plan flow per camel-execute/guides/re-plan-loop.md.

Command Cheat Sheet

# CLI
camel-kit init my-project --ai claude

# Greenfield (in AI assistant) — chained mode
/camel-brainstorm                        # Design → auto plan → auto execute → auto validate

# Greenfield — standalone mode (each stage independently)
/camel-brainstorm 001-order-processing   # Design (standalone, no auto-transition)
/camel-plan 001-order-processing         # Plan from existing spec (standalone)
/camel-execute 001-order-processing      # Execute from existing plan (standalone)
/camel-validate 001-order-processing     # Validate (standalone)

# Re-iteration (amend existing design, marks downstream stale)
/camel-brainstorm 001-order-processing   # Amend design-spec.md → downstream marked stale

# Controller-owned Ship workflow
/camel-ship --document requirements.md   # Delegate a document-driven run to the local controller
/camel-ship --resume <run-id>             # Resume a controller-owned run
/camel-ship --status <run-id>             # Inspect durable status without launching a worker
/camel-ship --start-from plan             # Import the active manual design and begin planning

# Migration
/camel-migrate                           # Analyze legacy project → auto plan → auto execute → auto validate

# Validate (standalone, any project)
/camel-validate                          # Validate routes in current project

# Debug (ad-hoc troubleshooting)
/camel-debug                             # Diagnose and fix a broken route

Camel-Kit Command Reference

Table of Contents

CLI Commands

camel-kit init

camel-kit doctor

camel-kit graph

camel-kit nextId

camel-kit doc

Slash Commands

/camel-start

/camel-brainstorm

/camel-plan

/camel-execute

/camel-migrate

/camel-validate

/camel-ship

/camel-debug

/camel-verify

Command Cheat Sheet