14174/job-search-assistant

Job Board Monitoring and Resume Filling

Entry Points and Modes

• First determine whether the user's request falls into one of two independent modes; filling does not depend on monitoring being configured.
  • Monitoring Mode: Read monitoring workflow, job matching rules, and data structures. When external sending is involved, also read privacy and confirmation boundaries.
  • Filling Mode: Read resume filling workflow, data structures, and privacy and confirmation boundaries. When interacting with an ATS, also read ATS adaptation spec.
• If the user explicitly requests creating an archive, monitoring, or filling, and the project lacks a .jobhunt/ directory, you may initialize an empty structure. Do not initialize solely for capability inquiries.
• Before any initialization, standalone archiving, or reading/writing archives, first read data structures.
• First extract facts from the user's existing resume, write them into a structured archive, and record the source of each field. Only reference the existing resume; do not generate, polish, rewrite, or fabricate resume content.
• When sources conflict, required fields are unknown, or an answer is not applicable, ask one question at a time addressing the most impactful unknown. Record the source, date, confirmation status, and applicability of each answer.
• Matching rules for majors, education, location, skills, time, etc., must all be confirmed by the user. If not configured, only provide suggestions and do not start monitoring. Unknown fields are not treated as non-matching.

Monitoring Boundaries

• Only access exact domains and path ranges that the user has manually added with enabled=true and confirmed=true. Re-verify the scope after each navigation or redirect; stop and report if the scope is exceeded.
• Monitoring runs independently. Extract job postings within the confirmed publication time window, retaining the original source, job identifier, requirements, dates, and evidence. Mark missing or ambiguous dates as pending verification; do not fabricate.
• Deduplication and writing follow the identity priority and minimal patch rules in the reference documents; call upsert_job.py serially. External links are only recorded as pending and do not expand the scope.
• Each scan report must cover the actual scope covered, new/matched/excluded items with reasons, company pool changes, failures, and items pending user action. Do not report "no new items overall" when coverage is incomplete.
• Use currently available Codex automation tools only when the user explicitly requests scheduling. Do not create persistent services or cron jobs. If there are no changes, remain silent per the reference workflow.

During monitoring, maintain a single-writer order: first check scope, then extract, verify dates, deduplicate, match, and finally write and report. If any step has insufficient evidence, preserve what has been done and mark the incomplete scope. Job matching output must distinguish between "confirmed match", "confirmed not match", and "unknown/pending verification", preserving the original job requirements, user fact sources, and exclusion reasons. Without user-confirmed scoring rules, provide only qualitative explanations. The company pool can be populated manually by the user or discovered from matching jobs, but adding a company to the pool does not automatically add it to the monitoring scope. Company websites, ATS tenants, and external links must each be verified independently.

Filling, Saving, and Submission Boundaries

• First verify the target company, website ownership, and ATS tenant. Use the browser/skill tool specified by the user and currently available; do not assume tool existence. PDF/document parsing can only call the currently available corresponding skill.
• The user must perform login, CAPTCHA, and other authentication themselves. Do not save passwords, cookies, OTPs, tokens, financial, or other authentication materials, nor bypass authentication or force-controlled pages.
• Before filling, only read the necessary archives for this task, applicable answers, and the user-specified resume version. For any ordinary field, highly sensitive field, or attachment before the first send, display the current specific destination, intended content/sanitized summary, source, and action, and obtain explicit confirmation.
• After explicit confirmation for the current transaction, you may overwrite the filling, uploading, automatic page saving, and independent company resume saving specified for that transaction. Scope changes require re-confirmation; authorization is not permanent and cannot be reused across companies or tasks.
• Saving a company resume is an allowed independent action, but requires confirmation for this session. After saving, read back the page fields, success indications, or other reliable evidence. Without evidence, only mark as unverified; do not falsely claim success.
• Never click job application, submission, or final submit buttons. Even buttons combining "Save and Submit" must not be clicked; always leave submission to the user. Filling/uploading/saving successfully does not equal successful submission.
• On widget, login, or field failures, use only limited and reliable methods. Stop at the failure point and report missing fields, obstacles, and progress made; do not repeatedly overwrite or erase drafts.

The filling report must distinguish per item: filled, uploaded, saved with evidence, unverified, and failed. Saved status can be recorded as "pending user submission", but must not be recorded as submitted unless the user personally performs the action and provides reliable evidence. If the page auto-saves or button meaning is unclear, stop the action and explain the specific risk. Do not substitute historical authorization, identical company names, or "this is usually the case" experience for current confirmation.

ATS Interaction Routing

• For ATS interaction, simultaneously read the ATS adaptation spec and the currently available browser skill/tool documentation. For untested systems, only record historical experience; do not claim compatibility.
• Locate controls by visible labels, semantics, and container context. After input, read back the result. If control ownership is unclear, date options are incompatible, or values are cleared, defer to the user.

Data and Privacy

• Personal state is stored only in the current project's .jobhunt/ directory. The global skill does not store personal values; a local general answer repository may store non-sensitive, confirmed answers with sources. Logs and reports must be minimized and never contain sensitive original text. Sensitive/highly sensitive information is placed only in the project private archive, read on demand, and not echoed in full within conversations or logs.
• Do not write job requirements as user facts. The resume index only references existing files; do not copy them into generic packages. .gitignore is not equivalent to encryption or access control.
• Before sharing, only check explicitly allowed skills, agents/openai.yaml, the six references, empty templates, and the four standard library scripts. Run a privacy scan, then perform manual review. Do not package personal archives, resumes, test data, caches, or project reports.
• A shared package contains only workflows and empty structures, not real names, contact information, addresses, credentials, accounts, resume content, screenshots, personal paths, or historical filling data. If found, remove or verify first.

When uncertain about the user's intent, ask only one key question that will change the mode, access scope, or authorization. Low-impact details such as naming, formatting, and directory structure are decided based on the current project state. Any completion claims must be supported by verifiable evidence such as pages, files, or script outputs.

Standard Scripts (Python 3.10+)

Command line passes only public job information, not personal data. <Skill directory> refers to the currently loaded skill directory; do not hardcode user paths.

python -X utf8 "<Skill directory>/scripts/init_workspace.py" "<project root>"
python -X utf8 "<Skill directory>/scripts/validate_workspace.py" "<project root>/.jobhunt"
python -X utf8 "<Skill directory>/scripts/upsert_job.py" "<project root>/.jobhunt/jobs.jsonl" "<job JSON>"
python -X utf8 "<Skill directory>/scripts/privacy_scan.py" "<directory to share>"

Scripts provide only mechanical guarantees such as structure and deduplication; they do not replace source, authorization, scope, and privacy judgment. This skill does not guarantee compatibility with any actual ATS and does not run persistent monitoring services. All external writes are based on the user's currently explicit scope; long-term authorization cannot be inferred from a single task. Before and after execution, verify the target, scope, action, and evidence to avoid mistakenly recording suggestions or drafts as completed.