Tessl • The management layer for AI agent skills

SkillPublic

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.

Quality

79%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./skills/mule-development/build-mule-integration/SKILL.md

Quality

Content

73%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

An operationally excellent workflow document: every step is executable, the sequence and validation gates are exemplary, and bundle files are structured with disciplined one-level-deep references. Its main weakness is token efficiency — the same rules are repeated across sections and a full command quick-reference duplicates earlier content, making the file far larger than the operational content requires.

Suggestions

State each discipline rule once in the "Workflow-wide discipline" section and reference it from steps ("see version source-of-truth, Step 3") instead of restating it — the HTTP-fallback, version-source, and build-mandatory rules each appear 4-5 times.

Cut the Quick Reference section or reduce it to the non-obvious invocations, since every command it contains already appears verbatim in its step.

Move Step 15's full annotated XML example and the Step 14 XSD namespace tables into a reference file (like template-project-creation.md) and keep only the rules plus a minimal example inline.

Dimension	Reasoning	Score
Conciseness	At ~1,267 lines the body restates the same discipline rules many times — "no HTTP fallback" appears in four places, the version source-of-truth rule in four, and the build-is-mandatory rule in five — and the Quick Reference section duplicates every command already shown in its step. Hardcoded driver version pins (e.g. "mysql-connector-j:8.4.0", "ojdbc11:23.9.0.25.07") add time-sensitive content outside any deprecated-patterns section.	2 / 5
Actionability	Fully executable throughout: exact bash invocations with arguments ("node scripts/pick_connector.mjs sfdc com.mulesoft.connectors:mule-salesforce-connector:11.1.0"), expected stdout/JSON output shapes for each command, complete XML generation examples, and decision tables mapping conditions to actions. Copy-paste ready and covering the common cases.	5 / 5
Workflow Clarity	Eighteen explicitly sequenced steps across two phases with [BLOCKER] gates, pre-conditions on Steps 17 and 18, a dedicated pre-build validator, and a build-then-verify protocol with a concrete error-recovery loop ("If BUILD FAILURE, find the [ERROR] line ... and return to step 1 of this protocol"). Validation checkpoints are everywhere.	5 / 5
Progressive Disclosure	References are real, one level deep, and well-gated (jdbc-drivers.md opens with "Read this file only when Step 6b lands on one of these branches"; the catalog carries a discovery-aid-only status note), and bundled scripts are documented in a table. Minor gap: bulky inline material like Step 15's ~55-line annotated XML example and Step 14's XSD rule tables could live in a reference file.	4 / 5
	Total	16 / 20 Passed

Description

76%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A trigger-spec-first description: exceptionally strong on when to invoke and on distinctiveness, but weak on stating what the skill actually does, and written in second-person imperative voice rather than the expected third person. The enumerated change types and prompt-shape guidance make false negatives unlikely.

Suggestions

State the capability concretely in third person up front, e.g. "Builds and modifies Mule 4 integrations via a two-phase design-then-build workflow with Exchange connector discovery, metadata-driven XML generation, and verified Maven builds" — this would raise both specificity and completeness.

Rewrite the directive sentences ("Call use_skill as your FIRST action", "attempt the change yourself", "When you call this skill") in third person to remove the second-person voice penalty.

Trim the long verb list (ten synonyms for 'change') to the 3-4 users most commonly say and spend the reclaimed space on the what-it-does summary.

Dimension	Reasoning	Score
Specificity	The skill's actual capability is stated only as "Workflow required before any Mule flow and integration work" — the verbs (create, fix, modify...) and component list describe trigger conditions, not what the workflow does. It also uses second person ("your FIRST action", "attempt the change yourself", "When you call this skill"), which triggers the -1 voice penalty on an otherwise base-3 score.	2 / 5
Completeness	The 'when' is answered exhaustively (first-action timing, change-type enumeration, prompt-shape disambiguation), but the 'what' is thin — the description never states what the workflow does (design phases, connector discovery, XML generation, build verification), so it falls short of the anchor-5 requirement that both be explicit.	4 / 5
Trigger Term Quality	Comprehensive natural-term coverage: ten action-verb synonyms ("create, generate, update, fix, modify, change, edit, tweak, adjust, or rework"), concrete component nouns users would actually say ("choice router", "catch block", "DataWeave", "scatter-gather"), and even verbatim prompt shapes ("This code defines...").	5 / 5
Distinctiveness Conflict Risk	Clear niche with distinct triggers — Mule/Anypoint-specific vocabulary ("Mule flow, sub-flow", "DataWeave transforms", "until-successful") leaves virtually no overlap risk with other skills.	5 / 5
	Total	16 / 20 Passed

Validation

93%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
skill_md_line_count	SKILL.md is long (1268 lines); consider splitting into references/ and linking	Warning

	Total	15 / 16 Passed

Repository: mulesoft/mulesoft-dx
Path: skills/mule-development/build-mule-integration/SKILL.md
Revision: 4340d6c

Reviewed: 8 days ago

Discovery Implementation Validation

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.

build-mule-integration

Table of Contents

Is this your skill?