camel-validate
/camel-validate is the last stage of the pipeline: a static quality analysis of the generated Camel routes that writes a report and changes nothing. It covers correctness, security, anti-patterns, project conventions and the constitution. Runtime failures (build, startup, tests) belong to the verification loop inside /camel-execute (see Runtime verification); a route broken outside a pipeline run belongs to /camel-debug.
When it runs
In a chained run /camel-execute continues to /camel-validate after the implementation and the runtime verification, with no further approval. A standalone /camel-execute stops after its summary, so invoke validation explicitly when you want the static gate:
/camel-validate <pipeline-id> /camel-validate
With a pipeline ID, or with an active pipeline recorded in .camel-kit/pipeline.json, validation is pipeline-scoped: it cross-references the design, the plan and the execution report under docs/camel-kit/<pipeline-id>/, checks their provenance with camel-kit doc check, and stops on a stale artifact until you choose to regenerate it, abort, or proceed with that exact revision. Without any pipeline it is project-scoped and validates the routes found in the current project.
Checks
The skill first builds the route inventory of every target module for the project’s runtime (module-root *.camel.yaml and application.properties for Camel Main, src/main/resources/camel/ and src/main/resources/application.properties for Spring Boot and Quarkus), then runs:
-
Camel YAML DSL schema validation and endpoint configuration;
-
endpoint verification against the Camel catalog through the
camelMCP server, for the project’s runtime and platform BOM; -
quality metrics and thresholds, relative to the project norms when
.camel-kit/project-graph.jsonexists; -
security analysis from the shared checklist: hardcoded credentials, TLS, headers and unsafe endpoint settings;
-
the anti-pattern catalog;
-
all eight constitution rules;
-
structural retirement candidates from the project graph when it exists (see Graph intelligence).
Validation is at least as strict as generation: a construct that Camel Kit refuses to generate does not pass validation because it was added by hand.
Report
Pipeline-scoped validation writes docs/camel-kit/<pipeline-id>/validation-report.md; project-scoped validation writes docs/validation-report-YYYY-MM-DD_HH-mm.md. The report records the project, runtime and Camel version, a summary table with pass, fail and warn counts per category, the findings, the constitution rule results, and the recommendations: priority fixes for the failures, suggested improvements for the warnings.
| Category | Pass | Fail | Warn | Total |
|---|---|---|---|---|
Schema validation | . | . | . | . |
Endpoint verification | . | . | . | . |
Quality checks | . | . | . | . |
Security analysis | . | . | . | . |
Anti-patterns | . | . | . | . |
Constitution compliance | . | . | . | . |
The report carries provenance metadata from camel-kit doc init, linked to the execution report when one exists. Fixing the findings is a separate step: edit the routes, or amend the design and rerun the affected stages, then validate again.