pinloop cli - Moses Yebei

The Problem

Job searching for coding agents is fragmented. Agents can scrape job boards, but they lack a structured, frequently refreshed dataset of postings and a way to evaluate them against a candidate's profile. Pinloop supplies a hosted, hourly-updated pool of 10,000+ postings from 4,000+ employers plus an AI-judging pipeline that runs either server-side or through the agent's own model subscription.

What This Does

Pinloop is a Node CLI written in TypeScript (21 source files). It acts as a thin client to Pinloop's servers: the server holds the postings, your resume, and preferences; the CLI invokes AI models to judge postings against your profile. The CLI is designed to be driven by a coding agent (Claude Code, Codex, Cursor), not typed by a human. pinloop prints agent-directed instructions; pinloop welcome runs a structured onboarding flow; pinloop guide prints full usage documentation.

How It Is Wired

Execution starts at the pinloop binary defined in package.json. Code splits into src/cli/ (interaction: browser-login.ts, screen.ts, rows.ts, format.ts, paths.ts, pinloop.ts, version.ts) and src/shared/ (domain logic: billing.ts, coverage.ts, filter.ts, limits.ts, model-calls.ts, registry.ts, sign-in.ts, skill-file.ts, verdicts.ts, welcome.ts).

The full call graph has not been mapped for this repository. The file set implies the flow: registry.ts likely routes commands; welcome.ts and guide.ts drive onboarding; sign-in.ts and browser-login.ts handle passwordless browser auth; model-calls.ts wraps AI invocations; verdicts.ts, coverage.ts, and filter.ts implement judgment and search. Per the README, every command except the guide requires an account and talks to Pinloop's servers — so the CLI makes network calls for auth, search, judging, and billing.

The widest blast radius sits in src/shared/, the domain logic shared across all commands. A change to verdicts.ts or model-calls.ts affects every judging path. Absent a lockfile, installs are non-reproducible.

How To Use It

Setup: npm install -g pinloop (requires Node 22+).

Configuration: no environment variables are documented in the repo. Account creation happens via pinloop login, which opens a browser.

Running: paste this into a coding agent:

Run npm install -g pinloop, then run pinloop welcome and follow the instructions.

Or run pinloop directly for the agent-directed instructions.

Real-World Use

A developer runs pinloop welcome in Claude Code. The agent installs the CLI, walks through browser login, uploads a resume as a skill file (src/shared/skill-file.ts), and runs a scheduled routine (pinloop upgrade unlocks unattended watches). The agent evaluates postings locally with its own model subscription and uploads judgments, avoiding Pinloop's paid judging quota.

Code Health & Issues

Static analysis findings (heuristic — verify against the code):

Med — no test files detected — repository-wide; untested code paths
Med — no CI/CD pipeline — no automated build/test gate in .github/ or CI config
Low — no lockfile — non-reproducible builds from package.json

Beyond that: MIT license, README, and demo GIF are present. Onboarding docs exist (welcome.ts, guide.ts), but there are no contributing guidelines or architecture documentation.

The Bottom Line

A cleanly structured thin client with sensible separation between CLI interaction and shared domain logic. The main risks are the absence of tests, CI, and a lockfile for a tool that handles auth and billing. It is a fork of pinloop-ai/pinloop-cli (279 stars upstream) and is most useful to developers who already work through coding agents; the hosted backend does the heavy lifting, keeping the CLI itself lightweight.

What the analyser found

Deployment readiness

3/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

27 files

TypeScript21
JSON2
Markdown1

React

Module dependencies

The 10 most depended-upon modules of 21, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_src_shared_coverage["coverage"] n1_src_shared_sign_in["sign-in"] n2_src_cli_screen["screen"] n3_src_cli_format["format"] n4_src_shared_guide_text["guide-text"] n5_src_shared_progress_events["progress-events"] n6_src_shared_skill_file["skill-file"] n7_src_cli_browser_login["browser-login"] n8_src_cli_rows["rows"] n9_src_shared_billing["billing"] n7_src_cli_browser_login --> n1_src_shared_sign_in n3_src_cli_format --> n0_src_shared_coverage n8_src_cli_rows --> n2_src_cli_screen n2_src_cli_screen --> n3_src_cli_format n2_src_cli_screen --> n5_src_shared_progress_events n9_src_shared_billing --> n1_src_shared_sign_in

Dependencies

2 of 6 declared dependencies are a major version behind. Resolved 6 of 6 against the registry.

Package	Declared	Latest	Behind
`@types/node`	^22.10.2	26.2.0	4 major
`typescript`	^5.7.2	7.0.2	2 major

Findings

MediumNo test files detected - untested code paths repository-wide
MediumNo CI/CD pipeline detected - no automated build/test gate .github/ or CI config
LowDependencies declared without a lockfile - non-reproducible builds package.json

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

high3

medium2

Add a test suite; this repository has nonehigh21 occurrences

21 source files, no test files

Any change ships with no signal that existing behaviour still holds, so a regression reaches production undetected.

Fix: Add one test per public entry point, then a CI step that runs them.

Commit a lockfile beside the manifesthigh

package.json

manifest with no lockfile in scope

An unlocked range means the artifact you tested and the artifact you ship can contain different transitive code, so a malicious patch release reaches production with no diff.

Fix: Run the package manager once and commit the generated lockfile.

Add a workflow that builds and tests this repositoryhigh

21 source files, no CI configuration

Every change merges with nobody having run the build once, which across this estate is 499 repositories.

Fix: Add a workflow running the project build and test command on push and pull_request.

Enable Dependabot or Renovatemedium

1 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Move large binaries to Git LFS or out of the repositorymedium

demo.gif

1 blobs over 5MB: demo.gif 6.4MB

One repository here carries twenty blobs over 5MB including a 10.9MB spreadsheet, so every clone and every CI checkout pays for data nobody diffs.

Fix: Track those extensions with LFS, or move datasets to object storage and fetch them in a setup step.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.