Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/mendixlabs/mxcliWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/commands/mendixlabs/mxcli/adr-new)<a href="https://agentmods.dev/commands/mendixlabs/mxcli/adr-new"><img src="https://agentmods.dev/badge/commands/mendixlabs/mxcli/adr-new/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/commands/mendixlabs/mxcli/adr-new"><img src="https://agentmods.dev/badge/commands/mendixlabs/mxcli/adr-new.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00013 | $0.01203 |
| Opus 5.5 | $0.00005 | $0.00481 |
| Sonnet 5.5 | $0.00003 | $0.00241 |
| Haiku 4.5 | $0.00001 | $0.00120 |
Grade A, and why
adr-new scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 144 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/mxcli-dev:adr-new — Create a New Architecture Decision Record
Guide the contributor through writing a new ADR in docs/13-decisions/.
Read docs/13-decisions/README.md first. It defines the template,
the naming convention, the when-to-write checklist, and the immutability
rules. This command is the workflow; the README is the contract.
Process
Phase 1: Confirm an ADR is the right home
Ask the user:
- What decision are you recording? (one sentence)
- Is it cross-cutting? Does it shape more than one feature?
- Is it durable? Expected to hold for years, not weeks?
- Would the why be hard to reconstruct from PR history later?
If any answer is "no", route to the correct artifact:
| If... | Use instead |
|---|---|
| Feature-specific design | /mxcli-dev:proposal |
| Active rule for everyday work | Add a line to CLAUDE.md |
| Step-by-step procedure | A skill in .claude/skills/ |
| Synthesized current model | A wiki page (use /mxcli-dev:wiki-sync after) |
Do not write an ADR for trivia. The README's checklist exists to prevent the folder from filling with low-value records.
Phase 2: Check for existing ADRs
ls docs/13-decisions/
grep -l "<topic keyword>" docs/13-decisions/
Specifically:
- Is there an ADR on this topic already? If so, does the user want to supersede it (new decision changes the previous one) or amend it (the existing one is fine, no new ADR needed)?
- Is the topic listed in the README's "Candidates to back-fill"? If so, remove that bullet when you create the ADR.
Phase 3: Investigate the decision
Before drafting, gather context:
- What forces are at play? Performance, compatibility, ergonomics, external constraints (Mendix versions, library availability)?
- What alternatives were on the table? A good ADR documents the roads not taken, with one sentence each on why they were rejected.
- Who is affected? Contributors, end users, both?
- What evidence supports the decision? Link to proposals, PRs, benchmarks, prior bugs.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 144 lines · 13 tokens per session scan A 1ea17330a1a3
adr-new is a command published in the GitHub repository mendixlabs/mxcli (130 stars, last pushed today), licensed Apache-2.0. It adds 13 tokens to every session and 1,203 once invoked, about $0.0001 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other commands, from other repositories
hatch3r-workflow
Guided development lifecycle with 4 phases (Analyze, Plan, Implement, Review) and scale-adaptive Quick Mode for small tasks; --plan-file executes an approved plan document without re-deriving it.
hatch3r-roadmap
Sequence delivery phases over time into a dependency-ordered milestone plan with business and technical lenses, emitting a todo.md rollout schedule rather than design docs.
hatch3r-migration-plan
Create a phased migration plan for a major dependency or framework upgrade. Analyzes breaking changes and produces an actionable plan with rollback procedures.
hatch3r-incident-response
Drive a live production incident through a structured lifecycle -- triage + topology, bounded-autonomy mitigation, stakeholder communication, then a blameless post-mortem with runbook -- via delegated sub-agents.
hatch3r-slo-scaffold
Generate baseline SLI/SLO scaffolding for a user-facing service — availability + latency p95/p99 objectives, 28-day error budget, and Google-SRE multi-window multi-burn-rate alert rules in OpenSLO openslo/v1. Implementer writes the files; hatch3r-reliability gates them against the CQ4 floor.
hatch3r-pack-install
Walk the user through the pack trust-model gate (tier + signature + body-scan + capability declaration), confirm the trust posture, then delegate the verified install to hatch3r-pack-installer.