Job Search

Automatically browse job boards to find postings that match the user's profile. This skill handles navigation, search queries, result extraction, and feeds each result into the job-screener for evaluation.

Before Starting Any Search

Run the self-check skill first. Read the user's config, profile, resume, and working folder to ensure you have up-to-date information about skills, projects, and application history. This prevents duplicate applications and ensures search queries reflect the current profile.

Search Platforms

Read config.search.platforms to determine which platforms are enabled.

Handshake (if config.search.platforms.handshake: true)

Navigate to app.joinhandshake.com. User should already be logged in via their university.

Navigation:

1. Open Handshake in a Chrome tab (use tabs_create_mcp + navigate)
2. Go to Job Search: https://app.joinhandshake.com/explore
3. Use filters to narrow results

Search Queries: Use config.search.target_roles — rotate through them.

Filters to Apply:

• Job Type: config.search.job_type (default: Internship)
• Posted: Last config.search.freshness_days days
• Location: config.location.preferred_cities
• Work Authorization: Based on config.visa.work_permit_type

Extracting Job Details: For each result, use get_page_text or read_page to extract:

• Company name
• Position title
• Location + remote/hybrid/onsite
• Pay rate (if listed)
• Posted date
• Key requirements from JD
• Visa/authorization requirements

Pagination:

• Handshake shows ~25 results per page
• Check for "Next" button or page numbers
• Process all results on current page before moving to next
• Stop after 3-5 pages unless the user asks for more

LinkedIn (if config.search.platforms.linkedin: true)

LinkedIn job search at linkedin.com/jobs/.

Search Queries: Same config.search.target_roles list.

• Add filter: Date Posted → Past Week
• Add filter: Experience Level → config.search.job_type
• Add filter: Location → config.location.preferred_cities

Rate Limiting Warning: LinkedIn has aggressive bot detection. Take screenshots between actions and don't rapid-fire clicks. If you encounter a CAPTCHA or "unusual activity" warning, stop immediately and tell the user. Never attempt to bypass these systems.

Indeed / Glassdoor (if enabled in config)

These platforms can also be searched using similar patterns. Navigate to their job search pages, apply the same filters, and extract JDs. Note that Indeed and Glassdoor may have different page structures — take screenshots to verify form elements before interacting.

Run Limits (Token Usage Control)

Read config.search.max_jobs_per_run and config.search.max_apply_per_run before starting.

• max_jobs_per_run (default 10): Stop searching and scoring after this many jobs have been fully evaluated. Quick-filtered jobs (obviously irrelevant) do NOT count toward this limit.
• max_apply_per_run (default 3): In batch application mode, stop after submitting this many applications. The full cover-letter debate + form-filling pipeline is token-intensive — this prevents runaway usage.

When either limit is reached, report the count and stop:

Reached search limit: [N] jobs scored this run.
Remaining results can be searched in the next session.

The user can override by saying "keep going" or "find more".

Search→Screen Pipeline

For each job found:

1. Extract the JD text (use get_page_text)
2. Quick-filter — immediately skip if:
   • Title contains: "Graphic Design", "Mechanical", "Civil", "Chemical", "Nursing", "Accounting" (obviously irrelevant)
   • Requires: "US Citizen only", "Security Clearance", "Permanent Resident only"
   • School-specific: "Only open to [specific school] students" (unless it's BU)
3. Score using the job-screener rubric (inline, don't need to invoke separate skill)
4. Collect all scored results into a ranked list

Output Format

After searching, present results as a ranked table:

## Handshake Search Results — [Date]

| # | Company | Position | Score | Decision | Notes |
|---|---------|----------|-------|----------|-------|
| 1 | [name]  | [title]  | 9.1   | APPLY    | Strong match, CPT ok |
| 2 | [name]  | [title]  | 8.7   | APPLY    | Good fit, NYC onsite |
| 3 | [name]  | [title]  | 7.8   | ASK      | Borderline — [reason] |
| 4 | [name]  | [title]  | 6.2   | SKIP     | [reason] |
...

### Ready to Apply (≥8.5):
1. [Company] — [Position] (Score: X.X)
2. [Company] — [Position] (Score: X.X)

### Borderline (7.5-8.4) — Need the user's Decision:
1. [Company] — [Position] (Score: X.X) — [why borderline]

### Skipped (<7.5):
[count] positions skipped. Top reason: [most common skip reason]

Batch Application Mode

Respect config.search.max_apply_per_run (default 3). Each full application (CL debate + form fill) is token-heavy. Stop after hitting the limit and report remaining positions for the next session.

When the user approves the APPLY list:

1. Process each position sequentially (up to max_apply_per_run)
2. For each: check cover letter requirement → write CL if needed → fill application
3. Track progress and report after each submission
4. If any application hits a blocker (file upload, CAPTCHA, unusual form), flag it and move to the next

Search Frequency

• Default to config.search.freshness_days (typically 7 days or fewer)
• If user says "find more", run a new search with different keywords or expanded location
• Keep track of which companies/positions have already been searched to avoid showing duplicates

Duplicate Detection

Before presenting a job to the user, check:

1. Has this exact position been scored before in this session?
2. Does the company + title match anything in the Job Tracker spreadsheet in config.files.tracker_dir?
3. Has the user already applied (check cover letter PDFs in config.files.cover_letter_dir)?

If duplicate, silently skip it.