LanguageTool

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me the writing checker I actually need instead of paying for LanguageTool Premium: my own style rules, enforced everywhere I write, on my own server.

Read this first: LanguageTool's server is open source and free to run, and the fee buys the larger premium rule set plus the add-ons. The rules for real grammar in twenty languages are decades of linguistic work by people who speak them — do not try to rewrite that. What you can build, and what actually improves writing more, is a strict style layer of your own on top of it.

STACK
- Run the open LanguageTool server in a container for grammar and spelling. Do not replace it
- Node 20+ with Fastify for your own layer: your rules, your dictionary, your history
- SQLite through better-sqlite3
- Vale, or a small rule engine of your own, for prose style
- Caddy in front, on a private network

THE DATA MODEL
- documents: id, source, external_ref, title, text_hash, checked_at
- findings: id, document_id, rule_id, engine, severity, offset, length, message, replacements_json, context
- rules: id, key, engine, kind, pattern_json, message, severity, scope_json, is_active
- dictionary: id, word, language, kind, note — accepted terms, product names, and the spellings you have chosen
- ignores: id, rule_id, text_hash, scope, reason, at — a suppression is a decision and is recorded with its reason
- style_guide: id, term, prefer, avoid, note — the term list, which is the single most useful artefact here
- Findings kept, so 'which rule fires most' is answerable and a rule nobody acts on can be deleted

THE TWO LAYERS
- Grammar and spelling: send the text to the LanguageTool server, get findings back, present them. Free, multilingual, and better than anything you would write
- Style: your own rules over the same text. This is the layer that makes writing consistent, and it is the layer no generic product can have because it encodes your decisions

YOUR STYLE RULES
- A term list: prefer this word, never that one, with a reason. 'Sign in' not 'login' as a verb; your product's name capitalised exactly one way
- Banned phrases: the hedges, the filler, the corporate abstractions
- Sentence length above a threshold, flagged as a suggestion rather than an error
- Passive voice detected and flagged with a low severity, because sometimes it is correct and a checker that insists otherwise gets switched off
- Repeated words within a window, and the same sentence opener three times running
- Numbers, dates, units and currency formatted consistently
- Headings in the case you chose
- Each rule has a severity, a message written as a sentence, and a scope — some apply to documentation and not to marketing
- Rules live in a file in a repository, reviewed like code. A style guide nobody can diff is a style guide nobody follows

WHERE IT RUNS
- A command-line checker over files, which is the one that matters: run it in CI on every pull request and comment on the lines that failed
- An HTTP endpoint taking text and returning findings, so anything can call it
- A browser extension checking textareas on the sites you write in, talking only to your own server
- An editor integration through the language server protocol, which gets it into most editors at once
- Never a service that sends your drafts to somebody else's server. That is the other reason to run this yourself

THE CHECK ITSELF
- Text segmented into sentences properly, respecting abbreviations and decimals, before any rule runs
- Code blocks, inline code, URLs, front matter and quoted passages excluded — a checker that complains about your code samples is a checker you mute
- Offsets returned against the original text so a highlight lands in the right place, including with multi-byte characters
- Fast enough to run on every save: cache by text hash and only check what changed

FIXING
- Each finding offers a replacement where one is unambiguous, and says nothing where it is not
- Apply one, apply all of a rule, or ignore with a reason
- An ignore is stored against the rule and the text, so the same false positive does not return every run
- Never rewrite silently. The writer decides, always

REPORTING
- Findings per rule over time, which tells you which rules are earning their place
- Readability scores if you want them, with the formula named — they are a rough signal and should be labelled as one
- A per-document summary in the CI comment: what failed and where, in the comment itself rather than behind a link

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, LT_SERVER_URL, SESSION_SECRET
- Migrations on boot, each once
- The LanguageTool container needs real memory for the larger language models; size it before deploying
- Nightly backup of the rules and the dictionary, which are the parts you cannot regenerate
- Health endpoint that checks both engines

WHAT MATTERS MOST
The term list and running it in CI. Write twenty rules you actually believe in, put the checker on every pull request, and delete any rule that gets ignored twice. A style guide that runs is worth ten that are written down, and this is the rare case where the thing you build yourself is better than the thing you were paying for.

Give me the repository, the CLI, the language server, the extension, migrations, .env.example, an example rule set, and a README with deploy steps.