Tratto un unico repository Git come il mio centro di controllo operativo. Ogni progetto vive lì come una cartella di documentazione viva; ogni attività ripetibile diventa una skill riutilizzabile; ogni piattaforma — Jira, Power BI, Confluence, Power Automate, Microsoft 365, Glean — è raggiungibile dall'interno dello stesso workspace. Claude Code è lo strato che tiene tutto insieme: legge la documentazione, esegue le skill, chiama le API delle piattaforme e mantiene tutto sincronizzato con Git.
Tutto si irradia da un unico repository. Claude Code sta al centro — legge la mia documentazione di progetto e agisce sulle piattaforme tramite skill, la CLI e i connettori MCP — poi committa l'intero stato di lavoro su Git.
Quando arriva nuovo lavoro creo una cartella di progetto invece di tenere il contesto
in testa o sparso tra email e chat. I progetti sono ordinati in bucket di priorità e seguono una
rigorosa convenzione di denominazione (tr-yyyy-mm-<name>) così il mio lavoro è filtrabile all'istante.
# projects/ — ordinati per priorità projects/ ├── 0-urgent/ ← lavoro che ha la precedenza assoluta ├── 1-priority/ ← focus dello sprint corrente ├── 2-normal/ ← priorità standard ├── 3-low/ ← backlog └── done/ ← archiviati / completati
Ogni cartella di progetto contiene gli stessi file fondamentali, così chiunque — o qualsiasi sessione futura — può riprendere il lavoro da zero:
| File | Scopo |
|---|---|
README.md | Il registro vivo — obiettivo, contesto, piano con checkbox, contatti, vincoli, stato attuale e prossima azione. |
plan.md | La suddivisione dei task per fasi. |
memory.md | Contesto condiviso per Claude — glossario, decisioni, insidie, dove si trovano le credenziali. |
log.md | Opzionale — diario corrente di cosa è successo, e quando. |
inputs/ working/ output/ scripts/ | Opzionale — materiale sorgente, lavoro di bozza, deliverable e qualsiasi codice prodotto dal progetto. |
La disciplina che fa funzionare tutto questo: il README riflette sempre la realtà attuale. Alla fine di una sessione aggiorno Stato e Prossima azione, così la sessione successiva parte con il contesto completo invece che con dell'archeologia.
Gestisco l'intera vita di un progetto con un insieme di skill /project-* —
slash-command che codificano ogni procedura così da non doverla mai reinventare. Lo stato è sempre messo
per iscritto; le transizioni sono automatizzate.
Crea lo scaffold della cartella e cerca prima su Glean lavori precedenti, così non parto mai da una pagina bianca.
Studia le API rilevanti, i documenti Confluence interni e i comandi CLI esistenti, poi scrive un plan.md per fasi.
Carica il README di un progetto nella sessione e lo rinomina, così tutto ciò che faccio dopo è ancorato a quel progetto.
Prende il task successivo nel piano e o lo esegue o mi dice esattamente cosa devo fornire.
Produce una nota di avanzamento datata e uno stato RYG — analizzando l'attività su Glean, o catturando la sessione corrente.
Conclude la documentazione e sposta la cartella in done/.
Quando mi accorgo di fare la stessa attività in più passaggi più di una volta, la trasformo in una skill
— una cartella sotto .claude/skills/ con un SKILL.md che diventa uno
/slash-command. Diversi dei miei progetti erano letteralmente progetti "crea una skill":
jira-filter-cleanup, confluence-broken-links,
confluence-permissions-audit, powerbi-dataflow-inspect. Costruisco la
capacità una volta, poi la riutilizzo per sempre — e pubblico quelle utili al resto dell'azienda.
Le skill rientrano in alcuni bucket:
/git-commit, /git-commit-push, /git-pull — controllano i file sensibili prima dello staging./project-* di cui sopra./entsol, /power-automate-docs, /confluence-space-creator, /jsm-ticket-responder e le skill di audit/cleanup./presentation, /investcloud-deck.Accanto alle skill c'è la CLI entsol — uno strumento Python che incapsula le stesse API delle piattaforme. La regola pratica: usa una skill quando l'attività beneficia del ragionamento (stesura, sintesi, decisioni in più passaggi); usa la CLI quando deve funzionare senza Claude — scripting, job pianificati o resilienza durante un disservizio.
Per il lavoro live e orientato alla lettura non lascio nemmeno la conversazione — i connettori MCP permettono a Claude di interrogare le piattaforme direttamente: Atlassian (Jira e Confluence), Glean (ricerca enterprise su oltre 100 app — il mio punto di riferimento per "che lavoro ho" e "qualcuno l'ha già fatto prima"), Microsoft 365 (Outlook, SharePoint, Teams), Figma e Power BI.
Questo è un workspace operativo, quindi il workflow è volutamente leggero: commit direttamente
su main. Nessuna cerimonia di branch/MR/review — non serve a un repo ops. Un solo comando
fa lo stage, committa con un messaggio generato e fa il push. Le skill git controllano comunque i segreti
(.env, chiavi, token) prima dello staging, così le credenziali non vengono mai committate.
Poiché tutto — documenti di progetto, skill, CLI, script generati — vive nel repo, il push su
main significa che il mio intero stato di lavoro è salvato, versionato e disponibile per il team.
/project-focus sul progetto a cui sto lavorando per caricarne il contesto./project-execute, oppure lavoro direttamente: scrivo uno script, ispeziono un dataflow Power BI, redigo una pagina Confluence, rispondo a un ticket JSM.README.md del progetto, oppure /project-update per una nota di avanzamento datata./git-commit-push per salvare tutto su main./plugins-publish.