Jev and BMAD together

BMAD and Jev are easy to mention in the same breath, because both are AI tools that a team adds to its workflow and both can be packaged as skills for a coding agent. They work at completely different layers.

BMAD is a delivery method. It helps a team decide what to build, keep the relevant project context where the next change can find it, shape specifications, implement and review. Jev is a runtime component. It answers typed questions inside a product, a workflow or an agent's loop. One helps you build the decision. The other is the decision, or rather a signal that your code turns into one.

They complement each other well when BMAD is used to specify and build the boundary that Parts 3 and 4 described. This part shows how, using Kloofvale's Fix-It routing feature. Kloofvale Local Municipality is fictional, and its systems and figures are illustrative. This is an independent CloudNala analysis. If BMAD is new to you, our BMAD in Practice series starts with what the method actually is.

Different layers, different jobs

A note on versions. As of 13 October 2026, BMAD's latest stable release is v6.12.2, with v7 available as a preview, and the documentation site describes the newer layout. The workflow names below are from the current documentation; check which line you have installed.

The integrated lifecycle

At Kloofvale, the routing feature moved through BMAD's loop like any other substantial change. The analyst and product perspectives helped the product owner write down the outcome: fewer urgent reports waiting behind routine ones, with nothing hidden from people. The architect perspective worked through where the decision sits, what the adapter owns and what happens when the service is down. The build step implemented the adapter and its tests. Then the feature ran, and evidence from production came back as updated project context for the next round.

That last arrow is the one teams skip. A decision feature is never finished at release. Thresholds move, new kinds of report appear, a language cohort turns out to perform worse than expected. Each of those is a change, and each should start from what production has taught the team rather than from the original assumptions.

What belongs in the specification

A decision feature's specification needs more than a normal user story. Kloofvale's covered:

• the business decision and who owns it;
• the state fields, where each comes from and how fresh it is;
• data-minimisation and redaction rules;
• the question type and its versioned criteria;
• the allowed answers, including "other" or a review route;
• the expected spread of answers, so drift can be noticed;
• what a false positive and a false negative each cost;
• thresholds for each action, by risk;
• when a person reviews, and who;
• timeout, retry and fallback behaviour;
• the fields in the evidence record;
• the evaluation set and the acceptance measures;
• how a change of model or provider is controlled.

That list looks long. Most of it is decisions the team would otherwise make implicitly, in code, without anyone signing them off.

Kloofvale's feature brief

# Feature: suggest a team and urgency for incoming Fix-It reports

## Outcome
Urgent reports reach the right team faster, without hiding uncertain reports
from people.

## Decision contract
- Choice `route`: roads, water, electricity, other
- Score `urgency`: routine, priority, urgent
- Noul `needs_human`: does this report need a person to triage it?
- State: report text, channel, ward if given, location-pin flag.
  No name, phone number or account data.

## Safety
- Never close or discard a report because of a model answer.
- "other", low-confidence and missing-location reports go to triage review.
- Fix-It is not an emergency line; emergency wording is always flagged
  for the 24-hour control room by the existing keyword rule.

## Evidence
- Labelled sample of real reports, balanced across English, isiXhosa,
  Afrikaans and code-switched messages
- Precision and recall per team, measured per language
- Review rate, time to correct team, latency and cost per report

The last item under Safety is worth noticing. Kloofvale already had a keyword rule that flags emergency wording for the control room. The team kept it exactly as it was, ahead of the decision call. A deterministic rule that works does not need replacing because a model is now available.

Brownfield: context first, then an adapter

Fix-It's case system is an older PHP application on MySQL, built by a contractor and extended by the current team. Before any feature work, the team ran BMAD's project-context step (bmad-project-context), which writes a verified project-context block into the repository's AGENTS.md. They corrected it by hand where the agent's reading of the code was wrong, then wrote down what the code could not tell it: how reports actually flow between queues, which runtime versions the server supports, how secrets are managed, what may be logged and how deployments are approved. Our article on greenfield and brownfield BMAD covers that recovery work in more depth.

Then they added the decision behind an adapter, so the vendor API does not leak into the case system's code.

The adapter is a small TypeScript service that the case system calls with a report identifier. It builds the minimised state, asks the versioned questions, validates the response, applies the policy rules, records the evidence and returns a queue. The case system does not know which provider answered, or whether one answered at all. That buys three things: the adapter can be tested with recorded responses, the provider can be changed after a fresh evaluation without touching the case system, and every failure ends in the triage queue rather than an exception in PHP.

BMAD and Jev inside the coding workflow

There is a second, smaller way the two meet. The coding agent the team runs BMAD in can also have the Jev Agent Skill installed, and can then ask bounded questions during delivery: is this proposed action risky, is this evidence enough to call the story done, does this change touch something the project context marks as sensitive? Part 4 described that loop.

Be precise about what this is. BMAD's documentation does not describe calling third-party skills from its workflows; it is the coding agent that has both installed. Treat the answers as advisory. BMAD's build step (bmad-build) plans, implements, runs independent reviewers and commits locally. The repository's permissions, the tests, code review and the team's approval rules remain the control system. A decision signal can sharpen a review. It cannot replace one.

When the combination is unnecessary

Do not add Jev to a BMAD workflow because both happen to support skills.

• If a decision can be written as a stable rule, write the rule. Kloofvale's emergency keyword check is a rule, and stays one.
• If a person makes the decision a few times a month and mistakes are cheap, keep it with the person.
• If nobody can say what a wrong answer costs, the feature is not ready for any kind of automation.

The combination is justified by a repeated judgement with measurable value and a safe way to fail. Fix-It's 1,400 reports a week qualified. A monthly report on park maintenance did not.

A template to start from

Kloofvale now uses this as the starting point for any decision feature, inside the normal BMAD specification:

# Decision feature

## Business outcome
[The measurable result]

## Owner and authority
- Business owner:
- Technical owner:
- Risk approver:

## Decision
- Name:
- Frequency:
- Current human or system process:
- Cost of a wrong answer, each way:

## State contract
- Allowed fields:
- Source systems:
- Freshness:
- Personal or confidential data:
- Redaction:

## Question contract
- Type: choice | score | noul
- Instructions:
- Criteria:
- Unknown or review route:
- Version:

## Policy
- Automation threshold:
- Human-review threshold:
- Deterministic checks that run first:
- Actions the signal may never trigger:

## Failure
- Timeout:
- Retry (429 and 529 only):
- Fallback:
- Duplicate protection:

## Evaluation
- Labelled set:
- Measures:
- Cohorts (including languages):
- Acceptance threshold:
- Drift trigger:

## Evidence
- Audit fields:
- Retention:
- Outcome feedback:

Key points

BMAD builds the boundary; Jev runs inside it. One is a delivery method, the other a runtime component.

A decision feature needs a fuller specification. Error costs, thresholds, fallbacks and evidence are design decisions, not details.

Recover context before you integrate. In brownfield systems, the adapter goes in after the project context is written down.

Keep the vendor behind an adapter. It makes testing, switching and failing safe much easier.

Skills in the same agent are still advice. The repository's controls stay in charge.

Previous: Part 4, Jev is not an agent. Next: Part 6, six South African places a decision layer could help. All parts are on the series page.

How CloudNala can help

We help delivery teams specify and build AI decision features properly: the decision contract, the adapter, the policy and the evaluation plan, written into the specification and project context so the next change starts from what the team has learned. Where BMAD is already in use, we fit this into the existing workflow rather than adding another process alongside it.

Work with CloudNala

CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.

Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.

Book an AI Decision Review or write to us at consult@cloudnala.co.za