---
url: /bpmnlint-rules/guide.md
---
# Getting started

## Install

Install the plugin together with `bpmnlint` (its peer dependency):

```bash
npm install --save-dev @miragon/bpmnlint-plugin-rules bpmnlint
```

## Use it (the bpmnlint way)

Add the plugin to your `.bpmnlintrc` and extend one of its configs, like any other plugin:

```jsonc
// .bpmnlintrc
{
  "extends": [
    // standard structural rules
    "bpmnlint:recommended",
    // the Miragon layer, pick a scope below
    "plugin:@miragon/rules/recommended-for-<scope>",
    // optional: Camunda engine rules, see below
    // "plugin:camunda-compat/camunda-cloud-8-10",
  ],
}
```

It ships three configs — pick one by who's modeling and why:

* `plugin:@miragon/rules/recommended-for-modeling` — for **purely business/technical models**, and for
  **modeler applications that surface linting** to their users. Layout hints only: bpmnlint's
  `standard-size` and the layout rules at `warn`, the naming/id rules **off** — a modeler is never
  blocked on execution-only conventions.
* `plugin:@miragon/rules/recommended-for-automation` — for **developers automating processes**, locally
  and in CI, on models wired up to a Camunda engine. Every Miragon rule on but as a non-blocking `warn`
  (`standard-size` too), so ids and layout get flagged without failing the build.
* `plugin:@miragon/rules/all` — every Miragon rule at `error`, engine-agnostic. The strict gate to opt
  into when you want findings to fail the build.

Then lint a diagram:

```bash
npx bpmnlint diagram.bpmn
```

## Next steps

* [Presets](./presets.md): which of the three configs fits who is modeling.
* [Camunda 7 / 8 engines](./guide/engines.md): add the deployability rules for your engine.
* [CI & programmatic API](./integrate/api.md): run it as a merge gate or from code.
* [Rules](./rules/index.md): every rule with a reported and a clean example.