career-ops: an AI job search pipeline that runs inside your coding CLI

What career-ops solves, and who it is actually for

Applying to jobs at volume has two costs that a spreadsheet does not reduce. The first is triage: deciding which of several hundred listings deserves an hour. The second is consistency: remembering why you skipped a role three weeks ago, and whether the CV you sent matched the description. career-ops attacks both by treating the job search as a pipeline with a scoring stage.

The README is explicit about the intended posture. It calls the project a filter, not a spray-and-pray tool, and states that the system strongly recommends against applying to anything scoring below 4.0/5. That threshold is the whole product thesis. If you are the kind of applicant who wants to send 200 applications, the scoring gate will feel like friction rather than help.

The audience is narrower than "job seekers". You need an AI coding CLI already installed and authenticated, because career-ops is packaged as agent skills and plugins for Claude Code, Codex, OpenCode and Antigravity rather than as a standalone web app. The README also points to docs/SUPPORTED_CLIS.md for the agent-skill-standard CLIs it runs on. A candidate who does not use one of those tools has no entry point.

How the A-H evaluation and the 1.0 to 5.0 score work

The core mechanism is a structured report, not a chat reply. According to the README, each evaluation produces blocks A through H: role summary, CV match, level strategy, compensation research, personalization, interview prep in STAR+R form, a posting-legitimacy check, and a drafted outreach block. The global score is reached by judgement across five dimensions rather than an arithmetic formula. That is a deliberate design choice and worth pausing on: because no formula is published, two runs over the same listing can land on different scores. You get reasoning you can audit, not a reproducible number.

Two blocks are quarantined from the score. Block G assesses whether the posting itself is legitimate, flagging scams and ghost jobs, and the README states it never affects the score. Block H is drafted only at 4.5 and above. There is also a Work-Auth signal that flags an explicit no-sponsorship line in the job description as a hard blocker, which is the kind of detail a keyword-matching filter would miss entirely.

The evaluation is agentic rather than keyword-based. The README says the chosen CLI navigates career pages with Playwright and reasons about your CV against the job description. Portal coverage is named as Greenhouse, Ashby, Lever and company pages. Batch evaluation of 10 or more offers runs through sub-agents. Interview stories accumulate across evaluations into a story bank of 5 to 10 master stories, so the system gets more useful the longer you run it.

Installing career-ops and running a first evaluation

The repository is a Node project, and package.json declares "node": ">=18". Start by copying the environment template, because the evaluation scripts read API keys from it. The .env.example file documents GEMINI_API_KEY for gemini-eval.mjs, OPENROUTER_API_KEY for openrouter-runner.mjs, and an OpenAI-compatible path through OPENAI_API_KEY, OPENAI_BASE_URL and OPENAI_MODEL.

cp .env.example .env

Open .env and fill in at least one key. The file notes that a Gemini key is available from aistudio.google.com and that the OpenRouter free tier covers hundreds of models at no cost. If you would rather skip the CLI entirely, the OPENROUTER_API_KEY route is the no-CLI path, driven by the or: prefixed scripts in package.json.

npm run doctor
npm run or:eval

The doctor script checks your setup before you spend tokens. The or:eval script runs an evaluation through openrouter-runner.mjs. The README warns that the first evaluations will not be good, because the system does not know you yet; you are expected to feed it your CV, career story, proof points and preferences. Treat the first run as onboarding, not as a verdict.

If Playwright will not install on your host, the Dockerfile exists for that case. It builds from mcr.microsoft.com/playwright:v1.62.1-jammy with Chromium preinstalled, and docker-compose.yml mounts the project at /app with a separate node_modules volume. The compose file forwards GEMINI_API_KEY, ANTHROPIC_API_KEY and OPENAI_API_KEY from the host and sets shm_size to 1gb because Chromium needs more than the default 64M of shared memory.

docker compose up -d
docker compose exec career-ops npm run scan

The tracker, the integrity scripts, and where they break

The tracker is meant to be a single source of truth, and package.json shows that the project treats data hygiene as a first-class job rather than an afterthought. There are separate scripts for normalize, dedup, merge and reconcile, plus a verify script and a sync-check. That is an unusual amount of plumbing for a personal tool, and it tells you the authors hit real data corruption: duplicate entries, statuses that drifted, a tracker that disagreed with the evaluation output.

The limitation is that none of this is automatic unless you run it. The scripts exist as npm targets, and the README does not present a scheduler or a daemon that keeps the tracker consistent for you. A user who evaluates in batches and never runs npm run reconcile will eventually be reading a tracker that no longer matches their pipeline.

A second constraint is the score itself. Because the 1.0 to 5.0 value comes from judgement rather than a fixed formula, it is a prioritization aid, not a gate you can delegate. The README says to always review before submitting. The 4.0 threshold is a recommendation from the project, not a guarantee that a 3.8 role is a waste of your time. Compensation research and level strategy inside the report are generated, and the README does not describe a verification step against a salary data source, so treat those blocks as a starting point for your own check.

career-ops vs. manual tracking and vs. a hosted job board

The obvious alternative is a spreadsheet plus the job board's own search. The difference is where the reasoning lives. A spreadsheet stores what you decided; career-ops stores why, in a structured report with a CV-match block and a level-strategy block attached to the listing. The trade is control for effort: you spend time feeding the system context, and in exchange the triage step is done for you.

The second alternative is any hosted service that scores listings and auto-applies. Those run on someone else's servers and typically push volume. career-ops runs locally in your own CLI, which the README frames as the point: your CV, your story and your tracker stay on your machine, and the output is a document you read rather than an application that is already submitted. The cost of that choice is setup. A hosted tool works after a signup; career-ops needs Node 18 or later, an API key, and a supported CLI before the first evaluation runs.

A third comparison is the free job tracker that people search for. career-ops is not that. The OpenRouter path is described as a $0 free tier, but it still requires an API key from OpenRouter, and the Gemini path requires a key from Google AI Studio. There is no mode where the tool evaluates listings with no model provider at all.

Maintenance, updates and the MIT licence

The repository is not archived, and the last push was on 2026-08-27. That same day carried two releases: career-ops-v1.30.0 and web-v0.8.1, with web-v0.8.0 two days earlier. Release-please is configured through .release-please-manifest.json, so version bumps and changelogs are generated rather than hand-written, and CHANGELOG.md is the place to read what moved between versions.

Upgrades are handled by a script rather than by git pull. package.json defines update:check, update:test, update, and rollback, where update runs update-system.mjs apply --confirm and rollback runs the same file with a rollback argument. The README does not document what rollback restores or how far back it can go, so verify that yourself before relying on it after a breaking change. There is also a migration test target, update:test, which suggests the maintainers expect schema changes in the tracker between versions.

The project is MIT licensed. That permits commercial and private use and modification, and it requires the licence and copyright notice to be preserved in copies. The repository also carries LEGAL_DISCLAIMER.md, TRADEMARK.md and SECURITY.md, which is a normal pattern for a project that wants its code permissive while reserving its name. Nothing here is legal advice; if you plan to redistribute a modified version under your own branding, the trademark file is the one to read.

Editorial conclusion

Adopt career-ops if you are applying to many roles and already pay for an AI coding CLI, because the evaluation rubric and the tracker are the parts a spreadsheet cannot do. Skip it if you are not willing to feed it your CV, proof points and preferences, since the README states the first evaluations will be poor without that context. Also skip it if you only want a free job tracker, because the OpenRouter runner still requires an API key. Before trusting a score, run npm run doctor, check that your CLI is listed in docs/SUPPORTED_CLIS.md, and open examples/sample-report.md to see what blocks A through H actually produce.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes