Command Reference

Generate an implementation plan from an approved design spec. This is Phase 2 of the pipeline.

Process:

1. Reads the approved design spec
2. Decomposes into implementation tasks with acceptance criteria
3. Runs wave analysis to identify dependency order and concurrency candidates
4. Specifies two-stage review per task (spec compliance then quality)
5. Continues to /camel-execute when running inside an orchestrated pipeline

Output: docs/camel-kit/<pipeline-id>/implementation-plan.md

Key rule: The plan is a recipe, not the meal — it describes WHAT to generate and HOW to generate and verify it, without embedding the generated artifact contents.

Execute the implementation plan with orchestrated task dispatch. This is Phase 3 of the pipeline.

Process:

1. Analyzes plan for dependency waves and target-capable concurrency
2. For each task: implement → adversarial review → spec compliance review → code quality review
3. Loads internal skills as needed (camel-implement, camel-test, camel-verify)
4. Runs internal runtime verification, then transitions to /camel-validate only in a same-conversation chained flow

Generated artifacts:

• .camel.yaml routes
• application.properties
• docker-compose.yaml when external services require it
• An XSLT stylesheet when XSLT DataMapper is selected, or inline Groovy in the route
• Citrus test definitions
• Execution report

Run static quality analysis after execution. This is Phase 4, the final pipeline stage. It validates routes for correctness, security, and constitution compliance, and reports findings without modifying routes.

Validation categories:

• Schema and endpoint verification
• Configuration validation
• Quality and anti-pattern checks
• Security analysis
• Constitution compliance (all 8 rules)

Output: Pipeline-scoped runs write docs/camel-kit/<pipeline-id>/validation-report.md. A standalone project-scoped run with no pipeline writes docs/validation-report-YYYY-MM-DD_HH-mm.md.

Migration-specific discovery and design for existing integrations.

Supported source platforms:

JBoss Fuse has no dedicated --source-platform value: Fuse projects are Camel 2.x/3.x codebases, so pass --source-platform camel or leave the default auto, which detects the redhat-*/fuse-* version qualifiers.

Features:

• Auto-detect source vendor
• Graph-based flow analysis
• DataWeave and BizTalk map parsing
• Flow-aware analysis assembled into one migration design package, approval, plan, and execution

Diagnose and repair broken routes outside an active pipeline run with a strict STOP → PRESERVE → DIAGNOSE → FIX → GUARD sequence.

Use it for startup failures, runtime exceptions, or incorrect behavior. Build and test failures during pipeline execution remain part of the internal camel-verify loop.

Delegate a Ship run to the local workflow controller. /camel-ship is a thin wrapper: it runs the registered camel-kit ship (or camel kit ship) command once with the options you supply, adds no defaults, and returns the command output. The local controller — not the agent — owns Ship stages, run state, oversight, evidence, and guarded publication. No harness command implements a second workflow.

Per-harness surfaces:

Upgrading from the prompt-owned Ship: earlier releases generated an agent-orchestrated Ship workflow. After upgrading, regenerate the workspace with camel-kit init --here --ai <same-agent> --force (or camel kit init ...); --force rewrites generated assets, so commit or back up customizations first. Re-initialization removes the obsolete Ship guides, harness traits, and Bob 2 Ship mode assets. A pre-controller .camel-kit/ship-state.json (or a non-manual .camel-kit/pipeline.json) makes Ship fail closed — archive it outside the project first.

See camel-kit ship under CLI Commands for the full option reference.

Start, inspect, resume, or abort a local Camel Ship run. The controller performs discovery → design → plan → execute → validate and, after the configured approval and validation gates, publishes accepted changes to the project. The harness commands (/camel-ship, $camel-ship, /skill:camel-ship) are thin wrappers around this command.

Usage:

camel-kit ship [options]
camel kit ship [options]

A bare camel-kit ship starts a new run at discovery with a short discovery conversation. Initial context is optional: text, one or more documents, or both — a requirements document is never mandatory. Supplied material is included in discovery input before questions.

Options (canonical descriptions, defaults, and prerequisites: Command and Options on the Ship Workflow page):

• Context: --text TEXT and --document PATH, both repeatable — valid when starting or resuming a run
• Oversight: --ask always|smart|never (default smart) — valid when starting a run, including with --start-from; not with --resume, --status, or --abort
• Run operations: --resume RUN_ID, --status RUN_ID, --abort RUN_ID, --start-from discovery|design|plan — mutually exclusive; --start-from prerequisites are listed on the Ship page
• Runtime and configuration: --pi PATH, --node PATH, --maven-repository PATH, --stage-timeout DURATION, --accept-experimental, -c/--config PATH, -p/--property KEY=VALUE — valid when starting or resuming

Configuration is loaded strictly: a missing or unreadable config file or a malformed override is an error, not a warning. Repeat the same -c/-p options when resuming a run.

Oversight (--ask):

• always — pauses after design, plan, execute, and validate, and on material ambiguity.
• smart (default) — pauses after plan and execute and on material ambiguity; a fully passing validation proceeds to guarded publication without a further pause.
• never — records reasonable defaults and does not pause, but the run still fails on failed mandatory validation checks, and publication remains controller-gated.

Run state and Stamp: run state lives outside the project, under $CAMEL_KIT_SHIP_STATE_HOME, else $XDG_STATE_HOME/camel-kit/ship, else ~/.local/state/camel-kit/ship. .camel-kit/pipeline.json remains a manual-mode pointer only; Ship never stores run state there. --resume re-reads recorded context and artifacts, compares digests, and restarts the earliest stale or incomplete stage. Validation produces a local Stamp whose pass/fail status is derived from the required checks; per check it records the executable, version, arguments with secrets redacted, exit status, and retained output. The Stamp describes checks performed on this machine and is not a signed release attestation.

Publication and recovery: discovery, design, plan, and validate never modify application source; execute works in a controller-owned staging copy, and accepted changes are published to the live project only after the configured approval and validation gates. An interrupted process is recoverable with the run ID, but Ship is a local orchestrator — not a daemon, a hostile same-user sandbox, a credential broker, or a release-attestation system. Provider credentials remain with Pi and provider tooling; Ship does not persist them or include them in command arguments, logs, or reports.

Requirements and compatibility: the first Ship worker runs on Linux only and needs Pi and Node. Ship targets Camel Main at the configured camel.main.version, which defaults to the bundled distribution pin and can be overridden through -p or -c, with YAML DSL, Simple expressions, no Java artifacts, and a required Citrus test for every route. The certified Pi versions are 0.84.2 and 0.83.0, with Node 22.22.2; any other detected version is reported as experimental and runs only with --accept-experimental. The compatibility tiers and the current live-gate status are documented in Worker Requirements and Support Tiers.

Examples:

camel-kit ship
camel-kit ship --text "Consume Kafka orders and send them to Salesforce"
camel-kit ship --document requirements.md
camel-kit ship --document requirements.md --text "Prefer YAML and Simple; no Java"
camel-kit ship --resume <run-id>
camel-kit ship --status <run-id>
camel-kit ship --abort <run-id>
camel-kit ship --start-from plan

Validate a generated Camel-Kit workspace. Use camel-kit doctor for the standalone CLI or camel kit doctor for the Camel JBang plugin.

camel-kit doctor [--project-dir <path>] [--json]
camel kit doctor [--project-dir <path>] [--json]

Doctor checks generated configuration, target-native entry points, registered workspace templates, skills, MCP configuration and allowlists, graph availability, command-prefix settings, prerequisites, and stale generated references. For Codex it also validates .codex/config.toml, prompt approval defaults, and .codex/agents/*.toml. Legacy Qwen/OpenCode configurations that predate current filter and permission fields produce upgrade warnings; malformed current configurations fail. A workspace generated before Citrus MCP support produces a warning for the missing citrus server on every JSON-configured agent, while a present but malformed citrus server fails. For OpenCode, all existing configuration layers are evaluated as one effective configuration and each finding names the file that defines the rule. It prints PASS, WARN, and FAIL findings with remediation; any failure returns exit code 1.

Track pipeline artifact provenance and staleness in YAML frontmatter. Use camel-kit doc with the standalone CLI or camel kit doc with the Camel JBang plugin.

camel-kit doc <init|check|stale|unstale> [options]
camel kit doc <init|check|stale|unstale> [options]

Examples:

camel-kit doc init --by camel-plan --from design-spec.md <file>
camel-kit doc init --by camel-brainstorm <file>
camel-kit doc check <file>
camel-kit doc stale --reason "design changed" --cascade <file>
camel-kit doc unstale <file>

--from is optional; include it when the new document derives from an upstream pipeline artifact. --cascade follows each document’s generated.from chain and marks downstream artifacts stale. Regenerated artifacts are cleared with doc unstale.

Create the next sequential pipeline directory and print its ID. Use camel-kit nextId with the standalone CLI or camel kit nextId with the Camel JBang plugin.

camel-kit nextId <slug>
camel kit nextId <slug>

The slug must contain lowercase letters, digits, and single hyphens. The command finds the highest numbered directory under docs/camel-kit/, creates the next one (for example, 003-order-processing), and prints that ID.

Query the project’s property graph for code intelligence.

camel-kit graph stats                           # Graph availability check
camel-kit graph generate                        # Rebuild project graph
camel-kit graph find --type CAMEL_ROUTE         # Find nodes by type
camel-kit graph neighbors <node-id>             # Get connected nodes
camel-kit graph route-flow <route-id>           # Trace a route's flow
camel-kit graph dead-code                       # Detect unused code
camel-kit graph project-norms                   # Get project norms for validation
camel-kit graph project-context                 # Get context for implementation
camel-kit graph route-context <route-id>        # Get context for testing
camel-kit graph migration-context <route-id>    # Structured migration context (JSON)
camel-kit graph visualize                       # Generate interactive HTML visualization
camel-kit plan analyze <plan-file>              # Analyze plan for parallel execution waves