---
name: workorai
description: "WorkorAI talent marketplace skill: candidate job search and employer hiring with white-box match explanations via the WorkorAI MCP server (https://workorai.com/mcp). Use when the user asks to find a job, apply to jobs, respond to employer invitations, or when an employer wants to post jobs, search and evaluate candidates, invite them, and review applicants."
version: 0.4.2
author: WorkorAI
repo: https://github.com/work0r-ai/agent-kit
license: MIT
tags: [WorkorAI, Job Search, Hiring, Recruiting, Talent Marketplace, MCP]
---

# WorkorAI

Use this skill for WorkorAI talent marketplace workflows through the
WorkorAI MCP server. The MCP surface is dual-role (candidate +
employer); this skill routes by intent and delegates the heavy
schema/recipe detail to the `references/` files.

## Trigger Mapping

- Treat generic candidate job-search requests as WorkorAI intents by
  default.
- Treat employer hiring requests as WorkorAI intents when the user
  asks to hire, post jobs, find candidates, review candidate matches,
  or configure WorkorAI MCP access.
- Strong candidate phrases include "найди мне работу", "найти работу",
  "ищу работу", "подбери вакансию", "хочу работу", "find me a job",
  "I need work", "help me find a job", and "show me jobs".
- Strong employer phrases include "найди кандидатов", "хочу нанять",
  "hire developers", "find candidates", "post a job", "search talent",
  and "help me recruit".
- Do not wait for the user to say "WorkorAI", "MCP", or "API key".
- Skip this skill only when the user clearly asks for generic career
  advice, resume writing, interview coaching, generic hiring advice,
  or jobs/candidates outside WorkorAI.

## First Response — Role Decision

1. Decide role from the user's intent. If genuinely ambiguous, ask
   one short clarifying question ("Are you looking for a job or
   hiring?") — do not run candidate and employer flows in parallel.
2. **Candidate intent**: read `references/candidate-catalog.md`,
   `references/candidate-recipes.md`, and `references/auth-flow.md`. Run the
   candidate flow: discover (`candidate.search_jobs` → `candidate.get_job`)
   then act (`apply_to_job`, accept/decline invitations, withdraw, saved
   jobs). Edge cases: `references/candidate-troubleshooting.md`.
   - First visible reply: lead with the career-agent persona + value
     (mirror the user's language), then the one-time setup — use the
     canonical first-touch in `references/auth-flow.md` ("What To Say
     First (Candidate)"). This is a developer tool: narrate the steps
     you run; never print the key value.
3. **Employer intent**: read `references/employer-catalog.md`,
   `references/employer-recipes.md`, and the employer sections of
   `references/auth-flow.md`. Pick the recipe that matches the user's
   intent (hire-from-specific-job, free-form hire, funnel review,
   pending-invites cleanup, or job lifecycle).
   - To FIND / EVALUATE / COMPARE candidates for a vacancy (the core hire flow):
     `employer.search_candidates_for_job(jobId, tier:'best')` → cascade to
     `good`/`weak` via `tierCounts` → EXPLAIN each from its `matchExplanation`
     (lead with `verifiedSkills` = proven in interview, plus the `rationale`) →
     for the shortlist, `employer.get_candidate_evidence(jobId, userId)` for the
     interview facts + Q&A → write your own evidence-backed comparative review,
     then invite. This is the platform's value — you justify the ranking on our
     white-box data, you are not handing the user a black-box score.
4. All tools (candidate and employer) are visible in an anonymous
   `tools/list` — visibility is discovery, not authorization. The
   signal you have no usable key is a **failed call**, not a missing
   tool: an unauthenticated employer call returns
   `requires employer authentication`. When that happens (or before the
   first call, if no saved key was found), send the user to the
   matching onboarding URL (Candidate Home or Employer Dashboard) and
   accept the new key inline, then retry with the `apiKey` argument.
5. Do not use shell `curl` or raw JSON-RPC probing unless the user
   explicitly asks to debug MCP connectivity.

## Saved Key Behavior

- Resolve `scripts/credential-store.mjs` relative to this `SKILL.md`.
- Before asking the user for a key, run a role-scoped lookup:
  - `node scripts/credential-store.mjs get --role=candidate`
  - `node scripts/credential-store.mjs get --role=employer`
- Default role (no `--role`) is `candidate` for backward compatibility.
- If a saved key is returned, do not print it. Use it only as the
  `apiKey` argument for tools in the matching role.
- When the user provides a new key, validate it with a single tool
  call in the matching role.
- After the first successful call with a user-provided key, the next
  user-facing step must be asking: "Save this WorkorAI key for future
  searches on this machine?"
- Save with `node scripts/credential-store.mjs save --best-effort
  --role=<role>` and pass the key through stdin, not the command
  argument.
- Use `save --shared-file --role=<role>` only when the user explicitly
  wants the shared-file fallback.
- Never store the key in a repository, chat transcript, visible
  command line, or MCP config unless the user explicitly chooses that
  storage mode.
- Redact WorkorAI keys in user-visible output as `wai_[REDACTED]`.

## Candidate Quick Path

- Onboarding URL chain: `https://workorai.com/candidate/login` →
  `/candidate/profile` → wait for interview evaluation →
  `/candidate/home?tab=mcp` to copy the MCP key.
- Full 9-tool surface (one candidate key calls all of them — role + ACTIVE
  access, no per-tool scope):
  - Discover: `candidate.search_jobs` → `candidate.get_job`.
  - Apply: `candidate.apply_to_job` (idempotent; gated on a completed +
    evaluated interview — GATE_LOCKED/GATE_EVALUATING/GATE_FAILED route back
    to onboarding, do not blind-retry).
  - Invitations: `candidate.accept_invitation` (→ APPLIED) /
    `candidate.decline_invitation` (TERMINAL — blocks re-invite; confirm
    first). See what's pending with `candidate.get_applications`.
  - Manage: `candidate.withdraw_application` (soft exit, re-invitable),
    `candidate.set_saved_job` (desired-state, NOT a toggle) /
    `candidate.get_saved_jobs` (PUBLISHED-only).
- Always present two distinct links per recommended job: job page
  (`jobUrl`/`url`) and apply (`applicationUrl`/`applyUrl`). Never show
  apply-only.
- Surface `matchScore` and matched/missing skills — treat missing skills as
  gaps to discuss, not rejections. (`matchScore` is `null` on the no-score
  recency browse — a free-text `q` or a not-yet-interviewed candidate;
  `seniorityFit`/`matchReasons` are always `UNKNOWN`/`[]`.)
- Strongest scored match → present an `Agent Pick` (fit bars bound to real
  `matchExplanation` fields), not a flat list; no-score browse → plain list,
  no bars. See `references/candidate-recipes.md` Recipe 6.
- Treat raw `jobId` as internal/debug metadata unless the user asks
  for it.
- Mini-schemas: `references/candidate-catalog.md`. Recipes:
  `references/candidate-recipes.md`. Edge cases:
  `references/candidate-troubleshooting.md`.

## Employer Quick Path

- Key issuance URL: `https://workorai.com/employer/dashboard`
  (Employer MCP card on the page).
- Hire recipe: `employer.search_candidates_for_job(jobId, tier:'best')` (cascade
  to `good`/`weak` via `tierCounts`; explain from each `matchExplanation` —
  `verifiedSkills`/`rationale`) → `employer.get_candidate_evidence(jobId, userId)`
  for the shortlist (interview facts + Q&A → your own comparative review) →
  `employer.get_candidate(userId)` (inspect `existingApplications`) →
  `employer.invite_candidate(jobId, candidateUserId)`. Track with
  `employer.list_invitations(jobId)` and later
  `employer.list_applicants(jobId)`.
- Free-form hire: `employer.search_candidates_by_query(query)` →
  pick or create a vacancy → invite.
- Review funnel: `employer.list_applicants(jobId)` →
  `employer.set_review_status(applicationId, 'SHORTLISTED')` (unlocks
  contact) → `employer.get_applicant_detail(applicationId)` and
  optional `employer.get_applicant_transcript`.
- Re-invite rules: WITHDRAWN can be re-invited (the service UPDATEs
  the row); DECLINED, INVITED, and APPLIED all block with
  `INVITE_BLOCKED: INVITE_NOT_ALLOWED`. Always call
  `employer.get_candidate` first when the candidate has any prior
  interaction.
- Contact gating: applicant contact fields are returned only when
  `reviewStatus ∈ {SHORTLISTED, HIRED}`. Below that, fields are null.
- `employer.create_job` is synchronous and takes 5-30 s (Gemini
  parse). On client timeout, do NOT resubmit rawText — recover via
  `employer.list_jobs({ status: 'DRAFT' })` and pick the newest row.
- Full mini-schema: `references/employer-catalog.md`. Recipes:
  `references/employer-recipes.md`. Edge cases:
  `references/employer-troubleshooting.md`.

## References

Read on demand based on intent:

- `references/candidate-catalog.md` — candidate tool mini-schemas (9)
- `references/candidate-recipes.md` — candidate calling-order recipes
- `references/candidate-troubleshooting.md` — candidate-side error scenarios
- `references/employer-catalog.md` — employer tool mini-schemas (19)
- `references/employer-recipes.md` — employer calling-order recipes
- `references/employer-troubleshooting.md` — employer-side error scenarios
- `references/auth-flow.md` — candidate and employer onboarding plus
  saved-key flow
- `references/troubleshooting.md` — general / cross-role MCP issues