| name | job-hunt |
| description | End-to-end job application pipeline orchestrator. Triggers on user pasting JD URL, asking "what should I apply to", saying "submitted" / "I'm at the form" / "follow up", or giving review feedback on a draft. Routes to one of 8 phases — bootstrap, research, tailor, review, submit walkthrough, track, outreach, learn — based on user intent. Per-role tailoring is delegated to the cv-tailor skill. Designed to be forked; configuration in your workspace's config.yaml drives paths and context. |
Job-Hunt Pipeline (Generic)
You are running a user's job application pipeline end-to-end. Always read the workspace config and memory files first — they tell you who the user is, what market they're targeting, and what writing rules they've codified.
Configuration
The workspace path is set when the user installs this skill. Default expectation:
config.yaml at: ${WORKSPACE}/config.yaml
Master CV: ${WORKSPACE}/cv_master.tex
Build script: ${WORKSPACE}/build.sh
Experience bank: ${WORKSPACE}/experience-bank/
Templates: ${WORKSPACE}/templates/
Applications: ${WORKSPACE}/applications/<company>-<role>-<YYYY-MM-DD>/
Tracker: ${WORKSPACE}/applications/_tracker.md
Memory (per Claude Code session): in your project's memory directory, conventionally:
- project.md (user profile, target market, eligibility)
- feedback.md (writing rules — accumulates over time via Phase 7)
Sub-skill: cv-tailor
If ${WORKSPACE} isn't set or config.yaml doesn't exist, ask the user where their workspace is, or trigger Phase 0.
State detection — pick the right phase
| User intent | Trigger phrases | Phase |
|---|
| First-time setup | "build my CV", no cv_master.tex exists, "let's start" | 0. Bootstrap |
| "What should I apply to" | "find me jobs", "what roles fit me", "research target companies" | 1. Research |
| Specific role discussed | pasted JD URL or full JD text, "apply to this", "tailor for this" | 2. Tailor |
| Drafts ready, not yet submitted | follows Phase 2 automatically; or "review this" | 3. Pre-submission Review |
| About to submit | "I'm at the form", "ready to submit", screenshot of application form | 4. Submit walkthrough |
| Just submitted | "submitted", "applied", "投了" | 5. Track + propose follow-up |
| Post-application warmth | "follow up on X", "DM the founder", "cold outreach" | 6. Outreach |
| Reviewing weekly | "this week's pipeline", "status of applications" | 5. Status review (read tracker) |
| Learning from feedback | user critiques a draft, says "change X to Y" | 7. Learn + backport |
If unsure which phase, ask. Don't auto-pick a phase that costs many tokens.
Phase 0 — Bootstrap (one-time per user)
Run when: no cv_master.tex exists, OR user explicitly asks to rebuild.
Steps:
- Get raw material from the user via conversation:
- Education (institutions, dates, grades / GPA, relevant modules)
- Work history — honest (dates, role, what was actually done; don't inflate "shadowing" to "managed")
- Projects — name, what it does, real numbers if any (users / revenue / stars)
- Skills (real, with depth)
- Languages
- Visa / work authorisation status
- Target roles + target market (e.g., "UK AI startups, junior")
- Pull verifiable evidence in parallel via WebFetch:
- GitHub profile + repo metadata (
gh api repos/<user>/<repo> if gh is installed)
- Personal sites / live products
- LinkedIn URL (user must provide; LinkedIn blocks scrapers)
- Write
cv_master.tex (1-page, ATS-friendly LaTeX, sections: About → Projects → Skills → Education → Experience).
- Build
experience-bank/<project>.md files: at least 4–6 bullet variants per project, framed by role type (Growth / Engineering / Data / BizOps / Product / etc.).
- Build
templates/cover_letter.template.md, linkedin_dm.template.md, why_i_fit.template.md (or copy from this skill's defaults).
- Save
memory/project.md and memory/feedback.md with:
- Profile snapshot (verified, dated)
- Default positioning ("AI Product Builder", "Founding Engineer-track", etc.)
- Initial writing rules (start with the 9 generic rules in
feedback.template.md)
- Verify build:
cd ${WORKSPACE} && ./build.sh → 1-page PDF.
Output: master CV + experience bank + templates + memory in place.
Don't: invent metrics. If user can't confirm a number, drop it.
Phase 1 — Research (target discovery)
Run when: user asks "what should I apply to" / "research X / Y companies" / "salary at ".
Steps:
- List 8–12 candidate companies based on user's target market + role types. Tier them: high-fit / mid-fit / stretch.
- For salary or open-role data — always dispatch sub-agent(s) rather than serially WebFetch. Glassdoor / LinkedIn block scrapers; ATS pages (Ashby / Greenhouse / Lever / Workable) work better.
- Sub-agent brief (template):
For each company: title, location, JD content summary (60–100 words),
required + nice-to-have, salary disclosed verbatim, salary triangulation
from 3+ sources (levels.fyi, Glassdoor, RepVue, WTTJ, 4dayweek, Reddit),
user-fit score /10, visa risk flag.
- Deduplicate against tracker — don't re-research already-applied companies.
- Output: ranked table (company × role × fit × est. comp × confidence × visa flag) + top 3-5 picks.
Hard rules:
- Don't invent salaries. "Not disclosed" is acceptable.
- Always flag visa gates (e.g., UK Security Clearance, "no sponsorship now or in the future" clauses) for blocked roles.
- Don't pad the list. 5 well-researched > 20 generic.
Phase 2 — Tailor (per role) — DELEGATE TO cv-tailor
Run when: user pastes a JD URL/text or says "apply to this".
Delegates to: the cv-tailor skill (separate SKILL.md at skills/cv-tailor/).
cv-tailor produces:
applications/<company>-<role>-<date>/
├── analysis.md # JD analysis + tailoring decisions
├── cv.tex / cv.pdf # 1-page tailored CV
├── cover_letter.tex / .pdf # 250–400 word cover letter
├── linkedin_dm.txt # ≤60-word cold DM
└── why_i_fit.txt # 3 bullets ≤25 words for application form
After cv-tailor finishes, always proceed to Phase 3 before Phase 4.
Phase 3 — Pre-submission Review
Run when: Phase 2 just produced application materials.
Steps:
- Tell user PDFs are ready, give
open commands.
- Ask user to review and critique before any submission. Do not push to submit.
- If user gives feedback:
- Apply each edit verbatim where possible.
- Re-build PDF. Verify still 1 page.
- Mark the rule for backport in Phase 7.
Common review-loop edits to apply preventively (read user's memory/feedback.md for accumulated rules):
- Don't claim measurement frameworks the user hasn't actually built (e.g., "weekly cohort review", "retention model") if they haven't confirmed they built one — use softer language like "weekly user-feedback reviews".
- Don't write end-to-end ops responsibility lists with words user hasn't validated — confirm scope before adding "finance", "fundraising", "hiring", etc.
- Don't use pitch-deck phrasing ("anti-spoonfeeding", "10x productivity", "redefining X") — concrete capability + behaviour wins.
If you find yourself re-applying the same edit twice across applications, hard-stop and update the relevant experience-bank/*.md so it's permanent.
Phase 4 — Submission Walkthrough
Run when: user says "ready to submit" / shows a form screenshot.
Branch on browser-automation availability:
- Connected (e.g., Claude in Chrome extension) → use browser tools to navigate, read form, paste field-by-field. Never click final Submit — user clicks.
- Not connected → produce a paste-by-field playbook. User does the clicks.
Field-by-field playbook template:
| Field | What to paste |
|------------------------------------------------|----------------------------------------------|
| First / last name | <from memory/project.md> |
| Email | <from memory/project.md> |
| Phone | <local format> |
| Location | "<city>, <country>" |
| Resume / CV | upload <abs path to applications/<x>/cv.pdf> |
| LinkedIn | <full URL> |
| GitHub / Portfolio | <full URL> |
| Cover letter (file or text) | upload <cover_letter.pdf> OR paste content |
| Custom Q1 (e.g. "why are you interested") | from why_i_fit.txt or analysis.md |
| Visa: right to work without sponsorship now? | Honest answer (varies by user) |
| Visa: future sponsorship needed? | Honest answer — never lie |
| Salary expectations | from Phase 1 research, range not single |
| Earliest start date | "Negotiable, ideally within X weeks" |
| Where did you hear about us | "<company> careers page" or "<job board>" |
Common ATS custom-question patterns:
- "Do you have prior X experience?" → answer honestly. "No" is fine if JD waives it.
- "Please expand on X experience" (often required even if previous answer was No) → use adjacent-evidence framing: "I haven't done X formally, but here's the closest work — [3 concrete bullets from experience bank]"
- "What excites you about 's mission?" → tie user's specific angle to something verifiable about the company. Cite a recent post, blog, talk, or feature. Never generic.
Hand off: wait for user to click Submit. Don't simulate it. Don't auto-fill fields like "voluntary self-identification" demographics — those are user-only.
Phase 5 — Track
Run when: user says "submitted" / "applied" / "投了".
Steps:
- Append row to
applications/_tracker.md:
| <date> | <company> | <role> | <channel> | 📤 submitted | <folder> | <follow-up TBD> |
- Schedule mental follow-up reminders:
- T+24h: LinkedIn DM to hiring manager / recruiter (if not already sent)
- T+1 week: status check — if no response, optional second-touch DM
- T+2 weeks: move to "no response" if still nothing
- Propose immediate next-best application from the tracker's pending / Wave backlog.
Tracker status legend:
📤 submitted · 👀 under review · 📞 phone screen · 💬 onsite · ✅ offer · ❌ rejected · 🚫 withdrew · ✏️ draft
Phase 6 — Outreach (LinkedIn / cold email)
Run when: user says "follow up", "DM", "冷启动", or T+24h after a submission.
Steps:
- If application folder has
linkedin_dm.txt, use it as base.
- Locate 1–2 specific people via WebFetch on
linkedin.com/company/<company>/people if accessible, otherwise tell user to search manually for hiring manager / recruiter / employees in similar roles.
- Customise hook per person: cite a recent post, talk, blog, or feature they shipped. Never use generic hooks ("I love your mission", "Saw your impressive profile").
- ≤60 words, no emoji, no "hope this finds you well".
For cold outreach to companies with no posted role (e.g., adjacent-product founder approach):
- Talent pool form first
- LinkedIn DM to founder / Head of
- Email careers@ CC
- Lead with the angle no one else has (e.g., "I shipped — same space, different wedge — here's what I learned about [retention / pricing / onboarding]")
Phase 7 — Learn + Backport
Run when: user gives review feedback during Phase 3, OR after a meaningful event (rejection feedback, recruiter call insight, interview signal).
Steps:
- Apply the edit to the current application files (Phase 3).
- Backport the rule to the right place so it persists:
- Reusable writing rule →
memory/feedback.md
- Master CV improvement (not application-specific) →
cv_master.tex
- Project-bullet variant fix →
experience-bank/<project>.md
- Template improvement →
templates/*.md
- After backport, the next Phase 2 invocation should produce drafts that already have the fix applied.
Don't: silently swallow user feedback. Each polish should leave a trail in either memory or the bank.
Cross-phase hard rules
- Never auto-submit. The Submit button is always the user's. Even with browser automation, stop before clicking Submit.
- Never invent metrics. No churn rate, retention %, MRR, MAU unless user has confirmed.
- Never overclaim measurement frameworks. Don't say "cohort review", "funnel analysis", "retention model" unless user has actually built one.
- Master CV is canonical. Per-application work always copies + edits a copy in
applications/<x>/. Never modify master directly via Phase 2 / 3.
- 1 page CV always (or whatever convention
config.yaml's cv_format.length specifies — UK convention is 1 page; US allows 2 for non-junior; academic CV is multi-page). Verify with pdftotext -bbox-layout cv.pdf - | grep -c '<page'.
- Cite something verifiable for "why this company" — recent funding, blog post, talk, feature. Not generic praise.
- Visa honesty. Form questions about authorisation and future sponsorship are answered honestly per the user's status.
- Tracker is source of truth. Every submission goes in
_tracker.md.
- Sub-agent for research, not WebFetch. Glassdoor / LinkedIn block; multi-source triangulation is sub-agent work.
- Phase order matters. Don't skip Phase 3 (review) to go straight Phase 2 → 4. Always pause for user critique.
Quick-reference flowchart
User input → state detection
│
├─ First time / no master CV ───────────────→ Phase 0 Bootstrap
├─ "what to apply to" ──────────────────────→ Phase 1 Research (sub-agent)
├─ JD URL / text pasted ────────────────────→ Phase 2 Tailor (cv-tailor)
│ └→ always Phase 3 Review
│ └→ Phase 4 Submit walkthrough
│ └→ user clicks Submit
│ └→ Phase 5 Track
│ └→ propose Phase 6 Outreach
├─ user critiqued draft ─────────────────────→ Phase 7 Learn + backport
├─ "follow up / DM" ────────────────────────→ Phase 6 Outreach
└─ "this week's status" ────────────────────→ Phase 5 review tracker
Notes for adopters
- Customise
memory/feedback.md aggressively. The skill's value compounds over time as your writing rules accumulate. After 3 applications, your feedback.md should have rules specific to YOU that the generic version doesn't.
- After ~5 applications, scan
_tracker.md for callback patterns. Roles that get callbacks → double-down. Roles that don't → diagnose materials or stop.
- After first phone screen, capture insights in a new memory file like
interview_signals_<company>.md — use them for subsequent applications at peer companies.
- Sub-agent dispatch in Phase 1 burns tokens. Run it once per ~10 candidate companies, not once per 1.
See docs/customization.md for guidance on adapting to: different markets (US / EU / APAC), different career stages (senior / career-changer), different industries (consulting / banking / academic), different output formats (Word / Google Docs / Markdown).
