Argot Repository Style Analyzer

Learn unwritten conventions from Git history and flag changes that diverge from the repository.

Stars
★ 48
Last updated
14d ago
License
MIT
Primary language
Rust

At a glance

Works with
Universal · cross-platformClaude Code
You'll need
Gitusable repository historysupported source languageShell / CLILocal filesystem
Typical use
A maintainer reviewing AI-generated pull requests wants to catch dependencies, calls, or constructions that compile but have no precedent in the repository.
Main limitation
It depends on sufficiently deep and suitable Git history; shallow, generated, vendored, or otherwise unsuitable history may not yield a useful model.
Source review
93/100 · Excellent

What does this agent do, and when should you use it?

Argot is an MIT-licensed Rust static binary that fits a statistical baseline from a repository's own Git history and evaluates selected changes against it. Its interfaces include the `audit`, `init`, `check`, and `status` CLI commands, plus skills, read-only MCP tools, a Claude Code plugin, pre-commit hooks, and a GitHub Action. It can surface unfamiliar dependencies and calls, foreign token patterns, duplicated functions, misplaced code, reversed architectural dependencies, weakened tests, and rule tampering. Findings include repository evidence and are intended as prompts for human review, not proof of a defect or a correctness verdict. Fitting and analysis can run locally without an account or cloud service, although useful results require suitable repository history and supported source code.

For an initial assessment, argot audit fits a historical baseline in a temporary worktree and evaluates the surviving base-to-HEAD net diff while leaving the working tree untouched. For continuing use, argot init creates argot.toml and a .argot/ fit snapshot; after those files are reviewed and committed, argot check scores the intended changeset, while argot status recommends a refresh when accepted source, function, or layout surfaces have materially changed. Built-in rules produce voice, semantic, architecture, integrity, and governance findings. Repositories can add rules through a TOML manifest and sandboxed Rhai script under .argot/rules/. The CLI performs the complete explicit check; MCP exposes read-only context, hunk, and complete-changeset tools; pre-commit checks staged supported files; and the GitHub Action scores a configured ref or range. The optional Claude Code pre-write hook checks only whether Write, Edit, or MultiEdit introduces a foreign import, and it asks rather than blocks.

  1. A maintainer reviewing AI-generated pull requests wants to catch dependencies, calls, or constructions that compile but have no precedent in the repository.
  2. A large codebase team uses redundant and misplaced before merging a new function to find an existing equivalent or a more historically appropriate module area.
  3. An architecture owner checks whether a new internal import reverses the dependency direction learned from the repository.
  4. A test owner reviews production changes for deleted or disabled tests, gutted test bodies, and assertions that were removed, tautologized, or loosened.
  5. A team that wants reproducible local and CI review commits argot.toml and .argot/ so both environments read the same learned baseline.
  6. A repository with project-specific governance requirements adds TOML and sandboxed Rhai rules and detects attempts to weaken locked rules.

How do you install or deploy this agent?

On macOS or Linux, run curl --proto '=https' --tlsv1.2 -LsSf https://github.com/get-tmonier/argot/releases/latest/download/argot-installer.sh | sh. On Windows, run powershell -c "irm https://github.com/get-tmonier/argot/releases/latest/download/argot-installer.ps1 | iex". The npm alternative is npm install -g @tmonier/argot. Tested release targets are macOS arm64/x64, Linux x64/arm64, and Windows x64. No account or API credential is required, and analysis can run offline. The first invocation must be made inside a repository with usable Git history and supported source code.

How do you use this agent?

For a trial, run cd your-repository followed by argot audit. If the audit produces useful leads, run argot init and then argot check. Review and commit the generated argot.toml and .argot/ snapshot, merge that snapshot into the branch future pull requests will target, and only then add CI in a separate change. CI reads the snapshot from the base branch and never fits a model. Later, use argot status to determine whether a local fit-and-commit refresh is warranted. Set ARGOT_OFFLINE=1 when network access must be prevented; this does not remove analytical functionality.

What are this agent's strengths and limitations?

Pros
  • The baseline comes from the target repository's history rather than generic style rules or a second generative model, and every finding carries repository evidence.
  • Core analysis is local: the embedding model is compiled into the binary, no account or cloud service is required, source code is not uploaded, and telemetry is off by default.
  • One system covers repository voice, semantic duplication, code placement, architectural layering, test integrity, and rule governance, with extensibility through sandboxed Rhai rules.
  • CLI, MCP, Claude Code, pre-commit, and GitHub Actions routes support different workflows, while local checks and CI can share one committed baseline.
  • Published evidence reports detector-specific catch rates, corpus sizes, qualifiers, and measured noise instead of presenting one unsupported aggregate accuracy claim.
Limitations
  • It depends on sufficiently deep and suitable Git history; shallow, generated, vendored, or otherwise unsuitable history may not yield a useful model.
  • Initial adoption requires a local fit, human review, and committing a .argot/ snapshot that is typically a few megabytes to a few tens of megabytes; its pull request must land before the CI workflow change.
  • Findings are probabilistic review prompts rather than proof of defects, and errors expressed entirely through familiar vocabulary or located outside the selected range may escape detection.
  • Coverage differs by route: the Claude Code hook checks only foreign imports, MCP depends on client tool selection, and the GitHub Action's fail-on-hits setting defaults to false.
  • Public measurements are detector-specific; the project does not yet publish a product-wide accuracy figure, combined-briefing result, or ordinary-repository runtime claim.
  • The documented scope is limited to 12 language adapters and five tested release targets; the source provides no assurance for other languages or platforms.

How does this agent compare with similar options?

A type checker asks whether code satisfies its type constraints; Argot asks whether a change resembles the code, layout, and dependency direction established by that repository. Unlike sending the code to a second LLM for an opinion, Argot derives findings from local statistical, graph, scripted, and embedding evidence, with no generative or opinion-forming model deciding the result. The tradeoff is that it remains a repository-specific review guardrail, not a general correctness oracle.

Key facts side by side with the most closely related agents.

Agent Source review Stars Updated Language Full support on
Argot Repository Style Analyzer This agent 93 · Excellent ★ 48 14d ago Rust Claude Code
Gortex Code Intelligence 78 · Good ★ 1.6k 7d ago Go Codex · Claude Code · OpenAI API · Claude API
Aura Code Audit Trail 70 · Some gaps ★ 47 5d ago Rust Codex · Claude Code
Happier 82 · Good ★ 1.7k today TypeScript Codex · Claude Code

How does FollowAgents rate this agent?

FollowAgents source review · FARS-2.1
Excellent
93/ 100 5-point scale 4.7 / 5
Trust 28/29
Reliability 11/14
Adaptability 18/18
Convention 16/18
Effectiveness 12/13
Verifiability 8/8
Why each dimension lost points
Trust28 / 29 · 4.8/5

The evidence describes local analysis with no default telemetry or source upload, an embedded analysis model, ARGOT_OFFLINE=1, network transports removed from local Git operations, constrained scripted rules, and explicit CI permissions. Findings are advisory by default, while fitting, CI gating, integrations, and updating require explicit setup or invocation. Dependency auditing, checksums, build provenance, an unsafe-code prohibition, and third-party model licensing are documented concretely. Rollback loses one point because temporary worktrees and version-controlled snapshots provide recovery, but failed self-update recovery and version downgrade procedures are not fully documented in the supplied files.

Reliability11 / 14 · 3.9/5

The workflow covers Linux, macOS ARM64, Windows, findings, SARIF, missing snapshots, missing assets, and checksum failures, including assertions for actionable failure behavior. A static binary, embedded assets, and pinned Rust toolchain reduce availability risks, although installation and the Action still depend on hosted releases and external CI infrastructure. Self-consistency is deducted because README statements that the model always ships inside the binary conflict with SECURITY.md's statement that a missing semantic model may be fetched on first use, without reconciling the two contracts.

Adaptability18 / 18 · 5.0/5

The source distinguishes CLI, skills, MCP, Claude Code plugin, pre-commit, and GitHub Action audiences, prerequisites, coverage, and trigger modes. It also specifies twelve languages, five release targets, and repository-history conditions that can make analysis unsuitable. Capability boundaries are unusually explicit: Argot is a probabilistic review prompt rather than proof of correctness, automatic surfaces are limited, CI is advisory by default, and model-dependent tools require a fitted repository. The supplied evidence justifies full scores across this dimension.

Convention16 / 18 · 4.4/5

The README is organized into onboarding, capabilities, execution routes, evidence, limitations, privacy, contribution, and attribution, with detailed installation and two-stage CI guidance. The MIT text, redistributed-model attribution, security contact, supported-version policy, and single-maintainer responsibility are clear. Naming stability is deducted because consistent current terminology does not establish long-term stability under a 0.2.x rolling-release policy; examples are strong but no actual FAQ is supplied; versioning references releases without including substantive changelog evidence.

Effectiveness12 / 13 · 4.6/5

Results are usable through terminal output, JSON, GitHub annotations, and SARIF, and the workflow validates required SARIF properties, advisory defaults, and machine-readable state. The product adds repository-history signals for voice, duplication, placement, layering, test integrity, and governance beyond conventional compilation checks, with detector-specific catch and noise measurements. Cost-benefit is deducted because no fixed runtime is promised, fit snapshots may occupy tens of megabytes, and ordinary-repository timing and combined product-level performance remain explicitly unmeasured.

Verifiability8 / 8 · 5.0/5

Major claims are tied to an approved claim manifest, research evidence, pinned corpora, proof receipts, checksums, and regeneration procedures. Workflows, Cargo configuration, README, and SECURITY.md independently support many claims about locality, dependency boundaries, output contracts, and platform coverage. The source carefully separates authored demonstrations from wild-case evidence, detector metrics from overall accuracy, findings from proven defects, and measured claims from unmeasured ones, justifying full marks for fact/inference separation.

Risks and how to mitigate them
  • README and SECURITY.md conflict on whether a semantic model can be fetched on first use; verify the behavior of the exact release before relying on an offline guarantee.
  • Installation examples use curl-to-shell or irm-to-iex, while example automation follows main or latest; high-assurance environments should pin versions and verify release checksums and provenance before execution.
  • This is a probabilistic review aid, not proof of correctness or security; shallow history, generated or vendored code, unsuitable fit scope, and errors expressed entirely in familiar vocabulary can reduce effectiveness.
  • Only the latest release is supported and maintenance is explicitly best-effort by one person; adopters should assess upgrade cadence, continuity, and downgrade requirements.
  • Published measurements are detector-specific and use differing corpora and denominators; they should not be combined into a product-wide accuracy expectation.
Evidence confidence: Low Reviewed Sep 24, 2026 Reviewed revision 254a7ef11b58
See the full review method →

FAQ

Does Argot require a cloud account, API key, or paid model?
No. The individual local core is MIT-licensed and requires no account or cloud service. Its embedding model is compiled into the binary, so analysis can run fully offline.
Does it upload source code or repository history?
Its analysis does not upload source code, and there is no default telemetry. Version checks, updates, release downloads, or explicitly configured review, update, and CI integrations may use the network; ARGOT_OFFLINE=1 prevents network use.
Does a clean check prove that the change is correct?
No. A clean result does not establish correctness, completeness, or perfect conformity. Findings and non-findings both require human judgment.
Will CI automatically retrain the repository model?
No. CI only reads the committed snapshot from the base branch. Fitting and refreshes are explicit local operations whose results must be reviewed and committed.
What can make the results unreliable?
Shallow, generated, vendored, or otherwise unsuitable history can produce a poor model. Mistakes written entirely with familiar vocabulary, issues hidden in prose, and code outside the selected changeset are also documented weak spots.
View on GitHub ↗ Install ↓

Compare agents like this one

The same FARS review applied across the shortlist this agent qualifies for.

Related agents