ai-job-search: a Claude Code workflow that keeps your job hunt in your own repo

The problem: application volume without a pipeline

Applying for jobs at volume is a document management problem disguised as a writing problem. Each posting needs a fit judgement, a CV that survives an applicant tracking system, a cover letter that addresses that specific employer, and interview preparation that references the same material. Doing this by hand means either sending the same CV everywhere or spending a Sunday per application. The author of this project describes building it during his own search after his position was cut in late 2025, and reports sixty-nine tailored applications, twenty first interviews and one signed contract, starting as an AI engineer in June 2026. That is a single-person account in the README, not a benchmark, and it should be read as such. The framework is aimed at people who already use Claude Code and want the job search to run as files on their own machine rather than inside a hosted service. The README states the core workflow of self-profiling, fit evaluation and the drafter-reviewer pipeline is language and country agnostic, while the portal search skills are built for the Danish market: Jobindex, Jobnet, Akademikernes Jobbank and others.

Three commands and a reviewer agent

The workflow is exposed as slash commands inside Claude Code. /setup fills in your profile and produces profile files. /scrape searches job portals and presents matches with fit ratings. /apply takes a posting URL, evaluates fit, scores and recommends, then drafts a tailored CV and cover letter in LaTeX. The part that distinguishes this from a prompt collection is the review stage: a separate reviewer agent critiques the draft, the draft is revised, and only then is the final output produced. That two-agent loop is the mechanism, and it is the reason the output is not simply one model pass over a job description. The README also lists optional salary benchmarking as part of the encoded career guidance, alongside structured evaluation criteria and what it calls forward-looking cover letter framing. The portal search side is implemented as skills under .agents/skills/, each with its own CLI directory and dependencies. The commands shown in the diagram are /setup, /scrape and /apply, with /interview named in the opening description as the preparation step.

Getting it running: fork, bun install, /setup

The README's quick start begins with gh repo fork MadsLorentzen/ai-job-search --clone followed by cd ai-job-search. Prerequisites are Claude Code, Python 3.10+, Bun for the job search CLI tools, and a LaTeX distribution providing lualatex and xelatex. The CV compiles with lualatex because pdflatex often fails on modern MiKTeX installs with fontawesome5 font-expansion errors, and the cover letter compiles with xelatex because cover.cls requires fontspec. Minimal installs such as TinyTeX or BasicTeX need extra packages listed in SETUP.md. Tool installation loops over six skills: jobbank-search, jobdanmark-search, jobindex-search, jobnet-search, linkedin-search and freehire-search. The Bash form is a for loop running (cd .agents/skills/$tool/cli && bun install); PowerShell uses Push-Location and Pop-Location. For linkedin-search and freehire-search the install is optional, since both have zero runtime dependencies and run with plain bun, with bun install only pulling TypeScript dev types. Then you launch claude and run /setup, which offers three paths: read a populated documents/ folder containing a CV PDF, LinkedIn export, diplomas, reference letters or past applications; import a single CV pasted into chat; or walk through an interview. Optional: pip install pypdf enables the ATS parseability check, with Poppler pdftotext as a fallback and a degradation to visual keyword review if neither is present.

The fork is public, and /setup writes into tracked files

This is the sharpest constraint in the repository and the README does not soften it. A fork of a public repository is always public on GitHub, and /setup writes personal data including name, contact details, employment history and salary expectations into tracked files. The README's instruction is explicit: if the copy is for your own job search rather than for contributing changes back, use a private repository with this repo as upstream, with the recipe in SETUP.md section 8, and fork only to contribute. The project claims every update workflow works identically in that arrangement, but that claim is the thing to verify yourself before you type your salary expectations into a file. A second limitation is geographic. The portal skills target Danish boards, so if you are searching elsewhere you are rewriting the scraping layer, not configuring it. The README points to AGENTS.md for users of other agent tools such as Codex, Antigravity or Gemini CLI, stating the portal search skills work there out of the box and that community forks adapt the full workflow. That is a pointer to other people's work, not a guarantee about the state of those forks.

Where a hosted application tracker differs

The obvious alternative is a hosted job application tracker, the category that includes tools like Huntr or Teal, where you paste postings into a web dashboard, track stages in a kanban view and generate documents from templates. The difference in approach is not cosmetic. A hosted tracker centralises your data and gives you a browser interface with no local toolchain; this project keeps everything as files in a git repository you control, but asks you to install Bun, Python and a LaTeX distribution, and to run commands from a terminal. The drafting mechanism also differs: a hosted tool typically fills a template you wrote once, while this one runs a drafter-reviewer agent loop over each posting, which can produce more specific text at the cost of being non-deterministic and dependent on your Claude Code access. If your main need is a shared pipeline view across many applications with reminders, a hosted tracker is the better fit. If your main need is tailored LaTeX output that you can diff, version and keep after the search ends, the repository model is the one that matches.

Maintenance load and the MIT licence

The project is active, with v1.7.1 released on 2026-09-06, three weeks before the last push on 2026-09-09. The release titles describe maintenance work rather than features: cheaper ranking, portals that fail loudly, forks that stop fighting CI, trackers that stay private, postings that admit they're closed, CVs that keep their text. Read that sequence as a signal about where the effort goes. Portal scrapers break when job boards change their markup, which means the scraping skills are a recurring maintenance cost, not a one-time setup. The LaTeX side is stable by comparison but pins you to a working lualatex and xelatex install. The licence is MIT, which permits commercial and private use, modification and redistribution provided the copyright notice and permission notice are included; it comes with no warranty. That is a statement about the licence text, not legal advice, and if you plan to redistribute a modified version, particularly one containing a forked workflow, read the licence yourself. The README also states the project has no affiliated cryptocurrency, token or paid sponsorship program, and that anything claiming otherwise is unauthorized and should be treated as a scam. Support channels listed are Ko-fi and contributing on GitHub. The project is not affiliated with, endorsed by, sponsored by or maintained by Anthropic; Claude Code is named only to describe the toolchain.

Who this is for, and what to check first

The fit is narrow but clear. You should adopt it if you already work in Claude Code, you are willing to keep a LaTeX toolchain alive, and you either search the Danish market or accept rewriting the portal skills for your own boards. You should not adopt it if you want a hosted dashboard with a shared pipeline view, if you will not maintain lualatex and xelatex, or if putting your employment history into a repository feels wrong even when that repository is private. The first thing to verify is the fork-versus-private-repo decision, because /setup writes into tracked files and a fork of a public repo cannot be made private. Follow SETUP.md section 8 and set this repository as upstream. The second is the ATS check: install pypdf or confirm pdftotext is on PATH, since the README states the check otherwise degrades to a visual keyword review, which is a different kind of assurance. The third is the scraping layer. Run /scrape once against your target boards before you invest in profile writing, because a scraper that no longer matches a portal's markup will fail loudly by design, and that failure is cheaper to find on day one than after you have tailored twenty CVs.

Editorial conclusion

Adopt it if you already run Claude Code, are comfortable editing LaTeX classes and Python entry points, and either job-hunt in Denmark or are willing to rewrite the portal skills for your own boards. Skip it if you want a hosted service, if you will not maintain a LaTeX toolchain with lualatex and xelatex, or if a public fork of your employment history is unacceptable. Before committing, clone it as a private repository with this repo set as upstream per SETUP.md section 8, run /setup against your documents folder, and check that the ATS parseability step works in your environment with pypdf installed or pdftotext on PATH.

Official sources

1. Issues
2. License: MIT
3. MadsLorentzen/ai-job-search on GitHub
4. README
5. Releases