Greenfield workflow

The agent now has the Camel Kit skills and the MCP servers (two by default; three with --with-citrus-mcp). The first pipeline run needs an active pipeline ID, which init does not create; /camel-brainstorm asks you to create it when none exists:

Start the interview with /camel-start (which routes new work to brainstorm) or directly with /camel-brainstorm. The agent first analyzes any requirements, examples or other project material you provide and does not ask again for facts that are already resolved; complete material can need no clarification at all. Open questions are asked one at a time, in three groups:

If no deliberate exclusions remain, the design records None identified instead of inventing scope boundaries. Before assembling the design, the agent verifies every source and sink component against the catalog through the camel MCP server; in the example it confirms that kafka exists for the selected Camel version and runtime.

The interview produces docs/camel-kit/001-order-processing/design-spec.md with six numbered sections:

An unnumbered Not Doing (and Why) section at the top records each deliberately excluded capability and its rationale, so implementation and review treat it as a scope boundary. Review the specification carefully: your approval ("Looks good, let’s proceed") authorizes everything downstream. There is no second approval for the plan.

After approval the pipeline invokes /camel-plan. It applies the Not Doing boundaries and decomposes the design into route, configuration, dependency, test and conditional infrastructure tasks, each with acceptance criteria, the catalog-verified components and patterns to use, the files to create and the verification steps. The plan is a recipe, not the implementation: it contains no generated code.

Retry and dead-letter behaviour belongs to the affected route tasks unless error delivery is itself a business flow. A structured metadata block lists each task’s files, the logical resources it provides and consumes and its explicit dependencies; /camel-execute derives the waves from it. Tasks in the same wave can run in parallel on agents that support concurrent dispatch; later waves wait for their dependencies.

/camel-plan then invokes /camel-execute, which runs all tasks without pausing between them. It first analyzes the dependency waves, probes the target environment, and batch-verifies the catalog artifacts needed by each wave. For every task it dispatches the persona and guides declared by the plan: route and configuration tasks use the internal camel-implement skill, test tasks use camel-test. Each task then goes through three reviews:

After all tasks, execute performs a cross-cutting review, dispatches the internal camel-verify skill once, and writes execution-report.md.

camel-verify runs three phases after the environment probe and embeds its evidence in the execution report:

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

The pipeline ends with /camel-validate, a static quality gate over the generated routes: schemas, endpoint URIs, project-relative quality thresholds, security, anti-patterns and all constitution rules. It reports findings in validation-report.md without modifying the routes.

Every stage persists its artifact under docs/camel-kit/<pipeline-id>/, so a session can be closed and resumed; .camel-kit/pipeline.json records the active pipeline ID.

With Camel Main selected during design, the routes and properties are generated at the project root and no pom.xml is needed:

Spring Boot and Quarkus projects use the Maven source layout instead, with routes under src/main/resources/camel/.

Every stage can be invoked on its own with a pipeline ID. Plan, execute and validate then read their input from the artifacts on disk instead of the conversation, and do not invoke the next stage. This supports resuming a session, triggering single stages from automation, and re-running only what changed:

To change an approved design, run /camel-brainstorm 001-order-processing. When design-spec.md already exists the skill enters amend mode: it loads the specification, applies your changes after approval, and marks each existing direct child stale with camel-kit doc stale. Regenerate the stale stages standalone, plan first and then execute. camel-kit doc check <artifact> shows the staleness state of any artifact; see Command reference.