/Open-to-work

name: open-to-work
description: A complete, self-contained job-search pipeline for ANY user. Onboards once — building resume, fact pack, voice, and styling files from a resume, LinkedIn/portfolio, or quick interview. After that it tailors your resume to any job (truthfully, never fabricating), builds a one-page DOCX + PDF, runs an ATS scoring loop twice, writes a cover letter in your voice, answers application questions, and can fill/upload the form in the browser. Scans job boards on a schedule, preps for interviews (prep kit, mock, debrief), drafts outreach to recruiters or hiring managers, and tracks every application in a standing pipeline ledger with follow-ups, thank-yous, and offer-negotiation help — all feeding one self-improving library. Use for anything job-search related — onboarding, tailoring, cover letters, ATS scoring, applying, scanning, interview prep or debrief, outreach, tracking applications, negotiating offers, or any time they paste a job posting. If there's a chance this is a job-search task, load it.

Open To Work

A full job-search loop in one self-contained skill: **scan → shortlist → tailor → ATS-score → cover letter + application answers → browser fill/upload.** It works for *any* user because all personal content lives in the user's own **`user-library/`** files, which the skill builds during onboarding. Nothing about any specific person is hardcoded.

There are four entry paths. Pick based on the request and on whether the user is already onboarded.

• **A. ONBOARDING** — builds the user-library. Runs on first use, or when the user

says "set me up / onboard me / customize me", or whenever the user-library is missing or empty.

• **B. RUN** — the tailor-and-apply pipeline for a specific job. Runs once the

user-library exists and the user brings a job description (or picks one from a scan).

• **C. PREP** — interview preparation for a role the user already applied to (or is

about to interview for), plus **post-interview debrief** that grades a real interview transcript against the prep and feeds the lessons back. Runs when the user says they "got an interview", asks to "prep", "practice", or "get ready" — or afterward, "debrief that interview / how did I do / review my interview". Best invoked **in the same chat where the application was built** — the strategy doc and JD are already in context — but works standalone too. See **C. PREP** below.

• **D. OUTREACH** — a direct, personal note (email or LinkedIn) to the recruiter or

hiring manager, to pull a strong application out of the pile. Runs when the user asks to "reach out", "email the hiring manager/recruiter", "find their email", or do "cold outreach" — and is **offered proactively at the end of a strong tier-1 RUN**. Gated to genuinely strong-fit roles. See **D. OUTREACH** below.

The one rule that overrides everything

**Never fabricate experience.** Every word on the resume, in the cover letter, and in the application answers must trace to the user's real background as recorded in their `user-library/fact-pack.md` and `base_resume.md`, or to something they say in the conversation. Tailoring means *reordering, reframing, and resurfacing* real experience to match a role — never inventing employers, titles, metrics, skills, tools, or projects. When the ATS step asks for something the user can't truthfully claim, you do not add it; you flag it. A higher score earned by a lie is worthless and collapses in an interview.

Everything you write follows the house writing standard

All copy this kit produces — résumé bullets, the cover letter, application answers, outreach notes, prep-kit framing — should read like the user wrote it, not like an AI. **`references/writing-standards.md`** is the advisory house style: the structural tells of machine-written prose (anaphora, the "not X, it's Y" false-negative, antithesis, asyndeton, rhetorical-question transitions, clever comparative endings, staccato fragments), the positive habits that read as human, and how the standard flexes by format (a résumé bullet is terse and fragment-normal; a cover letter flows). Hold it in mind *while drafting* so output adheres by construction — it's a writing habit, not a post-hoc scoring gate. It never overrides the two rules above it: `voice.md` (the user's actual voice) wins any conflict, and nothing it suggests excuses fabricating.

The library is a living system — improve it on every pass

The user-library is not a static file you only read. It's a **self-improving record** that should get richer and more accurate every time the user works with the kit. The truthfulness rule and the enrichment habit are two sides of the same coin: you never *invent* a fact to fill a gap, but you always *capture* a real one when it surfaces.

Across **every mode**, stay alert for material that belongs in the library but isn't there yet, and for entries that have gone stale:

• a **real metric** the user mentions in chat that a fact-pack bullet was missing;
• a **story** they tell (a conflict, a failure, a 0→1 win) not yet in `fact-pack.md`;
• a **new role, title, or tool** they reference that post-dates the base resume;
• a **recurring hard-gap** worth noting as a standing pattern, or one that's now

*closed* because they've gained the experience;

• a **refined preference** (a domain they're done with, a role shape they keep

picking) that should update `scanner_config.json`;

• a **gap with no prepared framing** that prep should add.

**How to capture, safely:**

1. **Only ever record what the user actually stated or confirmed.** Never infer a fact into the library to make an answer or score better. A fillable gap (a missing number the user knows) → ask. A genuine gap (no domain experience) → leave it logged as-is; don't nag about what can't truthfully change. 2. **Batch it at the end, never mid-task.** Don't interrupt a tailoring or prep flow to do bookkeeping. Collect candidate additions an