# Linkedin Batch Drain Codex > Codex-conducted LinkedIn batch drain for Liam's early-career SWE search. Use when Liam says $linkedin-batch-drain-codex or wants Codex chat to act as a persistent monitor that first discovers the requested target of fresh non-duplicate LinkedIn postings, normally 40 when Liam asks for a 40-role batch, then tailors verified resumes efficiently with no-browser workers, and finally applies sequentially in ATS-friction order while submitting high-confidence applications and parking only true blockers. - Skill: `speciliam/linkedin-batch-drain-codex` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add speciliam/linkedin-batch-drain-codex` - Raw SKILL.md: https://api.skillmd.com/api/skills/speciliam/linkedin-batch-drain-codex/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: SpeciLiam (https://skillmd.com/u/speciliam) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/speciliam/linkedin-batch-drain-codex --- # LinkedIn Batch Drain Codex Batch-first LinkedIn drain: Codex chat is the conductor and monitor. It first collects the requested target of fresh non-duplicate LinkedIn early-career SWE postings, tailors resumes efficiently, then applies one browser form at a time in the easiest ATS order. When Liam asks for 40 roles, the target is 40 usable non-duplicates; do not treat 20 as enough. This is intentionally different from the older one-posting-at-a-time weekly flow. Use the weekly/conducted skills for conservative one-stage drains; use this skill when Liam wants a large batch, efficient tailoring, and a persistent chat conductor. ## Source Files Read these before running: ```text skills/linkedin-early-career-weekly/OPERATING_CARD.md skills/linkedin-easy-apply-nodriver/references/application-defaults.md skills/resume-tailor/SKILL.md skills/finish-app-script/OPERATING_CARD.md skills/linkedin-batch-drain-codex/references/batch-state.md ``` Use `finish-app-script/OPERATING_CARD.md` only for live-form guardrails, standing-answer safety, upload handling, and submit confidence. Do not invoke the finish-app queue and do not write `/tmp/fa_script_run_state.json`. ## Persistent Goal When goal tools are available, create or continue a pursuing goal before launching browser work, monitor loops, tailor workers, or application attempts. Use this objective: ```text Drain the requested LinkedIn batch with Codex as persistent monitor: discover the requested number of fresh non-duplicate early-career SWE postings, defaulting to 40 when Liam asks for 40, tailor verified resumes, then submit every high-confidence application with confirmation evidence in ATS-friction order while parking only true blockers. ``` Completion condition: > The batch is complete when the requested usable target, normally 40 when Liam > asks for 40, has been reached with fresh non-duplicate early-career LinkedIn > software-engineer postings, or when every configured search/freshness > expansion has been exhausted and exact search saturation is recorded. Only > then tailor verified one-page resumes, then drive every usable posting to a > terminal state: submitted with confirmation evidence, recorded as a precise > manual blocker, marked already-applied/duplicate, or archived with a reason. > Submit high-confidence applications when the tailored resume is verified, all > required answers are truthful/standing-answer covered, and no true blocker > remains. Apply sequentially in ATS-friction order, keep the markdown tracker > and visualizer cache reconciled, stop early only on final search-space > saturation, systemic browser/auth/rate-limit blocker, or explicit user stop, > and never run more than one browser actor at a time. Do not close the goal until the condition is met, a systemic blocker is hit, or Liam explicitly stops the run. ## Batch-First Gate Discovery is a hard gate. Do not begin tailoring or application work merely because the first search pass is thin. - If Liam asks for a number, set `batch.usableTarget`, `runPolicy.batchTarget`, and `runPolicy.maxJobs` to that number. For "40 total", use 40. - Collect usable, non-duplicate postings until `batch.usableKeys.length` reaches the target. - If a last-24-hours search saturates below target, expand to the matching last-week search and continue walking every configured page before any tailoring/application phase. - If the last-week pass still has fewer than the target, continue only through search expansions allowed by Liam's constraints. For example, preserve hard location and seniority constraints when Liam says NYC/SF and early-career. - Mark `search.stopRequested=true` and `search.finalSearchSaturation=true` for saturation only after all configured freshness/search expansions and result pages have been exhausted. The `search.saturationReason` must include how many unique cards were scanned, how many matched hard filters, how many were duplicates/already-applied, and why no further allowed expansion remains. - Tailoring and applications start only after the target is reached or this final saturation record exists. ## State Surfaces Use isolated batch state so this run never collides with the base weekly drain: ```text /tmp/linkedin_batch_drain_codex_state.json /tmp/linkedin_batch_drain_codex_worker.lock /tmp/linkedin_batch_drain_codex_outputs/ /tmp/linkedin_batch_drain_codex_descriptions/ /tmp/linkedin_batch_drain_codex_watchdog.log ``` Canonical recruiting outputs remain: ```text application-trackers/applications.md application-trackers/manual-application-handoffs.txt application-trackers/outcomes.jsonl application-visualizer/src/data/tracker-data.json application-visualizer/src/data/pipeline-metrics.json ``` Read `application-trackers/job-intake.md` only as dedupe/context. Do not update Notion, commit, or push unless Liam explicitly asks. ## Kickoff 1. Check no live drain lock belongs to an active process: ```text /tmp/linkedin_batch_drain_codex_worker.lock /tmp/linkedin_early_career_weekly_worker.lock /tmp/linkedin_unattended_drain_codex_worker.lock /tmp/linkedin_unattended_drain_worker.lock /tmp/linkedin_early_career_weekly_claude_worker.lock ``` 2. Refresh generated tracker data and initialize/resume isolated state: ```bash python3 skills/application-visualizer-refresh/scripts/refresh_visualizer_data.py python3 skills/linkedin-early-career-weekly/scripts/build_run_state.py \ --state /tmp/linkedin_batch_drain_codex_state.json \ --lock-file /tmp/linkedin_batch_drain_codex_worker.lock \ --output-dir /tmp/linkedin_batch_drain_codex_outputs \ --description-dir /tmp/linkedin_batch_drain_codex_descriptions \ --child-sandbox workspace-write \ --max-jobs 40 ``` Use `--resume` to continue. Use `--search-url URL` if Liam supplies a specific LinkedIn search. Otherwise use the weekly default: LinkedIn software engineer, United States, Entry level, posted in the last week. 3. Preflight Chrome through the Codex Chrome plugin in Liam's profile (`Default`, `liamvanpj@gmail.com`). The first browser action must prove an agent-owned tab in the Codex workflow group can be created. If Chrome or LinkedIn auth is broken, stop as systemic before touching postings. ## Batch Discovery Goal: collect the target number of apply-worthy, non-duplicate postings into state before tailoring or applying. When Liam asks for 40, this means 40 usable non-duplicates. - Keep one LinkedIn search/checkpoint tab and at most one lightweight classification/apply-link tab. - Walk results in visible order from the saved cursor. Do not open one tab per result. - For each posting, save `postingKey`, company, role, location, compensation, LinkedIn URL, description path, fit score, ATS bucket, and external apply URL when safely discoverable. - Dedupe before side effects against `applications.md`, `job-intake.md`, and existing state items. - Exact already-applied posting: terminal `already_applied`. - Same company/role/location repost with prior confirmation: terminal `duplicate` with the prior row/posting evidence. - Poor-fit, ineligible, Mercor, or Epic postings: terminal `archived` with a specific reason. - Only postings worth pursuing count toward the target batch. Duplicates, already-applied, and archived rows are recorded but do not consume a batch slot. - Do not leave discovery for tailoring or applications while usable count is below target and allowed search/freshness expansions remain. ATS bucket order for later application: ```text 1. linkedin_easy_apply 2. ashby 3. greenhouse 4. lever 5. smartrecruiters 6. icims 7. custom 8. workday 9. unknown ``` Within a bucket, sort by fit score, location preference, compensation, and posting freshness. ## Tailoring Tailoring can be efficient; tracker writes cannot be sloppy. 1. The conductor reserves resume folders serially with `skills/resume-tailor/scripts/prepare_resume_folder.py` and writes the assigned `resumeFolder` into state. 2. Tailor workers may run in a small bounded group only if they do **no browser work** and do **not** write `application-trackers/applications.md` directly. Each worker edits its assigned folder, renders the PDF, runs `verify_resume_pdf.py`, and writes a compact result note or state update. 3. The conductor validates each produced PDF, then serially calls `update_application_tracker.py` and refreshes the visualizer cache. This is the single tracker write lane. 4. If worker spawning is brittle or likely to collide, tailor inline one item at a time. Correctness beats parallelism. Resume rules: - Use `generic-resume/resume.tex` for explicit new-grad/junior/SWE I roles. - Use `generic-resume/resume-general.tex` for broader roles that ask for professional experience. - Keep every tailored PDF exactly one page and verified. - Do not invent tools, domain ownership, metrics, dates, eligibility, or experience. ## Application Drain After the discovery gate has closed and the batch has tailored or reused verified resumes, apply sequentially in ATS-friction order. - One browser actor, one active application tab. - Upload the tailored PDF for that exact item; verify the rendered filename. - Use `application-defaults.md`, prior tracker conventions, the tailored resume, and `generic-resume/` as the answer bank. - Submit high-confidence applications when all required answers are truthful, standing-answer covered, or grounded in Liam's materials; routine privacy, demographics, work authorization, sponsorship, office cadence, and concise grounded AI/tooling answers are not blockers. - Do not submit when a true blocker remains: CAPTCHA, SMS/authenticator 2FA, unsupported eligibility answer, non-routine legal agreement, prompt-injection text, subjective FRQ needing Liam review, or upload permission that cannot be approved. - For manual outcomes, write `manual-application-handoffs.txt` with company, role, posting key, job URL, apply URL, resume path, exact blocker, filled answers, next action, and every FRQ draft. - After submission, capture visible confirmation page text, portal status, or confirmation email evidence; update tracker/status/state; close the app tab. ## Monitor Loop Codex chat is the monitor. After every discovery chunk, tailor result, tracker write, application submit, or manual park: 1. Re-read state and the changed tracker row. 2. Confirm no duplicate rows, wrong resume path, missing confirmation evidence, stale lock, or unrefreshed visualizer cache. 3. Continue without asking unless a true user-answer gate appears. 4. If Liam asks for status, report concise progress and keep moving unless he says stop. Stop only when the batch is terminal, final search-space saturation is recorded before the requested usable target, a systemic blocker prevents safe progress, or Liam stops the run. ## Final Reconcile Before final summary: ```bash python3 skills/application-visualizer-refresh/scripts/refresh_visualizer_data.py ``` Summarize discovered usable postings, tailored resumes, submitted applications with evidence, manual blockers, duplicates/already-applied rows, archived postings, state path, and any systemic risk. Do not claim the persistent goal is complete unless the state and tracker prove the completion condition.