Content Radar — loop bisettimanale autori + temi
Scopo: alimentare la produzione editoriale di Stefano (post LinkedIn + articoli Substack) con segnali
freschi, già tradotti in angle collegati ai SUOI core argument. Non è rassegna stampa: ogni output
deve superare il test "questo serve a scalare un POV di Stefano?".
Working directory attesa: il repo System-content-flywheel. Se non ci sei, chiedila o usa
c:\Users\Utente\Documents\System-content-flywheel.
Config: autori e temi stanno in references/watchlist.md (in questa cartella skill).
Modificare quella, non questo workflow.
Fase 0 — Setup contesto
git pull nel repo System-content-flywheel (il sistema è cross-surface).
- Leggi da
knowledge/foundation/: pov.md (POV-master + sotto-POV), content-strategy.md
(5 tipi di contenuto, trigger), audience.md (buyer, convinzioni, lessico). Questi sono i core
argument contro cui mappare TUTTO.
- Leggi
knowledge/hypotheses/active.md (per la sezione "Segnali per la knowledge").
- Determina la data del run (
YYYY-MM-DD, chiave del ciclo) e la finestra: ultimi 15 giorni.
Come etichetta di periodo secondaria usa il range di settimane ISO coperte (Wxx–Wxx+1).
- Leggi
references/watchlist.md di questa skill: lista autori + temi + query.
Fase 1 — Radar autori (Chrome MCP)
Per ogni autore della watchlist:
- Naviga
https://www.linkedin.com/in/[handle]/recent-activity/all/ con Chrome MCP
(browser dell'utente, già loggato).
- Estrai i post degli ultimi 15 giorni: hook (testo prima del "…altro"), corpo se rilevante,
formato (testo / carosello / immagine / video), tema trattato, engagement se visibile
(reactions, commenti).
- Regole anti-rumore: max 3-4 post rilevanti per autore · skip repost senza commento,
giveaway "commenta per ricevere", post puramente promozionali · se l'autore non ha pubblicato
nella finestra, scrivilo e passa oltre.
- Se un profilo non carica (rate limit, login scaduto, layout cambiato): annota nel report
(sezione Note di processo) e continua — mai bloccare il run per un profilo.
Fase 2 — Radar temi (WebSearch)
Per ognuno dei temi della watchlist: 1-2 ricerche mirate su cosa è uscito negli ultimi 15 giorni
(newsletter di settore, ricerche/report con dati, dibattiti, take contrarian). Usa le query suggerite
nella watchlist come base, adattandole all'attualità.
Filtro: scarta tutto ciò che non è collegabile ai core argument (test del generico: se il segnale
potrebbe interessare qualsiasi marketer, non è un segnale — è rumore).
Fase 3 — Sintesi editoriale (il cuore del radar)
Per ogni segnale sopravvissuto al filtro, mappa TRE coordinate:
- Quale POV scala → POV-master (accumulo) o sotto-POV 1-3 (reframe madre / sequenza invertita /
moltiplicatori) da
pov.md. Un segnale che non scala nessun POV si scarta o finisce al massimo
tra i "Segnali per la knowledge".
- Quale tipo di contenuto → Opinion / POV-Framework / Case-Teardown / Backstory
(da
content-strategy.md, con lo stadio di awareness che muove).
- Quale trigger del buyer aggancia → dai 4 tipi in
audience.md (dolore / evento positivo /
esterno / transizione di fase).
Poi produci 5-8 angle prioritizzati (mai di più — la scarsità è il valore). Per ogni angle:
- Titolo/hook proposto (in italiano, nella voce di Stefano: diretto, specifico, mai guru)
- Formato consigliato: post LinkedIn / articolo Substack / infografica / combinazione hub&spoke
- Perché ora: il segnale che lo rende attuale in questo ciclo
- Le 3 coordinate (POV · tipo · trigger)
- Fonte: link al post dell'autore o alla risorsa
Ordina per priorità: prima gli angle che (a) scalano il POV-master, (b) hanno un aggancio d'attualità
forte, (c) coprono tipi di contenuto diversi tra loro (variety dentro LinkedIn).
Fase 4 — Report su Google Doc
Crea un Google Doc via Google Drive MCP, titolo: Content Radar — Ciclo [YYYY-MM-DD] (Wxx–Wxx+1).
(Cartella di destinazione: se l'utente ne ha indicata una, usala; altrimenti root di Drive.)
Struttura fissa del Doc (in italiano):
- Executive summary — 3 righe: il tema del ciclo, l'angle più forte, cosa ignorare.
- Cosa hanno detto gli autori — per autore: temi trattati + il post più notevole con perché.
- Cosa gira sui temi core — segnali dalle ricerche, con fonte.
- Gli angle pronti per te (5-8, prioritizzati) — il cuore, formato della Fase 3.
- Segnali per la knowledge (solo candidati — nessun file modificato) — pattern nuovi candidati
per
references/, evidenze pro/contro le ipotesi H01-H07. Formato: "CANDIDATO: [cosa] → [dove
andrebbe] → [perché]". Decide Stefano cosa promuovere.
- Note di processo — profili non raggiunti, limiti dei dati, tempo di run.
Fase 5 — Log, push e rinnovo del loop
- Aggiungi una riga a
radar/log.md nel repo progetto:
| [data run YYYY-MM-DD] | [Wxx–Wxx+1] | [link al Doc] | [sintesi in 1 riga] |
- Commit + push:
chore: content radar — ciclo [YYYY-MM-DD] (autorizzato dal CLAUDE.md di progetto).
- Trigger durevole (primario): è lo scheduled task Windows
Content Radar (domenica
alterna 10:00, StartWhenAvailable) che lancia scripts/launch-content-radar.ps1 — sopravvive
alla chiusura di Claude Code. Non serve fare nulla qui per rinnovarlo: il task ricorre da solo.
Fallback (solo se il task NON è installato): registra con CronCreate un job one-shot
(recurring: false) per 15 giorni dopo la data del run, alle 10:00 (cron: 0 10 [giorno] [mese] *),
prompt: Esegui la skill content-radar nella directory c:\Users\Utente\Documents\System-content-flywheel (run bisettimanale automatico).
Se CronCreate non è disponibile, caricalo con ToolSearch. Nota: i cron sono session-only — valgono
solo finché la sessione resta aperta; per questo il meccanismo primario è lo scheduled task OS.
- Chiudi riportando all'utente: link al Doc, i 3 angle top in una riga ciascuno, e conferma che il
prossimo run è già coperto dallo scheduled task
Content Radar (o dal cron di fallback).
Regole di qualità (non negoziabili)
- Test del generico: un angle che potrebbe scrivere qualsiasi consulente si scarta.
- Ogni angle dichiara il suo POV. Senza collegamento esplicito, fuori.
- Mai inventare: se un dato/post non è verificabile, si omette o si marca come incerto.
- Voce: suggerimenti di hook in italiano, mai pomposi, con esempio/numero dove possibile.
- Scarsità: meglio 5 angle forti che 12 mediocri.
Troubleshooting
- LinkedIn chiede login / blocca: avvisa l'utente e prosegui con gli autori raggiungibili +
WebSearch come fallback parziale ("[autore] LinkedIn post [tema] last 2 weeks").
- Google Drive MCP non disponibile: salva il report come
radar/[YYYY-Wxx]-content-radar.md
nel repo progetto (fallback), segnala il mancato Doc.
- Run manuale fuori cadenza: la finestra resta "ultimi 15 giorni" dal giorno del run.
1---2name: content-radar3description: Radar bisettimanale per la content strategy: monitora i post LinkedIn recenti degli autori di riferimento (watchlist) + le conversazioni sui temi core (posizionamento B2B, early stage, growth, product marketing, GTM), li mappa sui POV del sistema content-flywheel e produce un Google Doc con 5-8 angle prioritizzati per post e articoli. Usa quando l'utente dice "content radar", "radar bisettimanale", "lancia il radar", "cosa hanno pubblicato gli autori nelle ultime 2 settimane", o quando il cron bisettimanale lo invoca. NON aggiorna la knowledge base: propone solo candidati.4---56# Content Radar — loop bisettimanale autori + temi78Scopo: alimentare la produzione editoriale di Stefano (post LinkedIn + articoli Substack) con segnali9freschi, già tradotti in angle collegati ai SUOI core argument. Non è rassegna stampa: ogni output10deve superare il test "questo serve a scalare un POV di Stefano?".1112**Working directory attesa:** il repo `System-content-flywheel`. Se non ci sei, chiedila o usa13`c:\Users\Utente\Documents\System-content-flywheel`.1415**Config:** autori e temi stanno in `references/watchlist.md` (in questa cartella skill).16Modificare quella, non questo workflow.1718---1920## Fase 0 — Setup contesto21221. `git pull` nel repo System-content-flywheel (il sistema è cross-surface).232. Leggi da `knowledge/foundation/`: `pov.md` (POV-master + sotto-POV), `content-strategy.md`24 (5 tipi di contenuto, trigger), `audience.md` (buyer, convinzioni, lessico). Questi sono i core25 argument contro cui mappare TUTTO.263. Leggi `knowledge/hypotheses/active.md` (per la sezione "Segnali per la knowledge").274. Determina la data del run (`YYYY-MM-DD`, chiave del ciclo) e la finestra: ultimi 15 giorni.28 Come etichetta di periodo secondaria usa il range di settimane ISO coperte (`Wxx–Wxx+1`).295. Leggi `references/watchlist.md` di questa skill: lista autori + temi + query.3031## Fase 1 — Radar autori (Chrome MCP)3233Per ogni autore della watchlist:34351. Naviga `https://www.linkedin.com/in/[handle]/recent-activity/all/` con Chrome MCP36 (browser dell'utente, già loggato).372. Estrai i post degli **ultimi 15 giorni**: hook (testo prima del "…altro"), corpo se rilevante,38 formato (testo / carosello / immagine / video), tema trattato, engagement se visibile39 (reactions, commenti).403. **Regole anti-rumore:** max 3-4 post rilevanti per autore · skip repost senza commento,41 giveaway "commenta per ricevere", post puramente promozionali · se l'autore non ha pubblicato42 nella finestra, scrivilo e passa oltre.434. **Se un profilo non carica** (rate limit, login scaduto, layout cambiato): annota nel report44 (sezione Note di processo) e continua — mai bloccare il run per un profilo.4546## Fase 2 — Radar temi (WebSearch)4748Per ognuno dei temi della watchlist: 1-2 ricerche mirate su cosa è uscito negli **ultimi 15 giorni**49(newsletter di settore, ricerche/report con dati, dibattiti, take contrarian). Usa le query suggerite50nella watchlist come base, adattandole all'attualità.5152**Filtro:** scarta tutto ciò che non è collegabile ai core argument (test del generico: se il segnale53potrebbe interessare qualsiasi marketer, non è un segnale — è rumore).5455## Fase 3 — Sintesi editoriale (il cuore del radar)5657Per ogni segnale sopravvissuto al filtro, mappa TRE coordinate:5859- **Quale POV scala** → POV-master (accumulo) o sotto-POV 1-3 (reframe madre / sequenza invertita /60 moltiplicatori) da `pov.md`. Un segnale che non scala nessun POV si scarta o finisce al massimo61 tra i "Segnali per la knowledge".62- **Quale tipo di contenuto** → Opinion / POV-Framework / Case-Teardown / Backstory63 (da `content-strategy.md`, con lo stadio di awareness che muove).64- **Quale trigger del buyer aggancia** → dai 4 tipi in `audience.md` (dolore / evento positivo /65 esterno / transizione di fase).6667Poi produci **5-8 angle prioritizzati** (mai di più — la scarsità è il valore). Per ogni angle:68691. **Titolo/hook proposto** (in italiano, nella voce di Stefano: diretto, specifico, mai guru)702. **Formato consigliato**: post LinkedIn / articolo Substack / infografica / combinazione hub&spoke713. **Perché ora**: il segnale che lo rende attuale in questo ciclo724. **Le 3 coordinate** (POV · tipo · trigger)735. **Fonte**: link al post dell'autore o alla risorsa7475Ordina per priorità: prima gli angle che (a) scalano il POV-master, (b) hanno un aggancio d'attualità76forte, (c) coprono tipi di contenuto diversi tra loro (variety dentro LinkedIn).7778## Fase 4 — Report su Google Doc7980Crea un Google Doc via Google Drive MCP, titolo: `Content Radar — Ciclo [YYYY-MM-DD] (Wxx–Wxx+1)`.81(Cartella di destinazione: se l'utente ne ha indicata una, usala; altrimenti root di Drive.)8283Struttura fissa del Doc (in italiano):84851. **Executive summary** — 3 righe: il tema del ciclo, l'angle più forte, cosa ignorare.862. **Cosa hanno detto gli autori** — per autore: temi trattati + il post più notevole con perché.873. **Cosa gira sui temi core** — segnali dalle ricerche, con fonte.884. **Gli angle pronti per te (5-8, prioritizzati)** — il cuore, formato della Fase 3.895. **Segnali per la knowledge (solo candidati — nessun file modificato)** — pattern nuovi candidati90 per `references/`, evidenze pro/contro le ipotesi H01-H07. Formato: "CANDIDATO: [cosa] → [dove91 andrebbe] → [perché]". Decide Stefano cosa promuovere.926. **Note di processo** — profili non raggiunti, limiti dei dati, tempo di run.9394## Fase 5 — Log, push e rinnovo del loop95961. Aggiungi una riga a `radar/log.md` nel repo progetto:97 `| [data run YYYY-MM-DD] | [Wxx–Wxx+1] | [link al Doc] | [sintesi in 1 riga] |`982. Commit + push: `chore: content radar — ciclo [YYYY-MM-DD]` (autorizzato dal CLAUDE.md di progetto).993. **Trigger durevole (primario):** è lo **scheduled task Windows `Content Radar`** (domenica100 alterna 10:00, `StartWhenAvailable`) che lancia `scripts/launch-content-radar.ps1` — sopravvive101 alla chiusura di Claude Code. Non serve fare nulla qui per rinnovarlo: il task ricorre da solo.102 **Fallback (solo se il task NON è installato):** registra con CronCreate un job **one-shot**103 (`recurring: false`) per **15 giorni dopo la data del run, alle 10:00** (cron: `0 10 [giorno] [mese] *`),104 prompt: `Esegui la skill content-radar nella directory c:\Users\Utente\Documents\System-content-flywheel (run bisettimanale automatico).`105 Se CronCreate non è disponibile, caricalo con ToolSearch. Nota: i cron sono session-only — valgono106 solo finché la sessione resta aperta; per questo il meccanismo primario è lo scheduled task OS.1074. Chiudi riportando all'utente: link al Doc, i 3 angle top in una riga ciascuno, e conferma che il108 prossimo run è già coperto dallo scheduled task `Content Radar` (o dal cron di fallback).109110---111112## Regole di qualità (non negoziabili)113114- **Test del generico:** un angle che potrebbe scrivere qualsiasi consulente si scarta.115- **Ogni angle dichiara il suo POV.** Senza collegamento esplicito, fuori.116- **Mai inventare:** se un dato/post non è verificabile, si omette o si marca come incerto.117- **Voce:** suggerimenti di hook in italiano, mai pomposi, con esempio/numero dove possibile.118- **Scarsità:** meglio 5 angle forti che 12 mediocri.119120## Troubleshooting121122- **LinkedIn chiede login / blocca:** avvisa l'utente e prosegui con gli autori raggiungibili +123 WebSearch come fallback parziale ("[autore] LinkedIn post [tema] last 2 weeks").124- **Google Drive MCP non disponibile:** salva il report come `radar/[YYYY-Wxx]-content-radar.md`125 nel repo progetto (fallback), segnala il mancato Doc.126- **Run manuale fuori cadenza:** la finestra resta "ultimi 15 giorni" dal giorno del run.