CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

translate-agent-broker-old-to-new-project

Convert a MuleSoft Agent Network V1 project (`schemaVersion: 1.0.0`) into a V2 project (`agentNetwork: 2.0.0`). Each V1 broker becomes a V2 broker with one orchestrator node — no graph splitting, no prompt rewriting. Use when the user asks to upgrade, convert, migrate, translate, or port an Agent Network / Agent Broker / Daisy planner from V1 to V2, or whenever the working folder contains a V1 `agent-network.yaml`.

73

Quality

92%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

86%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.

A high-quality, highly actionable conversion skill: field-by-field mapping tables, executable templates, and a validated workflow cover the task comprehensively. The main weaknesses are minor redundancy (duplicated ID-format caveats, Common-mistakes restatements) and the absence of a post-write verification step.

Suggestions

Consolidate the twice-stated 'connection/broker IDs are not format-restricted by the V2 schema' caveat into a single note in Step 3a, since the connections and brokers paragraphs repeat the same convention-vs-lint-rule explanation almost verbatim.

Add a post-write verification step (e.g., re-check that each trigger's target 'brokers://<broker-id>/a2a' matches the YAML broker key exactly and that the output mirrors references/v2-example.md structurally) to close the workflow's missing output-validation feedback loop.

DimensionReasoningScore

Conciseness

The body is dense with domain-specific V1→V2 mapping rules Claude cannot know, with no generic-concept padding. However, the 'IDs are not format-restricted by the V2 schema' caveat is explained at near-identical length twice (connections and broker IDs), and the 'Common mistakes' section largely restates rules already stated in Steps 3a–3c.

4 / 5

Actionability

Guidance is fully executable: a copy-paste-ready V2 broker YAML skeleton, an exact before/after connection translation example, a field-by-field V1→V2 mapping table, concrete tool directives (mkdir -p, Write, AskUserQuestion), and a placeholder template (references/v2-template.agent) to fill for the .agent file.

5 / 5

Workflow Clarity

A clear 5-step sequence with an explicit input-validation gate in Step 1 (including a quoted stop-and-ask failure message) and overwrite guards in Steps 2 and 4. The gap is post-write: 'After writing, list the created files' is a listing, not verification of the output, so no feedback loop closes the workflow.

4 / 5

Progressive Disclosure

Three real, one-level-deep reference files, each clearly signaled with its purpose and the workflow step where it applies; the heavy canonical examples (v1-example.md, v2-example.md) and the full .agent template are appropriately offloaded from SKILL.md, and body sections are well organized.

5 / 5

Total

18

/

20

Passed

Description

95%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.

An exemplary description: third-person, concrete, and version-pinned, with a comprehensive set of natural trigger synonyms and an explicit 'Use when' clause including a folder-content fallback. The only shortfall is that the what-clause details just the broker transformation rather than the full conversion surface.

DimensionReasoningScore

Specificity

Concrete actions are pinned to exact schema markers ('Convert a MuleSoft Agent Network V1 project (schemaVersion: 1.0.0) into a V2 project (agentNetwork: 2.0.0)', 'Each V1 broker becomes a V2 broker with one orchestrator node'), but coverage stops at the broker-level transformation without mentioning registry/connection/exchange translation — several specific actions with minor gaps, not the comprehensive 5.

4 / 5

Completeness

Both halves are explicit: a clear what ('Convert a MuleSoft Agent Network V1 project... into a V2 project', 'Each V1 broker becomes a V2 broker with one orchestrator node — no graph splitting, no prompt rewriting') and a concrete 'Use when the user asks to upgrade, convert, migrate, translate, or port... or whenever the working folder contains a V1 agent-network.yaml' trigger clause.

5 / 5

Trigger Term Quality

Five natural verb synonyms ('upgrade, convert, migrate, translate, or port'), product-specific nouns ('Agent Network / Agent Broker / Daisy planner'), the V1→V2 direction, and the exact filename 'agent-network.yaml' — comprehensive coverage of natural terms including synonyms and file names.

5 / 5

Distinctiveness Conflict Risk

A clear niche with distinct, version-pinned triggers (schemaVersion: 1.0.0 → agentNetwork: 2.0.0) plus a folder-content fallback; the closely related builder skill fires on new-build requests rather than V1→V2 conversion, so conflict risk is minimal.

5 / 5

Total

19

/

20

Passed

Validation

100%

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

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

mulesoft/mulesoft-dx

Path

skills/mule-development/translate-agent-broker-old-to-new-project/SKILL.md

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.