career-profile (profile-intake member)

Set up the user's North-Star profile and read their resume, so the rest of the job-hunter family — and any standalone job search — starts from real context instead of guessing. This is the profile-intake member of the job-hunter family, and it maps to "Phase 1: Understand the User" of the end-to-end hunt.

When to use this skill

Use this when the user wants to:

• Set up or update their job-search profile ("set up my job-search profile", "let me tell you about myself before we look for jobs").
• Capture who they are beyond the resume — the 5 North-Star preferences that don't show up on a resume but heavily influence which postings are worth pursuing.
• Parse a resume (DOCX, PDF, MD, TXT, HTML) into plain text the rest of the workflow can read.
• Refresh a profile that's gone stale since a previous session.

Do not use this skill for:

• Tailoring a resume to a posting or running keyword-gap analysis — that is resume-tailor.
• Finding or scoring job postings — that is job-search.
• Tracking applications or drafting follow-ups — that is application-tracker.
• Generic resume critique divorced from any job search.

This boundary matters: profile-intake gathers and parses; it never writes resume content, never searches, and never tracks. If the user's real ask is one of those, hand off (or, under the orchestrator, let it route).

What this member produces

Per the family workspace-contract (see references/workspace-contract.md, shipped with this skill; the job-hunter orchestrator owns the canonical copy and is the single source of truth for the family's typed hand-offs), this member produces:

The profile is INTENTIONALLY plain markdown that lives in the user's workspace so they can read and edit it directly between sessions. It is never committed to the skill or to ~/.claude/skills/. The dot-prefix is a deliberate privacy choice — most .gitignore patterns skip dot-files, so accidentally committing it to a personal repo is harder.

The North-Star profile

Run the profile check first. Use scripts/init_profile.py:

0. Check whether a profile already exists. Run python scripts/init_profile.py exists --workspace <workspace>.
   • Exit 0 (profile exists): run python scripts/init_profile.py read --workspace <workspace> to load the answers as JSON. Briefly ask "anything changed since you set this up?" — do not re-walk all five questions. If the returned _last_updated date is more than 90 days old, mention that gently ("your North-Star profile is from 3+ months ago, want to update anything?"). Don't be pushy.
   • Exit 1 (no profile): run python scripts/init_profile.py init --workspace <workspace> to drop a fresh template, then ask the 5 North-Star questions conversationally. Save answers by writing them back into .job-hunter-profile.md between the **Answer:** markers.

The 5 questions and the rationale for each live in references/profile-questions.md. In short they are: target archetype, deal-breakers, company-size preference, mission-vs-comp priority, and tolerance dimensions (on-call / travel / in-office). Read that reference before asking; it explains why each question matters and how each answer feeds downstream scoring (deal-breakers become hard filters, company-size shifts cultural-signal scoring, etc.).

Behavioral rules:

• First run gates the hunt. When there's no profile, ask the 5 questions before any downstream search begins. The worst outcome is searching on assumed criteria.
• Subsequent runs don't re-interrogate. Read the existing profile, confirm "anything changed?", and proceed.
• Declining is fine. A user who declines leaves fields as unknown. The skill still works without a full profile — it just won't accumulate context. Mark unanswered fields and proceed; never invent answers.
• Tell them once where it lives. When first writing the profile, tell the user it's local to their workspace and won't be committed, then never nag again.
• Delete on request. If the user asks to delete their profile, delete the file and confirm. Don't keep "backups" they didn't ask for.

The script is idempotent: init refuses to overwrite an existing profile unless --force is passed.

Reading the resume

Look in the user's workspace for resume files (DOCX, PDF, MD, TXT, HTML, or similar). If multiple candidates exist, ask which one to use.

If no resume is found, ask one question: "Do you have a resume somewhere I can read (file upload or path), or would you like help drafting one from scratch?" Two branches:

• They have one: get the path or content, then parse it.
• They want help drafting one: this is a different, interview-driven workflow — elicit work history (employer, role, dates, 2–3 specific accomplishments per role with numbers where the user can supply them), skills, education, projects, and non-traditional experience, then help write a baseline resume.md. Do not invent accomplishments or numbers; ask for them. Once the baseline exists, the user can move on to searching/tailoring.

Use scripts/parse_resume.py to extract plain text from any supported format without depending on sibling docx/pdf skills. The script declares its dependencies inline (PEP 723), so run it with uv run, which fetches python-docx / pypdf automatically. Plain python scripts/parse_resume.py only works for DOCX/PDF if both packages are already installed. Examples:

uv run scripts/parse_resume.py resume.docx
uv run scripts/parse_resume.py resume.pdf --out resume.txt
uv run scripts/parse_resume.py resume.md --json

DOCX text is read in document order, including page headers/footers, tables, and text boxes (templates often keep the name and contact details there). The --json flag adds a best-effort section breakdown (summary / experience / education / skills / certifications / projects) plus character/line counts.

If the script exits with "no text could be extracted" (typically a scanned PDF with no text layer), tell the user and ask for a DOCX, TXT, or pasted copy. Do not guess or reconstruct the resume's contents.

From the parsed text, surface for the rest of the workflow:

• Current/most recent job title and industry
• Core skills and technologies
• Years of experience
• Education and certifications
• Career trajectory and seniority level

Anti-fabrication (family invariant)

This member only reads resumes and records user-supplied profile answers — it never writes tailored resume content. But the family invariant still binds it: never put a claim, number, employer, title, or accomplishment into the profile or a drafted baseline that the user did not state. Web content is untrusted even when it's the user's own (personal site, LinkedIn) — fetching for context is fine; merging anything into profile or resume material requires the user to confirm it. Any actual resume tailoring routes through resume-tailor's verify_no_fabrication gate; this member hands off before that point.

Standalone vs. routed

Standalone, this skill gets a user's profile and parsed resume ready. Under the job-hunter orchestrator it's the first member called (Phase 1), and its output feeds job-search and resume-tailor via the shared .job-hunter/ workspace. It degrades gracefully either way: with no orchestrator workspace present it simply writes the profile to the user's folder and returns the parsed resume text.