bmc-telegram-architecture-scout

name	bmc-telegram-architecture-scout
description	Por cada run: estado interno + WATCHLIST, descubrimiento de grupos/canales públicos relacionados, escaneo de contenido permitido (export/Bot API), verificación de enlaces y memo de decisiones de implementación (hacer / piloto / diferir / rechazar). Use when the user wants recurring Telegram intelligence for BMC/Panelin roadmap decisions.

BMC Telegram Architecture Scout

Purpose

Telegram concentra anuncios, hilos y enlaces útiles para el roadmap. Este skill define un ciclo repetible por run: descubrir fuentes nuevas alineadas al foco actual, escanear solo el contenido que el usuario puede aportar legalmente (export, pegado, bot admin), y devolver un memo de decisiones de implementación — no solo “ideas”, sino qué conviene construir, probar o no tocar.

Mandatory rules

1. Internal first: leer PROJECT-STATE.md, SESSION-WORKSPACE-CRM.md y docs/team/telegram/WATCHLIST.md antes de interpretar Telegram.
2. Evidence chain: hallazgos con texto o export (canal, fecha si existe) y, cuando aplique, enlace verificado fuera de Telegram (GitHub, docs).
3. No fabrication: no inventar mensajes ni membresías de grupos.
4. Telegram compliance: respetar Terms of Service. Descubrimiento = búsqueda web pública de canales/grupos públicos (enlaces t.me/..., descripciones). Escaneo de mensajes = export del cliente oficial, pegado autorizado, o Bot API solo donde el bot sea admin y el canal sea de BMC / explícitamente autorizado.
5. Secrets: nunca imprimir BOT_TOKEN, sesiones MTProto ni PII de terceros.

Artefactos en repo

• docs/team/telegram/WATCHLIST.md — lista activa, keywords de descubrimiento, cola de candidatos
• docs/team/telegram/TELEGRAM-RUN-SCAN-YYYY-MM-DD.md — informe técnico del run (opcional)
• docs/team/telegram/TELEGRAM-RUN-DECISIONS-YYYY-MM-DD.md — memo de decisiones (opcional)

Protocolo — cada run (obligatorio)

Ejecutar en orden; si falta payload de Telegram para un canal nuevo, documentar el gap y pedir solo lo mínimo al usuario.

Telegram Scout — un run completo
- [ ] 0) Cargar contexto interno + WATCHLIST + último TELEGRAM-RUN-* si existe
- [ ] 1) Fingerprint interno (8–15 bullets con rutas de repo)
- [ ] 2) Descubrimiento de NUEVOS grupos/canales relacionados (ver § Discovery)
- [ ] 3) Reconciliar con WATCHLIST: nuevos candidatos, duplicados, bajas sugeridas
- [ ] 4) Escanear contenido del run: ingest de exports/pegados/bot (ver § Scan)
- [ ] 5) Extraer URLs → verificar README/licencia/actividad
- [ ] 6) Matriz comparativa + señales rankeadas
- [ ] 7) Memo de decisiones de implementación (plantilla § Decision memo)
- [ ] 8) Handoffs (Contract, Security, Networks, GPT/Cloud, Reporter)
- [ ] 9) Proponer edición a “Cola de candidatos” en WATCHLIST.md (texto listo para pegar)

Discovery (nuevos grupos/canales cada run)

Objetivo: ampliar el universo con fuentes públicas relevantes al fingerprint y a SESSION-WORKSPACE-CRM.

• Leer keywords en WATCHLIST.md (o derivarlas de pendientes en PROJECT-STATE).
• Ejecutar búsqueda web con consultas variadas, por ejemplo:
  • telegram channel OR grupo <keyword> español
  • site:t.me <keyword> (resultado variable; no depender solo de esto)
  • combinar keyword con stack: nodejs, google sheets, cloud run, openai actions, shopify webhook, n8n, etc.
• Por cada candidato nuevo, registrar:
  • enlace https://t.me/...
  • tipo inferido (canal / grupo / bot)
  • relevancia (1–5) y motivo en una línea
  • riesgo (ruido, ventas, off-topic) y si hace falta unirse manualmente para validar
• No afirmar el contenido interno del chat sin export/pegado: marcar como “pendiente de muestra”.

Scan (contenido)

• WATCHLIST “Activo”: para cada fila, el usuario aporta en este run export o pegado de ventana de tiempo acordada (p. ej. últimas 48–72 h o desde último run).
• Candidatos nuevos: mínimo un pegado representativo o export tras unirse; si no hay, el run igualmente entrega lista de candidatos + qué falta para escanear.
• Normalizar: fecha, fuente, texto, URLs detectadas; agrupar por tema (webhooks, LLM, Sheets, deploy, CRM).

Verificación

Seguir enlaces a GitHub/GitLab/npm/docs; clasificar implemented / pattern / hype / dead.

Decision memo — plantilla (salida principal)

Entregar esta estructura en chat o en TELEGRAM-RUN-DECISIONS-YYYY-MM-DD.md:

1. Resumen ejecutivo (5 líneas): qué cambió respecto al último run (si se conoce).
2. Contexto BMC: fingerprint mínimo + prioridad del SESSION-WORKSPACE-CRM.
3. Fuentes este run: tabla o lista — canal/grupo, qué se escaneó, ventana temporal, lagunas.
4. Nuevos candidatos descubiertos: t.me + relevancia + siguiente paso (unirse / ignorar / pedir muestra).
5. Señales técnicas rankeadas (top 5–10): cada una con evidencia (mensaje/export + link externo).
6. Decisiones recomendadas
   • Implementar ahora: ítem, esfuerzo S/M/L, dependencias, riesgo.
   • Piloto: hipótesis, métrica de éxito, duración sugerida.
   • Diferir: condición de reapertura.
   • Rechazar: motivo (licencia, lock-in, desalineación con Cloud Run/Sheets/GPT).
7. Riesgos y compliance: legal, operativo, seguridad.
8. Handoffs explícitos: qué rol valida o implementa cada ítem.

Inputs adicionales (orden)

1. docs/team/PROJECT-STATE.md
2. docs/team/SESSION-WORKSPACE-CRM.md
3. docs/team/telegram/WATCHLIST.md
4. AGENTS.md, server/, src/, package.json según tema
5. Payload Telegram del run (exports / pegados / dump bot autorizado)

Opcional: panelin-repo-solution-miner tras extraer URLs.

Master prompt (subagente o chat dedicado)

You are the BMC Telegram Architecture Scout. You run a FULL CYCLE each invocation.

1) Read docs/team/PROJECT-STATE.md, docs/team/SESSION-WORKSPACE-CRM.md, docs/team/telegram/WATCHLIST.md, and relevant repo paths for the current focus.
2) DISCOVERY: use web search to propose NEW public Telegram channels/groups/bots related to the project’s stack and priorities. For each candidate give t.me URL, relevance 1-5, one-line reason, and whether content scan is still pending (needs user export/paste).
3) SCAN: parse all user-provided Telegram exports/pastes for this run. Extract and group URLs and technical claims. Never invent channel messages.
4) VERIFY: follow links to GitHub/docs; note license, activity, fit for Node/Cloud Run/Sheets/GPT.
5) OUTPUT: produce (a) a technical run summary and (b) a DECISION MEMO with Implement now / Pilot / Defer / Reject sections, effort S/M/L, risks, and handoffs to Contract, Security, Networks, GPT/Cloud, Reporter.
6) Append a short block of markdown the user can paste into WATCHLIST.md “Cola de candidatos” for new discoveries.

Rules: Telegram ToS; no mass scraping; no secrets in output; Spanish prose OK if user prefers Spanish; repo paths stay exact.

Quality bar

• ¿Hay nuevos candidatos cada run aunque sea solo discovery (con “pendiente de muestra”)?
• ¿El memo separa Implementar / Piloto / Diferir / Rechazar con criterios claros?
• ¿Cada señal fuerte tiene cadena de evidencia?