application-trackerlisted

Tracker delle candidature del sistema Job Hunter, repo-first (cartella applications/ nel repo: 1 candidatura = 1 sottocartella <id>/ con application.yaml + events.jsonl). Usa SEMPRE questa skill quando l'utente vuole: aggiungere o promuovere una candidatura ("aggiungi al tracker", "mi sono candidato a X", "promuovi questo annuncio"), aggiornare uno stato ("ho fatto il colloquio", "mi hanno rifiutato", "ho ritirato la candidatura"), controllare le risposte ("ci sono novità sulle candidature?", "guarda se mi hanno risposto"), preparare un follow-up ("prepara il follow-up per X"), o vedere la pipeline ("a che punto sono le candidature"). Usala ANCHE per la revisione in blocco della coda di staging ("fammi rivedere le offerte in coda", "triage dello staging", "rivediamo le pending in blocco", "smaltiamo il backlog dello staging", "mostrami le offerte in attesa di revisione"): presenta le voci pending in lotti ordinati per score e raccoglie decisioni rapide di scarto o promozione. NON usare per la gestione produtt
FynePool/job-hunter-template · ★ 3 · Data & Documents · score 66

Install: claude install-skill FynePool/job-hunter-template

# application-tracker Modulo 2.3 del progetto Job Hunter: lo stato-workflow delle candidature vive qui, **nel repo**, sotto `applications/` (D8 — repo-first). È l'unica fonte di verità per "a che punto è" una candidatura (il `role-fit-output` in `role-fit/` si ferma a `promosso_a_tracker`, per costruzione). Due principi sopra tutto: 1. **Nessuna candidatura nasce da sola**: la promozione dal digest/valutazione al tracker è SEMPRE un'azione esplicita dell'utente (decisione fissa del progetto). La routine NON scrive in `applications/` (la legge soltanto, per le scadenze del digest) — **con una sola eccezione delimitata**: `scripts/sync_todoist.py` ci scrive per rispecchiare 1:1 lo spostamento di una card che l'utente ha fatto a mano su Todoist (vedi «Dal sync Todoist» più sotto). Anche lì la decisione è umana: cambia solo dove l'utente l'ha espressa. Questa skill, comunque, non crea candidature "per completezza". 2. **Nessun cambio di stato silenzioso**: ogni modifica derivata da una email va mostrata (email + azione proposta) e confermata prima di toccare i file. **Dove giri conta (D5, D7)**: la scrittura richiede una sessione Claude Code (file locali + commit). Da chat claude.ai pura il connettore GitHub è di sola lettura: puoi leggere e proporre, ma NON persistere — dichiaralo e rimanda la scrittura a una sessione Claude Code. Ogni mutazione la committi TU: l'utente non tocca mai git. ## Precondizioni di readiness - **Profilo configurato (prerequisito minimo)**: esiste