It runs the application process from a local repository
/setup builds a candidate profile from documents, a pasted CV, or an interview. /scrape finds listings, /rank compares them with the profile, and /apply drafts a tailored CV and cover letter. A separate reviewer agent checks those drafts before the workflow compiles them. Later commands record outcomes and prepare interview material from the application the employer actually saw. Submission stays with the candidate.
That breadth is real code and instructions, not a tiny prompt pack. Our checkout at commit d7287ec contained 241 files, roughly 19,938 lines of source, and occupied 3.2 MB. The repository also includes six portal tools, local state for search results, PDF verification utilities, and commands for reports and profile updates. You are adopting a working folder that will accumulate personal history, not installing a disposable command.
The 15-second install is only the first setup layer
The Python environment is modest, but the working system asks more of your machine. Claude Code requires a paid subscription or Anthropic API credits. Portal tools run on Bun. The stock CV compiles with lualatex, while the cover letter uses xelatex. Python 3.10 or newer supports the utility scripts. You also need to fill the profile, decide which portals may run, and keep the repository private.
In our sandbox, 35 packages installed in 15 seconds and occupied 37 MB. The build then passed in 19 seconds. Those figures make the codebase easy to inspect and test, but they do not include Claude usage, a TeX installation, portal downloads, or time spent correcting your career record. The README explains those pieces well. It simply cannot make them disappear.
What happened when we ran it
Our run used commit d7287ec in a fresh Debian container with 3 CPUs, 8 GB of RAM, Python 3.12, no secrets, and no elevated privileges. Installation succeeded in 15 seconds, the build succeeded in 19 seconds, and the test step succeeded in 43 seconds. Pytest reported 494 passed, 0 failed, and 9 skipped in the supplied 494-test summary.
Pip-audit found 0 known vulnerabilities in the installed environment. The 241-file checkout had 2 CI workflow files and a tests directory, but no Dockerfile. That absence fits a tool meant to live beside one person's documents rather than a packaged web service. Our results cover repository mechanics only. We did not judge generated prose, live job matches, PDF appearance, or whether a model scored a particular career move sensibly.
PDF inspection is the strongest application feature
The /apply flow does more than ask a model for a resume. It compiles the CV and cover letter, reads the rendered pages, checks the PDF text layer, and revises layout problems. The default target is a 2-page CV and a 1-page letter. Supported profile evidence can become a keyword; an unsupported skill remains a gap. That is the right bias for a document an employer may question line by line.
Release v1.7.2 made those checks more concrete by adding layout measurements and tighter text verification. Our 43-second test step finished with 494 passes and 0 failures, which supports confidence in the underlying utilities at d7287ec. It does not prove that every generated sentence is accurate. You still need to compare each claim with your source documents and open both PDFs before applying.
Personal files and job posts share one trust boundary
The setup warning deserves attention. GitHub forks of public repositories are public, while /setup writes identifying and employment data into tracked files. The recommended arrangement is a private repository with this project added as an upstream remote. Documents, the tracker, salary data, and application archives have ignore rules, but the populated profile itself needs a private home if you push it anywhere.
Job postings create the other risk. An agent with file access reads untrusted listing text beside your profile. The security policy tells the agent to treat posting text as data and limits approved shell commands, yet it plainly says these measures are not a sandbox. A 3.2 MB checkout does not create isolation. Review what the agent fetched and wrote, especially after adding a community portal skill or using an unfamiliar board.
October activity is healthy, with four open issues
GitHub showed 44,872 stars and a last push on October 3, 2026. Release v1.7.2 shipped on September 29. The current queue contained 4 open issues and 3 open pull requests, rather than 7 bugs. Recent reports cover mixed-script job keys, raw HTML from one Danish portal, a host-check test gap, and local test guards in personalized forks. The paired pull requests on two reports show maintainers working in public.
The remaining rough edge is ownership cost. You must reconcile upstream changes with customized files, audit copied portal code, and keep the profile out of a public fork. Our 37 MB environment and clean 494-pass result make that effort easier to justify. Issue #496 still matters, though: a personalized fork can trigger placeholder tests locally when GITHUB_REPOSITORY is unset, even when the untouched template passed cleanly for us.