Checks whether a machine can read your résumé at all, then whether it matches the posting you are about to apply to.
Checks that an applicant tracking system can read a résumé at all, then matches it against a posting. Built on the JSON Resume schema.
npm i -D @alokraj68/ats-resume Built on the JSON Resume schema, so you bring a resume.json you may already have rather than learning another format. Zero dependencies.
This is not a writing checker. plainspoken asks whether prose reads as machine-written; this asks whether a machine can parse the file. The two are deliberately separate tools.
It also compares two versions of the same résumé and reports which facts the rewrite dropped. Reordering bullets is where a figure quietly disappears, because both versions read as perfectly good English and no linter compares them: "carrying over $50M in annual revenue, held at over 99.95% uptime" and "held at high availability" are each fine on their own.
The half that matters most reads the extracted text rather than the source, because that is what an applicant tracking system actually receives. Standalone separator elements in a contact block look perfect in the DOM and on screen, and can be dropped from a PDF text layer entirely, leaving one unsplittable string where a parser expected four fields. Only reading the extraction finds it.
What a parser needs, and the location field holding five cities that parses as one nonsense place.
A position written as Junior Dev to Developer to Lead parses as one garbled job title.
Em and en dashes anywhere in a parsed field, and non-ISO dates. Date extraction is the most fragile part of parsing.
Whether the PDF has one at all. An image-only PDF scores zero everywhere.
Whether the separators survived extraction, which is the defect that looks right everywhere except where it counts.
Measured as density rather than as a statistical outlier. On a 700-word document almost any word appearing ten times clears three sigma; real stuffing sits at 2.5% or more for one term.
Team size, hiring, retention, budget, revenue, scale, delivery speed and strategy, reported as questions rather than as defects.
Every figure and named client in the previous version that is in the new one nowhere at all. Reordering is invisible to it on purpose, because reordering is the safe half of a rewrite.
Lint the source
npx @alokraj68/ats-resume lint resume.jsonLint what an ATS receives
pdftotext -layout Sam-Rivera-Resume.pdf out.txt
npx @alokraj68/ats-resume lint out.txtMatch against a posting
npx @alokraj68/ats-resume tailor resume.json posting.txtCheck a rewrite dropped nothing
npx @alokraj68/ats-resume diff before.txt after.txtFor the source checks, yes - it uses the JSON Resume schema, which is an existing open format rather than a new one. The extracted-text checks take a plain .txt dumped from your PDF, whatever produced it.
Seventy per cent or more against a posting generally clears. Sixty to sixty-nine is marginal. Under sixty and a human is unlikely to see it. The more useful output is the gap list, because that is your interview preparation.
No. It reports what a parser cannot read and which terms from the posting are missing. What to do about a missing term is a judgement call: add it where the work actually happened, mention it once if it is weak, or leave it out and treat it as a gap.
Run diff against the version you trust: npx @alokraj68/ats-resume diff before.txt after.txt. A missing figure is an error, a missing client name is a warning, and a bullet that only moved is reported as nothing at all.