πŸ›‘οΈ Formal, readable and lintable specifications

SpecLint β€” the linter that improves the structural quality of your specs

Stop discovering gaps in a specification during development. SpecLint validates a normalized spec format, detects critical missing pieces and finally makes reliable analysis possible before coding.

Standardized spec template
Structural linting and traceability
A strong base for backlog and impact mapping

The problem

A free-form spec is easy to write. A usable spec is much rarer.

Today, teams write specifications in Confluence, Notion or Google Docs with inconsistent structures and uneven levels of detail. The result: uncovered business rules, forgotten error cases, blurry impacts and ambiguities discovered too late.

SpecLint introduces a simple framework: a clear spec format, then a validation engine that checks what can be verified formally.

πŸ’» Sample output
βœ” Scope present
βœ” Actors defined
βœ” Acceptance criteria linked
⚠ BR-2 not covered by any AC
⚠ UI impact declared but no mockup linked
βœ– Missing edge case for authentication failure
Quality score: 78 / 100

What SpecLint does

A formal validation layer for structural spec quality

βœ”

Validate the structure of your specs

SpecLint checks that a specification contains the expected sections, traceability links and the elements required for an actionable read.

⚠

Catch gaps before development

Uncovered business rules, missing acceptance criteria, forgotten edge cases, poorly documented impacts: the report highlights where the spec is fragile.

βŽ‡

Create an actionable foundation for what comes next

Once the spec is normalized, you can unlock backlog generation, impact mapping and more reliable automation.

Key checks

What the engine can verify in v0.1

SpecLint does not claim to judge business truth. It checks formal quality, expected completeness and traceability between spec elements.

βœ”

Required sections are present

βœ”

Unique IDs and valid references

βœ”

Business rule coverage by acceptance criteria

βœ”

Scenarios linked to the right actors

βœ”

Missing error cases and edge cases

βœ”

Expected UI artifacts when visual impact exists

How it works

Three steps to move from a fuzzy spec to an actionable base

Step 1

Write in a simple format

A Markdown spec with required and optional sections: Scope, Actors, Rules, Scenarios, AC, Impacts, Artifacts…

Step 2

Run SpecLint

The engine analyzes completeness, traceability and structural coherence. It does not pretend to judge the business domain, it judges the formal quality of the spec.

Step 3

Fix issues before coding

You get an actionable report with errors, warnings and suggestions to strengthen the spec before development kickoff.

Product vision

Start with linting. Then open the way to backlog and impact maps.

Once the spec is normalized and validated, new capabilities become possible: Feature and User Story generation, impact mapping, coverage analysis and more reliable automation. SpecLint is the first building block.

1SpecLang
2SpecLint
3Backlog generation
4SpecMap

FAQ

Questions teams will ask

Does SpecLint replace the work of the PO or architect?

No. It acts like a specification linter: it helps verify structure, coverage and traceability, but it does not replace business judgment or human review.

Do teams need to adopt a specific format?

Yes. SpecLint relies on a normalized spec template. That is precisely what makes the analysis reliable and actionable.

Is it compatible with Confluence, Notion or Git?

The starting point is a simple Markdown format, easy to version and integrate into existing workflows.

Can it lint images or mockups?

Not directly. However, the spec can reference visual artifacts and SpecLint can verify their presence when they are expected.

Early access

Specs deserve their own linter too !

Join the waitlist to follow the release of SpecLint v0.1 and see the first lintable spec examples.

Join the waitlist β†’