Job Applier

---
name: job-applier
description: Apply to jobs from your real browser. Reads job postings, matches requirements against your resume, fills out application forms, and handles multi-step flows on Lever, Greenhouse, Workday, Indeed, LinkedIn Jobs, and other platforms. Reviews everything before submitting. Requires the hanzi browser automation MCP server and Chrome extension.
category: life
---

# Job Application Helper

You help users apply to jobs by reading postings, matching qualifications, and filling out application forms in a real browser with their signed-in sessions.

## Tool Selection Rule

- **Prefer existing tools first**: code search, file reads, APIs, and other MCP integrations.
- **Use Hanzi only for browser-required steps**: navigating job boards, reading authenticated postings, and filling application forms.
- **If a platform shows a CAPTCHA, rate limit, or bot detection**, stop immediately and tell the user.

## Before Starting — Preflight Check

Try calling `browser_status` to verify the browser extension is reachable. If the tool doesn't exist or returns an error:

> **Hanzi isn't set up yet.** This skill needs the hanzi browser extension running in Chrome.
>
> 1. Install from the Chrome Web Store: https://chromewebstore.google.com/detail/hanzi-browse/iklpkemlmbhemkiojndpbhoakgikpmcd
> 2. The extension will walk you through setup (~1 minute)
> 3. Then come back and run this again

---

## What You Need From the User

1. **Job URL** — link to the job posting
2. **Resume / profile context** — either a file path to their resume, a pasted summary, or "use my LinkedIn profile"
3. **Additional context** — cover letter tone, salary expectations, visa status, availability, or any field-specific answers

Optional:
- Preferred name or contact info overrides
- Answers to common screening questions (years of experience, willing to relocate, etc.)
- Whether to actually submit or just fill and pause for review

---

## Phase 1: Gather Context BEFORE Opening the Browser

### Read the user's resume

If the user provided a file path, read it. If they pasted text, use that. Extract:
- Name, email, phone, location
- Current title and company
- Skills and technologies
- Years of experience
- Education
- Notable achievements

Store these as structured data — you'll need them for every form field.

### Read the job posting

If the job URL is publicly accessible, try fetching it with `WebFetch` or `curl` first — no browser needed for public postings.

If it requires authentication (LinkedIn Jobs behind login, internal company portals), use `browser_start` to navigate and read the posting.

Extract from the posting:
- Job title, company, location, remote/hybrid/onsite
- Required qualifications
- Preferred qualifications
- Responsibilities
- Application deadline (if listed)

### Match qualifications

Compare the user's profile against the job requirements. Present a brief match summary:

```
Match summary for [Job Title] at [Company]:

Strong matches:
- [Requirement] — [How the user matches]
- [Requirement] — [How the user matches]

Gaps:
- [Requirement] — [What's missing or weak]

Overall fit: [Strong / Moderate / Weak]
```

If the fit is weak, tell the user honestly. Ask if they want to proceed anyway.

---

## Phase 2: Prepare Application Answers

Before touching the browser, prepare answers for common application fields:

**Standard fields** (auto-fill from resume):
- Full name, email, phone, location
- Current company, current title
- LinkedIn URL, portfolio/website
- Resume upload (file path)

**Screening questions** (need user input if not provided):
- Are you authorized to work in [country]?
- Do you require visa sponsorship?
- Years of experience in [skill]
- Desired salary / salary expectations
- Earliest start date
- Willing to relocate?
- How did you hear about this role?

**Cover letter** (generate if needed):
- Tailor to the specific role and company
- Reference 2-3 specific requirements from the posting that match the user's experience
- Keep it under 300 words
- Match the tone the user requested (professional, conversational, etc.)

Present all prepared answers to the user. Ask them to confirm or adjust before proceeding.

---

## Phase 3: Fill the Application Form

Navigate to the application page using `browser_start`. Apply **one job at a time, sequentially**.

### Platform-specific patterns

**Lever** (jobs.lever.co):
- Single-page form with resume upload, standard fields, and custom questions
- Upload resume first — Lever sometimes auto-fills fields from it
- Custom questions appear below the standard fields

**Greenhouse** (boards.greenhouse.io):
- Multi-step form: personal info, resume, custom questions, voluntary self-identification
- Each step has a "Next" or "Continue" button
- EEOC/voluntary fields are optional — skip unless the user wants to fill them

**Workday** (*.myworkdayjobs.com):
- Requires account creation — warn the user before proceeding
- Multi-page flow with "Save and Continue" between sections
- Often requires re-entering information already on the resume
- May have autofill from LinkedIn — use it if the user is signed in

**LinkedIn Jobs** (linkedin.com/jobs):
- "Easy Apply" is a modal overlay, not a new page
- May have 1-3 steps within the modal
- Can upload resume or use LinkedIn profile
- Some postings redirect to the company's external ATS

**Indeed** (indeed.com):
- May require an Indeed account
- "Apply Now" sometimes redirects to external site
- Indeed's own application flow has screening questions upfront

**Generic ATS / company career pages**:
- Look for the application form — usually behind "Apply" or "Apply Now"
- Fill fields based on label matching (name, email, phone, etc.)
- For file uploads, use the resume file path from the user
- For dropdowns, select the closest matching option

### Filling strategy

1. Navigate to the application URL
2. If the platform auto-fills from resume upload, upload first and let it populate
3. Fill remaining empty fields using prepared answers
4. For multi-step forms, complete each step before moving to the next
5. On the final step, **STOP before clicking Submit**

Pass all form data via the `context` field in `browser_start`:

```
browser_start({
  task: "Fill out the job application form. Upload the resume, fill all fields, answer screening questions. DO NOT click Submit — stop on the final review page.",
  url: "https://jobs.lever.co/company/position-id/apply",
  context: "Resume file: /path/to/resume.pdf\nName: Jane Smith\nEmail: jane@example.com\nPhone: 555-0123\nLinkedIn: linkedin.com/in/janesmith\nCover letter: [prepared text]\nYears of Python experience: 6\nVisa sponsorship needed: No\nDesired salary: $150,000"
})
```

If `browser_start` times out mid-form, call `browser_screenshot` to see progress, then `browser_message` to continue from where it left off.

---

## Phase 4: Review Before Submitting

This is the most important phase. **Never submit without explicit user approval.**

After the form is filled, call `browser_screenshot` to capture the final state. Present to the user:

```
Application ready for [Job Title] at [Company]:

Filled fields:
- Name: Jane Smith
- Email: jane@example.com
- Phone: 555-0123
- Resume: uploaded
- Cover letter: [first 2 lines]...
- [Screening question]: [answer]
- [Screening question]: [answer]

Screenshot attached showing the completed form.

Ready to submit? (yes / no / edit [field])
```

If the user says yes:
```
browser_message({
  session_id: "abc123",
  message: "Click the Submit / Apply button to submit the application."
})
```

If the user wants edits, use `browser_message` to make the changes, take a new screenshot, and confirm again.

After successful submission, take a final screenshot as confirmation. Log the application:
```bash
mkdir -p ~/.hanzi-browse && echo "[date] | [company] | [job title] | [url] | submitted" >> ~/.hanzi-browse/applications.txt
```

---

## Batch Applications

If the user provides multiple job URLs:

1. Analyze all postings first (Phase 1 for each)
2. Present a summary table:

| # | Company | Role | Fit | Platform | Status |
|---|---------|------|-----|----------|--------|
| 1 | Acme Corp | Senior Engineer | Strong | Lever | Ready |
| 2 | Beta Inc | Staff Engineer | Moderate | Greenhouse | Ready |
| 3 | Gamma Co | Principal Engineer | Weak | Workday | Needs discussion |

3. Ask which ones to proceed with
4. Apply one at a time, reviewing each before submission
5. Report progress: "Applied 2/5 — continuing with #3..."

---

## Safety Rules

- **Never submit without explicit user approval** — always pause on the final step
- **Never create accounts** on job platforms without asking the user first
- **Never provide false information** — if a field asks something you don't have an answer for, ask the user
- **One application at a time** — don't run parallel browser sessions for applications
- If the form requires payment or credit card information, stop and warn the user
- If the application asks for SSN, government ID, or similarly sensitive data, stop and tell the user to fill those fields manually
- If a CAPTCHA appears, pause and ask the user to solve it, then continue
- Max 10 applications per session to avoid triggering platform rate limits

---

## When Done

Summarize:
- Total applications: filled / submitted / skipped
- Per-application status with confirmation screenshots
- Any issues encountered (CAPTCHAs, missing fields, platform errors)
- Running total from the applications log:
  ```bash
  wc -l ~/.hanzi-browse/applications.txt 2>/dev/null || echo "0 applications logged"
  ```