Installs into .claude/skills of the current project.
Are you the author of Search?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/blehmaks-search)
---
name: career-search
description: Discover and screen opportunities across approved market and profession-specific resources, with duty-level matching and canonical deduplication.
---
# Search and screening
Require approved campaign briefing and general CV before campaign activation. Read current policy, completed catalogue coverage, exclusions and unresolved questions. Do not repeat an entire company sweep because a summary is stale. Record source coverage separately from pending applications.
## Discovery
Use public openings and LinkedIn/authorized mailbox alerts as initial discovery channels when relevant. Set roughly three to five approved title alerts with agreed location, language and cadence, if the person wants them. Use people/groups/programs/calls for fields where these are more effective (`profession-workflows.md`). Research other useful resources within approved classes. Capture canonical employer/institution URL, requisition/call ID, source URL, discovered time and live requirements. Prefer the official employer/institution/ATS route; LinkedIn is a discovery source, not a reason to duplicate a formal application.
Read full duties for plausible matches. A senior/lead title can be hands-on; a familiar title can hide unsuitable duties. Resolve search-card vs posting location, remote-country eligibility, mandatory language/qualifications and current opening status. Reject obvious hard-limit violations early; do not spend a full tailoring cycle first. Retain direct evidence, honest transfer, gap and unknown classifications, not made-up ATS percentages.
Read alternative qualifications as alternatives: “degree or equivalent experience” does not require both. A graduate label alone is not a recent-graduation restriction; inspect the actual eligibility window. Record explicit restrictions and their source rather than inferring new hard filters from a category name.
## Identity and prioritization
Canonical employer+requisition/call identity plus URL aliases prevents multi-city/cross-board duplicates. A second distinct requisition at one employer can be a separate opportunity. Ambiguous identity needs reconciliation before sending. Do not use row counts or employer name alone as proof of unique applications.
Queue high-value viable opportunities first using approved priorities, deadlines and evidence strength. Check employer/end-client exclusions again before submission. Source capture, screening, document readiness, form state and delivery remain separate. A blocked login does not make the vacancy unsuitable; share that blocker only over its observed scope and continue independent applications.
## Outputs
Use the SQLite opportunity/company registry and runtime queries (`docs/tracking.md`); supported commands record their own effects. Keep ongoing summaries short and derived, without a second text catalogue or model helper for logging. Before discovery, handle current employer replies, invitations and deadlines. Preserve approved broad positioning and expansion: unexpected relevant opportunities may be useful. At each runtime-created 50-submission review ask whether the direction remains appropriate; changes require confirmation and do not rewrite history.
Before rejecting a plausible opportunity for a missing key skill, reread relevant current facts/claims (or use `track evidence`). Unknown is not confirmed absence; finding a term is not proof of direct expertise. Preserve direct/transfer/unknown distinctions and avoid uncalibrated percentage scores as interview probabilities.
Keep screening reasons, evidence/gaps, source/confidence, deadline/timezone, official route and next step in the opportunity record. Report actual new submissions separately from recovered history and blocked preparation. Follow `skills/applications/SKILL.md` for execution and its scheduling instructions for recurring work.
LinkedIn account ownership does not imply automation permission or no restriction risk. Use only the approved current integration within host and platform constraints; do not evade limits or create replacement accounts after restriction.