# CLIARE builds a command index by running your CLI, and the build defaults allow 5000 probes

> A Rust workspace of sixteen crates that probes a released CLI as a black box, records evidence and infers a command index for agent harnesses, where the traversal budget defaults to a deep profile at 5000 probes and the authenticated context runs the target with credentials present.

**modiqo/cliare** — CLI agent-readiness measurement, command-shape inference, and CI scorecards

- Repository: https://github.com/modiqo/cliare
- Website: https://cliare.sh
- Stars: 470 · Forks: 19
- Language: Rust
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/modiqo-cliare

## The justfile measures the installed cliare, not the one you just built

The repository ships a justfile whose recipes are the documented workflow, and its first variable decides which CLIARE actually runs. `cliare_bin := "cliare"` resolves to whatever is on the PATH, with a comment saying to override it with `just cliare_bin=target/debug/cliare ...` when dogfooding a local build. An un-overridden recipe therefore audits the released binary rather than the working tree, and the local dogfood check the cheatsheet puts first, `just justdev` followed by `just review cliare`, is only a self audit if the override is remembered. The default recipe prints the cheatsheet instead of running anything, and the cheatsheet orders five paths: the dogfood check, a standard maintainer review, a deep measurement for large surfaces, a security or host-state review, and an authenticated or local-context comparison.

## The sixteen crates are listed twice, and only one list is Cargo's

Cargo.toml declares a workspace with the root package and sixteen members: cliare-app, cliare-cli, cliare-context, cliare-core, cliare-eval, cliare-evidence, cliare-guidance, cliare-inference, cliare-inspect, cliare-issues, cliare-measure, cliare-policy, cliare-report, cliare-runtime, cliare-score and cliare-shape. The justfile then keeps a second copy of the same names inside one string, `packages := "cliare-core cliare-runtime cliare-policy cliare-issues cliare-inference cliare-evidence cliare-shape cliare-context cliare-cli cliare-score cliare-report cliare-eval cliare-guidance cliare-measure cliare-inspect cliare-app cliare"`. That is a hand maintained inventory in a build file, not something Cargo reads. Two inventories of one workspace is the same command-shape drift the tool exists to catch in other projects, and adding or renaming a crate means editing both files with nothing in either marking the second list as authoritative.

## The build defaults start at 5000 probes, depth 12, nothing dropped

The traversal budget sits at the top of the justfile as plain variables: `profile := "deep"`, `max_depth := "12"`, `max_probes := "5000"`, `concurrency := "8"`, `allowed_drop := "0"`. Deep is the default there, while the first measurement example in the README passes `--profile standard`, so the cheap screen and the exhaustive walk are one flag apart and the build file begins at the expensive end. `allowed_drop := "0"` is the sharper of the two: the budget tolerates no dropped items, which reads as a demand for a complete surface or a visible failure rather than a quietly partial index. Eight probes run concurrently against a binary that may be writing files, which is the number to keep in mind whenever the target is not a test fixture. None of these values appear in the usage documentation; they exist only in the justfile. A `just jobs <run-name>` recipe appears in the cheatsheet alongside the deep measurement step, which reads as a way of inspecting what the fan-out actually cost, though the recipe itself is not described further.

## Measurement leaves a .cliare/ directory inside the repository it audits

Every example writes its results into a run folder under the project being measured, `.cliare/mycli`, holding `command-index.json`, `AGENT_SKILL.md` and `persona-harness.json`. The audit therefore drops files into the tree it inspects, and Cargo.toml answers that by excluding the output directories from the published package, alongside `.cliare-bench/**`, `.github/**`, `target/**`, `.DS_Store`, `AGENTS.md`, `action.yml` and parts of `docs/`. That exclude list is a compact admission of what a run leaves on disk. A team wiring this into CI gets a new directory in the working tree on every run, and the repository does carry a `.gitignore`, though nothing in the project states whether that file covers `.cliare/`. The same exclusion applies to measurement data kept outside the audited project, since `.cliare-bench/**` is dropped too, and the presence of a `benchmarks/` directory at the root suggests the tool is measured against other tools as well as against CLIs.

## The authenticated context tells the probe that credentials are present

Context is the axis that decides how much of a machine the probe touches, and the six named values are clean, repository, authenticated, host, fixture-backed and CI. The heaviest documented invocation combines several of them:

```sh
cliare measure mycli \
  --out .cliare/mycli \
  --context authenticated \
  --auth-state present \
  --execution-mode host \
  --profile deep \
  --refresh
```

`--auth-state present` is the flag to read twice, since it declares that credentials are in place, and `--execution-mode host` says the commands run against the host rather than a sandbox. Bounded controls do exist: named contexts, a probe ceiling, a depth cap, concurrency 8. What the documented flags do not include is a dry run, so the configuration that produces the most complete index is also the one that hands the target live auth state, and the same run is eight probes wide.

## The security claim is a filesystem snapshot around probes that look harmless

The security method is stated precisely: CLIARE snapshots filesystem state around each probe and reports persistent side effects from commands that appear read-only, naming help, version, invalid flag and output-mode probes as the ones it watches. That is a real finding class, because the design runs discovery commands against a binary nobody has read, and a version flag that quietly drops a cache directory leaves no trace in help text. Evidence references are preserved for review and audit trails, and the reports separate expected auth, host, network, daemon and fixture behavior from surprises, which is what makes a finding arguable rather than alarming. The maintainer-facing output is a queue in the same spirit, with missing help, confusing diagnostics, parseable output gaps, unsafe discovery side effects, precondition blockers and command-shape drift as the categories, each entry carrying associated commands, suggested remedies and verification commands, and the reports come in maintainer, harness and security variants in markdown, json or human format. What the claim is not is a guarantee: a write that is cleaned up before the snapshot closes, or one that only fires on a platform the project does not name, sits outside what a before-and-after comparison can see.

## Four knobs on the command line, two values ever shown

One measure invocation takes profile, context, execution-mode and auth-state, and only two profile values appear anywhere in the project: `standard` and `deep`. The justfile sets `profile := "deep"` for its own recipes, and the README's opening example passes `--profile standard`, so the two documented profiles are also the two ends of the range. `--refresh` appears on every example, which implies results are otherwise reused from the run folder, and that same folder is what the summary and report commands read back. The consumed surface is wide on top of that: `cliare surface query`, `cliare surface explain` and `cliare surface list` for compact routing answers, with `command-index.json` named as the evidence-backed source of truth whenever a route needs auditing. The project shows which questions to ask a CLI, not what the answers look like for any particular one.

## cargo install gives you the July tag, while main is a month newer

The documented install is `cargo install cliare`, and the release history is three tags: v0.1.7 on 18 June 2026, then v0.1.8 and v0.1.9 both on 2 July 2026, 27 minutes apart. Cargo.toml carries version 0.1.9 across the workspace, so the manifest and the newest tag agree, but the last commit on main is dated 2 August 2026, a month after that tag, which means the tree you clone is ahead of the binary you install. Five routes reach the same tool with different pinning behaviour: the crate, `install.sh`, `flake.nix`, `devbox.json` and `action.yml`, with a `packaging/` directory behind them. Building from source sets a high floor, since the workspace asks for edition 2024 and `rust-version = "1.89"`.

## Conclusion

CLIARE is worth running on a CLI you maintain, and the finding class it reports, side effects hiding behind help and version flags, is the part no hand written contract would have caught. Two things decide how you run it. The justfile measures whatever `cliare` is on your PATH, so a self audit needs the `cliare_bin` override or it grades the released binary. And the deep authenticated context tells the probe that credentials are present and runs commands against the host, with no dry run in the documented flags, so that measurement belongs in a sandbox with credentials you can throw away. Do not read the resulting index as a compatibility promise for agents; it is a snapshot of one binary, taken on one day.

## FAQ

### What does CLIARE actually measure?

It treats the released CLI binary as a black box, probes runtime behavior under bounded controls, records evidence, infers the command surface, detects side effects, and emits command indexes, issue ledgers, scorecards, one-command summaries, persona reports, CI artifacts and agent skills. The name stands for CLI Agent Readiness Evaluation.

### What goes into the CLIARE command index?

Command paths, flags, operands, preconditions, output contracts, confidence, suitability and evidence references, written to .cliare/<run-name>/command-index.json. The same run folder also receives AGENT_SKILL.md and persona-harness.json, so a skill file and the index are generated together.

### Which contexts can CLIARE measure a CLI in?

Clean, repository, authenticated, host, fixture-backed and CI. The documented deep run pairs the authenticated context with --auth-state present and --execution-mode host, meaning the probe environment holds credentials and the commands run against the host rather than a sandbox.

### How do I install CLIARE and what version do I get?

cargo install cliare pulls the published crate, whose newest tag is v0.1.9 from 2 July 2026, while the last commit on main is dated 2 August 2026. The repository also carries install.sh, flake.nix, devbox.json, packaging/ and action.yml, and building from source needs edition 2024 with rust-version 1.89.

## Sources

- [License: Apache-2.0](https://github.com/modiqo/cliare/blob/main/LICENSE)
- [modiqo/cliare on GitHub](https://github.com/modiqo/cliare)
- [Project website](https://cliare.sh)
- [README](https://github.com/modiqo/cliare/blob/main/README.md)
- [Releases](https://github.com/modiqo/cliare/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/modiqo-cliare