Task Schedulati con Claude Code: Come Automatizzare Operazioni Ricorrenti (Guida Pratica 2026)

7 task schedulati. Zero interventi manuali negli ultimi 10 giorni. Ogni mattina il tuo profilo LinkedIn pubblica un post, ogni lunedì la SEO viene monitorata, ogni sera un health check verifica che tutto sia in ordine.

Nessun cron job su server esterno. Nessun workflow Zapier o n8n. Solo Claude Code, file di istruzione in linguaggio naturale e un bus di segnali condiviso tra i task.

Questa è una guida pratica basata su 5 settimane di produzione con 21+ automazioni attive su un ecosistema reale. Dentro trovi:

• come funzionano i task schedulati in Claude Code
• il pattern architetturale Orchestrator + Signals Bus
• 5 task schedulati reali e cosa fanno
• gli errori commessi e come evitarli
• il setup minimo per iniziare in meno di un pomeriggio

Cosa Sono i Task Schedulati in Claude Code

I task schedulati sono operazioni che Claude Code esegue automaticamente a intervalli definiti:

• ogni giorno alle 8:00
• ogni lunedì alle 10:00
• il primo del mese

Non servono:

• server dedicati
• cron expression in formato Unix
• competenze di programmazione

Ti basta:

1. definire un file SKILL.md con istruzioni in linguaggio naturale
2. impostare la frequenza di esecuzione
3. dare i permessi agli strumenti (browser, file system, API, CMS)

La differenza rispetto a un cron job tradizionale è sostanziale:

• il cron esegue uno script rigido con IF/ELSE hardcoded
• Claude esegue istruzioni interpretate con accesso a tool, API, file system e browser

Se un passaggio fallisce, Claude può adattarsi. Se il contesto cambia (file mancante, dato diverso dal previsto), il task può reagire senza crashare.

Nel mio ecosistema uso i task schedulati per:

• pubblicare post LinkedIn ogni mattina
• monitorare Google Search Console
• verificare lo stato di salute del sito
• pubblicare draft dal CMS
• tracciare competitor
• coordinare tutto con un orchestratore settimanale

Come Creare il Tuo Primo Task Schedulato

Per creare un task schedulato ti servono tre elementi:

1. File SKILL.md – il cuore del task
2. Frequenza di esecuzione – giornaliera, settimanale, mensile o custom
3. Permessi per gli strumenti – browser, file system, API, CMS

Struttura base di un file SKILL.md

Un SKILL.md è un documento in linguaggio naturale che descrive, step by step, cosa Claude deve fare.

Più le istruzioni sono precise, più l'esecuzione è affidabile.

Esempio di struttura base:

## Daily Post Publisher — Pubblica il post LinkedIn del giorno

### Step 1: Leggi contesto
Apri il file `./config/content-plan.md` e leggi la sezione `## linkedIn-weekly-plan`.
Identifica il post previsto per la data di oggi.
Se non trovi un post per oggi, termina il task e scrivi un log di avviso.

### Step 2: Prepara contenuto
- Estrai: testo del post, eventuale CTA, hashtag, riferimento al visual.
- Verifica che il testo sia compreso tra 500 e 1.300 caratteri.
- Se il testo è più lungo, sintetizzalo mantenendo tono e messaggio chiave.

### Step 3: Pubblica su LinkedIn
- Apri il browser e accedi a LinkedIn con le credenziali salvate.
- Crea un nuovo post.
- Incolla il testo preparato.
- Cerca il visual nella cartella `./assets/linkedin/[anno]/[settimana]/`.
  - Se il visual esiste, allegalo al post.
  - Se non esiste, pubblica solo testo.
- Conferma la pubblicazione.

### Step 4: Primo commento dopo 20 minuti
- Attendi 20 minuti reali.
- Torna sul post appena pubblicato.
- Aggiungi un commento di approfondimento (max 400 caratteri) che:
  - espanda un punto chiave del post
  - inviti alla conversazione con una domanda aperta

### Step 5: Salva output
Scrivi un log in `./logs/daily-post-publisher.md` con:
- timestamp di inizio e fine
- titolo o incipit del post
- se il visual è stato allegato (sì/no)
- URL del post pubblicato
- eventuali errori incontrati

Il livello di dettaglio nelle istruzioni determina tutto.

• "Scrivi un articolo" → risultati imprevedibili
• "Scrivi un articolo di 1.500+ parole sul topic X, con struttura H1-H2, almeno 2 link interni a [pagine specifiche], meta description di 155 caratteri" → output consistente

Anatomia di un Task Reale: il Blog Publisher

Un esempio concreto: il task seo-blog-publisher, che gira il martedì e il venerdì alle 10:00.

Flusso del task

Step 0 — Leggi i segnali di sistema

• apre ./signals/system-signals.md
• legge:
• ## orchestrator-directives
• ## seo-performance
• ## competitor-alerts
• se l'orchestratore ha assegnato un topic specifico (es. "un competitor ha pubblicato su una keyword dove siamo posizionati"), quel topic ha priorità assoluta

Step 1 — Scegli il topic dal piano editoriale

• legge il piano editoriale in ./config/editorial-plan.md
• considera 4 cluster in ordine di priorità:

1. Claude AI
2. Claude Code
3. Automazione B2B
4. Case Study

• se il competitor tracker ha segnalato una keyword critica, il segnale sovrascrive la scelta standard

Step 2 — Scrivi l'articolo SEO

Regole operative:

• minimo 1.500 parole
• struttura con H2 e keyword secondarie
• almeno 2 link interni:
• 1 verso un post correlato
• 1 verso una pagina di conversione
• almeno 1 link esterno autorevole
• meta description ottimizzata (max 155 caratteri)

Step 3 — Pubblica su Sanity

• usa le API di Sanity
• crea un nuovo documento post con:
• titolo
• slug SEO friendly
• body in formato portable text / markdown
• campi SEO (title, description, canonical)

Step 4 — Scrivi il log

• salva un log in ./logs/seo-blog-publisher.md con:
• timestamp
• titolo
• slug
• keyword target
• fonte del segnale che ha determinato la scelta del topic

Punto chiave: il task non opera nel vuoto. Prima di decidere cosa fare, legge i segnali prodotti da altri task.

Il Pattern Orchestrator + Signals Bus

Dopo alcune settimane con task isolati emerge un collo di bottiglia chiaro:

• il blog publisher non sa cosa il competitor tracker ha trovato
• l'outreach non sa quali keyword stanno salendo o scendendo

La soluzione è un file condiviso, ad esempio ./signals/system-signals.md, che funziona come bus di comunicazione tra i task.

Ruoli nel sistema

• Producer – scrivono la propria sezione nel file
• Consumer – leggono le sezioni rilevanti prima di eseguire
• Orchestratore – coordina tutto e definisce le priorità

Esempi:

• il competitor tracker aggiorna ## competitor-alerts con nuovi contenuti pubblicati dai competitor
• il monitor GSC aggiorna ## seo-performance con impressioni, click, keyword in movimento
• il blog publisher legge ## seo-performance e ## competitor-alerts per scegliere il topic migliore
• l'outreach legge ## outreach-status per non contattare due volte lo stesso target

L'orchestratore gira la domenica sera, legge tutti i segnali della settimana e scrive direttive operative in ## orchestrator-directives.

Risultato misurato su un caso reale: gli articoli scritti in risposta a un segnale hanno avuto circa +40% impressioni nella prima settimana rispetto a quelli generici (N=8 articoli, periodo 3 settimane).

Esempio di system-signals.md

# System Signals Bus

## seo-performance
- periodo: ultimi 28 giorni
- top keyword in crescita:
  - "task schedulati claude code" → +65% impression, CTR 4.2%
  - "automazione seo claude" → +38% impression, CTR 3.1%
- pagine in calo:
  - /blog/automazione-seo → -27% impression

## competitor-alerts
- 2026-04-05: Competitor A ha pubblicato un articolo su "task automation con AI" con focus LinkedIn.
- 2026-04-06: Competitor B ha lanciato una guida su "cron job AI".

## outreach-status
- prospect contattati questa settimana: 7
- follow-up pendenti: 3

## orchestrator-directives
- priorità contenuti settimana prossima:
  1. Guida pratica su task schedulati con Claude Code
  2. Case study su automazione SEO con GSC
- indicazioni specifiche:
  - rispondere al contenuto di Competitor A con un articolo più pratico e con esempi di produzione reale
  - includere sezione su pattern Orchestrator + Signals Bus

5 Task Schedulati in Produzione: Cosa Fanno e Perché

Di seguito 5 task schedulati reali, con ruolo e motivazione.

1. Daily Post Publisher (ogni giorno, 8:00)

Obiettivo: pubblicare il post LinkedIn del giorno dal piano settimanale pre-approvato.

Cosa fa:

• legge il piano contenuti della settimana
• seleziona il post del giorno
• cerca il visual pre-generato nella cartella corrispondente
• se il visual esiste → lo allega
• se non esiste → pubblica solo testo
• dopo 20 minuti pubblica il primo commento sotto il post

Tasso di successo su 4 settimane: 95%+. I fallimenti sono quasi sempre legati a timeout del browser, non a errori logici.

2. GSC Weekly Monitor (lunedì, 10:00)

Obiettivo: trasformare Google Search Console in un flusso di segnali azionabili.

Cosa fa:

• apre Google Search Console via browser
• scarica dati degli ultimi 28 giorni (query, pagine, dispositivi, paesi)
• confronta con il report del mese precedente
• genera un dashboard HTML o markdown
• scrive i risultati nella sezione ## seo-performance del signals bus

È il task che alimenta le decisioni di tutti gli altri.

3. Blog Draft Publisher (lunedì, 11:00)

Obiettivo: non lasciare draft bloccati nel CMS.

Cosa fa:

• interroga Sanity per trovare draft non pubblicati
• verifica che abbiano tutti i campi compilati (titolo, slug, body, SEO)
• se tutto è ok → pubblica automaticamente
• se manca qualcosa → logga l'errore e salta il draft

Questo task nasce da un dato concreto: un mese con 10+ draft pronti ma non pubblicati, quindi zero traffico da contenuti già scritti.

4. Weekly System Orchestrator (domenica, 20:00)

Obiettivo: coordinare l'intero ecosistema di automazioni.

Cosa fa:

• legge tutti i segnali accumulati nella settimana:
• ## seo-performance
• ## competitor-alerts
• ## outreach-status