/batch-resume

name: batch-resume
description: Process multiple job descriptions from the batch_jds folder into tailored application packages, each produced by the native Resume Team, with independent candidate-fit gates and ordered DOCX and tracker writes. Use when the user has several JDs to run at once, drops files in batch_jds, or asks for batch or bulk resume generation across many roles.

Batch Resume Builder — Native Resume Teams

Process multiple job descriptions with concurrent read/scoring work. Each resume is produced by the native four-role team; final DOCX and tracker mutations remain ordered and coordinator-owned.

Arguments

The user may pass options when invoking this skill; the job descriptions themselves are read from `.txt` files in the `batch_jds/` folder.

Instructions

You are the **team lead** for a batch resume processing operation. Execute the following steps:

---

STEP 1: DISCOVER JDs (READ-ONLY)

Scan the `batch_jds/` folder for `.txt` files:

Use file search (`rg --files batch_jds` or `find`) for `batch_jds/*.txt`

Each file should be named: `{Company} - {Job Title}.txt`

Parse the filename to extract:

• **Company**: Everything before ` - `
• **Job Title**: Everything after ` - ` (without `.txt`)

If no files found, tell the user to add JD text files to `batch_jds/` and explain the naming format.

Display a numbered list of all JDs found and confirm with the user before proceeding.

---

STEP 2: CANDIDATE-FIT PREFLIGHT (MANDATORY FIRST GATE PER JD)

Resolve and read `master_resume_path` from `config.json` once. It is the sole base and factual source for every job; never inspect, screen, or substitute an existing tailored application resume. For each exact JD, independently generate a safe `run_id`, safe `case_id`, and strict ISO `as_of_date`, then run the deterministic machine preflight before starting a scorer, role/native team, output directory, resume draft, DOCX, or tracker operation for that JD:

`python candidate_fit_preflight.py --resume <configured-master-resume> --job-description <exact-JD-file> --run-id <run_id> --case-id <case_id> --as-of-date <YYYY-MM-DD> --json`

Require exit `0` and a valid `candidate-fit-policy-v3` report bound to that JD, master, date, and IDs. Canonically hash it as `candidate_fit_report_digest`. A passing report has exact threshold `70.0`, score at least 70, trustworthy extraction, zero hard knockouts, `passed: true`, and no codes. Exit `1`, any score below 70 (including 60–69), or any hard knockout is `REJECTED:CANDIDATE_FIT`. Create nothing for that JD, record the rejection in the in-memory/private batch report, and continue screening the remaining JDs. Exit `2` or an unavailable, malformed, stale, non-canonical, or digest-mismatched report is `FAILED:CANDIDATE_FIT_PREFLIGHT`; fail that JD closed, create nothing, and continue the remaining independent JDs. There is no automatic or manual workflow bypass. ATS/HR scores are advisory and cannot override this gate.

Keep each passing report, canonical digest, IDs, and date in private coordinator state. Do not create an application directory to store preflight results.

---

STEP 3: SCORER SERVER PRE-FLIGHT FOR PASSING JDs

If no JD passes candidate fit, skip scorer startup and finish with the rejection report. Otherwise, check whether the scorer server is running:

curl -s http://localhost:8100/health

• **If server responds**: Proceed immediately.
• **If NOT running**: Start it in a background shell session from the repo root

with `python scorer_server.py --port 8100`.

• Wait up to 45 seconds for `/health`. If unavailable, use CLI ATS/HR scoring after

publication; that advisory failure cannot bypass or reverse candidate fit.

---

STEP 4: RUN ONE NATIVE RESUME TEAM PER JD

Operate only on JDs with a passing candidate-fit report. Read the resume-team skill (`skills/resume-team/SKILL.md`), run the non-model host preflight once, and require macOS or Linux; Windows fails closed with `POSIX_RUNTIME_REQUIRED`. For **each JD file**, derive a prospective non-existing output path but do not create it. Invoke `native_resume_team.py` for the current host with that JD's exact `run_id`, `case_id`, and `as_of_date` instead of manually reproducing `resume-team/v2`. The runtime enforces role separation, lineage, replay protection, three deterministic votes, and receipt/readback verification. Independent read/scoring work may overlap across JDs, but draft publication and tracker writes are serialized.

The runtime recomputes candidate fit from the configured master and exact JD before constructing its output state or role adapter. Require its report and canonical digest to exactly match the independently validated preflight. Each `resume-team-result/v2` runtime `PUBLISHED` result is only an authorized, digest-verified `resume.md` draft-stage artifact. Independently verify `final_draft_digest`; do not count it as a completed package. The task must still finish its cover letter, both DOCX files, tracker update, artifact verification, cleanup, and final report.

If a runtime defense-in-depth recomputation instead returns `REJECTED:CANDIDATE_FIT` or `FAILED:CANDIDATE_FIT_PREFLIGHT`, require that JD's prospective output path to remain absent, record the closed result, and continue the remaining independently passing JDs without creating a fallback package.

For every draft, resolve `authorization_receipt_path` against its output directory when relative and require the resolved parent to equal that resolved directory. Read only regular, non-symlink JSON, recompute its canonical digest, and require it to equal `authorization_receipt_digest` and the inline `authorization_receipt`. Validate its `resume-team-final-receipt/v2` shape against `schemas/resume-team-final-receipt.schema.json` before accepting it. Require the receipt's `candidate_fit_report` and `candidate_fit_report_digest` to exactly match the runtime and independent preflight, including the fixed threshold,