Adoption Guide

Clarx is designed to be adopted in layers. You do not need to restructure your entire codebase on day one.

Three adoption paths

Option 1 — Philosophy only

Use the standard vocabulary in design review, architecture discussions, and PR feedback.

This is useful when you want shared language around discoverability, boundaries, and edit safety before changing tooling or repo layout.

What to do:

• Read the Standard overview and Pillars
• Reference rule IDs (e.g. C3, O1) in code review
• Share the Manifesto with your team as a framing doc

Option 2 — Score in CI

Add clarx-manifest.json, guidance files, and clarx score to your pipeline.

This works with any stack. The CLI exits non-zero when thresholds are not met, so you can gate merges on structural health.

What to do:

• Run clarx init to scaffold a manifest
• Add CI integration with --min-score or --min-pillar-score
• Use clarx explain <rule> to turn failures into actionable fixes

Option 3 — Full operational adoption

Standard + manifest + CI + AI rules files committed to the repo.

This is the highest-leverage path. Agents load the manifest every session, CI enforces the standard, and portable rules keep generated code aligned with your conventions.

What to do:

1. Commit clarx-manifest.json with verification commands and common task locations
2. Add CLAUDE.md, Cursor rules, or AGENTS.md snippets
3. Track score trends over time and fix pillar gaps iteratively

---

For any codebase

Clarx is not tied to a specific framework. The filesystem and guidance rules apply everywhere. Import-graph rules are deepest on JavaScript and TypeScript projects, but every repo benefits from a clear manifest, generated-artifact hygiene, and operational guidance.

Start with clarx score . and improve from the findings.