---
name: rigor-baseline-reduce
description: >-
  Reduce an existing `.rigor-baseline.yml` rule by rule by triaging sites, fixing or intentionally
  suppressing them, and regenerating the baseline. Use for baseline diagnostics already acknowledged by a
  project; not for first-time setup or plugin authoring.
license: MPL-2.0
metadata:
  version: 0.1.0
  homepage: https://github.com/rigortype/rigor
---

# Rigor Baseline Reduce

Opportunistic, session-bounded quality improvement for a project
that already has a `.rigor-baseline.yml`. Each session picks a rule,
walks its sites, and lands a mix of fixes, intentional suppressions,
and issue reports — then refreshes the baseline so the gains stick.

This skill is for **users improving their own project**. It uses the
published `rigor` executable on `PATH` and references only public CLI
flags and config keys.

## First: load the version-current copy

The step-by-step commands live in this skill's `references/` files, and
their exact flags drift between Rigor releases — so follow the copy that
ships with the **installed** Rigor rather than any vendored or frozen copy
of this file. Get the complete current procedure in one call:

```sh
rigor skill --full rigor-baseline-reduce   # this body + all its references/, inline
```

If you already loaded this skill *via* `rigor skill` you have the current
copy — just proceed (read any `references/NN-*.md` from the directory the
header names). If `rigor` is not on `PATH`, this task needs it: run
**`rigor-next-steps`** to install Rigor first, then come back.

## Phase 0 — When to use this skill

**Precondition: the project is in acknowledge mode.** This skill
operates on a `.rigor-baseline.yml` that `.rigor.yml` /
`.rigor.dist.yml` declares via `baseline:`. A strict-mode project
(`severity_profile: strict`, no baseline) has nothing for this skill
to reduce — its diagnostics are already all live; fix them as
ordinary `rigor check` output. If no baseline exists, the user wants
`rigor-project-init`, not this skill.

Do NOT trigger for:

- **First-time onboarding** — no `.rigor.yml` yet → `rigor-project-init`.
- **Writing a plugin** for the project's DSL → `rigor-plugin-author`.

## What baseline reduction is

`.rigor-baseline.yml` records `(file, rule, count)` buckets — the
diagnostics that existed when the project adopted Rigor. They are
suppressed while their count holds. Reduction means: go through them
deliberately, decide what each one really is, and shrink the file.
Three outcomes per site:

- **Real bug** — Rigor caught a genuine defect. Fix the code.
- **Stylistic / safe** — the static reading is worst-case-sound but
  the site is fine in practice (an idiom the analyzer's narrowing
  doesn't follow, a slot the project always initialises). Mark it
  `# rigor:disable <rule>` with intent.
- **False positive** — Rigor is wrong; the rule should narrow
  further. Leave it baselined and open a Rigor issue.

Shrinking the baseline is progress whichever outcome applies — the
file gets smaller, and "reduce the baseline by N this sprint" is a
trackable goal.

## Phase outline

| Phase | What | Reference |
| --- | --- | --- |
| 1 | Prioritise — `rigor triage --format json` + `rigor baseline dump` pick the rule to work. | [`references/01-classify.md`](references/01-classify.md) |
| 2 | Per rule: sample 3–5 sites, classify each (real bug / stylistic / FP). | [`references/01-classify.md`](references/01-classify.md) |
| 3 | Act — fix, `# rigor:disable`, or open a Rigor issue. | [`references/02-fix-or-suppress.md`](references/02-fix-or-suppress.md) |
| 4 | Refresh — `rigor baseline drift`, then `rigor baseline regenerate`. | [`references/02-fix-or-suppress.md`](references/02-fix-or-suppress.md) |

Phases 2–4 repeat per rule until a stop condition (below) fires.

## Reading order — modules

| Module | Read | Covers |
| --- | --- | --- |
| 1 | [`references/01-classify.md`](references/01-classify.md) | **Phases 1–2.** Priority order from the `rigor triage` hints + ascending bucket count. The sample-and-classify protocol; the three-way real-bug / stylistic / FP triage and how to tell them apart. |
| 2 | [`references/02-fix-or-suppress.md`](references/02-fix-or-suppress.md) | **Phases 3–4.** Acting on each classification — fix patterns, `# rigor:disable` placement (per-line vs per-file), FP escalation as a Rigor GitHub issue. Refreshing the baseline with `drift` + `regenerate`. |

## Stop conditions

End the session — do not grind indefinitely — when any of these hit:

- The user signals halt.
- The next rule's site count exceeds the session budget (default:
  ~20 sites). A 200-site rule is systemic; escalate it as a decision
  (below), do not walk it site by site.
- A wall-time budget is reached (default: ~60 minutes).

Always finish with Phase 4 (refresh the baseline) before stopping, so
the landed work is recorded.

## Decision points to escalate to the user

- "This rule has 200 sites across 14 files — it looks systemic. A
  plugin or an engine fix would clear them in bulk; want me to
  investigate that instead of walking sites one by one?"
- "This file's diagnostics would be cleaner under one per-file
  `# rigor:disable-file <rule>` than 30 per-line comments — switch?"
- "The diagnostic wording changed between Rigor versions and the
  baseline no longer matches cleanly — regenerate now?"