job-hunter-team

Extract the company logo for a company in the companies table and store it as a small base64 data-URI (max ~35KB, min 32px). Primary path is fully automated via logo_fetch.py against the official website (apple-touch-icon → icon → og:image → favicon); when the site blocks bots or has no usable icon, find a direct logo image URL via web search and pass it with --from-url. Verify the website really belongs to the company BEFORE fetching. Sets companies.logo, logo_source, logo_fetched.

Lo sweep di manutenzione INFRA del Mantenitore 👷‍♂️ (gemello del Dottore, scope infrastruttura non agenti). Una passata giornaliera one-shot: canary di liveness dei processi salva-vita del container (bridge/daemon/watchdog) via process_health.py, smoke-test dei tool mission-critical (browser/LinkedIn) via tool_health.py, audit/consolidamento deps fuori standard, GC di script e tmp orfani, de-dup di script ricorrenti, freschezza deps, trend disco/RAM. Single-writer: il Mantenitore è l'UNICO che ripara l'infra; le azioni DISTRUTTIVE (delete/archive) le PROPONE, il Capitano decide. Esito in append su mantenitore-logbook.jsonl.

Doctor-only. Context-refresh round: for each agent session read its real context occupancy (provider client-side command, zero tokens) and refresh ONLY sessions whose context window is >50% full — do a retrospective (capture + interview + analytics), append a dense synthesis to the growing daily journal, then KILL + recreate + resume the session with continuation context, so its context window is cleared without losing where it was. Runs 2× per work window (at +30min and at mid). Skips fresh, low-context (≤50%), and Capitano-parked sessions.

Run the mandatory 3-round CV review loop with the Critico — autonomously, without going through the Capitano. For each round you spawn a FRESH `CRITICO-S<N>` session (same N as your Scrittore session: SCRITTORE-2 → CRITICO-S2), send PDF + JD, wait for the structured verdict, kill the Critic, correct the CV, regenerate the PDF, and start the next round with another fresh instance. Three rounds are non-negotiable — neither 1 nor 2. After the 3rd round, gate: `critic_score ≥ 5` → `ready`, else `excluded`. Owned by the Scrittore.

DB + filesystem contract every Scrittore follows when taking a position from `scored` (≥50) to `ready`/`excluded`. Three gates BEFORE writing a single line of CV (anti-rewriting, anti-collision, link verification), one canonical path for deliverables, one final gate after the 3rd Critic round. Skipping any of these produces duplicate work, overwrites another Writer's claim, or — worst — pushes an `excluded`-grade CV to the user as `ready`. Owned by the Scrittore.

Insert NEW records into the JHT DB (positions / scores / applications / companies / position_highlights). Use it ONLY when an agent needs to create a record — Scout for positions, Analyst for companies and highlights, Scorer for scores, Writer for applications. Never blind-overwrite — for updates use `db-update`.

Query the JHT SQLite DB (positions, applications, stats). Use it whenever you need position status, per-agent queues, scores, match rate, or record counts. DB path from $JHT_DB, fallback /jht_home/jobs.db.

Convert UTC timestamps to the user's timezone before showing them in chat, charts, Telegram, or any user-facing output. Use this helper whenever you would otherwise write a raw `strftime("%H:%M")` of a UTC datetime in something the user reads.

Maintain `$JHT_HOME/profile/candidate_profile.yml` — the structured candidate data the entire team consumes. The frontend polls this file every ~2s; an invalid YAML makes the user's left panel go silently blank. Owned by the Assistente. Use this skill on EVERY new piece of information from the user (text or uploaded file): write incrementally, validate immediately, talk to the user only after the validator says VALID_PROFILE. Also covers `ready.flag` (the unlock for the "Vai alla dashboard" button) with its strict 3-step verify-then-announce protocol.

Stima salariale gerarchica per il Scorer (bug

Spawn a JHT team agent (Scout, Analista, Scorer, Scrittore, Critico, Assistente, Capitano-2) via the launcher, then deliver the kick-off message that actually starts its main loop. Captain-only — the Captain is the single owner of team scaling. ALWAYS use this skill: bypassing `start-agent.sh` with `tmux new-session` + raw `send-keys "kimi ..."` produces sessions where the CLI never boots (`command not found`), the Captain sees a "live" session that is actually dead, and the team silently underperforms.

Deliver a message to another agent's tmux session atomically. ALWAYS use this to communicate with SCOUT/ANALISTA/SCORER/SCRITTORE/CRITICO/SENTINELLA/CAPITANO. NEVER call `tmux send-keys` by hand — Ink-based TUIs (Codex, Kimi) lose the Enter character.

Send a message to the user via Telegram (outbound). Use this on the Telegram bridge — the user is on their phone, NOT in front of the web dashboard. Wrapper `jht-telegram-send` resolves bot token + chat_id per-agent from config (`--from assistente|capitano|mentor`); never call the Bot API directly.

The Critic's full review protocol — receive PDF + JD, run a blind review (no profile access), produce a structured verdict with score 1-10 + 7 fixed sections + JD-vs-CV table + prioritized actions, save the file under `$JHT_USER_DIR/critiche/`, notify the spawning Writer, stop. Owned by the Critic. The whole point of "blind" — you must NOT read the candidate profile; you only know what is on the PDF in front of you. Anchoring bias from prior knowledge would break the 3-round protocol the Writer relies on.

Write the CV markdown that will be PDF'd and reviewed by the Critico. First read the user's ORIGINAL CV in `$JHT_HOME/profile/sources/` to mirror their voice and match the register to the industry (the tech defaults — "Technical Skills: Python", metric+tech-in-parens — are wrong for hospitality/sales/care/creative). Six fixed sections, max 2 pages, every claim traceable to `candidate_profile.yml`/sources (zero invenzioni — T10). Languages appear ONCE (Header only). Cover Letter only if the JD explicitly asks, with its own "Cover Letter" title (never "CV"). Owned by the Scrittore. Pair with `application-flow` (claim + path) and `critic-loop` (review iterations).

Daily handoff diary for the Captain. The Captain is restarted often (context-refresh, new work window, reboot) and otherwise loses the day's hard-won pacing lessons — repeating the same mistakes (e.g. 3 Scouts at once → an unbrakable spike → a 5h coast to repay the debt). Read the PREVIOUS day's notes at startup (handoff), and APPEND a one-line note whenever something significant happens during the day (a scaling decision, a spike, a kill, a lesson). One append-only file per day.

Read the rate-limit budget snapshot for the active provider (usage %, time-to-reset, velocity, projection, recommended throttle) from the bridge. Use it at Captain startup to plan pace and decide how many agents to spawn, then periodically when you want a fresh snapshot without spending tokens calling the provider directly. Zero provider calls — reads the latest tick already written by the bridge.

Calibrazione graduale del roster — misura il burn di 1 worker, calcola quanti worker e con quale throttle servono per centrare la velocità-target, e spawna a scaglioni (mai in 6ª marcia).

Reply to the user when they message you from the JHT web chat. The user reaches you with the prefix `[@utente -> @capitano] [CHAT] <body>`; reply ONLY with `jht-send` — never write to `chat.jsonl` by hand (shell quoting breaks the JSON line and the frontend silently drops the message, the user sees nothing while you think you have answered). Use this skill on every `[CHAT]` message; do NOT use it for inter-agent traffic (that's `tmux-send`).

When a mission-critical tool fails, NEVER degrade silently or report "queue exhausted"/new=0. Classify broken-vs-empty, then climb the fallback ladder — auto-repair via jht-install, retry, alternative method, mark OPEN_UNVERIFIED, escalate to the Capitano with the exact fix. Use whenever a tool you depend on (browser, linkedin_check, a fetch, a CLI) errors or a dependency is missing.

Reference table mapping `proj` (projected usage at reset) to a Sentinel state and a throttle level (0-4). Use it every tick AFTER you have a fresh sample to decide which order to send to the Captain.

Day-start sourcing dalla casella email DEDICATA del team (l'utente vi inoltra i propri job alert). Sorgente a più alta accuratezza: l'alert è già pre-filtrato sull'intento dell'utente. Poll IMAP di QUALSIASI piattaforma (LinkedIn/Glassdoor/Indeed + board nazionali/di città/di nicchia), crea posizioni col tag source, idempotente per Message-ID. Il VOLUME lo bilancia il Capitano (C-16): a inizio giornata si legge l'email PRIMA dello scraping web; su flood si ingeriscono solo le salienti, così il funnel arriva allo SCORE.

Capitano — gestisce un agente sospettato BLOCCATO IN UN LOOP ATTIVO (vivo e che genera turni, ma ripete lo stesso ciclo senza produrre: ping-loop di ACK con un peer, stessa azione/query a vuoto). Copre la crepa fra C-08 (morto/silenzioso → Dottore) e C-12 (brucia con cadenza 0.00/min → kill). Scala graduata Dottore-FIRST → kill+respawn-pulito solo se persiste o brucia budget. Rilevamento deterministico (capture-pane diff + 0 avanzamento DB), decisione di escalation all'LLM.

Verifica se un annuncio di lavoro è ANCORA APERTO senza falsi-aperti. Sostituisce il curl ad-hoc (HTTP 200 = "aperto") che NON vede l'expiry renderizzato in JavaScript (Ashby/Workday/Greenhouse) né l'authwall LinkedIn (200 anche per i chiusi). Usala SEMPRE nel recheck; non marcare mai is_open a mano da un solo HTTP 200.

Update existing records in the JHT DB (positions / applications). Use it to promote positions to checked/excluded, write Critic score/verdict, mark applications as sent, update salary, last-checked, etc. Always after a `db-query` that confirms the current record state.

Estrae deadline dal JD (helper deadline_extract) e produce alert utente quando una candidatura READY sta per scadere (helper expiration_alerts, idempotente). F-4 task

Standardize positions.location free-text into structured loc_*/work_*/role_family columns BEFORE marking any position as `checked`. Covers 10 special cases (Europe Remote, Italy+remote, multi-location, US-entity-in-EU). Enforces one-position-at-a-time, peer-aligned vocabulary, never-NULL work_country. Use whenever the Analyst is about to set status=checked on a position.

Notify the user with automatic fallback. Tries Telegram first; if the bot is not configured / unreachable / rate-limited, the message lands on the web dashboard via cloud sync instead. Always records the message in `pending_user_messages` so nothing is lost. Use this whenever you need to reach the user with a status update, a question, or a digest — never call `jht-telegram-send` directly for that purpose.

Single source of truth dello SCHEMA del candidate_profile.yml — il formato canonico che TUTTO il team produce e consuma. Modello a 3 livelli: core congelato + blocchi standard + blocchi custom liberi. Definisce i 6 `kind` di blocco che il web sa rendere e la regola di governance (nessun agente inventa il formato). Ogni write del profilo va validato con `jht profile validate`. Riferita da profile-yaml, onboarding-flow, parse-cv, cv-structure.

Strato web-access cross-provider per gli Scout (F-2). 5 componenti coordinati — anti-bot robust scrape, LinkedIn session + search, email IMAP poll, multi-Scout workspace claim, freshness focus. Usato come stack base per ogni sweep: lo Scout sceglie il livello di accesso più leggero che funziona, e sale solo quando bloccato.

Read user replies that arrived via the web dashboard (fallback channel when Telegram was down/not configured). Run this at the top of every loop iteration. The tool returns the unseen replies for YOUR agent and marks them as seen so you don't process them twice. This is the "marker prompt-injection" half of the notify-user pattern (decision 2026-05-13).

Conversational protocol the Assistente follows to onboard the user — first message, iterative one-question-per-turn pacing, blocking checklist (the floor that unlocks the dashboard) vs rich checklist (what makes Writers actually useful), settore-agnostic question style (NEVER assume IT), and the mandatory checkpoint sequence when the user uploads files. Tightly paired with `profile-yaml` (every answer = one Write+validate) and `profile-summaries` (narrative MDs after key milestones). Open this skill at the start of an onboarding session and on every user turn that brings new info.

Write the 4 narrative Markdown summaries under `$JHT_HOME/profile/summaries/` that complement the structured YAML. The Writers downstream NEED these — a YAML alone produces sterile CVs because it has no voice, no narrative, no positioning. Owned by the Assistente. Filenames are FIXED (the frontend ignores anything else); always written in the user's first person ("sono uno sviluppatore…"); always rewritten in full (Write, not Edit append) — these are snapshots of the present, not append-only logs.

Check provider usage via HTTP fast path (~2s, zero CLI tokens). PRIMARY action when the bridge fails to read usage. Falls back to `check-usage-tui` if HTTP returns RATE_LIMIT or fails.

Check provider usage via TUI worker (~30s, costs CLI tokens). FALLBACK when `check-usage-http` returns RATE_LIMIT or fails. Spawns an ephemeral tmux session, runs `/usage` (or `/status` for Codex), parses the modal, kills the session.

How to handle rate-limit emergencies and the FATAL cascade when the bridge goes blind. Includes the cooldown-bypass triggers, the L4-SOFT/L5-HARD recovery path, and the RESET SESSIONE handling on a >30-point usage drop.

State variables the Sentinel must keep across ticks (last order sent, freeze flag, FATAL streak, per-state counters, emergency history, cooldowns). Use this skill on every tick to update memory and decide if a new order is required (edge-triggered).

Templates for the orders the Sentinel sends to the Captain. Use this skill whenever you decide to notify the Captain — pick the matching template, fill in the placeholders, send via `jht-tmux-send`.

Drain pending bridge verdicts at the START of every Captain turn — MANDATORY first action before doing anything else. During a long turn, `jht-tmux-send` from the bridge can fail with rc=3 (text never appeared in the pane) and a `[BRIDGE PACING]` or `PIPELINE STALLED` verdict gets silently dropped. The bridge appends EVERY verdict to a JSONL mailbox so you can recover them. Skipping this drain means acting on stale measurements while a fresher verdict sits unread.

Translate a `[BRIDGE PACING]` 15-min calibration tick into per-agent throttle adjustments. The bridge measures the team's actual rate of consumption and gives you a verdict (SFORO / MARGINE / ALLINEATO) plus the per-agent share + cadence needed to choose WHO to slow down and BY HOW MUCH. Open this skill ONLY when a `[BRIDGE PACING]` line lands; the routine `[SENTINELLA]` orders use a different flow (`sentinel-orders`).