ai-job-search: The Claude Code Pipeline That Turns Job Hunting Into a Local Operating System

A file-system-native framework for scraping roles, scoring fit, drafting tailored applications, and forcing an AI reviewer to challenge the result before it becomes a PDF.

8 min read • View on GitHub • More from MadsLorentzen

A wide black-ink editorial scene shows a job application assembled like a production line. A drafting arm writes on paper, a second inspector reviews the pages under a lamp, and a LaTeX press waits at the end of a conveyor. The scene explains that this repo treats job hunting as a governed workflow rather than a single prompt.
The core idea is not automation for its own sake. It is process, review, and output control, all running locally.
Key Takeaways

The first thing that separates ai-job-search from the usual job-search automation stack is its refusal to behave like a chatbot. It behaves like a system. Jobs are discovered, scored, drafted, reviewed, compiled, and tracked as separate stages, with each stage doing one job well.

That matters because the failure mode of most AI job tools is not speed. It is sloppiness. They optimize for volume, while this repo optimizes for fit, honesty, and a finished document that looks like it came from a disciplined production workflow.

The job search as a pipeline, not a prompt

The repo's basic move is simple, but the implications are not. It uses Claude Code as the runtime, then wraps it in commands such as /setup, /scrape, /apply, and /interview. Instead of asking a model to do everything in one shot, it breaks the work into bounded stages with state in between.

The headline mechanism is the loop. Drafting is never final until a second context has challenged it.

A medium-close cross-section of a filesystem cabinet shows drawers labeled .claude/commands, .claude/skills, .agents/skills, seen_jobs.json, and job_search_tracker.csv. Thin cables run from the drawers to a Claude Code terminal, and a small gear train moves job cards through found, scored, and applied states. The image explains how the repository uses the filesystem as its control layer and memory.
The repository behaves less like a script collection and more like a small operating system with memory.

Why the Drafter-Reviewer loop is the real innovation

The smartest part of the repo is the two-agent pattern inside /apply. One agent drafts the tailored CV and cover letter. A separate reviewer context then checks honesty, alignment, and weak claims before the application advances. That turns the system into editorial production, not just generation.

The framework encodes career guidance best practices, including structured evaluation criteria, forward-looking cover letter framing, and optional salary benchmarking.

Mads Lorentzen, Creator & Data Scientist · MadsLorentzen/ai-job-search GitHub README

The important detail is not that the model reviews itself. It is that review happens in a separate context with its own instructions. That separation creates friction in the right place. Weak evidence gets flagged. Overclaiming gets blocked. The final PDF is only the result of a process that survived critique.

Claude Code as the runtime

This repo treats Claude Code less like a chat window and more like an execution environment. The Markdown files in .claude/commands/ define workflows. The skills folders provide domain grounding. Together they act like a control plane for memory, prompts, and actions.

That choice matters because it makes the system inspectable. You can read the commands, inspect the skills, and understand where the model is supposed to be creative and where it is supposed to obey constraints. The architecture is not hidden behind a product UI.

The scoring engine decides what gets attention

Before drafting starts, the repo filters aggressively. The evaluation framework assigns weights to technical match, experience, behavioral fit, and career alignment, then adds a location veto. In other words, not every job is worth a tailored application.

Criterionai-job-searchBulk-apply tools
Primary goalHigh-fit, reviewed applicationsMaximum submission volume
Decision gateWeighted scoring plus vetoesUsually minimal filtering
Output qualityTailored CV and cover letterTemplate variation at best
Review processSeparate reviewer agentOften none
PrivacyLocal-first on the user's machineTypically SaaS-managed
User profileTechnical user who wants controlUser who wants convenience over control
- Technical Match: 30%
- Experience: 25%
- Behavioral: 15%
- Career Alignment: 30%
- Location Veto: pass or fail

The scoring layer is what keeps the repo honest about scale. It is not trying to flood the market. It is trying to spend attention on the right openings and skip the rest.

LaTeX makes the output feel finished, not assembled

The output path matters as much as the logic path. The repo uses LaTeX to generate CVs and cover letters, which gives the final artifact a deliberate, professional finish. This is where the system stops feeling like an AI demo and starts feeling like document production software.

lualatex cv.tex
lualatex cover_letter.tex

That compiler step is important for another reason: it creates a clear boundary between draft and deliverable. The model can propose structure and content, but the document only becomes real after it passes the formatting pipeline.

The filesystem becomes the database

The repo's state model is pleasantly old-school. Files like seen_jobs.json and job_search_tracker.csv keep the system from reprocessing the same roles and let the workflow stay idempotent. Scrapers in .agents/skills/ feed structured job data into that state layer.

LayerWhat it storesWhy it matters
CommandsWorkflow instructionsMakes the system reproducible
SkillsDomain knowledgeKeeps generations grounded
State filesSeen jobs and tracker dataPrevents duplicate work
ScrapersStructured job inputsMakes job discovery modular
LaTeX templatesDocument structureTurns text into finished PDFs

This is the part that gives the repo durability. It remembers what it has done. It can recover from interruption. And it can run again without pretending the world is new.

What this beats, and what it does not

Forked nearly 1000 times, and I suspect will be forked 1000's more times, because why not have an agent constantly looking for jobs (deals, leads, partners, whatever) for you?

Hung Lee, Editor of Recruiting Brainfood · Recruiting Brainfood: AI Job Search

The comparison is not really about feature checklists. It is about philosophy. Tools like LazyApply and Loopcv optimize for breadth. SaaS products like Teal optimize for organization. ai-job-search is for people who want ownership, privacy, and a workflow they can inspect or extend.

That makes it less universal, but more interesting. It asks for setup. It asks for technical comfort. In return, it gives you a local system that can be audited, modified, and trusted more than a black-box service.

Why this project matters beyond job hunting

The bigger pattern here is not careers. It is how agentic software is maturing. The strongest systems are starting to look like pipelines with commands, state, and verification, not free-form prompts with a polished UI. This repo is a clean example of that shift.

That is why the project resonates. It does not promise magic. It offers process. In a category crowded with noisy automation, that is the more credible innovation.