Pipeline
The design-to-code pipeline — manual or autonomous
Overview
The Camel-Kit pipeline transforms integration requirements into working code through an orchestrated workflow. You can run it two ways:
- Manual (3-phase): Invoke
/camel-brainstormand approve each phase transition. Full control at every step. - Autonomous (
/camel-ship): Run the entire pipeline in one command with configurable oversight — from--ask always(approve everything) to--ask never(fully autonomous).
Both modes execute the same phases and enforce the same Iron Laws.
The Three Phases
Approval Gate
The design phase has an approval gate. 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 the pipeline continues. You can request changes — the AI revises and re-presents.
After design approval, planning and execution auto-proceed without additional approval gates. /camel-plan generates the task breakdown and automatically transitions to /camel-execute. /camel-verify then runs automatically after execution completes — it’s non-destructive, building, starting, testing, and reporting. 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. After design approval, planning and execution auto-proceed without additional gates. 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.yamlroute file - Loaded by:
/camel-executefor 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-executeduring 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-executeduring 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
(Auto-proceeds)
AI: /camel-execute → Wave-based generation → Code
AI: /camel-verify → Build → Test → Report
Total: 1 command, 1 approval, 4 phases
You: Migrate my MuleSoft/BizTalk flows to Camel
AI: /camel-migrate → Detect → Parse → Graph → Design
(You approve flow 1 design)
AI: /camel-plan → Task decomposition
(Auto-proceeds)
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...
Autonomous Mode: /camel-ship
For hands-off execution, /camel-ship chains all four phases with configurable oversight:
# Smart oversight (default) — pauses only on ambiguity
/camel-ship requirements.md
# Fully autonomous — pauses only on blockers, creates PR at the end
/camel-ship requirements.md --ask never --create-pr
# Resume interrupted pipeline
/camel-ship --resume
Three oversight levels control when the pipeline pauses:
| Level | Behavior |
|---|---|
always | Pause for approval at every stage |
smart | Auto-proceed when clear, pause on ambiguity |
never | Fully autonomous — only stop on blockers |
See /camel-ship for the full autonomous pipeline documentation.
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
- /camel-ship — Autonomous pipeline with configurable oversight
Design Interview
/camel-brainstorm — Phase 1: AI-guided design interview
Task Planning
/camel-plan — Phase 2: Task decomposition and planning
Code Generation
/camel-execute — Phase 3: Orchestrated execution with two-stage review
Runtime Verification
/camel-verify — Runtime verification feedback loop
Autonomous Pipeline
/camel-ship — End-to-end pipeline with configurable oversight