/entrix

name: entrix
description: Set up or repair Entrix guardrail specs in the current repository by discovering real quality signals, generating docs/fitness, and iterating with entrix validation until the result is executable. Use when the user asks to bootstrap entrix, add or split fitness dimensions, repair invalid guardrail specs, or make docs/fitness actually runnable.
license: MIT

Entrix Skill

Goal: leave the target repository with a working `docs/fitness/` configuration that matches real tooling, is discoverable from the repository entrypoint, and passes Entrix validation instead of merely looking plausible.

Entrix uses `fitness` in the evolutionary architecture sense: an executable check that measures whether a codebase still satisfies a quality or architecture goal. The user-facing description is "quality guardrail".

This skill now uses a small entrypoint plus reusable spec files under `specs/`. Read those specs instead of improvising schema details.

Skill Folder Contents

• `specs/README.md`: second-level map of the available specs
• `specs/schema-frontmatter.spec.md`: Entrix-compatible evidence file shape
• `specs/manifest.spec.md`: required `manifest.yaml` shape
• `specs/dimension-boundaries.spec.md`: how to split or merge dimensions
• `specs/dimension-*.spec.md`: per-dimension guidance
• `examples/`: copyable minimal snippets
• `../../tests/fixtures/skill_regression/`: bundled repository profiles used by

the skill regression harness

Read Order

For any bootstrap or repair task, read in this order:

1. target repository `AGENTS.md` and `CLAUDE.md` if present 2. target repository manifests and task runners: `package.json`, `pyproject.toml`, `Cargo.toml`, `justfile`, `Makefile` 3. target repository `.github/workflows/**` 4. existing target `docs/fitness/**` if present 5. this skill's `specs/README.md` 6. only the specific `specs/dimension-*.spec.md` files needed for the task 7. matching `examples/*.md` when entry-document or CI-boundary behavior is ambiguous

Core Rules

• Use real repository signals only. Do not invent commands.
• Prefer repository-root-safe wrappers such as `just`, `make`, `npm run`, or

`cargo --manifest-path ...` when a bare tool invocation would depend on a subdirectory working directory.

• Prefer checked-in scripts and CI-established commands over plausible

defaults.

• For bootstrap output, prefer commands that are runnable in the current local

environment, not only commands that look semantically correct from CI or repo structure.

• Only create a security metric when the repository shows direct evidence for

that tool in scripts, CI, or checked-in docs. Do not add common scanners by assumption.

• If a candidate metric depends on optional local tooling that is not installed

and no checked-in wrapper self-bootstraps it, do not leave it as a default `fast` hard gate. Prefer a locally runnable wrapper, another repo-established signal, or explicit blocker reporting.

• If a repository's real test or build command is authoritative but requires

repo-specific dev dependencies or CI provisioning that are missing locally, do not force it into the default local fast tier. Prefer a locally runnable smoke check plus a CI-scoped authoritative metric. Prefer `execution_scope: ci` over leaving that command as a default local metric that will fail on a fresh machine.

• Treat missing compiler/runtime versions the same way. If the repository

requires a newer Rust, Node, Python, or similar toolchain than the current machine provides, do not keep those commands as default local metrics unless the user explicitly wants that blocker preserved.

• Use Entrix-compatible schema only. Do not invent alternate manifest or

frontmatter shapes.

• If weighted dimensions participate in scoring, their file-level weights must

sum to exactly `100`.

• If the repository has a real build, package, docker, or CLI smoke signal,

consider `release_readiness` explicitly.

• If the repository has a contract or schema surface, consider

`api_contract` explicitly.

Schema Rules

Use the standard Entrix shapes only:

• each evidence file uses YAML frontmatter with:
• `dimension`
• `weight`
• `tier`
• `threshold`
• `metrics`
• dimensions use `snake_case`, for example:
• `code_quality`
• `testability`
• `release_readiness`
• `api_contract`
• `manifest.yaml` uses:

schema: fitness-manifest-v1
evidence_files:
  - docs/fitness/code_quality.md
  - docs/fitness/testability.md

Never use:

• `dimensions:`
• metric-level `weight`
• `pass_threshold`
• bare filenames in `manifest.yaml`
• hyphenated dimension ids when the repository already uses Entrix-style

snake_case

Workflow

1. Inspect the target repository

Determine the real executable signals from:

• package manager scripts
• task runners such as `just`
• CI workflows
• checked-in helper scripts
• existing `docs/fitness/**`

Preferred command order:

1. repository task runner or package scripts already used locally 2. root-safe commands copied from CI 3. direct tool commands only when the repo clearly uses them and the working directory is unambiguous

2. Design dimensions from actual surfaces

Common dimension families:

• `code_quality`
• `testability` or `test_coverage`
• `security`
• `release_readiness`
• `api_contract`
• `ui_consistency`
• `design_system`
• runtime evidence such as `observability` or `performance`

Keep one stable concern per file. If the repository already separates concerns, do not collapse them into one vague file.

3. Write discoverable fitness docs

Minimum output for a new repository:

• `docs/fitness/README.md`
• `docs/fitness/manifest.yaml`
• `docs/fitness/review-triggers.yaml`
• at least `code_quality` and `testability` or another clearly justified test

dimension

Keep the repository entrypoint short:

1. if `AGENTS.md` exists, add or repair a short fitness section there 2. if `CLAUDE.md` exists, add or re