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.
- ai-job-search is interesting because it treats applications as a governed pipeline, not a prompt.
- The Drafter-Reviewer loop is the repo's sharpest move because it makes the model critique its own output before anything is submitted.
- Claude Code is used like an execution runtime, with commands and skills acting as a control plane for the whole workflow.
- Local state, scoring, and LaTeX output make the system feel auditable, repeatable, and more serious than bulk-apply tooling.
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.
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.
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.
| Criterion | ai-job-search | Bulk-apply tools |
|---|---|---|
| Primary goal | High-fit, reviewed applications | Maximum submission volume |
| Decision gate | Weighted scoring plus vetoes | Usually minimal filtering |
| Output quality | Tailored CV and cover letter | Template variation at best |
| Review process | Separate reviewer agent | Often none |
| Privacy | Local-first on the user's machine | Typically SaaS-managed |
| User profile | Technical user who wants control | User 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.
| Layer | What it stores | Why it matters |
|---|---|---|
| Commands | Workflow instructions | Makes the system reproducible |
| Skills | Domain knowledge | Keeps generations grounded |
| State files | Seen jobs and tracker data | Prevents duplicate work |
| Scrapers | Structured job inputs | Makes job discovery modular |
| LaTeX templates | Document structure | Turns 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?
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.





