Greenfield Workflow

The first pipeline run needs an active pipeline ID. Because init does not create one, /camel-brainstorm prompts you to create it when none exists (see camel-kit nextId in the command reference):

camel-kit nextId order-processing
# Camel JBang plugin equivalent: camel kit nextId order-processing

Then launch the design phase by invoking the /camel-brainstorm command:

/camel-brainstorm

The interview adapts to what you have already supplied and asks one unresolved question at a time:

• Project questions (Q1–4) establish the name, business purpose, systems landscape, and integration goals or flow names.
• Per-flow questions (Q5–9) cover each flow’s intent and data, source, transformations, sink, and error handling, with field-mapping, routing, and resilience follow-ups only when needed.
• Cross-cutting questions (Q10–13) cover relevant performance, security, monitoring, and remaining constraints; categories that do not apply are recorded with a rationale.

The AI first analyzes any requirements, examples, or other project material you provide and does not re-ask facts that are already resolved. Complete material can require no clarification questions. The examples below illustrate possible exchanges rather than a fixed checklist:

AI: What business problem does this integration solve? 
    What is the primary purpose?
You: We need to process incoming orders from an HTTP API,
validate them, enrich with customer data, and send
to our fulfillment system.

AI: What systems will this integration connect? Where does 
    data come from and where does it go?
You: Orders arrive via REST POST at /api/orders. Customer
data comes from a PostgreSQL database. Validated orders
go to a Kafka topic called "fulfillment.orders".

AI: What data formats are involved? JSON, XML, CSV?
You: Orders arrive as JSON. Customer enrichment adds fields
from the database. Output to Kafka is also JSON.

AI: What transformations or business logic need to happen? 
    Any validation rules?
You: Validate that order amount > 0 and customer ID exists.
Enrich with customer email and address from the database.
Calculate order total including tax.

AI: How should the integration handle errors? Dead letter 
    queues? Retry logic?
You: Invalid orders should go to a separate Kafka topic
"orders.invalid" with the validation error. Database
failures should retry 3 times with exponential backoff.

AI: What are the throughput and latency requirements?
You: We expect 100-500 orders per minute during peak hours.
Processing should complete within 2 seconds per order.

After requirements are complete and before assembling the design, the AI verifies every source and sink component against the MCP catalog. In this example, it confirms that kafka exists for the selected Camel version and runtime.

After discovery, the AI generates a formal Design Specification with exactly six sections:

Review this carefully. Once you approve, the AI proceeds to planning. To approve: “Looks good, let’s proceed!”

The AI automatically invokes /camel-plan and decomposes the design into route, configuration, dependency, test, and conditional infrastructure tasks. The table below shows selected route tasks; supporting artifact and test tasks are omitted for brevity:

After writing the plan, /camel-plan automatically invokes /camel-execute under the existing design approval:

Auto-invoking /camel-execute to implement the plan...

For each task, the executor dispatches the persona and guides declared by the plan. Route and configuration tasks use camel-implement; test tasks use camel-test. Every task then goes through the applicable review stages:

1. Implements - Generates the task’s declared artifact with its assigned skill
2. Adversarial Review - A fresh-context moderator and parallel critics inspect the task diff where supported; single-conversation targets such as Bob 1 and Pi run the critic lenses sequentially and record the missing isolation. Verified failures return to implementation before staged review.
3. Spec Compliance Review - Validates the route matches the task’s acceptance criteria
4. Code Quality Review - Checks constitution compliance (single responsibility, observability, external config, etc.)

You’ll see progress updates:

Wave 1/4: Task 1 (REST Endpoint)
  - Implementing route...
  - Adversarial review: PASS
  - Spec compliance: PASS
  - Code quality: PASS
  - Task 1 complete

Wave 2/4: Running 3 independent tasks concurrently where supported...
  Task 2 (Validation Flow)
    - Implementing route...
    - Spec compliance: PASS
    - Code quality: PASS
  
  Task 3 (Customer Enrichment)
    - Implementing route...
    - Spec compliance: PASS
    - Code quality: PASS
  
  Task 6 (Dead Letter Queue)
    - Implementing route...
    - Spec compliance: PASS
    - Code quality: PASS

All routes follow the constitution:

• Single responsibility per route
• Separation of concerns (reception → validation → enrichment → publish)
• Observability (route IDs and descriptions, with context-specific correlation and logging)
• External configuration (database URL, Kafka brokers from application.properties)
• Only supported components (verified via MCP catalog)

During /camel-execute, the AI dispatches internal camel-verify after implementation:

Dispatching camel-verify to validate the integration...

The verification loop runs three phases after execute’s environment probe:

Build and test failures enter bounded classify/fix/retry loops (up to 15 attempts); the Camel Main startup smoke test allows up to 6 attempts. Missing tools skip their dependent checks with a recorded reason. Verification is informational and does not block /camel-execute from finishing, so review its report and resolve any failed or skipped checks before deployment.

Once the implementation is generated, review its execution report and resolve any failed or skipped verification checks before deployment:

• Customize — Edit generated routes to add business-specific logic
• Deploy — Use the generated run.sh for Camel Main or package a runtime-appropriate container image
• Monitor — Use route IDs and descriptions plus the project-specific monitoring configured from your requirements
• Extend — Run /camel-brainstorm <pipeline-id> to amend the approved design, then regenerate stale downstream artifacts

Async Processing — mention during the interview: “Orders should be processed asynchronously with 10 concurrent threads” → AI uses SEDA component.

DataMapper — for JSON-to-JSON mapping, DataMapper uses inline Groovy when both schemas are absent or the mapping has fewer than 20 leaf fields; it uses XSLT only when the mapping has at least 20 leaf fields and at least one schema.

Multiple Environments — say “We need dev, staging, and production configurations” → AI generates application-{env}.properties files.

A route breaks later? Run /camel-debug for structured diagnosis. Failures during /camel-execute are handled by its internal verification loop.

Design changes after approval? Run /camel-brainstorm <pipeline-id> with the new requirements, then regenerate stale downstream artifacts.

Constitution rules too strict? Edit docs/constitution.md before running the pipeline. The 8 rules are customizable per team.