Shared guardrails

Rules stop the AI from sounding confident for the wrong reason.

In this repo, rules hold reusable engineering discipline. They reduce guessing, keep output shapes stable, and make it easier to trust what a skill or flow returns.

Overview Start Here Skills Rules Block DV Flow

Common rules

These apply across many skills.

Common

Evidence Grounding

Every reported fact must trace back to the given RTL or input text.

Why it exists It stops invented structure, fake certainty, and name-based guesses.

Small example A signal called `foo_sync` is not proof of a safe synchronizer by itself.

Common

Output Discipline

Each skill must emit one clean YAML document with the exact expected shape.

Why it exists It keeps output stable for reuse, comparison, and validation.

Small example If a section is empty, emit `[]` instead of silently dropping it.

Analysis rules

These keep CDC and timing analysis conservative.

CDC

CDC Classification

This rule defines when a crossing is really proven safe and how to grade severity.

What it prevents Calling a crossing "safe" just because the signal name looks right.

Small example A plain 2-FF scheme on a multi-bit bus is not treated as a safe transfer by default.

Timing

Timing Register Evidence

This rule defines what counts as a real register and when timing structure must stay unresolved.

What it prevents Tracing through unknown macros, wrappers, or missing submodule logic as if they were known.

Small example A block named `state_ff` is only a hint until the RTL proves it is sequential logic.

DV planning rules

These keep tests, assertions, and coverage tied to real objectives.

Objective Traceability

Every test, assertion, and coverage item must link back to objective IDs.

UVM Component Selection

Add only the agents, scoreboards, and models that the objectives really justify.

Assertion Classification

Put each assertion candidate into one clear class such as reset, protocol, state, or error.

Coverage Taxonomy

Cover reset, nominal, corner, config, and error behavior when the inputs actually show them.

Stimulus Prioritization

Use `must`, `should`, and `could` with real meaning, not vague emphasis.

Why this matters

Smaller plans, stronger reasons

These rules help the repo create plans that are easier to review because every item has a reason to exist.

Key idea

The repo keeps shared policy in `rules/` so the same anti-hallucination and planning discipline does not get copied into every skill file.

View upstream rules See the skills that use them