Problem
LintLang 0.5.1 is a deterministic, local static linter for AI agent instructions, tool descriptions, prompt/config files, and embedded prompts in Python. It is not a security scanner and does not claim agent safety or runtime correctness.
Its CLI maps cleanly to MegaLinter project execution:
lintlang scan . --fail-on fail
lintlang scan . --fail-on fail --format sarif
In an isolated spike, a clean fixture exited 0 with zero findings; a deliberately ambiguous/unbounded fixture exited 1 with 13 findings. SARIF 2.1.0 remained valid on both paths, including the failing path.
Taxonomy question
LintLang spans Markdown, YAML, JSON, text, and Python agent artifacts. Would maintainers prefer:
- a new
AI descriptor producing AI_LINTLANG; or
- the existing
REPOSITORY descriptor producing REPOSITORY_LINTLANG?
The AI option is semantically clearer and leaves room for future agent-configuration linters, but it adds a new descriptor and requires an explicit flavor-membership decision. The REPOSITORY option avoids a new taxonomy category but groups agent-instruction quality analysis with repository-wide tooling.
Exclusion detail
Project mode is preferable because LintLang applies its prompt-file heuristics and skips known non-prompt/dependency paths. LintLang's --exclude accepts one variadic list, whereas MegaLinter's generic project exclusion adapter emits repeated option/value pairs. A production patch can add a minimal LintLangLinter adapter that emits one --exclude list followed by -- ., plus root and nested .wireit poison fixtures. Alternatively, the descriptor can rely on repository .lintlangignore and LintLang's built-in exclusions if maintainers prefer no custom class.
Proposed bounded follow-up
After the taxonomy and flavor choice, I can submit one focused PR containing the descriptor, exact 0.5.1 pin, good/bad fixtures, exclusion adapter and poison fixtures if requested, generated files from make megalinter-build, the linter-specific Docker test, and one changelog line.
Problem
LintLang 0.5.1 is a deterministic, local static linter for AI agent instructions, tool descriptions, prompt/config files, and embedded prompts in Python. It is not a security scanner and does not claim agent safety or runtime correctness.
Its CLI maps cleanly to MegaLinter project execution:
In an isolated spike, a clean fixture exited 0 with zero findings; a deliberately ambiguous/unbounded fixture exited 1 with 13 findings. SARIF 2.1.0 remained valid on both paths, including the failing path.
Taxonomy question
LintLang spans Markdown, YAML, JSON, text, and Python agent artifacts. Would maintainers prefer:
AIdescriptor producingAI_LINTLANG; orREPOSITORYdescriptor producingREPOSITORY_LINTLANG?The
AIoption is semantically clearer and leaves room for future agent-configuration linters, but it adds a new descriptor and requires an explicit flavor-membership decision. TheREPOSITORYoption avoids a new taxonomy category but groups agent-instruction quality analysis with repository-wide tooling.Exclusion detail
Project mode is preferable because LintLang applies its prompt-file heuristics and skips known non-prompt/dependency paths. LintLang's
--excludeaccepts one variadic list, whereas MegaLinter's generic project exclusion adapter emits repeated option/value pairs. A production patch can add a minimalLintLangLinteradapter that emits one--excludelist followed by-- ., plus root and nested.wireitpoison fixtures. Alternatively, the descriptor can rely on repository.lintlangignoreand LintLang's built-in exclusions if maintainers prefer no custom class.Proposed bounded follow-up
After the taxonomy and flavor choice, I can submit one focused PR containing the descriptor, exact 0.5.1 pin, good/bad fixtures, exclusion adapter and poison fixtures if requested, generated files from
make megalinter-build, the linter-specific Docker test, and one changelog line.