What Happened
Speclint launched as an open-source spec linter designed specifically for teams using AI coding agents. The tool scores GitHub issues and specifications on a 100-point scale across six dimensions before any AI agent starts writing code. Issues must hit 70 or above to get a "spec-ready" label; anything below gets flagged as "spec-needs-work."
The six scoring dimensions: Measurable Outcome (20 points), Testable Criteria (25 points), Constraints (20 points), No Vague Verbs (20 points), Definition of Done (tracked but unscored), and Verification Steps (15 points). The tool penalizes ambiguous language like "improve" or "optimize" without specific metrics attached.
You can run it three ways: as a CLI tool (npx @speclint/cli lint "spec text"), as a GitHub Action that auto-comments on issues, or as a programmatic API imported into your own tools. The GitHub Action adds labels automatically and returns machine-readable JSON for CI/CD pipelines.
The project offers a self-hosted open-source tier (unlimited, free), plus cloud tiers ranging from free (5 daily lints) to team plans with dashboards and analytics. It is MIT-licensed and built as a TypeScript monorepo.
Why It Matters
Anyone who has used Claude Code, Cursor, or Copilot on a real codebase knows the pattern: the agent builds exactly what you asked for, and what you asked for was wrong. A spec that says "improve dashboard performance" gives the agent no target to hit. It might refactor CSS, add caching, or rewrite database queries - all technically valid, none necessarily what you wanted.
This is a workflow problem, not an AI problem. The agents are competent enough to execute. The bottleneck is specification quality. The better your issue is written, the better the output. Speclint formalizes that insight into an automated gate.
For teams adopting AI coding agents at scale, this addresses one of the real friction points: inconsistent spec quality across team members. Junior developers and product managers writing issues do not always include acceptance criteria or measurable outcomes. A linter catches that before anyone - human or AI - burns time on ambiguous work.
Our Take
The premise is correct. Most AI coding failures trace back to vague prompts, not model limitations. A quality gate on specifications is a practical intervention that costs almost nothing to implement.
The scoring rubric is sensible but opinionated. Requiring "Given/When/Then" format for acceptance criteria works well for backend features but can feel forced for UI work or exploratory tasks. The 70-point threshold will need tuning per team - some organizations will want stricter gates, others will find it too rigid for early-stage prototyping.
The more interesting question is whether this becomes a standard part of the AI coding workflow. Right now, most teams go from issue to agent with no quality check in between. If tools like Speclint become common, it could shift the bottleneck from "writing better prompts" to "writing better specs" - which is arguably where it should have been all along.
Worth trying if your team writes more than a handful of AI-assisted features per week. The self-hosted option means zero risk to evaluate.