CLARXThe standard for AI-first codebases

Make your codebase
legible to AI.

Clarx scores your repository against five structural pillars, generates a manifest agents can follow, and gives you a semantic component vocabulary that means the same thing to engineers and AI.

$clarx score .copy
Read the standard →
Overall score
0/100
B+confidence: high
$ clarx score .scope: 218 files · 4 packages2 warnings · 1 recommendation
DDiscoverability72
BBoundary clarity94
CContext efficiency82
OOperational guidance100
EEdit safety66

Your codebase isn't broken.
It wasn't designed for agents.

Three failure modes agents hit in unprepared repos. Each is detected by a Clarx rule.

Context waste
C1
Agent loads 12 files to answer a question that touched 2.
Context efficiency · –24
Unsafe edits
E3
Agent modifies a shared utility with 40 callsites. No signal it's load-bearing.
Edit safety · –31
Lost guidance
O1
Agent doesn't know how to verify its work. No manifest. No verification command.
Operational guidance · capped at 50

A scoring framework, not a magic number.

Five structural properties. Each weighted 20%. Each auditable. Score capped if a hard rule fails.

01 · DISCOVERABILITY20%

Find the right file in two attempts.

An agent should locate any module by name, purpose, or callsite without reading implementations.

D2Every package directory must contain a PURPOSE statement.
02 · BOUNDARY CLARITY20%

Infer ownership without reading code.

Module boundaries are explicit at the file system level. Imports cross them deliberately, not casually.

B4A module's public API must live in one entry file; deep imports flagged.
03 · CONTEXT EFFICIENCY20%

Complete a task loading ≤5 files.

Average task footprint stays low. Files have one job. Cross-cutting concerns are factored, not threaded.

C3File length capped at 400 lines; warnings emitted at 300.
04 · OPERATIONAL GUIDANCE20%

Tell an agent how to work.

The repo declares its verification commands, generated paths, and task locations in a single manifest.

Hard failure · O1No clarx-manifest.json → score capped at 50.
05 · EDIT SAFETY20%

Make incorrect changes structurally hard.

Load-bearing files are signalled. Utility sprawl is bounded. The blast radius of any single edit is visible from the file alone.

E2Utility files capped at 20 exports; over-cap files require a @callsites tag.

Run it on your repo. Read the score.

No telemetry. No login. The scoring engine is open source.

~/work/your-repo — clarxzsh
$ clarx score .
clarx v0.1.4 · scoring 218 files…
Discoverability72clean root, missing purpose stmts
Boundary clarity94
Context efficiency823 files over 400 lines
Operational guidance100
Edit safety662 utility files over 20 exports
Overall score83 / 100(confidence: high)
2 warnings · 1 recommendation
Run clarx explain C3 for details
$clarx score
Score the current repo against all five pillars.
$clarx init
Generate a starting clarx-manifest.json from your repo shape.
$clarx explain <rule>
Print rule rationale, examples, and the fix path.

One file. The on-ramp to every other pillar.

Agents know where to look, what to skip, and how to verify their work. Works with any stack — drop it in alongside your package.json.

Why a manifest, not docs?

Documentation is read once, by humans, when motivation is high. A manifest is read every time, by every agent, in every session. It's load-bearing infrastructure for AI workflows.

It's three things together: an intent declaration, a navigation map, and a verification contract.

stack-agnostic~30 linesversion-pinnedCI-checked
clarx-manifest.json✓ valid
.clarxignore
{
  "version": "0.1",
  "purpose": "AI-first design system and codebase standard",
  "generatedDirectories": [
    ".next", ".source", "dist"
  ],
  "verificationCommands": {
    "typecheck": "pnpm tsc --noEmit",
    "test": "pnpm test",
    "lint": "pnpm lint"
  },
  "commonTaskLocations": {
    "components": "packages/ui/src/",
    "engine rules": "packages/engine/src/scoring/rules.ts"
  }
}

A component API that speaks in intent.

Legible to AI tools, design tokens, and the engineer on call at 2am.

Before · utility sprawlopaque
// Status badge <span className="inline-flex items-center px-2 py-0.5 rounded text-xs font-medium bg-red-100 text-red-800"> Failed </span>
Failed
After · semantic Clarxintent-driven
// Same output. Different contract. <Badge intent="danger" keyword="failed" /> <Button intent="danger">Delete</Button>
FailedPendingHealthy

Start where you are.

The standard works without the components. The components work without the CLI. Everything gets better together.

01 · Lightest

Philosophy

Use the vocabulary and the thinking. Talk about discoverability and edit safety in PRs. No code changes.
Read the standard
Apply rule names in review
02 · Medium

Rules only

Add clarx-manifest.json and guidance files. Run clarx score in CI. Works with any stack.
Manifest committed
CLI in CI
Scoring gate on PRs
03 · Full

Full adoption

Standard + CLI + reference components. The same intent vocabulary from the README to the runtime.
Manifest + CI
Reference components
Org-wide score dashboard
The interface is not a decoration layer.
It is a communication layer.
— from the Clarx standard, §0 · Premise