Pipeline

Overview

The Camel-Kit pipeline transforms integration requirements into working code through a three-phase orchestrated workflow. Each phase has a specific responsibility, and explicit approval gates ensure you maintain control.

The Three Phases

Phase 1: Design

💡 /camel-brainstorm

Goal: Transform vague integration ideas into formal Design Specifications

Socratic questioning about your requirements
MCP catalog verification of all components
Generation of 7-section Design Specification

Output: Design Specification ready for approval

Why this matters: Most AI coding tools jump from prompt to code. This works for scripts but fails for complex integrations. Camel-Kit separates requirements gathering from implementation.

Phase 2: Plan

📋 /camel-plan

Goal: Break the design into executable tasks with dependencies

Analyze design spec and identify distinct flows
Create task breakdown with acceptance criteria
Build dependency graph for wave analysis

Output: Implementation Plan with parallelizable task waves

Why this matters: Without decomposition, you get a giant blob of code. Tasks enable incremental validation and parallel execution.

Phase 3: Execute

⚙️ /camel-execute

Goal: Transform the plan into working, verified code

Wave-based parallel task execution
Two-stage review per task (spec compliance + code quality)
Generation of routes, tests, and configuration

Output: Complete Maven project with verified artifacts

Auto-invokes: /camel-verify for runtime validation

Approval Gates

Each phase has a gate. The AI cannot proceed without your explicit approval. Toggle to see each gate:

Gate 1: Design Approval

After /camel-brainstorm completes, the AI presents the Design Specification with 7 sections (business purpose, flows, endpoints, data formats, error handling, technical requirements, observability).

You must explicitly approve before /camel-plan begins. You can request changes — the AI revises and re-presents.

Gate 2: Plan Approval

After /camel-plan completes, the AI presents the task breakdown with wave analysis showing which tasks can run in parallel.

You must explicitly approve before /camel-execute begins. Review task scope, acceptance criteria, and dependencies.

Verification: No approval needed. After /camel-execute completes, /camel-verify runs automatically. It’s non-destructive — builds, starts, tests, and reports. If it fails, the AI fixes and retries without asking.

Iron Laws

Four non-negotiable rules enforced across all phases:

Every Apache Camel component name must be verified against the MCP catalog before appearing in any design or code. Prevents AI hallucination — no invented component names.

User: I need to connect to Kafka

AI: (Calls MCP catalog lookup for "kafka")
    ✓ Found: camel-kafka

If a component doesn’t exist, the AI asks for clarification instead of guessing.

Every generated route must comply with the Constitution’s 7 rules:

Route Structure — from → process → to
Single Responsibility — one route = one business capability
Separation of Concerns — no business logic in technical routes
Naming Conventions — kebab-case route IDs, camelCase beans
Observability — metrics, logging, tracing
External Configuration — no hardcoded values
Supported Components — only catalog-verified components

The AI cannot generate implementation code until the Design Specification is explicitly approved. Prevents wasted effort — if the design is wrong, the implementation will be wrong.

/camel-execute checks for approved design spec before starting. If none found: “Please run /camel-brainstorm first.”

Every artifact must pass spec compliance review before code quality review. Two-stage review per task:

Stage 1: Does this match the spec’s acceptance criteria?
Stage 2: Is this well-written? Does it follow the constitution?

If stage 1 fails, regenerate without running stage 2.

Internal Skills

Three skills are loaded by /camel-execute — not user-invocable:

Generates Camel YAML route definitions from task specifications. Uses templates and follows the constitution.

Input: Task description with acceptance criteria
Output: .camel.yaml route file
Loaded by: /camel-execute for each implementation task

Creates Citrus integration tests for behavioral verification with Testcontainers.

Input: Route specification and test scenarios
Output: Citrus Java test class
Loaded by: /camel-execute during test generation tasks

Validates component names against the MCP catalog and checks YAML syntax, constitution compliance, and security.

Input: Route YAML file
Output: Timestamped validation report
Loaded by: /camel-execute during spec compliance review

Pipeline Patterns

You: I need to build an order processing integration

AI: /camel-brainstorm → Interview → Design Spec
    (You approve)
AI: /camel-plan → Task decomposition → Plan
    (You approve)
AI: /camel-execute → Wave-based generation → Code
AI: /camel-verify → Build → Start → Test → Report

Total: 1 command, 2 approvals, 4 phases

You: Migrate my MuleSoft flows to Camel

AI: /camel-migrate → Detect → Parse → Graph → Design
    (You approve flow 1 design)
AI: /camel-plan → Task decomposition
    (You approve)
AI: /camel-execute → Generate migrated code
AI: /camel-verify → Verify migrated flow

Flow 1 complete! Ready for flow 2?

You: I need a REST API that writes to a database

AI: /camel-brainstorm → Interview → Design Spec

You: Actually, add caching before the database

AI: (Revises design spec)

You: Approved

AI: /camel-plan → /camel-execute → /camel-verify

You: The build is failing with a dependency error

AI: /camel-verify
    → Classifies as build error
    → Fixes POM dependency
    → Retries build
    → Build succeeds
    → Continues to runtime tests...

What’s Next

Dive into each phase:

/camel-brainstorm — Phase 1: Design interview
/camel-plan — Phase 2: Task decomposition
/camel-execute — Phase 3: Code generation
/camel-verify — Runtime verification loop