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/proposal-lint)<a href="https://agentmods.dev/commands/mendixlabs/mxcli/proposal-lint"><img src="https://agentmods.dev/badge/commands/mendixlabs/mxcli/proposal-lint/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/proposal-lint"><img src="https://agentmods.dev/badge/commands/mendixlabs/mxcli/proposal-lint.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.00870 |
| Opus 5.5 | $0.00005 | $0.00348 |
| Sonnet 5.5 | $0.00003 | $0.00174 |
| Haiku 4.5 | $0.00001 | $0.00087 |
Grade A, and why
proposal-lint 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 — 104 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/mxcli-dev:proposal-lint — Audit and Clean Up Proposals
Audit docs/11-proposals/ for status drift, missing frontmatter,
misplaced files, and convention violations.
Read .claude/skills/lint-proposals.md first. It defines the
frontmatter format, status vocabulary, and the seven lint rules. This
command is the trigger; the skill is the contract.
Arguments
- (no args) — run the lint, produce a report, stop.
--apply— only after the user has reviewed and approved the report: execute the proposed moves and frontmatter migrations.--category <name>— limit the run to one category (e.g.frontmatter-missing,move-to-archive). Useful for incremental cleanup.
Process
Phase 1: Walk and check
- Walk
docs/11-proposals/anddocs/11-proposals/archive/(recursive). - Scan
/proposals/at the repo root for stragglers. - For each file, run rules R1–R7 from the skill.
- Collect findings into the eight categories defined in the skill.
Phase 2: Report
Print a structured report:
## Proposal lint report
Files scanned: NN active, MM archived, K strays
Total findings: XX
### move-to-archive (N)
- `PROPOSAL_xxx.md` — status: done; propose: git mv → archive/PROPOSAL_xxx.md
- ...
### frontmatter-missing (N)
- `proposal-yyy.md` — inline status "Draft" found; propose: add YAML frontmatter
- ...
### readme-drift (N)
- `archive/PROPOSAL_zzz.md` listed in README under Active section
- `PROPOSAL_aaa.md` exists on disk but missing from README
- ...
(etc. for each category)
Stop after the report. Do not modify files.
Phase 3: User direction
Ask the user:
- Which categories to apply, and in what order?
- Are there any flagged items to skip (e.g. a
doneproposal staying in active because work isn't fully finished, despite the inline status)? - Should naming-convention violations (R7) be ignored for now? (Default recommendation: yes.)
Phase 4: Apply (only with explicit approval)
For approved categories:
- Frontmatter migration: prepend YAML frontmatter to each file,
preserving the inline
**Status:**line for one cycle. - Moves: use
git mvso history is preserved. Update the README index to reflect new paths. - Duplicate resolution: keep one canonical location; for the root
/proposals/stragglers, confirm with the user which to keep before removing. - Supersession symmetry: add the missing direction (
supersedes:/superseded-by:) to frontmatter.
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 · 104 lines · 13 tokens per session scan A da3dbc103463
proposal-lint is a command published in the GitHub repository mendixlabs/mxcli (132 stars, last pushed 2d ago), licensed Apache-2.0. It adds 13 tokens to every session and 870 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-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.
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.