build-mule-integration
Workflow required before any Mule flow and integration work. Call use_skill as your FIRST action — before reading project files — whenever the user asks to create, generate, update, fix, modify, change, edit, tweak, adjust, or rework any Mule flow, sub-flow, or component. Do not read project files and attempt the change yourself — even targeted single-component changes like 'modify the choice router', 'fix the until-successful', or 'update the catch block' require this workflow. Covers all change types, new integrations and targeted changes to error handlers, catch blocks, choice routers, DataWeave transforms, HTTP listeners, foreach loops, retry policies, scatter-gathers, connectors, and variable assignments. Prompts beginning with 'This code defines...' or 'This flow...' are generation requests, not analysis. When you call this skill, it must be the only tool call in that response.
67
81%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Advisory
Suggest reviewing before use
Quality
Discovery
100%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is an exceptionally well-crafted skill description that excels across all dimensions. It provides comprehensive trigger terms covering both user action verbs and specific MuleSoft component names, clearly states both what the skill does and when to use it, and occupies a distinct niche unlikely to conflict with other skills. The description also includes important behavioral instructions (must be first action, must be only tool call) that guide correct usage.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists numerous specific concrete actions and components: create, generate, update, fix, modify Mule flows, sub-flows, error handlers, catch blocks, choice routers, DataWeave transforms, HTTP listeners, foreach loops, retry policies, scatter-gathers, connectors, and variable assignments. | 3 / 3 |
Completeness | Clearly answers both 'what' (workflow required before Mule flow and integration work, covering all listed change types) and 'when' (explicit trigger guidance: 'as your FIRST action whenever the user asks to create, generate, update, fix, modify...'). Includes detailed 'Use when' equivalent with explicit triggers and even anti-patterns (do not read project files first). | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural trigger terms users would say: 'create', 'generate', 'update', 'fix', 'modify', 'change', 'edit', 'tweak', 'adjust', 'rework', plus specific component names like 'choice router', 'until-successful', 'catch block', 'DataWeave transforms'. Also includes pattern-matching triggers like 'This code defines...' and 'This flow...'. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive — targets a very specific niche (MuleSoft/Mule flow development) with domain-specific terminology (DataWeave, scatter-gather, HTTP listeners, choice routers) that is unlikely to conflict with other skills. The description also clarifies edge cases like distinguishing generation requests from analysis. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
62%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill demonstrates exceptional workflow clarity and actionability — every step has concrete, executable commands, explicit validation gates, and clear error recovery paths. However, it is severely over-verbose, repeatedly explaining design rationale and restating rules across multiple sections, which wastes significant context window budget. The content would benefit enormously from splitting detailed reference material (JDBC drivers, connector selection rules, anti-patterns) into separate files, keeping SKILL.md as a lean orchestration guide.
Suggestions
Extract design rationale paragraphs ('Why this gate exists', 'Why drafts instead of pins', 'Why scripts instead of inline bash') into a separate DESIGN-DECISIONS.md — Claude needs the rules, not the justifications for them.
Move the Step 6b JDBC driver resolution table, the Step 5 trigger decision ladder details, and the Step 3 selection rules into separate reference files, keeping only the decision flow and script invocations in SKILL.md.
Consolidate the workflow-wide discipline rules and per-step blocker gates — many constraints are stated 2-3 times (e.g., 'connector versions come only from Step 3 flow' appears in workflow discipline, Step 3, Step 8, and Best Practices).
Remove explanatory sentences that teach Claude things it already knows (e.g., 'Exchange carries dedicated connectors for hundreds of SaaS products', 'A dedicated connector gives metadata discovery, typed operations, and correct authentication; HTTP gives raw request plumbing').
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | This skill is extremely verbose at ~1200+ lines. It repeatedly explains rationale ('Why this gate exists', 'Why drafts instead of pins', 'Why scripts instead of inline bash', 'Why one wrapper instead of N inlined substitutions'), includes extensive anti-pattern discussions, and restates rules multiple times across steps. Many paragraphs explain design decisions that Claude doesn't need — it just needs the instructions. The workflow-wide discipline section, for example, repeats constraints that are already stated in the individual steps. | 1 / 3 |
Actionability | The skill provides fully executable bash commands, concrete XML examples, specific JSON schemas for metadata responses, exact flag semantics, and copy-paste-ready code blocks for every step. Commands reference real tools (anypoint-cli-v4, jq, mvn) with correct syntax, and examples show actual connector GAVs, XML structures, and file paths. | 3 / 3 |
Workflow Clarity | The 18-step workflow is meticulously sequenced across two phases with explicit blocker gates, validation checkpoints (Step 16's pre-build validator, mvn verification), feedback loops (fix → re-validate → re-build), and clear pre-conditions for each step. The build-then-verify protocol explicitly prevents skipping validation, and the Phase 1 → Phase 2 approval gate is well-defined with error recovery paths. | 3 / 3 |
Progressive Disclosure | The skill references external files (references/connector-catalog.md, references/jdbc-drivers.md, scripts/) and delegates to bundled scripts appropriately, but the SKILL.md itself is a monolithic wall of text that inlines enormous amounts of detail that could be split into separate reference files — e.g., the Step 3 selection rules, Step 5 decision ladder, Step 6b JDBC driver resolution table, and the extensive troubleshooting section could all be separate documents referenced from a leaner overview. | 2 / 3 |
Total | 9 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
skill_md_line_count | SKILL.md is long (1217 lines); consider splitting into references/ and linking | Warning |
Total | 10 / 11 Passed | |
- Repository
- mulesoft/mulesoft-dx
- Commit
32e2b58
- Reviewed
Table of Contents
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.