← ClaudeAtlas

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"). NON usare per la gestione produttività generale (backlog, roadmap, task personali): questa skill tocca SOLO la cartella applications/ del sistema Job Hunter.
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, niente Todoist). È 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), e questa skill 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 `master-profile.yaml` nella radice del repo ed è non vuoto. Se manca, l'utente non ha ancora fatto l'onboarding: non procedere e non iniziare a tracciare candidature su un sistema non inizializzato. Fermati e reindirizza ad `agent-config` con una frase specifica al