Processing Site Visit Recordings
YAML--- name: processing-site-visit-recordings description: Transforms voice/video notes from construction site visits into transcripts, client-ready emails, and structured site diary entries. Use when a user uploads or describes audio/video from a cantiere (construction site) visit and needs to extract the original transcript, produce a client communication, and log progress/issues in a running site diary/journal. ---
Given a video/audio recording (or its transcript) from a site visit, produce three outputs in this order:
- Original Transcript (verbatim, cleaned of filler words only)
- Client Email (professional, selective, actionable)
- Site Diary Entry (structured, dated, cumulative log)
Minimal invocation example:
"Ho caricato il video della visita in cantiere di oggi riguardo alla piscina. Trascrivi, prepara l'email per architetto e cliente, e aggiorna il diario di cantiere."
If no diary exists yet, create a new one with the project name as header. If one exists (shared in conversation or prior message), append to it — never overwrite past entries.
Progress:
- [ ] Step 1: Transcribe audio/video verbatim
- [ ] Step 2: Extract site/project name and visit date (ask if missing/unclear)
- [ ] Step 3: Identify content category/categories (closure, start of work, problem, decision, client-input-needed, general communication)
- [ ] Step 4: Draft client email (filtered, professional tone)
- [ ] Step 5: Draft/append site diary entry (structured, dated)
- [ ] Step 6: Present all three outputs clearly labeled and separated
Step 1 — Transcription
- Produce a faithful transcript of the spoken content.
- Remove filler words ("ehm", "cioè", false starts) but do NOT paraphrase or summarize — this is the archival original.
- If multiple recordings are provided for the same visit, transcribe each separately, labeled (es. "Video 1 – Piscina", "Video 2 – Facciata").
Step 2 — Metadata extraction
- Date of visit (ask explicitly if not stated in the recording or by the user — never assume today's date without confirmation).
- Project/cantiere name or address.
- If multiple recordings cover different topics in the same visit, treat them as one visit with multiple entries/sections.
Step 3 — Categorize content For each recording/topic, tag it as one or more of:
- ✅ Lavori conclusi (work completed/closed)
- 🚧 Lavori iniziati (work started)
- ⚠️ Problema emerso (issue/problem)
- 📌 Decisione presa (decision made)
- ❓ Serve input cliente (client input/specs needed)
- 📣 Comunicazione da fare (something to communicate)
This tagging drives both the email filtering and the diary structure.
Step 4 — Client email
- Audience: architect + client (adjust tone/technicality accordingly — slightly more technical for architect, clear and non-technical for client, unless asked to write two separate emails).
- Include ONLY what's relevant to them: problems, decisions needing approval, questions requiring specs, and major milestones. Exclude internal/operational details (e.g., which worker did what) unless relevant.
- Structure: greeting → context (date, site) → key point(s) grouped by topic → clear action items/questions if any → closing.
- Keep it concise — this is a professional update, not a transcript dump.
Step 5 — Site diary entry
- Always structured by date, then by topic/category within that date.
- Cumulative: new entries are appended below previous ones in reverse-chronological or chronological order (ask user preference once, then stay consistent).
- Format per entry:
Argomento: [es. Piscina] Categoria: ⚠️ Problema emerso Dettagli: [sintesi tecnica concisa, 2-4 righe] Stato: [aperto / chiuso / in attesa di input cliente] Azioni richieste: [se presenti]
- If multiple topics in one visit, repeat the block per topic under the same date header.
**Step 6 — Output presentation**
Always output in this order with clear markdown headers:
1. `### Trascrizione Originale`
2. `### Email per Cliente/Architetto`
3. `### Aggiornamento Diario di Cantiere`
Example 1: Input: Video trascritto in cui l'utente spiega: "Oggi 14 marzo sono andata al cantiere di Villa Rossi, problema con la piscina: infiltrazione sul fondo vasca, probabilmente dovuta a una crepa nel rivestimento. Ho chiesto all'impresa di fare un sopralluogo tecnico entro venerdì. Serve che il cliente decida se vuole rifare tutto il rivestimento o solo la riparazione localizzata."
Output:
### Trascrizione Originale
[trascrizione pulita fedele]
### Email per Cliente/Architetto
Oggetto: Aggiornamento cantiere Villa Rossi – Problema piscina (14/03)
Gentile [Architetto/Cliente],
durante il sopralluogo odierno è emerso un problema di infiltrazione sul fondo della piscina,
probabilmente causato da una crepa nel rivestimento. Abbiamo richiesto un sopralluogo tecnico
da parte dell'impresa, previsto entro venerdì.
Vi chiediamo di valutare, non appena disponibile la diagnosi tecnica, se procedere con:
- rifacimento completo del rivestimento, oppure
- riparazione localizzata della zona interessata.
Resto a disposizione per ulteriori dettagli.
Cordiali saluti, [Nome]
### Aggiornamento Diario di Cantiere
Argomento: Piscina Categoria: ⚠️ Problema emerso / ❓ Serve input cliente Dettagli: Infiltrazione sul fondo vasca, probabile crepa nel rivestimento. Richiesto sopralluogo tecnico impresa entro venerdì 17/03. Stato: Aperto — in attesa di diagnosi tecnica Azioni richieste: Cliente deve decidere tra rifacimento completo o riparazione localizzata del rivestimento.
- Always confirm the visit date if ambiguous — this is the key index for the diary.
- Keep transcript, email, and diary distinct in tone: transcript = verbatim, email = polished/selective, diary = structured/telegraphic technical log.
- Maintain diary continuity: when the user references "il diario di cantiere" from earlier in the conversation or pastes a previous version, append — don't regenerate from scratch.
- One entry per topic, not per video: if two videos cover the same topic, merge into one diary entry; if one video covers two topics, split into two entries.
- Use status tracking (aperto/chiuso/in attesa) consistently so the diary functions as a true progress-tracking tool, not just a log.
- Default to Italian for all outputs unless the user specifies otherwise, matching the language of the input.
- When client input is needed, make the question explicit and isolated in the email so it doesn't get lost in narrative text.
- Don't summarize or interpret in the "Trascrizione Originale" — it must stay a faithful archival copy.
- Don't include internal/operational chatter (who said what to the worker, informal remarks) in the client email.
- Don't silently assume today's date for the visit — always derive it from content or ask.
- Don't overwrite previous diary entries — always append/update status, preserving history.
- Don't merge unrelated topics into a single diary entry just because they came from the same visit — keep them separable by topic for easy future consultation.
- Don't make the client email a transcript dump — it must be curated and action-oriented.