Entrix

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 repair the same short fitness section there too
3. if both exist, keep them consistent instead of updating only one
4. if neither exists, create a minimal AGENTS.md

Creation rules are strict:

• do not create a new CLAUDE.md when the repository did not already have one
• do not create a new AGENTS.md when CLAUDE.md already exists as the sole agent entrypoint unless the user explicitly asks for both
• if neither exists, create only AGENTS.md

Do not duplicate the whole rulebook into the entrypoint file. The goal is discoverability from every agent entry document the repository already uses, not just the first one you happen to see.