メニュー
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.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
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`.
| name | decision-throttle |
| description | 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. |
Riferimento per decidere lo stato dal proj ricevuto e il livello throttle da imporre al Capitano.
proj| Stato | Condizione proj | Ordine al Capitano |
|---|---|---|
| CRITICO | > 100% | EMERGENZA / RALLENTA forte |
| ATTENZIONE | 95-100% | RALLENTA leggermente |
| STEADY (G-spot) | 90-95% per 3 tick consecutivi | MANTIENI |
| SOTTOUTILIZZO vicino | 70-90% per 2+ tick stagnanti | PUSH G-SPOT |
| SOTTOUTILIZZO grave | < 70% per 2+ tick + vel<ideale×0.7 | SCALA UP |
| OK | qualunque, primo tick | ACCELERARE |
Niente throttle sotto i 5min. Lo storico mostra che i throttle <5min (78-86% degli
eventi su Kimi/Codex) erano correzioni marginali applicate a raffica = chatter. Ora il
throttle è 0 (off) oppure ≥5min agganciato alla ladder {5,10,15,20,25,30,40,50,60}min
(floor 5min, cap 1h). jht-throttle/throttle-config agganciano da soli qualunque valore
(es. 120s → 300s), quindi ordina pure in minuti "puliti".
rapporto = velocità_smussata / velocità_ideale
| rapporto | sleep tra operazioni | semantica |
|---|---|---|
| ≤ 1.0 | 0s | sotto target, full speed |
| 1.0 – 1.5 | 5 min | leggermente sopra |
| 1.5 – 2.0 | 10 min | moderato |
| 2.0 – 3.0 | 20 min | pesante |
| > 3.0 | 30 min (sali fino a 60) | near-freeze, emergenza |
Se velocità_ideale ≤ 0 (proj > SAFE_TARGET 95%) → sali la ladder (30-60min).
⚠️ Per CONSUMARE di più NON si scende sotto i 5min. Il throttle pace il SINGOLO agente; la PORTATA del team la regola il numero di agenti. Se al floor di 5min il team sotto-utilizza il budget, la leva è il PARALLELISMO: ordina SCALA UP → il Capitano spawna più agenti (più agenti in simultanea = più throughput a parità di floor). Mai inseguire il budget abbassando il throttle sotto i 5min: non esiste più.
Una di queste condizioni → manda EMERGENZA + esegui freeze_team.py (vedi skill emergency-handling):
proj > 200% (catastrofica)velocità_smussata > velocità_ideale × 5 (esplosione)usage ≥ 90% assoluto (limite hard)velocità_ideale = (TARGET - usage_attuale) / ore_al_reset
TARGET è dinamico, scelto in quest'ordine:
[BRIDGE TICK] include target=N% → usa N (target work-hours-aware: il pacing-bridge l'ha calcolato in base alle ore di lavoro che l'utente ha configurato e al rapporto cap-5h/cap-weekly del provider).[BRIDGE TICK] ... (no target field) → target = 92.[BRIDGE TICK] ... target=76% work_phase=ON → target = 76. Significa che il pacing-bridge sa che l'utente lavora 9-18 e con quel ratio una finestra 5h piena varrebbe 14.7% del weekly → puntare al 76% al reset distribuisce esattamente il 100% del weekly sulle ore ON.[BRIDGE TICK] ... target=0% work_phase=OFF → target = 0 (team deve scendere/restare basso).Le soglie 95%/90% nella tabella in cima si interpretano sempre come "vicino al target". Quando il target è 76% (work-hours), STEADY = proj ∈ [target−4, target+1] ≈ 72-77%, ATTENZIONE = 77-82%, CRITICO > 84%. Quando il target è 92% (fallback) le soglie tornano ai numeri originali 90/95/100.
Se non sei sicura del target nel tick corrente → tienilo a 92 e log esplicito "(target fallback 92)". Meglio comportamento conservativo che fraintendere lo schedule.