Turn your style guide into a ruleset you actually own.

Sixty-three percent of teams run Spectral on its defaults — a config file nobody wrote, grounded in nothing. Spectral Ruleset Studio makes the other path cheap: paste a prose statement, and the tool walks you to a target, one of the 9 core functions, a message and severity — and forces the grounding (a named id, an owner, a rationale, a docs link) that turns a bare verdict into guidance. Distilling the prose is the point: it exposes exactly where the words were too vague to enforce.

Open the studio ↓ Browse starter rules

npx @api-common/spectral-ruleset-studio operations info -o .spectral.yaml

Distill, don't copy

Paste style-guide prose; the tool flags vague words and makes you pin down exactly what a rule checks.

9 functions, no JS

Every rule uses one of Spectral's built-in functions — defined, truthy, pattern, casing, length, enumeration, schema and more — with guided args.

Grounding required

No rule ships without a convention id — spec-version-property-semantics-severity — an owner, a rationale and a docs link, so a red build teaches instead of just stopping.

Swagger 2.0 + 3.x

Every rule targets both specs. Divergent paths (definitions vs components.schemas) emit as a multipath given or format-tagged twins — pick 3.x, 2.0, or Both.

Valid YAML out

Live, categorized .spectral.yaml that parses as you type — copy it, download it, or scaffold it from the CLI.

The studio

Add rules three ways — paste prose to distill, drop in a grounded starter, or build one from scratch — then tune every field. The ruleset on the right updates as you go.

No rules yet. Paste prose above, add a starter rule, or start a blank one.

.spectral.yaml Target x-grounding

Starter library

Ready, already-grounded rules you can add and tune — of them. They are a starting point, not a standard: own them before you gate on them.

Philosophy & usage

A ruleset you did not write is a ruleset nobody at your organization had to think through — which means nobody owns it, which means the identical YAML that is a governance artifact in one repo is an empty gesture in another. This tool makes the human work — distilling prose, naming the rule, grounding it, owning it — the cheap part. Read the paper: The State of Spectral in API Pipelines.

Scaffold from the CLI

# Emit the whole grounded starter library to stdout
npx @api-common/spectral-ruleset-studio

# Only certain areas, written to a file
npx @api-common/spectral-ruleset-studio operations info -o .spectral.yaml

# A specific rule by id
npx @api-common/spectral-ruleset-studio --id oas-x-operation-operationId-defined-error

# List every template id
npx @api-common/spectral-ruleset-studio --list

Run your ruleset in CI (sparingly, and never silently)

- name: Govern the API
  run: npx @stoplight/spectral-cli lint openapi.yaml --ruleset .spectral.yaml
# then turn the JSON into a readable report:
#   spectral lint -f json openapi.yaml | npx @api-common/spectral-reporter -o report.html

The 9 core functions

defined · truthy · falsy · undefined — presence checks.
pattern · casing · length — string shape.
enumeration · alphabetical · schema — allowed values, ordering, structure.

The emitter is a pure, shared module used verbatim by this page and the CLI — so the YAML you copy here is byte-for-byte what the terminal writes. Free and open under the Apache-2.0 license. When you want experts in the loop, .