Spotter for Bicep
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';
}
}
},
};
Extension settings
No configuration required. Spotter reads its settings from .spotter.json in the workspace root.
Links
