¿Qué hace promo-scout?
Inteligencia de promoción genérica, basada en verificación. Es lo opuesto a un recolector de hype: nada llega al tablero a menos que el estado en vivo de GitHub lo respalde, y el juicio se realiza por consenso sshx (perspectivas aisladas + tabla de verdad), no por la opinión de un solo modelo.
Requiere: gh autenticado con tu autenticación de GitHub existente, ya sea mediante gh auth login o GH_TOKEN, y la skill sshx disponible para el invocador.
Cuándo usarlo
Un agente u operador quiere, para un repositorio/organización objetivo: qué es genuinamente promocionable ahora mismo, cómo se conectan las piezas entre repositorios, y qué afirmaciones tentadoras NO son verificables.
Paso 0 — confirmar el alcance explícito CON EL USUARIO
No hay un alcance predeterminado amplio para toda la cuenta. Exige que el usuario nombre:
- una organización completa (solo repos públicos por defecto),
- uno o más repositorios específicos (
owner/repo), o - una lista mixta.
También confirma
REPO_LIMITpara objetivos de organización (por defecto 12 repos públicos más recientemente activos). La recolección de repositorios privados requiere una aceptación explícita con--include-private; no uses esa bandera a menos que el usuario lo haya confirmado.
Paso 1 — obtener el estado en vivo (determinista; se ejecuta desde cualquier lugar)
Ejecuta el recolector integrado con un objetivo explícito:
python3 scripts/promo_scout_fetch.py <org | owner/repo> [más...] # alcance público/por defecto
python3 scripts/promo_scout_fetch.py --include-private <org | owner/repo> [más...] # solo después de confirmación explícita
Esto escribe /tmp/promo_scout_bundle.json: README principal de cada repositorio, commits recientes, releases, PRs abiertos, issues recientes. Esta es la ÚNICA evidencia que el paso de consenso puede usar.
Paso 2 — ejecutar consenso sshx real sobre el bundle
Invoca la skill sshx (agentes delegados, perspectivas aisladas, trabajadores codex-cli) con esta decisión, alimentando el bundle como entrada fija:
Dado SOLO este bundle de estado en vivo de GitHub, produce tres listas. (1) Promocionable: elementos que realmente vale la pena promocionar ahora — cada uno DEBE citar evidencia concreta del bundle (una etiqueta de release, un commit fechado, una capacidad del README). (2) Conexiones: enlaces entre repositorios donde el trabajo de un repositorio se compone con el de otro, cada uno respaldado por una señal real en el bundle (PRs compartidos, menciones de dependencias, capacidades complementarias). (3) Descartado: afirmaciones tentadoras que el bundle NO respalda, con la evidencia faltante. Sin exageraciones; si la evidencia está ausente, va a Descartado, no a Promocionable.
Usa perspectivas de pensamiento sshx distintas, por ejemplo: una lente de promocionabilidad, una lente de conexión entre repositorios, y una lente de escéptico / cazador de exageraciones. Exige convergencia según la tabla de verdad sshx; respeta abstain cuando los trabajadores no puedan establecer una afirmación.
Paso 3 — emitir el tablero
Escribe el resultado acordado como un tablero (markdown + JSON opcional): ## Promocionable ahora, ## Conexiones, ## Descartado (no verificable). Cada elemento promocionable o de conexión lleva su evidencia del bundle en línea. La lista Descartado es obligatoria — es la credibilidad del tablero.
Barreras de seguridad
- Evidencia o no se envía. El bundle en vivo es la única fuente; sin memoria externa, sin números inflados.
- Las conexiones/síntesis deben SURGIR del consenso sobre el estado en vivo — no inyectes una narrativa preescrita.
- Honesto por construcción: no verificable → Descartado; cuando no se pueda alcanzar consenso, reporta
abstain, no una suposición.