Skip to content

Quickstart

This walk-through takes a fresh repo from zero to a green Sextant verdict in under five minutes. It assumes you have sextant and sextant-mcp on PATH (see Installation).

Terminal window
cd path/to/your-repo
sextant init

This writes a starter .sextant/ directory:

.sextant/
├── config.toml # verdict thresholds and rule limits
└── rules/ # repo-local rule markdown files (empty by default)

The default config is conservative — max_errors = 0, file-length warn at 400 lines, error at 800. Tune these later if needed.

Terminal window
sextant grade

Output looks like:

Sextant — 12 findings (0 errors, 7 warns, 5 info)
warn src/parser.rs:412
builtin.size.file-length
File length 412 exceeds warn threshold (400)
warn src/handlers.rs:88
builtin.size.fn-length
Function `dispatch` is 78 lines (warn at 60)
verdict: approve

The default mode grades whole files: every line is checked, every finding listed. Useful for an audit of a repo’s debt.

For day-to-day work and CI, you almost always want diff mode:

Terminal window
sextant grade --diff --base origin/main

This restricts findings to lines in your branch’s diff. It’s fast (sub- second on most changes) and matches how the GitHub Action and the agent hooks grade.

Terminal window
sextant rules list

Shows every rule loaded for this repo — built-ins plus anything under .sextant/rules/. To read a rule’s full body and fix advice:

Terminal window
sextant rules explain builtin.size.fn-length

You’re now ready to wire Sextant into a feedback loop:

  • A .sextant/ config that the CLI, MCP server, and Action all read from.
  • Seven built-in rules covering size, complexity, duplication, and tests.
  • A grading entry point you can call from a shell, an editor, or CI.

Next, learn the data model so the report fields make sense, or jump straight to a surface.