Skip to content
LintLang 0.5.3 · FAQ and comparison10 questions · sources checked 7 September 2026

Why use LintLang, and how it compares.

Direct answers on what LintLang does, what a clean scan proves, and how it relates to the adjacent tools teams weigh it against. Every comparison states jobs and boundaries from the other project’s own documentation, not a ranking.

Machine-readable copy: /lintlang/faq.json · Product page: /lintlang

§ 01

Questions

Same text as the JSON-LD and JSON export

What is LintLang?

LintLang 0.5.3 is an open-source, Apache-2.0 static linter from Hermes Labs for the natural-language instructions that control AI agents. It scans JSON and YAML agent configurations with recognized top-level fields, .txt, .md, and .prompt instruction files such as AGENTS.md, CLAUDE.md, and GEMINI.md, and Python files through AST extraction of prompt-like strings and thresholds. It reports findings such as ambiguous or overlapping tool descriptions, missing stop conditions, conflicting directives, and schema and description mismatches, with PASS, REVIEW, FAIL, or ERROR verdicts and terminal, JSON, or SARIF 2.1.0 output. LintLang's default static checks are deterministic and local. They make no LLM, API, telemetry, or network calls.

Why use LintLang?

Because an instruction defect is cheap to catch as text and expensive to discover in production. A vague tool description sends the model to the wrong tool, a missing stop condition lets an agent retry without limit, and two contradictory rules leave the model to guess. LintLang finds those patterns deterministically in the files a repository already has, before any model call, with no API key, network access, or per-run cost, and it fits pre-commit, a GitHub Action, and GitHub Code Scanning through SARIF. It is nonblocking by default; --fail-on fail blocks HIGH and CRITICAL findings and --fail-on review also blocks MEDIUM findings.

What does a clean LintLang scan prove?

A clean LintLang scan is not evidence that an agent is safe or runtime-correct. PASS means no MEDIUM, HIGH, or CRITICAL finding remained in the recognized content extracted from the requested inputs under the selected checks and filters. LintLang does not determine whether an instruction is factually or semantically correct, observe an agent selecting or executing tools, prove that a finding causes a runtime failure, certify an agent as safe or production-ready, or replace runtime evaluation or human review. Use it before prompt tests, guardrails, and production monitoring, not instead of them.

Which tool should I use for my situation?

Start from the failure in front of you and pick the layer that catches it earliest. The instructions or tool descriptions are vague, overlapping, or contradictory. Use LintLang: the defect is in the text and can be caught before any model runs. You want one repository-wide check of Claude Code, Cursor, Codex, or MCP configuration trees. Use Agent Lint: it validates harness-specific configuration structure, and it can run beside LintLang. The model got worse after a prompt change, or you need to compare models on test cases. Use promptfoo: behavior only shows when the prompt runs against the model with assertions. You need behavioral test suites, generated test sets, or vulnerability scans of an agent or RAG pipeline. Use Giskard: those checks require the agent to answer. The application must check or alter inputs, retrieved content, actions, or outputs while it runs. Use NVIDIA NeMo Guardrails: only a runtime layer can act on a live interaction. These tools complement each other more than they compete, and none of them answers the others' question.

Can I use LintLang together with these tools?

Yes, and that is the intended order: syntax and schema validation, then LintLang static language checks, then runtime agent evaluation, then domain and security review. LintLang and Agent Lint can both run in pre-commit and CI on the same repository. promptfoo and Giskard evaluate the behavior that LintLang cannot see. NeMo Guardrails acts on live interactions that no pre-runtime check can reach. Each layer answers a different question, so a pass at one layer says nothing about the others.

How do I try LintLang?

Run it once without installing anything: uvx --from lintlang==0.5.3 lintlang scan AGENTS.md. It requires Python 3.10+ and depends only on PyYAML. The product page includes a browser playground that runs the released 0.5.3 wheel locally. To make findings block CI, add --fail-on fail; to generate a pinned GitHub Code Scanning workflow, run lintlang init --github from the repository root.

§ 02

Jobs and boundaries

One card per tool · sources checked 7 September 2026

LintLang 0.5.3 is deterministic static analysis of AI agent instructions and configuration. The instruction text itself: JSON and YAML agent configurations with recognized top-level fields, .txt, .md, and .prompt instruction files such as AGENTS.md, CLAUDE.md, and GEMINI.md, and Python files through AST extraction of prompt-like strings and thresholds. It runs before any model call, on files, directories, or stdin. Each card below restates the linked official documentation for one adjacent tool. Silence in a source is not treated as a missing feature.

Static configuration linter

LintLang vs Agent Lint: which should I use?

Agent Lint describes itself as: “A linter for Claude Code, Cursor, and Codex configuration.”

What it checks
Repository configuration and documentation for Claude Code, Cursor, Codex, and MCP: .claude/, .claude-plugin/, .cursor/, .cursorrules, .codex/, .codex-plugin/, AGENTS.md, .agents/skills/, and MCP configuration. Deterministic static validation with JSON output, a GitHub Action, and a pre-commit hook.
When it runs
Before runtime, on the repository configuration tree
Choose LintLang when
Choose LintLang when the defect is in the wording of instructions and tool descriptions: vague or overlapping tools, missing stop conditions, contradictory directives, or schema and description mismatches, across prompt files, YAML or JSON agent configs, and prompts embedded in Python, with SARIF for GitHub Code Scanning.
Choose Agent Lint when
Choose Agent Lint when you want to validate the structure of harness-specific configuration trees for Claude Code, Cursor, Codex, and MCP, including skills, plugin manifests, and marketplace files, as one repository-wide check.
Combine them
Both are deterministic pre-runtime linters that run in CI and pre-commit. Run Agent Lint over the configuration tree and LintLang over the instruction text. The projects are independent; the Agent Lint maintainer has publicly recorded ideas carried from LintLang.

Its README states that a clean lint result is not a safety or correctness proof for an agent, model, tool, command, or deployment.

Prompt evaluation and red teaming

LintLang vs promptfoo: which should I use?

promptfoo describes itself as: “A CLI and library for evaluating and red-teaming LLM apps.”

What it checks
How prompts, models, and LLM applications behave on test cases: it runs them against configured model providers, scores outputs with assertions, compares models side by side, and runs red-team and vulnerability scans, from the CLI, as a library, or in CI/CD.
When it runs
Against live model providers, in development and CI
Choose LintLang when
Choose LintLang when you want a deterministic check of the instruction text itself, with no model call, that can gate a commit or pull request before any evaluation run.
Choose promptfoo when
Choose promptfoo when the question is how the model behaves: regressions after a prompt change, model comparisons, assertion-based test cases, or red-team probes against the running application.
Combine them
Lint first, then evaluate. A LintLang PASS does not predict evaluation results, and a passing evaluation does not repair vague or contradictory instruction text. Running both catches text defects for free and behavioral defects where they show.

Agent testing, evaluation, and red teaming

LintLang vs Giskard: which should I use?

Giskard describes itself as: “Open-source Python library for testing and evaluating agentic systems.”

What it checks
Agent and RAG behavior: it defines scenario-based tests and checks, generates test cases, runs a vulnerability scan that probes the agent with hostile inputs across categories such as prompt injection and harmful content, and runs a quality scan over a RAG knowledge base.
When it runs
Against the running agent or model, before and after deployment
Choose LintLang when
Choose LintLang when you want to catch instruction and tool-description defects as text, before any agent run, in a CI step that needs only Python and PyYAML and emits SARIF.
Choose Giskard when
Choose Giskard when you need behavioral test suites for an agent or RAG pipeline, generated test sets, or vulnerability scans that require the agent to answer.
Combine them
Lint the instruction files in CI, then test behavior with Giskard. Neither substitutes for the other: LintLang sees text, Giskard sees answers.

Runtime guardrails

LintLang vs NVIDIA NeMo Guardrails: which should I use?

NVIDIA NeMo Guardrails describes itself as: “An open-source toolkit for easily adding programmable guardrails to LLM-based conversational applications.”

What it checks
Live interactions: input, dialog, retrieval, execution, and output rails, defined in Colang flows and configuration, that can block, alter, or validate user inputs, retrieved chunks, custom actions, and model responses.
When it runs
Around every live model call, inside the application
Choose LintLang when
Choose LintLang when the defect is in the written instructions and you want it caught before deployment, with no runtime component and no model call.
Choose NVIDIA NeMo Guardrails when
Choose NVIDIA NeMo Guardrails when you must check or alter inputs, retrieved content, tool actions, or outputs while the application is running.
Combine them
LintLang cannot block a bad action at runtime, and guardrails cannot fix the instructions that keep causing it. Lint the instructions in CI and keep rails around the live calls.

Its README notes that the built-in guardrails may or may not be suitable for a given production use case.

A clean LintLang scan is not evidence that an agent is safe or runtime-correct. The same limit applies to every pre-runtime check: a linter sees text, and behavior also depends on the model, the assembled context, the tools, and the environment.

§ 03

Start from the failure

Pick the layer that catches it earliest
  • The instructions or tool descriptions are vague, overlapping, or contradictory.LintLang
  • You want one repository-wide check of Claude Code, Cursor, Codex, or MCP configuration trees.Agent Lint
  • The model got worse after a prompt change, or you need to compare models on test cases.promptfoo
  • You need behavioral test suites, generated test sets, or vulnerability scans of an agent or RAG pipeline.Giskard
  • The application must check or alter inputs, retrieved content, actions, or outputs while it runs.NVIDIA NeMo Guardrails

Start with one real instruction file

Lint the text before you test the behavior.

$ uvx --from lintlang==0.5.3 lintlang scan AGENTS.md
Try it in your browser →Where static linting fits →Read the README ↗