coverctl vs native commands (go test -cover, pytest --cov, nyc)

TL;DR

coverctl is not the Go cover tool, and not locked to one language. It is a governance layer for all sorts of languages: it invokes whatever native coverage command your project already uses, then evaluates per-domain policy from .coverctl.yaml — for agents via MCP, or for humans via the CLI.

	Native commands	coverctl
What it is	Language coverage runners (go test -cover, pytest --cov, nyc, …)	Agent-loop policy over those runners
What runs the tests	You invoke them	The same native commands, invoked by coverctl
What reads the result	You, in a terminal	The agent (via MCP) or you (via CLI)
Per-language	Yes, only one at a time	One uniform interface across 15 languages
Domain policy	None	First-class, in .coverctl.yaml
Agent integration	None	Native MCP
Pre-commit signal	You wire it up manually per-language	Built-in, MCP-native

Separate from Go cover

go tool cover, go test -cover, and -coverprofile remain Go’s coverage substrate. coverctl may call them on Go repos the same way it calls pytest --cov on Python repos. Domains, MCP tools, and .coverctl.yaml are coverctl’s job — not go cover’s.

Native commands are the substrate

coverctl does not replace go test -cover, go tool cover, pytest --cov, or nyc. It runs them. Then it does three things native commands cannot:

1. Adds per-domain policy — require 90% on src/auth/** and 60% on src/utils/** in the same repo, declared once (Go repos may use ./internal/auth/... as the match dialect).
2. Speaks one language across many — same .coverctl.yaml works in a Go + Python + TypeScript monorepo. Native commands force you to wire each language’s coverage tool independently.
3. Exposes coverage as a tool an agent can call — through MCP. The native commands have no agent interface.

Use native commands directly when

• You’re hacking on a one-language project and just want to see a number.
• You’re not using an AI coding agent.
• You don’t need per-domain enforcement.

Use coverctl when

Anything beyond the above. Especially:

• Polyglot codebases where wiring N coverage tools is N times the work.
• Teams using Claude Code / Cursor / Cline that want the agent to read coverage signals before commit.
• Critical-path code that needs stricter coverage than utility code.

What you don’t lose

coverctl never hides the underlying tool. coverctl run -v shows exactly what runner invocation it produced (go test, pytest --cov, nyc, cargo llvm-cov, etc.). If something fails, you can reproduce it with the native command directly. coverctl is a thin governance layer over a stable substrate, not a replacement for Go cover or any other language’s coverage CLI.

See also

• coverctl vs Codecov
• coverctl vs Coveralls
• Configure domains — path groups, not Go packages
• The agent loop, end to end