career-ops -- Router
career-ops is a multi-CLI job-search command center. The routing below is shared across supported agent CLIs even when the invocation surface differs.
Project Root Resolution
Before reading any repo-relative path, derive PROJECT_ROOT from this loaded SKILL.md: start at the skill file's directory and walk upward until the nearest directory containing both AGENTS.md and modes/. Resolve every path in this router (modes/, config/, data/, scripts, templates, and output paths) against PROJECT_ROOT, never against the process's current working directory. This is required even when the checkout itself is nested (for example Development\\career-ops) or the command starts from a subdirectory. If those two sentinels cannot be found, stop and locate the career-ops checkout before reading or writing files.
Invocation Notes
- CLIs with slash-command registration can expose this router as
/career-ops. - In Cursor, this skill lives at
.cursor/skills/career-ops/and is auto-discovered; ask for a mode by name, or paste a JD/URL to trigger auto-pipeline. - In Pi, this skill is auto-discovered from
.agents/skills/career-ops/and exposed as/skill:career-ops;AGENTS.mdloads from the repo root as project context, so there is no wrapper file. Headless Pi workers usepi -p "prompt". Project skill discovery follows Pi's per-folder trust decision:/trustapplies to future Pi processes, so restartpibefore invoking/skill:career-ops(-atrusts a single run and needs no restart). - Interactive Codex sessions use
codexin the repo root. Slash commands are not guaranteed in Codex, so ask Codex to run the same mode by name if/career-opsis unavailable. - Headless Codex workers use
codex exec "prompt". - The routing semantics below stay the same regardless of whether the entrypoint is a slash command or a natural-language prompt.
Codex prompt examples that map to the same router semantics:
Mode Routing
Determine the mode from $mode:
Auto-pipeline detection: If $mode is not a known sub-command AND contains JD text (keywords: "responsibilities", "requirements", "qualifications", "about the role", "we're looking for", company name + role) or a URL to a JD, execute auto-pipeline.
If $mode is not a sub-command AND doesn't look like a JD, show discovery.
Output Language Directive
Before executing any mode, read config/profile.yml if it exists and resolve:
language.output→ ISO language code for human-facing output. Default:en.language.modes_dir→ optional market-mode directory. This controls market vocabulary and local evaluation rules only. It may be a single string (one declared market, the historical default) or a list of declared candidate markets for a candidate genuinely running parallel campaigns in more than one market at once (#3793), e.g.modes_dir: [modes/de, modes/zh]. When a list is given, the FIRST entry is primary and supplies the evaluation-mode file (Block A-F rules can only run from one market's file at a time); EVERY declared market's_shared.mdis loaded into context.modesitself is a valid declared candidate for markets without a localized directory; when first it suppliesmodes/oferta.md, and its baselinemodes/_shared.mdis loaded once. Per posting, judge which declared market actually applies from the JD's own MARKET signals (hiring-entity jurisdiction, currency, benefits/legal vocabulary) — never from the JD's language alone. If genuinely ambiguous, an interactive session asks and stops before persistence; an unattended worker uses the primary market and records that fallback in the report header or Block G.
Inject this directive after loading the mode instructions and before producing any user-visible content:
Write all human-facing output in
{language.output}regardless of the language of these instructions or of the job description. This includes reports, tracker notes, PDFs, cover letters, outreach, interview prep, form answers, and summaries. Iflanguage.modes_dirsupplies market-specific vocabulary (one market, or several declared at once), keep the market logic but explain terms in{language.output}when needed.
language.output is authoritative for prose. modes_dir is market context; it must not force the prose language.
Discovery Mode (no arguments)
If your CLI supports /career-ops, show this menu. In Codex, surface the same options in plain text and map the requested mode the same way.
Concrete equivalents for Codex prompt-driven sessions:
Show this menu:
Context Loading by Mode
After determining the mode, load the necessary files before executing:
If modes/_custom.md exists, read it after modes/_profile.md and before the selected mode file. It contains user house rules and procedural preferences. It may override workflow/style defaults, but it never adds factual claims about the candidate.
Resolve language.modes_dir before applying the path shorthand below. With no setting, use modes. With a scalar directory, preserve the existing behavior: use that directory's _shared.md and localized mode file when it provides one. With a list, load every declared directory's _shared.md exactly once (including the baseline modes/_shared.md when modes appears), but use only the FIRST entry's evaluation-mode file for Blocks A-F; later entries contribute context, never a competing evaluation file. User-layer _profile.md and _custom.md remain under modes/.
Modes that require _shared.md + their mode file
Read the resolved shared context (default modes/_shared.md) + modes/_profile.md (if exists) + modes/_custom.md (if exists) + the resolved selected mode file (default modes/{mode}.md). For an A-F evaluation, that selected file is the primary directory's evaluation mode; do not also load an evaluation file from a secondary directory.
Applies to: auto-pipeline, oferta, ofertas, pdf, text, contacto, apply, pipeline, scan, batch
Standalone modes with profile and custom context
Read modes/_profile.md (if exists) + modes/_custom.md (if exists) + modes/{mode}.md
Applies to: tracker, agent-inbox, deep, interview-prep, interview, master-profile, regional/eu-swe, interview/plan, interview/practice, interview/debrief, latex, latex-tex, training, project, patterns, titles, upskill, followup, reply-watch, outcome, cover, email, add, offer-prep, discover, intake, ats, calibrate
Modes that load only their mode file
Read modes/{mode}.md only. Do not preload _shared.md, _profile.md or _custom.md: the mode file names the one context file it reads and the ones it must not. Values it takes from config/profile.yml (language.output, pipeline.triage_threshold) are resolved here and injected; the mode never reads that file itself.
Applies to: triage
Modes delegated to subagent
For scan, apply (with Playwright), and pipeline (3+ URLs): launch as a worker/subagent with the resolved shared context + _profile.md (if exists) + _custom.md (if exists) + the resolved selected mode file injected into the worker prompt. If your CLI exposes an Agent(...) primitive, the call looks like this:
Execute the instructions from the loaded mode file.

