SuperAPI AI Directory
Partner中文AI newsFavorites
Skillsjob-hunt-skill

job-hunt-skill

Office & productivity

View repository

Updated 10-16 09:30

About this skill

job-hunt-skill

Turn "help me see what jobs are available" into a job database that can be continuously searched, compared, and updated, rather than a one-off recommendation answer.

简历 / 目标方向 / 种子 JD
          ↓
搜索画像 → 查询矩阵 → 公开候选池 → 去重与证据分层
          ↓
完整 job-hunt-skill HTML 报告 → 搜索 / 筛选 / 打开职位 → 选择深评对象

Scope of responsibility

  • Responsible for batch discovery, collecting public information, deduplication, preliminary screening, evidence layering, ranking, and generating the job list.
  • By default, retain all unique positions that pass the hard criteria; do not arbitrarily compress them into a 5–10 item shortlist.
  • Do not automatically click Apply, do not fill out forms, do not send messages, and do not apply on behalf of the user.
  • Do not request or process passwords, verification codes, cookies, session tokens, or other login credentials.
  • When encountering a login wall, CAPTCHA, HTTP 429, or robots restriction, stop that access path; switch to public company career pages, public search results, or clickable query links, and do not attempt to bypass.
  • Do not expand job discovery into a complete single-position Offer Strategy. After the user selects a position, hand it over to job-description-skill。

0. Determine whether the input is sufficient

Prioritize materials the user has already provided; do not repeatedly request them:

  1. Resume: PDF, Word, HTML, or plain text are all acceptable.
  2. Target: title, level, domain, location, work mode.
  3. Optional seed JD: used to supplement position semantics; must not be used to fabricate resume capabilities in reverse.
  4. Optional existing links: used to merge, supplement, or update an old list.

If information that would significantly change the result set is missing, ask only one question at a time, in the following order:

  1. Target title / level
  2. Location and remote / hybrid / relocation
  3. Time range
  4. Industries, companies, contract types, or visa thresholds that must be excluded

Defaults are the last 30 days, full-time, and one level above and below the target level. The final report must explicitly state the defaults.

1. Build a search profile

Extract only evidence-backed capabilities from user materials to form:

target_titles: []
adjacent_titles: []
level: ""
locations: []
workplace: []
date_posted: "30d"
employment_types: ["full-time"]
core_capabilities: []
domains: []
company_preferences: []
exclusions: []
seed_signals: []

Echo the profile back to the user in no more than 8 lines. If the user does not correct it, continue execution without requiring a second confirmation.

2. Generate a complementary query matrix

Generate 6–12 sets of short queries, with only 1–2 discriminating terms in each set:

  1. Exact title: target title + location
  2. Adjacent title: adjacent title + location
  3. Capability-led: title + core capability
  4. Domain-led: title + domain
  5. Scope-led: title + scope such as platform / growth / 0-to-1 / enterprise
  6. Company-led: user-preferred companies or adjacent companies + title

Record each set's query, URL, execution time, and source. Do not cram all synonyms into one query, or jobs will be systematically missed.

3. Discover public positions

Use accessible sources in the following priority order:

  1. Specific job pages or official company career pages
  2. Publicly accessible LinkedIn job pages and search results
  3. Search engine site:linkedin.com/jobs/view results
  4. Other public job posting pages

For each candidate, collect as much as possible:

  • title
  • company
  • canonical URL / job id
  • location and workplace
  • posted date / age
  • salary, recorded only when explicitly shown on the page
  • JD visibility level: full / partial / unavailable
  • source and checked_at

Deduplicate by canonical job id / URL. When there is no id, use normalized company + title + location, and keep the record with more complete evidence and a newer update time.

Stop conditions:

  • the full query matrix has been run; or
  • the first 2 pages / first 25 items have been checked for each group; or
  • the current source triggers access restrictions.

Do not keep jobs that clearly violate location, level, employment type, or hard requirements just to pad the count.

4. Strictly distinguish facts from inferences

Read references/evidence-ranking.md, and mark the evidence status for each field:

  • verified: appears directly on the job page or official page
  • partial: visible in a public summary, but the full JD is not visible
  • inferred: inferred from title, company, or nearby signals
  • unknown: no reliable information

Leave unknown fields blank or display "pending verification". Never fill in salary, posting date, work mode, visa policy, job status, or JD requirements.

5. Sort, but do not delete the full candidate pool

First pass the hard conditions, then sort by two levels:

  1. Jobs with the full JD read: use 0.60 Must Have + 0.20 Nice to Have + 0.20 Hidden Signal Fit to calculate the match range.
  2. Jobs with incomplete JDs: perform only directional sorting, and do not display a falsely precise match score.

Sort order: evidence completeness → match strength → posting date → closeness to the target direction. A missing posting date must not automatically be treated as an old job.

Priority fields may be kept internally for sorting and filtering, but by default do not display Tier A / Tier B labels in the job rows. Display them only when the user requests it.

6. Generate a single-file HTML

Generate HTML by default, not Markdown. Read assets/report-spec.md and follow its data, table, and interaction contract.

Filename:job-hunt-skill-{candidate-or-topic}-{YYYYMMDD}.html

Save to the user-specified directory by default; if unspecified, save to the current working directory. After generation, open the local file for the user to check.

The report must include:

  • search profile, generation time, sources and evidence notes
  • total unique job count, deep verification count
  • search box and quick filters
  • job, company, domain tags, recommendation reason, main Gap
  • verifiable posting date, location / work mode, salary, match score
  • open link pointing to the specific job
  • query log and access restriction notes

Do not expose the full local resume, login information, or unrelated personal data on the page.

7. Verify before delivery

At minimum complete the following checks:

  1. The HTML inline JavaScript syntax is valid.
  2. The number of rendered job rows equals the number of deduplicated data rows.
  3. Each table row has a consistent number of columns, and specific job links are validly formed.
  4. Search can match title, company, domain, reason, and gap.
  5. "Pending verification" fields have not been automatically filled in as facts.
  6. If there are domain tags, the tags are adjacent to the company name and searchable.
  7. The page does not display Tier A / Tier B badges unless the user explicitly requests it.

When browser testing tools are available, actually load the page and verify the DOM; when not available, at least perform a script syntax check and static structure check.

8. Subsequent updates

When the user provides an old job-hunt-skill report:

  1. Parse the existing job id / URL.
  2. Only add newly discovered jobs, and merge more complete evidence.
  3. Do not assert that a position is closed just because it is temporarily inaccessible.
  4. Keep the original first_seen, update last_checked。
  5. In the report, list the counts of newly added, updated, and pending review items.

Delivery format

Briefly tell the user: the save path, the number of unique positions, the number of in-depth reviews, access restrictions, and verification results. Do not copy the entire job table back into the chat.