Progressive Bicep standards ratchet — catches policy violations inline as you code, without blocking you on existing debt.

How it works

Spotter runs your custom rules against every .bicep file in the workspace on each save. Violations are shown as squiggles in the editor and in the Problems panel.

Yellow warning — new violation not yet in the baseline (must fix or baseline)
Blue info — violation exists in the baseline (already accepted, tracked)

The status bar shows a live count: ⚠ 3 new or ✓ 12 baselined.

Requirements

The Bicep CLI must be installed. Spotter uses it to compile .bicep files internally.

Install via Azure CLI:

az bicep install

Or via winget:

winget install Microsoft.Bicep

Getting started

Open a workspace that contains .bicep files — Spotter activates automatically.
Run spotter init in the terminal to create an initial .spotter.json baseline from your current violations.
Write custom rules in .spotter/rules/ — Spotter picks them up on the next save.

Baseline

The .spotter.json file is the ratchet. It records which violations are accepted so that adding rules never blocks existing code — only new code is held to the new standard. Commit .spotter.json to git; its history is your improvement curve.

Run spotter check from the CLI to update the baseline after reviewing and accepting violations.

Custom rules

Rules live in .spotter/rules/*.ts in your workspace. Example:

import type { SpotterRule } from '@bicep-spotter/core';

export const rule: SpotterRule = {
  id: 'MY001',
  description: 'Storage accounts must have HTTPS-only enabled',
  check(resource) {
    if (resource.type === 'Microsoft.Storage/storageAccounts') {
      if (resource.properties?.supportsHttpsTrafficOnly !== true) {
        return 'supportsHttpsTrafficOnly must be true';
      }
    }
  },
};