Part 6: Building it with MuleSoft Vibes: skills, rules, workflows and hooks

Part 6 of 10 · Building an Agentic Change-Approval MVP on MuleSoft

Parts 4 and 5 covered what the integration team builds: MCP tool flows with strict contracts, behind a governed gateway. This part covers how they build it. We used MuleSoft Vibes in Anypoint Code Builder, and the interesting part wasn't the code it wrote. It was how we taught it our standards so every tool came out the same way.

Three ways to teach Vibes your standards

Vibes gives you three building blocks, and each one solves a different problem:

	What it is	When it applies	What we used it for
Rules	Natural-language constraints	Every message (global or workspace)	Standards that never change
Skills	Instruction packs with optional files	Only when a request matches the skill	How to build one kind of thing
Workflows	Named multi-step tasks	When you run them as a slash command	Repeatable sequences

The difference matters because of context. Rules are always loaded, so they should be short. Skills load only when relevant, so they can carry detail, templates and examples without crowding out everything else.

Rules: the things that are always true

Our workspace rules are a short list. Each one is something we never want to explain twice:

• Tool flows never call a System API directly. They call a Process API.
• Every flow has an error handler that returns a named error code.
• Tool names are snake_case and start with a business verb (create_, read_, request_, import_).
• No credentials, hostnames or client names in code. Use properties and secure properties.

If a rule needs a paragraph of explanation, it probably belongs in a skill instead.

Skills: how to build one kind of thing

Workspace skills live in .a4drules/skills/, one folder per skill, committed with the project. Each folder has a SKILL.md and can carry references/, assets/ and scripts/. Vibes loads a skill only when a request matches its description.

We wrote one skill per kind of artifact. The most-used one teaches Vibes how to build an MCP tool flow:

.a4drules/skills/mcp-tool-flow/
├── SKILL.md
└── references/
    ├── tool-listener-template.xml
    ├── input-schema-template.json
    └── description-checklist.md

The top of SKILL.md:

---
name: mcp-tool-flow
description: Use when creating or changing an MCP tool flow with the
  MCP Connector Tool Listener. Covers naming, description, input schema,
  Process API call and error codes.
---

1. Ask for the business action and who will call it, if not given.
2. Name the tool <verb>_<object>, snake_case.
3. Write the description with: what it does, when to use it,
   what it needs first, what it returns.
4. Build the input schema from references/input-schema-template.json.
   Every field typed, constrained and described. No additionalProperties.
5. Call the Process API, never a System API.
6. Map failures to named error codes from the Process API contract.

The description checklist is the same four rules from Part 4. Putting it in a skill means every developer gets it, including the ones who never read the series.

Workflows: the sequence we kept repeating

Adding a tool always took the same steps, so we made it a workflow and run it as /new-mcp-tool:

1. Collect the business action, caller (which agent) and Process API operation.
2. Generate the input schema and Tool Listener flow, using the mcp-tool-flow skill.
3. Generate an MUnit test for the happy path and each named error.
4. Draft the change request for the platform team: add the tool to the Global Access allow-list and to the right agent's ABAC rule (Part 5).

Step 4 is the one people forgot before the workflow existed. A tool that works locally but isn't on the gateway's allow-list is invisible to every agent.

Guardrails: what the AI doesn't get to decide

Rules and skills make good output likely. They don't make it certain. A developer can ignore a suggestion, and a model can miss an instruction. So the checks that must always pass are deterministic and live outside Vibes:

• A git pre-commit hook runs a small script that checks every Tool Listener has a description and an input schema, that tool names match the naming rule, and that no tool flow references a System API.
• The CI pipeline runs the MUnit suite and the same checks again, because hooks can be skipped locally.

Vibes itself doesn't have hooks; these are ordinary git hooks and pipeline steps. If your team also uses an AI coding tool that supports hooks, such as Claude Code, you can run the same checks at edit time. The principle is the same as in the runtime design: the AI proposes, deterministic checks decide.

Who owns what

• Integration team: workspace rules, the skills and workflows in the repo, and the pre-commit checks.
• Integration CoE or platform team: global rules shared across projects.
• Every developer: proposes a new rule or skill when they catch themselves correcting the same thing twice.

Next

Part 7 covers testing an agentic flow: MUnit for the deterministic tool layer, evaluations for agent answers, and the evidence a regulated quality team will ask for.

Which of your team's standards would you turn into a skill first?

---

This series describes a reference model built on a fictional company. Vibes capabilities are based on MuleSoft documentation as of October 2026; check current docs before you build.