Sextant

What is Sextant, and when should I use it?

Sextant is a code-quality grader built for codebases where AI agents (Claude Code, Cursor, Copilot, …) write a real share of the code.

Imagine you want every diff — agent-written or human-written — to stay within your team’s bar for file length, function length, complexity, duplication, test coverage, and whatever other house rules you have.

Usually you only find out a diff is over the line one of three ways:

• a teammate catches it in PR review, hours or days later;
• CI lint or format jobs flag it after the agent has already finished its turn and moved on;
• you read the diff yourself, decide the function is too long or duplicates something, and either fix it by hand or feed the complaint back to the agent as a follow-up prompt.

All three are reactive. By the time the feedback lands, the agent’s context is cold and the cleanup falls on you.

Sextant moves that feedback into the loop. The same grader runs in two places:

• inside the agent, as an MCP tool and Claude Code hooks — the agent grades its own diff after every edit and self-corrects before ending the turn;
• on every PR, as a GitHub Action that posts a single review comment and only blocks merge on regressions, so pre-existing debt doesn’t gate new work.

One .sextant/ config drives both. You customize what counts as a finding (thresholds for the built-in rules, plus your own markdown rules judged by Claude or GPT), how strict the verdict is (how many errors or warnings flip a grade from approve to request_changes), and what the grader looks at (just the diff, the touched files, or the whole repo).

If you’re hand-reviewing every agent diff for the same handful of issues, or watching CI flag the same things over and over, Sextant is the loop you’re missing.

One engine, five surfaces

MCP server

Agents call grade_diff after each edit and self-correct before finishing the turn. Stdio or HTTP transport. Read the MCP guide →

GitHub Action

Posts a single review comment on every PR. Gates merge on regression — pre-existing findings don’t block new work. Wire up CI →

Claude Code plugin

Skills, slash commands, and hooks that wire grading into the Claude Code edit loop with zero extra configuration. Install the plugin →

Editor (LSP)

Squiggles in your editor as you type. Hover any squiggle for the rule’s full documentation. VS Code extension included. Install for your editor →

CLI

sextant grade for human, JSON, markdown, or SARIF output. Works offline once installed. Browse the CLI reference →

Why Sextant

Built for the inner loop

Diff-mode grading runs in well under a second on a typical change, so an agent can grade after every edit without slowing the user down.

Deterministic by default

Built-in rules are pure Rust — file length, function length, cyclomatic complexity, nesting, parameter count, token duplication, untested public functions. No network calls.

LLM rules when you want them

Author markdown rules that are evaluated by Claude or GPT against individual files. Cached by content hash so repeat grades are free.

Regression-aware

PR mode only blocks on findings introduced by the change. The repo’s existing debt is its problem; the PR’s job is to not make it worse.

Shareable rule packs

Install curated rule sets with sextant rules add github:owner/repo@tag. Every file is hash-locked — agents can’t silently disable a pack rule. Browse packs →

Quickstart

# Install (brew tap pending)
cargo install --path crates/sextant-cli
cargo install --path crates/sextant-mcp

# Bootstrap a config in your repo
cd your-repo && sextant init

# Grade the working tree
sextant grade

# Grade only what changed since main
sextant grade --diff --base origin/main

Then wire it into Claude Code or your CI.