Mule Build

Build Mule Application

Build the current Mule 4 application using its repository instructions and configured build tools. Default to a validation and package operation. Do not turn a build request into a release.

This skill owns local validation, test execution, reports, packaging, local runtime actions, and version/commit/tag preparation. Route MUnit authoring, repair, fixtures, mocks, and assertions to mule-testing when that skill is installed. Route Exchange publishing and Anypoint deployment to mule-ops and the authenticated Anypoint connector.

1. Establish scope

Distinguish these modes:

If the user says only build, use Package. Version bumps, changelog edits, commits, tags, local runtime changes and pushing require explicit user scope. Publishing and deployment are separate Anypoint operations owned by mule-ops.

2. Inspect before changing anything

1. Read repository instructions, pom.xml, mule-artifact.json, build scripts, CI workflows, and relevant changelog or release policy.
2. Review git status --short and preserve unrelated or uncommitted changes.
3. Confirm required Java, Maven, Mule runtime, and connector versions.
4. Identify the project's established validation, test, package, and release commands.
5. Check whether the requested build needs network or authenticated artifact repositories.

Do not copy organization names, application identity, repositories, profiles, endpoints, or credentials into reusable commands or output.

3. Validate the source

Before choosing a lint profile, follow the shared mule-lint standards protocol. The build workflow executes the project gate; it does not redefine which Mule practices or rules are canonical.

Run the project's configured checks before packaging. Prefer, when available:

1. XML, DataWeave, RAML/OAS, and configuration validation;
2. Mule lint and security checks;
3. focused MUnit tests for changed behavior;
4. the required full test suite.

Do not skip tests by default. Skip them only when the user requests it or the repository's documented workflow requires a separate test stage, and state the resulting verification gap.

When Mule source changed, use the mule-development post-development checklist before building. When Mule XML changed and the development skill is installed, run:

python3 <skills-root>/mule-development/scripts/check_embedded_expressions.py .

<skills-root> is the directory holding the mule-* skills: ${CLAUDE_PLUGIN_ROOT}/skills when installed as a Claude Code plugin, .agents/skills when vendored into the project.

This catches truncated #[…] expressions in CDATA that XML parsing and packaging can miss.

4. Reconcile contracts and documentation

Review the changed files and update only documentation made stale by the change:

Use the mule-docs targeted-refresh workflow when installed. Do not rewrite unrelated prose or add unsupported business context.

5. Package

Use the repository's established command or the configured Mule build tool. For a tool call, pass the project root as cwd and preserve the project's normal test behavior.

Before running, show or record:

• command or tool and relevant non-secret options;
• whether tests are enabled;
• expected artifact directory;
• any known network or authentication dependency.

If the build fails, report the first actionable failure and relevant context. Do not mask a failed test by rerunning with tests skipped unless the user approves that diagnostic step.

6. Release preparation, only when requested

When the user explicitly requests a release:

1. Apply the repository's versioning policy. If none exists, propose patch, minor, or major with the compatibility rationale and obtain direction when the choice is material.
2. Update all evidenced version surfaces that must remain synchronized.
3. Update an existing changelog using its established format; do not create one unless requested or required by repository instructions.
4. Re-run validation, tests, and packaging after version changes.
5. Use mule-review in release-readiness mode on the resulting candidate when the skill is installed. Do not continue on Not ready or Unresolved; complete or explicitly accept every condition before continuing from Ready with conditions.
6. Commit or tag only when authorized. Make an annotated tag only after the final release commit.
7. Push only when explicitly requested.

If the user also requests publishing to Exchange or deploying, restarting, scaling, or rolling back a runtime, hand that work to mule-ops and the authenticated Anypoint connector after local release preparation is complete. The operational handoff follows <skills-root>/mule-ops/references/anypoint-readiness.md; mule-build does not probe or mutate the platform itself. Those platform mutations are a separate scope and approval. Never treat a readiness probe or a successful package as approval to publish or deploy.

Use semantic-version guidance as a starting point, not a replacement for the project's release policy:

Configuration-only changes do not universally mean “no version bump”; follow how the project packages and deploys configuration.

7. Verify the artifact

After a successful package:

• locate the generated deployable artifact;
• confirm it was produced by the current build and is not a stale file;
• confirm the packaged version matches the intended build or release version;
• report whether tests, lint, and security checks passed, failed, or were skipped;
• confirm no secret-bearing configuration or unintended generated files entered the diff.

8. Report

Provide:

1. build mode and outcome;
2. exact artifact path;
3. validations and tests run;
4. tests or checks skipped and why;
5. files changed by the workflow;
6. version, commit, and tag only when release actions occurred;
7. remaining warnings or user actions.