/ai-job-scout

name: ai-job-scout
description: "Find open AI engineering jobs that fit a candidate, verify location and apply links, and assess each employer's product. Use for one-off shortlists or a job alert's research step. Don't use for résumé writing, job applications, or company news."
license: MIT
effort: high
metadata:
  version: 1.1.1
  author: "Luong NGUYEN"

AI Job Scout

Find the requested number of open roles (three by default) that match the candidate, then examine the *company and project*, not just the job ad. Research-only: never apply, contact recruiters, or change a job tracker without a separate request.

When to Use

Use when a candidate asks for an AI job shortlist, the research step of an already configured job alert, or whether the projects behind open roles are worth pursuing. The skill produces a report, not a schedule: use a scheduler only when the user asks, and never claim a schedule exists without verifying it.

Instructions

Run steps 1–4 in order. Research a company (step 3) only for roles that passed step 2. After each step, print its Step Completion Report.

Terms used throughout:

• **Verified listing:** the role's page on the employer's careers site or its ATS (Greenhouse, Lever, Ashby, Workable, and similar), opened and read on the run date. Aggregators (LinkedIn, Welcome to the Jungle, remote boards) and search snippets only help discovery; they are never a verified listing.
• **AI-central:** the listing's responsibilities make building, evaluating, securing, or operating AI/ML systems a primary duty.
• **Prior report:** an earlier report or list of listing URLs that the user supplied or that this run can open.
• **Near-miss:** a shortlisted role that failed the step 3 gate; report it with its evidence, and never rank it.

Inputs and branches

• **Candidate:** Public GitHub/profile URL and any résumé or constraints the user has supplied. If no profile is available, ask for one before any personal-fit claim. If none arrives, or no one can answer (an unattended alert run), label the search unpersonalized. Re-read the public profile on each run; do not store a biography in this skill.
• **Geography:** Build the **location rule**, the candidate's accepted work arrangements as testable conditions, from the user's work arrangement and home location. Hybrid in a city: admit a role only when its verified listing names that city and states an office-attendance policy. Fully remote: admit a role only when its verified listing says applicants in the user's country are eligible. Example: "Paris hybrid or fully remote from France" admits Paris hybrid roles with a stated attendance policy and remote roles open to France-based applicants. "Remote" with no eligible country or region is *unknown*, not worldwide. If hybrid is only inferred (for example, from where the candidate lives), label the fit conditional and ask the candidate to confirm.
• **Cadence:** If a recurring alert has a prior report, compare against it and skip repeats unless the listing materially changed. If no prior report is available, state that deduplication was not verified; do not claim every pick is new.
• **Count:** Default to three roles; use the user's count when given. Fewer qualifying roles is a valid result.
• **Format:** Write the text report by default. If the count is above five, or the user asks to filter roles (for example by salary or remote policy), read `references/interactive-report.md` and build the HTML report instead, unless the user asks for text. If HTML cannot be produced here, say so and write the text report.

1. Derive a candidate-fit brief

Read the profile and note supported seniority, projects, languages, AI specialties, adjacent domain experience, and geographic constraints with links. Distinguish observed repository code/activity from a README's self-description and from independently unverified career claims. Do not infer work authorization outside the candidate's home country, education, spoken languages, relocation willingness, or production deployment from project descriptions alone.

**Gate:** The brief records at least one source for each positive fit claim and the location rule. Missing essential constraints are listed, not guessed.

2. Discover and verify live listings

1. Search employer career pages and ATS boards for several role families that match the brief. 2. Open the verified listing for each candidate role. If the page is blocked, retry with another retrieval method or the employer's ATS endpoint, then with an interactive browser. If every method fails, reject the role. 3. Open the application form when one exists. A reachable application tab on the listing URL counts as a working apply path. 4. Record from the verified listing: title, employer, responsibilities, required seniority, location/remote eligibility (quoted), posting date or "unknown", and salary and equity or "not listed". Do not turn an old posting date into a new one. 5. Apply the hard rejects. Record each rejected role with the check it failed.

**Hard reject:** unreachable verified listing; closed or missing application; the location rule fails or remote eligibility stays ambiguous; the role is not AI-central; a junior or intern role outside the requested level; a prior report's listing with no material change.

**Gate:** Every shortlisted role has a verified listing URL and a quoted location policy that passes the location rule. Never weaken a hard reject to reach the count.

3. Research each company's product and the role's project

For *each* shortlisted role, read the employer's product/about pages, docs or engineering blog; consult independent coverage only where it adds substantiated context. Explain:

1. The product, its users or problem, and the role's documented responsibilities. Name the specific assigned project only when the listing or another employer source identifies it; otherwise label the assignment unknown. 2. Where AI actually fits in the product and