The workflow covers the job search after profile setup
AI Job Search turns a repository into a working folder for one candidate. /setup builds a profile from existing documents, a pasted CV, or an interview. /scrape searches enabled portals, and /rank scores results against preferences and deal-breakers. /apply evaluates one posting, drafts tailored documents, sends them through a second-agent review, compiles the PDFs, and presents the result for human inspection.
The project goes beyond document generation. It tracks application outcomes, prepares for interview stages using the exact materials already submitted, produces a local HTML report, and can propose status updates from Gmail for approval. A Notion integration publishes a one-way view while repository files remain authoritative. The included 12 commands and several skills create a process that can be repeated, audited, and changed.
Danish portals work first; other markets need adaptation
Four bundled command-line tools target Jobbank, Jobdanmark, Jobindex, and Jobnet. LinkedIn and Freehire provide broader starting points. The profile, evaluation, drafting, and interview steps are meant to work across countries and languages, but search quality depends on the portal adapters. A developer outside Denmark may spend more time building and testing a local board integration than filling in the initial profile.
The /add-portal command investigates a site's search pattern, result structure, robots rules, and access restrictions before generating a skill. Authenticated portals are declined, and restrictive terms trigger a personal-use warning. Copied community skills deserve manual review because portal CLIs are pre-approved in Claude settings and can access career data. The README explicitly tells users to inspect network calls, dependencies, lifecycle scripts, and file access.
What happened when we ran it
Our sandbox installed commit e2c311a in 9 seconds, adding 35 packages and using 37 MB on disk. The build succeeded in 1 second. Pytest completed in 25 seconds with 307 passed, 0 failed, and 6 skipped. Pip-audit reported 0 known vulnerabilities in the installed Python environment.
The checkout contained 214 files, about 14,412 lines of source, and 2.9 MB. It had 2 CI workflow files, no Dockerfile, and a tests directory. Those results are strong for the repository logic. They do not cover a real Claude session, live portal responses, Gmail or Notion access, LaTeX packages, PDF rendering, or the accuracy of a model's fit judgment.
Our unprivileged Debian container had 3 CPUs, 8 GB of RAM, Python 3.12, and no secrets. The 9-second install understates end-user setup because the full README requires Claude Code, Bun, and a TeX distribution. pdftotext is optional, but skipping it changes the ATS check from inspecting the PDF text layer to a visual keyword review.
PDF checks catch errors that source review misses
The default CV uses lualatex, while the cover letter uses xelatex. After drafting and review, Claude compiles both, inspects the rendered pages, and adjusts layout. The target is a 2-page CV and 1-page letter, with the signature visible and no orphaned headings. A user can register another template and compilation command through /add-template.
Version 1.6.0 documents why the compiled artifact needs inspection. The release fixed bullets that disappeared because LaTeX parsed them as optional labels, percent signs that removed the rest of a line, and text extraction that mishandled non-ASCII characters on some pdftotext builds. CI now checks that expected body text survives into the PDF text layer. Human visual review is still necessary before submission.
Personal data makes repository visibility a setup decision
A normal GitHub fork of a public repository is public. /setup writes the candidate's name, contact details, employment history, and salary expectations into tracked files. The README now places that warning beside the fork command and recommends creating a private repository with this project configured as upstream. Release 1.6.0 also added a visibility check before onboarding writes personal information.
That guard should be treated as a backup, not the privacy plan. Check the repository visibility yourself, inspect git status after setup, and review ignore rules before adding CVs, application archives, interview notes, or Gmail-derived status. Removing sensitive data from a commit later may require GitHub's sensitive-data process; force-pushing alone does not remove every copy in a fork network.
Job postings remain untrusted and sometimes wrong
The workflow instructs agents not to follow commands embedded in a posting or fetch links from its body. The README also says those protections are instruction-level rather than a sandbox. On an unfamiliar site, inspect fetched content and every written file before sending an application. A fabricated skill claim or wrong employer detail can cost more than a failed command.
Open issue #331 reports occasional nonexistent or mismatched LinkedIn listings being ranked as good fits. Issue #371 shows a narrower parser flaw: --jobage 0.5 can be truncated to zero, causing the freshness filter to disappear while the command succeeds. Use integer flags, open every shortlisted posting at its canonical URL, and confirm that it still accepts applications.
Active maintenance supports a careful recommendation
GitHub recorded 36,168 stars, 6 combined issues and pull requests, and a last push on August 26, 2026. Version 1.6.0 was released on August 19 with portal-contract, document, privacy, and test fixes. Recent activity plus our 307-test pass supports using the framework as a serious personal system.
The boundaries are sensible: Gmail changes need approval, follow-ups are drafts, unsupported keywords remain gaps, and application documents are presented before sending. That restraint is a better fit for hiring than blind submission volume. The recommendation depends on the user keeping it: verify postings, compare every claim with the profile, inspect PDFs, and keep the personalized repository private.