GitHub on KnightLi Blog

Qué es GitHub Spec Kit: usar el desarrollo guiado por especificaciones para encauzar la programación con IA

Mon, 25 May 2026 00:19:14 +0800

Spec Kit de GitHub es un nuevo conjunto de herramientas para programación con IA. Su objetivo es ayudar a los desarrolladores a practicar Spec-Driven Development, es decir, desarrollo guiado por especificaciones.

El problema que aborda es muy directo: muchos flujos actuales de programación con IA se parecen demasiado a “chatear mientras se escribe código”. Una persona da una idea aproximada y el Agent empieza de inmediato a modificar el código. A corto plazo parece rápido, pero los límites de los requisitos, los criterios de aceptación, las decisiones técnicas y la división de tareas a menudo no quedan asentados. En cuanto el proyecto se vuelve un poco complejo, es fácil que termine convertido en vibe coding de una sola vez.

La idea de Spec Kit es la contraria: primero escribir claramente la especificación y luego pasar a la planificación, las tareas y la implementación. El código ya no es el primer paso. La especificación lo es.

Qué es Spec Kit

Spec Kit es el conjunto de herramientas open source de GitHub para desarrollo guiado por especificaciones. Proporciona la CLI specify, plantillas, scripts y comandos orientados a AI coding agents, para que los equipos puedan avanzar alrededor de un mismo conjunto de artefactos estructurados.

Lo que enfatiza no es “hacer que la IA pregunte menos”, sino hacer que la IA genere y refine estos elementos antes de escribir código:

Principios del proyecto: restricciones del equipo sobre calidad, pruebas, experiencia, rendimiento y aspectos similares;
Especificaciones funcionales: qué se va a construir, por qué se construye, historias de usuario y requisitos funcionales;
Plan técnico: qué stack tecnológico se usará, cómo se aterrizará y qué decisiones de arquitectura están involucradas;
Lista de tareas: dividir el plan en pasos ejecutables;
Proceso de implementación: modificar el código paso a paso según las tareas, en lugar de hacer una tanda caótica de cambios.

Este flujo hace que la programación con IA se parezca más a una colaboración de ingeniería y menos a una demostración basada en un único prompt.

Flujo básico de uso

El README oficial describe un flujo inicial parecido a este:

1
2
3

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@vX.Y.Z
specify init my-project --integration copilot
cd my-project

Después de la inicialización, el proyecto genera un directorio .specify, plantillas, scripts y comandos para la integración con el Agent. Luego se usan comandos /speckit.* dentro de un AI coding agent compatible para impulsar el desarrollo.

Una secuencia típica es:

/speckit.constitution
/speckit.specify
/speckit.clarify
/speckit.plan
/speckit.tasks
/speckit.implement

Aquí, /speckit.constitution establece los principios del proyecto, /speckit.specify describe los requisitos del producto, /speckit.clarify completa los puntos ambiguos, /speckit.plan genera el plan técnico, /speckit.tasks divide el trabajo en tareas y, al final, /speckit.implement ejecuta la implementación.

Esto es muy distinto de decirle directamente a un Agent: “ayúdame a construir una aplicación”. Spec Kit exige aclarar primero qué se va a construir y cómo se aceptará, y solo después dejar que el Agent empiece a trabajar.

Cambia el punto de entrada de la programación con IA

La programación tradicional con IA suele empezar desde el código:

`1`	`Quiero crear una aplicación de gestión de tareas. Ayúdame a escribirla.`

Spec Kit se parece más a esto:

Primero define los usuarios, escenarios, límites funcionales, criterios de aceptación y no objetivos de esta aplicación de gestión de tareas;
luego elige la solución técnica según esas especificaciones;
después divídelo en tareas;
finalmente impleméntalo paso a paso.

Este cambio es importante. La IA es muy buena ejecutando a partir de contexto, pero si el contexto en sí es disperso, cuanto más rápida sea la ejecución, más rápido puede desviarse la dirección. Spec Kit convierte el contexto en archivos y plantillas, de modo que los requisitos, planes y tareas puedan revisarse, modificarse y versionarse.

Dicho de otra forma, no hace que la IA sea más “libre”; le da una vía de ingeniería más clara para que pueda desplegarse con libertad.

Cómo entender los comandos principales

`/speckit.constitution`

Esta es la “constitución” del proyecto. Genera o actualiza .specify/memory/constitution.md, que registra los principios a largo plazo del proyecto, por ejemplo calidad del código, estándares de pruebas, consistencia de experiencia de usuario, requisitos de rendimiento y reglas para decisiones técnicas.

Este paso es adecuado para escribir consensos del equipo, no requisitos de una única función.

`/speckit.specify`

Esta es la fase de especificación funcional. Hay que describir qué se quiere construir, quiénes son los usuarios, qué problema se resuelve y cuáles son los flujos principales.

La guía oficial enfatiza especialmente que en esta fase no se debe prestar atención demasiado pronto al stack tecnológico. Primero hay que aclarar el what y el why, y luego discutir el how.

`/speckit.clarify`

Esta es la fase para completar preguntas. Muchos requisitos tienen huecos cuando se escriben por primera vez: cómo se gestionan los permisos, cuáles son los estados de error, si los datos deben persistirse, cómo se aceptan las condiciones límite.

El valor de /speckit.clarify está en permitir que el Agent detecte activamente los puntos inciertos de la especificación y registre las respuestas de vuelta en el documento, reduciendo retrabajo más adelante.

`/speckit.plan`

Esta es la fase de planificación técnica. Solo aquí se empieza a definir el framework, la base de datos, la arquitectura, las APIs, la estrategia de pruebas y las restricciones.

Si /speckit.specify es lenguaje de producto, /speckit.plan es lenguaje de ingeniería.

`/speckit.tasks`

Este paso divide el plan en tareas ejecutables. Una buena lista de tareas debería permitir que el Agent avance paso a paso, y también permitir que las personas entiendan el propósito de cada paso.

`/speckit.implement`

Solo al final se entra en la implementación. El Agent modifica el código según las especificaciones, planes y tareas asentados previamente. En ese momento ya no está adivinando requisitos a partir de un gran prompt, sino ejecutando dentro de un conjunto de documentos estructurados.

Por qué encaja con la programación con IA

El valor de Spec Kit no está en un comando mágico concreto, sino en recuperar lo que más fácilmente se pierde en la programación con IA:

Los requisitos se pueden revisar;
Los planes se pueden discutir;
Las tareas se pueden rastrear;
Las decisiones tienen contexto;
Los artefactos pueden entrar en el historial de Git;
Los equipos pueden reutilizar plantillas y principios;
La implementación del Agent ya no depende solo de un registro de chat de una sola vez.

Esto es especialmente útil para proyectos complejos. Cuanto más involucre un proyecto colaboración entre varias personas, mantenimiento a largo plazo y requisitos de calidad altos, menos puede depender solo de prompts temporales para impulsar el desarrollo.

Extensions y Presets

Spec Kit también ofrece dos tipos de personalización:

Extensions: añadir nuevos comandos, nuevas plantillas o integraciones con herramientas externas;
Presets: cambiar el formato y la terminología de las plantillas existentes de especificación, plan y tareas.

En términos simples: si quieres añadir una capacidad nueva, usa Extension; si quieres transformar el estilo del flujo de trabajo, usa Preset.

Por ejemplo, un equipo puede usar un Preset para exigir revisión de seguridad, trazabilidad regulatoria, terminología de dominio o reglas de pruebas primero. También puede usar una Extension para añadir integración con Jira, revisión de código, comprobaciones de salud del proyecto y otras fases nuevas.

Esto muestra que Spec Kit no intenta encerrar a todos los equipos en el mismo flujo. Proporciona un esqueleto extensible para desarrollo guiado por especificaciones.

Para quién es adecuado

Spec Kit encaja en escenarios como estos:

Usar un AI coding agent para crear el prototipo de un proyecto nuevo;
Convertir vibe coding en un flujo que se pueda revisar posteriormente;
Unificar el formato de requisitos y planificación antes de que el equipo deje que la IA genere código;
Proyectos que necesitan criterios de aceptación y requisitos de pruebas claros;
Incorporar requisitos, planes, tareas y proceso de implementación al control de versiones;
Equipos que están explorando usos colectivos de GitHub Copilot, Claude Code, Codex CLI y herramientas similares.

No necesariamente encaja con scripts muy pequeños de una sola vez. Para problemas que se resuelven con unas pocas líneas de código, el flujo completo de especificación puede sentirse pesado. Pero en cuanto una tarea empieza a involucrar varias páginas, varios módulos, gestión de estado, permisos, modelos de datos o mantenimiento a largo plazo, el beneficio estructural de Spec Kit se vuelve evidente.

Mi lectura

Spec Kit representa un giro importante en las herramientas de programación con IA: pasar de “hacer que el Agent escriba código más rápido” a “hacer que el Agent participe de forma más fiable en la ingeniería de software”.

La programación con IA del pasado se centraba en prompts y capacidad del modelo. Spec Kit presta más atención al proceso, los artefactos y las restricciones. Nos recuerda que cuanto más rápido escribe código la IA, menos podemos permitirnos omitir especificaciones, planes y aceptación.

Si ya estás acostumbrado a dejar que la IA implemente funciones directamente, puedes probar a cambiar el movimiento inicial con Spec Kit:

Primero deja que la IA te ayude a escribir los requisitos como una especificación; después deja que escriba el código.

Ese paso puede parecer más lento, pero en la práctica reduce el retrabajo posterior de “el código está terminado, pero no es lo que quería”.

Referencias

github/spec-kit

¿Qué es oh-my-pi? Un asistente de programación con IA que conecta la terminal, el IDE y el depurador

Sat, 23 May 2026 19:02:20 +0800

oh-my-pi es un AI Coding Agent para la terminal y el editor. Nace como un fork del proyecto Pi de Mario Zechner y fue ampliado por can1357. Su objetivo no es ofrecer solo una interfaz de chat en línea de comandos, sino conectar lectura de archivos, búsqueda de código, ediciones estructuradas, LSP, depuradores, navegador, subagentes y múltiples proveedores de modelos dentro de un mismo flujo de trabajo.

Según el README del proyecto, se parece más a una capa de herramientas para programación con IA que a un asistente sencillo: se puede usar de forma interactiva en la terminal, conectar con editores mediante ACP o integrar en proyectos Node mediante el SDK. Para quienes ya usan Claude Code, Codex CLI, Cline, Cursor u otras herramientas tipo Agent, lo interesante de oh-my-pi es que convierte muchas capacidades normalmente dispersas en herramientas externas en una superficie integrada.

Qué problema intenta resolver

En muchas herramientas de programación con IA, el punto débil no es el modelo, sino la interfaz de herramientas que lo rodea. Si el modelo quiere modificar código pero solo puede leer archivos completos de forma poco precisa, hacer reemplazos frágiles de cadenas y ejecutar shell de una sola vez, la propia herramienta amplifica los fallos.

oh-my-pi intenta reducir esos puntos de fricción:

Al leer archivos, prioriza resúmenes estructurados en vez de meter archivos completos en el contexto.
Search, glob, find, resaltado de sintaxis y conteo de tokens se implementan de forma nativa cuando es posible, reduciendo la dependencia de comandos externos.
Al escribir código, puede usar LSP para que renombrados, referencias y movimientos de archivos se comporten más como operaciones de IDE.
Para depurar, puede usar herramientas DAP como lldb, dlv y debugpy, en vez de depender solo de logs y suposiciones.
Las tareas complejas se pueden dividir entre subagentes y devolver como resultados estructurados.
Las ediciones usan anclas de contenido y vista previa para reducir la posibilidad de que un patch incorrecto se escriba directamente en disco.

Estas decisiones muestran que el foco no es “si el modelo puede responder”, sino “si el modelo puede completar de forma fiable un cambio real en el código”.

Instalación

El proyecto ofrece varias vías de instalación. En macOS y Linux se puede usar el script de instalación:

`1`	`curl -fsSL https://omp.sh/install \| sh`

Si usas Bun, el README recomienda instalar globalmente el paquete npm:

`1`	`bun install -g @oh-my-pi/pi-coding-agent`

En Windows PowerShell:

`1`	`irm https://omp.sh/install.ps1 \| iex`

El README también menciona fijar versiones con mise:

`1`	`mise use -g github:can1357/oh-my-pi`

Antes de instalar, conviene revisar el requisito de versión de Bun. El README indica soporte para macOS, Linux y Windows, y requiere bun >= 1.3.14.

Capacidades que conviene observar

1. Las llamadas a herramientas van más allá del shell

oh-my-pi incluye herramientas para leer archivos, buscar, escribir, editar, hacer ediciones AST, usar navegador, dividir tareas, depurar y trabajar con LSP. El README menciona 32 herramientas integradas, 13 operaciones LSP y 27 operaciones DAP.

Eso significa que el Agent no tiene que envolver todo como salida de línea de comandos. La búsqueda de referencias puede ir por LSP, los PR e issues pueden leerse mediante una interfaz unificada parecida a un sistema de archivos, y las páginas web o PDF pueden convertirse a Markdown conservando la estructura de enlaces antes de entregarse al modelo.

2. La integración LSP sirve en bases de código reales

En proyectos grandes, renombrar o mover archivos suele romper re-exports, imports con alias, barrel files o referencias entre directorios. El README de oh-my-pi destaca que las rutas de escritura pueden pasar por LSP. Por ejemplo, los renombrados de archivos usan workspace/willRenameFiles, acercando la edición a una operación semántica de IDE.

Esto es útil para refactorizaciones diarias en TypeScript, Rust, Go, Python y proyectos similares, sobre todo cuando el cambio manual es posible pero fácil de dejar incompleto.

3. El depurador es una herramienta de primera clase

Muchos flujos de programación con IA siguen depurando mediante logs, nuevas ejecuciones y lectura de salida. oh-my-pi conecta depuradores DAP a la superficie de herramientas. El README da ejemplos con programas en C usando lldb, servicios Go usando dlv y procesos Python usando debugpy.

Esto cambia cómo un Agent aborda un bug: puede pausar un proceso, inspeccionar frames de la pila, leer variables locales y decidir el siguiente paso, en vez de adivinar solo desde el texto del error.

4. Hashline reduce fallos de patch

El proyecto enfatiza Hashline, un método de edición basado en anclas de contenido. La idea es que el modelo apunte al contenido que quiere cambiar, en lugar de emitir diffs grandes una y otra vez. Esto reduce errores causados por espacios, contexto obsoleto o fallos al encontrar cadenas.

Para una herramienta tipo Agent, este mecanismo importa mucho. Aunque el modelo sea capaz, si la interfaz de escritura falla constantemente, la experiencia termina siendo una cadena de reintentos.

5. Subagentes y aislamiento de workspace

El README presenta la capacidad de subagentes con task: una tarea puede dividirse entre workers aislados, y los resultados vuelven como objetos estructurados. El proyecto también incluye lógica de aislamiento de workspace para tareas paralelas, exploración por ramas y prevención de ediciones solapadas.

Esto encaja con revisión de código, migraciones, arreglos masivos e investigación de tests. El valor no es solo que sea más rápido en paralelo, sino que separa mejor los caminos de exploración y sus cambios.

6. Puede heredar reglas y configuraciones existentes

En el primer arranque, oh-my-pi puede leer reglas y configuraciones dejadas por otras herramientas, incluyendo .claude, .cursor, .windsurf, .gemini, .codex, .cline, .github/copilot y .vscode.

Esto es práctico. Muchos equipos ya han escrito reglas para varias herramientas de IA. Migrarlas de nuevo para cada herramienta es costoso, así que oh-my-pi intenta reutilizar lo que ya existe en disco.

Cuatro formas de entrada

El proyecto ofrece cuatro formas principales de uso:

TUI interactiva: ejecutar omp directamente en la terminal.
Comando de una sola vez: usar omp -p para enviar un único prompt.
Node SDK: integrarlo en un proyecto Node o TypeScript mediante @oh-my-pi/pi-coding-agent.
RPC / ACP: conectar otros programas y editores mediante stdio o Agent Client Protocol.

Esto significa que no está pensado solo para usuarios individuales de terminal. También deja espacio para IDE, plugins, plataformas de automatización y herramientas internas.

Para quién tiene sentido

oh-my-pi encaja especialmente con:

Desarrolladores que editan, depuran y revisan código a menudo desde la terminal.
Personas que ya usan AI Coding Agents, pero no están satisfechas con la lectura de archivos, patch, búsqueda o depuración.
Desarrolladores que quieren conectar un Agent a un editor, una capa RPC o un servicio Node.
Usuarios que necesitan alternar entre varios modelos y proveedores en una misma herramienta.
Creadores de herramientas interesados en LSP, DAP, edición AST y flujos con subagentes.

Si solo quieres un asistente de código tipo chat que funcione de inmediato, la curva de aprendizaje puede parecer alta. Está más orientado a quienes aceptan entender la cadena de herramientas y tratar el Agent como un entorno de desarrollo configurable.

Qué tener en cuenta

Primero, oh-my-pi sigue siendo un proyecto open source de evolución rápida. Hay commits frecuentes y muchos issues y pull requests, así que la instalación y el uso pueden cambiar.

Segundo, sus capacidades dependen mucho del entorno local. LSP, depuradores, Bun, autenticación de proveedores de modelos, configuración de terminal y diferencias entre Windows y Unix pueden afectar la experiencia.

Tercero, tener muchas herramientas integradas no significa que haya que activarlas todas en cada caso. En la práctica conviene habilitar las necesarias para la tarea y configurar bien reglas, permisos y límites de workspace.

Cuarto, un AI Agent puede escribir código, pero también puede cambiar el código equivocado. Incluso con vistas previas y ediciones ancladas por contenido, los proyectos importantes siguen necesitando control de versiones, tests y revisión humana.

Resumen

Lo interesante de oh-my-pi no es que sea otra shell de IA para la terminal. Lo interesante es que reorganiza la capa de herramientas que suele frenar la programación con IA: lectura de archivos, búsqueda, edición, LSP, depuración, navegador, subagentes e integración SDK dentro de un único flujo de Agent.

Vale la pena seguirlo si te interesa la infraestructura de programación con IA o si quieres comparar distintas rutas de Coding Agent. La competencia entre herramientas de programación con IA ya no va solo de la calidad de las respuestas del modelo. También consiste en quién logra conectar los modelos de forma fiable con bases de código reales, flujos reales de depuración y reglas reales de equipo. oh-my-pi es un intento open source ambicioso en esa dirección.

Referencias:

Proyecto en GitHub: https://github.com/can1357/oh-my-pi
Sitio oficial: https://omp.sh/
Documentación del SDK: https://omp.sh/docs/sdk

Verificación de parches con poc-lab: confirma si las vulnerabilidades recientes de alta severidad están corregidas, incluidas Chrome CSSFontFeatureValuesMap UAF, NGINX Rift, Dirty Frag y Fragnesia

Fri, 22 May 2026 23:13:24 +0800

poc-lab es un repositorio de PoC y scripts de reproducción para vulnerabilidades de alta severidad divulgadas recientemente. Se centra en material de reproducción de CVE recientes e impactantes, incluyendo vulnerabilidades del kernel Linux, Windows, macOS, contenedores, componentes de servicio y navegadores.

Por su enfoque, el repositorio se parece más a una base de materiales para investigación de seguridad que a una colección de herramientas de un clic para usuarios generales. Cada directorio de vulnerabilidad suele incluir scripts PoC, archivos de compilación y documentación para ayudar a investigadores a entender el impacto, las condiciones de reproducción y las referencias.

Contenido principal del proyecto

El repositorio está organizado actualmente por identificador de vulnerabilidad o por nombre público. Los nombres completos de vulnerabilidades listados incluyen:

CVE-2026-2441: Chrome CSSFontFeatureValuesMap use-after-free, también listado como Chrome CSSFontFeatureValuesMap UAF.
CVE-2026-27623: Pre-Authentication Denial of Service from malformed RESP request.
CVE-2026-31429: Slab Cross-Cache, una línea de explotación de cross-cache en slab del kernel Linux.
CVE-2026-31431: Copy Fail, una vulnerabilidad relacionada con el kernel Linux.
CVE-2026-31635: DirtyDecrypt, una vulnerabilidad relacionada con límites de seguridad del sistema.
CVE-2026-42945: NGINX Rift, una vulnerabilidad de alta severidad relacionada con NGINX.
CVE-2026-43284: Dirty Frag, una vulnerabilidad relacionada con el kernel Linux.
CVE-2026-43494: PinTheft, una vulnerabilidad relacionada con permisos o límites de seguridad de credenciales.
CVE-2026-43500: Dirty Frag, una vulnerabilidad relacionada con el kernel Linux.
CVE-2026-46300: Fragnesia, una vulnerabilidad relacionada con el kernel Linux.
CVE-2026-46333: SSH Keysign pwn, una vulnerabilidad relacionada con el límite de seguridad de SSH keysign.

Estos nombres muestran que el proyecto no se limita a una sola plataforma. Abarca navegadores, kernel Linux, componentes de servidor y límites de seguridad del sistema operativo. Para quienes trabajan en análisis de vulnerabilidades, validación de parches, escritura de reglas de detección y laboratorios de formación en seguridad, este tipo de material puede servir como referencia.

Estructura de directorios

El README del proyecto indica que cada directorio de vulnerabilidad intenta mantener una estructura consistente. Los archivos habituales incluyen:

exploit.py o exploit.sh: script PoC
README.md: información de la vulnerabilidad, versiones afectadas, pasos de reproducción y referencias
build o archivos de compilación relacionados: usados para compilar o preparar el entorno de reproducción

La estructura aproximada del repositorio es:

poc-lab/
├── CVE-2026-XXXXX/
│   ├── exploit
│   ├── build
│   └── README.md
├── VULN-NAME/
│   ├── exploit.sh
│   └── README.md
└── ...

Si una vulnerabilidad ya tiene identificador CVE, el directorio suele usar ese nombre. Si aún no tiene CVE asignado, puede usar el nombre público de la vulnerabilidad.

Casos de uso adecuados

Este tipo de repositorio es más adecuado para los siguientes usos:

Investigadores de seguridad que reproducen condiciones de activación de vulnerabilidades.
Equipos de seguridad empresarial que verifican si un parche es efectivo.
Ingenieros de detección que escriben reglas IDS, EDR, WAF o reglas basadas en logs.
Cursos de seguridad o formación interna que construyen entornos de laboratorio aislados.
Investigadores que comparan requisitos de explotación e ideas defensivas entre vulnerabilidades.

No es adecuado para escaneo directo en producción, y no debe usarse contra sistemas no autorizados. El valor de un PoC está en ayudar a entender el riesgo y verificar defensas, no en ampliar la superficie de ataque.

Qué tener en cuenta al usarlo

Primero, las pruebas deben realizarse en un entorno aislado. La reproducción de vulnerabilidades puede provocar caídas, cambios de privilegios, corrupción de archivos o indisponibilidad del servicio. No debe ejecutarse directamente en equipos de trabajo, servidores de producción o sistemas de terceros.

Segundo, hay que leer primero el README.md dentro de cada directorio de vulnerabilidad. Cada PoC tiene dependencias, versiones objetivo, condiciones de activación y riesgos distintos. Leer solo el README raíz no es suficiente.

Tercero, confirma los límites de autorización. Aunque un PoC sea público, ejecutarlo contra un sistema que no te pertenece o para el que no tienes permiso explícito puede crear riesgos legales y de cumplimiento.

Cuarto, después de reproducir, hay que volver al flujo defensivo. Eso incluye confirmar versiones parcheadas, añadir reglas de detección, revisar la superficie expuesta, actualizar inventarios de activos y documentar procedimientos de respuesta.

Por qué vale la pena seguir este tipo de repositorio

En los últimos años, el tiempo entre la divulgación de vulnerabilidades de alta severidad y la aparición de detalles públicos de reproducción se ha acortado. Para los defensores, los avisos de seguridad y las descripciones CVE a menudo no bastan. Los equipos también necesitan entender condiciones de activación, límites de explotación y señales de detección en entornos realistas.

El valor de repositorios como poc-lab está en organizar material disperso de reproducción de vulnerabilidades de alta severidad por directorio, ayudando a los investigadores a completar la validación de riesgos con más rapidez. No sustituye los avisos oficiales, los parches de proveedores ni las líneas base de seguridad, pero puede servir como material complementario para la verificación de parches y la ingeniería de detección.

También existe riesgo. Los PoC públicos reducen la barrera de reproducción. Si una organización no tiene gestión de parches e inventario de activos oportunos, el material público de reproducción puede ampliar la ventana de exposición. Para los equipos de seguridad empresarial, seguir estos proyectos importa, pero construir un proceso rápido de evaluación y remediación importa aún más.

Resumen

poc-lab es una colección de PoC y scripts de reproducción para vulnerabilidades recientes de alta severidad, con cobertura de kernel Linux, navegadores, componentes de servicio y problemas de seguridad del sistema operativo. Es útil para investigación de seguridad, verificación de parches y desarrollo de reglas de detección, pero debe usarse dentro de límites de autorización, aislamiento y divulgación responsable.

Para lectores generales, el punto no es “cómo ejecutar un PoC”. La lección importante es que, después de que una vulnerabilidad crítica se hace pública, la verificación y la explotación avanzan más rápido. Los equipos de seguridad necesitan completar identificación de activos, evaluación de parches, refuerzo de detección y cierre de riesgos con mayor rapidez.

Referencias:

Proyecto en GitHub: https://github.com/Unclecheng-li/poc-lab/tree/main
README en chino: https://github.com/Unclecheng-li/poc-lab/blob/main/README.zh-CN.md

Clasificación de proyectos open source de AI en GitHub: de Coding Agent a bases de conocimiento RAG

Thu, 21 May 2026 08:53:13 +0800

Esta página organiza proyectos de AI en GitHub por dirección de uso: AI Coding y Coding Agents, skills y flujos Agent, RAG y bases de conocimiento, creación multimodal, modelos locales e inferencia, aplicaciones verticales y automatización, e infraestructura para desarrollar aplicaciones de AI. Cuando aparezcan nuevos proyectos, pueden añadirse con la misma estructura.

Resumen por categoría

Categoría	Proyectos	Para quién empezar aquí
AI Coding y Coding Agents	22	Usuarios que trabajan con Claude Code, Codex, Cursor, agents de terminal o automatización de repositorios
Skills y flujos Agent	7	Usuarios que quieren estandarizar AI Coding, investigación o flujos de creación
RAG, bases de conocimiento y memoria	7	Usuarios que necesitan búsqueda documental, bases de conocimiento, memoria de largo plazo, crawling web o extracción estructurada
Aplicaciones verticales y automatización	7	Usuarios interesados en finanzas, trading, monitoreo de Xianyu, control de escritorio, automatización de navegador y otros escenarios prácticos
Multimodal y creación de contenido	5	Usuarios que trabajan con imágenes, video, transcripción, librerías de prompts y distribución de contenido
Infraestructura para aplicaciones de AI	5	Desarrolladores que construyen apps de AI, automatización de navegador o toolchains Prompt/MCP
Modelos locales e inferencia	1	Usuarios interesados en DeepSeek local, motores de inferencia y adaptación de hardware

La distribución muestra varias direcciones frecuentes en los proyectos open source actuales de AI: las herramientas de AI Coding son las más numerosas, seguidas por flujos Agent, bases de conocimiento RAG y escenarios aplicados. Hay menos proyectos centrados solo en inferencia local porque mucho contenido de despliegue local se organiza alrededor de modelos, GPUs o planes de despliegue, no de un único proyecto de GitHub.

AI Coding y Coding Agents

Esta categoría se centra en comprensión de código, modificación de código, flujos de ingeniería y agents de terminal. Es el grupo más grande, con 22 proyectos.

Proyecto	Artículo	GitHub	Uso principal	Para quién
Ralph	Ralph: convertir Claude Code y Amp en un ciclo autónomo de desarrollo	snarktank/ralph	Guiar Claude Code / Amp por PRD, planificación, ejecución y revisión	Quienes quieren ordenar el flujo de AI Coding
Claude-Mem	Claude-Mem: memoria de largo plazo entre sesiones para Claude Code	thedotmack/claude-mem	Añadir memoria entre sesiones a Claude Code	Usuarios intensivos de Claude Code
Claude Code Hooks Mastery	Claude Code Hooks Mastery: introducción a 13 etapas del ciclo de hooks	disler/claude-code-hooks-mastery	Aprender el ciclo de vida de hooks y control de automatización	Quienes quieren personalizar Claude Code
Compound Engineering Plugin	Compound Engineering Plugin: convertir AI Coding en ciclos de planificación, ejecución y revisión	EveryInc/compound-engineering-plugin	Dividir AI Coding en planificación, ejecución y revisión	Usuarios que buscan ingeniería más disciplinada
free-claude-code	free-claude-code: conectar Claude Code a OpenRouter, DeepSeek y modelos locales	Alishahryar1/free-claude-code	Conectar Claude Code a distintos backends mediante proxy	Usuarios que quieren reducir costes
Hermes Agent	Qué es Hermes Agent: visión general, ventajas, inicio rápido y comparación con OpenClaw	NousResearch/hermes-agent	Framework local de Agent con herramientas y ejecución de tareas	Usuarios que quieren correr Agents locales
OpenHarness	Qué puede hacer OpenHarness como Agent Harness open source	HKUDS/OpenHarness	Agent Harness y ejecución multi-agent	Investigadores de orquestación Agent
CodexBridge	Usar Codex con modelos nacionales: API compatibles con OpenAI y CodexBridge	begonia599/CodexBridge	Conectar Codex a APIs compatibles con OpenAI	Usuarios que quieren usar Codex con modelos nacionales
ccx	Usar CCX para gestionar APIs compatibles con OpenAI para Codex y modelos nacionales	BenedictKing/ccx	Gestionar proxies de API para Claude, Codex, Gemini y más	Usuarios que alternan varios modelos
cc-haha	cc-haha: un escritorio de trabajo para Claude Code	NanmiCoder/cc-haha	Workspace de escritorio y entrada Computer Use para Claude Code	Usuarios de Claude Code que prefieren GUI
DeepSeek-TUI	DeepSeek-TUI: convertir DeepSeek V4 en un agente de programación en terminal	Hmbown/DeepSeek-TUI	Ejecutar un agente de programación DeepSeek en terminal	Usuarios de DeepSeek y línea de comandos
Open Design	Open Design: convertir Claude Code y Codex en herramientas de diseño AI	nexu-io/open-design	Llevar Claude Code / Codex a generación de diseño	Usuarios que quieren agentes para prototipos
agentmemory	agentmemory: memoria persistente para Claude Code, Codex y Cursor	rohitg00/agentmemory	Añadir memoria persistente a coding agents	Desarrolladores con proyectos largos
Graphify	Graphify: convertir una base de código en un grafo consultable por AI	safishamsi/graphify	Convertir código en grafo de conocimiento para reducir lecturas repetidas	Usuarios con bases de código grandes
oh-my-pi	Qué es oh-my-pi: un asistente de AI coding que conecta terminal, IDE y depurador	can1357/oh-my-pi	Conectar terminal, IDE, LSP y depurador como consola local de AI coding	Desarrolladores que quieren unir flujos CLI e IDE
Claude Plugins Official	Claude Code ya tiene directorio de plugins: qué instalar, cómo instalarlo y qué cuidar	anthropics/claude-plugins-official	Directorio oficial de plugins de Claude Code y punto de instalación	Usuarios que quieren ampliar Claude Code
CodeGraph	Qué es CodeGraph: un mapa local de código para Claude Code, Codex y Cursor	colbymchenry/codegraph	Generar índices locales y grafos de relación para ayudar a Coding Agents a entender proyectos	Desarrolladores que mantienen bases de código medianas o grandes
CC Switch	CC Switch: gestionar Claude Code, Codex, Gemini CLI y OpenClaw en una herramienta de escritorio	farion1231/cc-switch	Gestionar varias CLI de AI y cambios de cuenta/configuración	Usuarios de varias CLI
Warp	Warp open source: del terminal al Agentic Development Environment	warpdotdev/warp	Terminal y entorno de desarrollo agentic	Usuarios intensivos de terminal
opencode	opencode vs Claude Code vs Codex: guía de herramientas open source de AI Coding	anomalyco/opencode	Agent open source para AI Coding	Quienes buscan alternativas a Claude Code / Codex
9Router	9Router: conectar Claude Code, Codex y Cursor a un único router de AI	decolua/9router	Ruteo de modelos para AI Coding y control de coste de tokens	Usuarios multi-herramienta y multi-modelo
goose	goose: AI Agent open source para escritorio, CLI y API	aaif-goose/goose	Agent open source en escritorio, CLI y API	Usuarios que quieren un workspace Agent general

Skills y flujos Agent

Esta categoría convierte capacidades de AI en skills, procesos y especificaciones repetibles. Incluye 7 proyectos.

Proyecto	Artículo	GitHub	Uso principal	Para quién
mattpocock/skills	Rechazar Vibe Coding: el repo skills de Matt Pocock añade restricciones de ingeniería	mattpocock/skills	Usar skills para controlar flujos de AI Coding	Quienes quieren disciplina de ingeniería para Agents
Superpowers	Superpowers: devolver Coding Agents al flujo de ingeniería	obra/superpowers	Framework de skills agentic y metodología de desarrollo	Quienes quieren flujos sistemáticos con Coding Agents
Prompt-Vault	Prompt-Vault: biblioteca de especificaciones de prompts para probar AI Coding	w512/Prompt-Vault	Reunir prompts de prueba para AI Coding	Evaluadores de modelos y herramientas
web-video-presentation	web-video-presentation: skill Agent para convertir artículos en videos web grabables	ConardLi/garden-skills	Convertir artículos en videos web grabables	Creadores y usuarios de automatización
nuwa-skill	nuwa-skill: convertir “destilar una persona” en un flujo ejecutable	alchaincyf/nuwa-skill	Reproducir estilo expresivo y flujo de pensamiento con skill	Usuarios que construyen Agents de estilo
Scientific Agent Skills	Scientific Agent Skills: entregar flujos científicos a AI Agents	K-Dense-AI/scientific-agent-skills	Colección de skills para investigación científica	Investigadores, analistas y redactores técnicos
easy-vibe	easy-vibe: mapa de aprendizaje para principiantes de Vibe Coding	datawhalechina/easy-vibe	Mapa de aprendizaje de Vibe Coding	Principiantes de AI Coding

RAG, bases de conocimiento y memoria

Esta categoría aborda búsqueda documental, construcción de bases de conocimiento, memoria de largo plazo y extracción estructurada. Incluye 7 proyectos.

Proyecto	Artículo	GitHub	Uso principal	Para quién
LangExtract	Google LangExtract: extraer datos estructurados de textos largos con LLM	google/langextract	Extraer información estructurada de textos largos	Usuarios de extracción de información y datos
qmd	qmd: búsqueda local en Markdown para AI Agents	tobi/qmd	Búsqueda local en documentos Markdown	Usuarios que gestionan conocimiento en Markdown
Firecrawl	Firecrawl: búsqueda, crawling e interacción web para AI Agents	firecrawl/firecrawl	Crawling web, búsqueda y entrada de datos estructurados	Usuarios de RAG e ingestión de datos para Agents
RAGFlow	RAGFlow: funciones y uso de un motor RAG open source	infiniflow/ragflow	Motor RAG open source	Bases de conocimiento empresariales y Q&A documental
OpenHuman	OpenHuman: ruta de escritorio para AI Agent personal open source	tinyhumansai/openhuman	Agent personal local-first y capa de memoria	Usuarios que quieren integrar datos personales
OpenKB	OpenKB: compilar documentos en bases de conocimiento LLM actualizables	VectifyAI/OpenKB	Compilar documentos en bases de conocimiento actualizables	Mantenedores de documentación y conocimiento
PageIndex	PageIndex: indexación RAG razonada sin bases vectoriales	VectifyAI/PageIndex	Indexación documental razonada sin bases vectoriales	Usuarios que siguen nuevas rutas de RAG

Multimodal y creación de contenido

Esta categoría cubre imágenes, video, transcripción y distribución de contenido. Incluye 5 proyectos.

Proyecto	Artículo	GitHub	Uso principal	Para quién
rembg	rembg: herramienta local para quitar fondos de imágenes	danielgatis/rembg	Eliminación local de fondos	E-commerce, diseño y procesamiento de imágenes
awesome-gpt-image-2-prompts	Biblioteca de prompts GPT-Image 2: e-commerce, pósters, retratos y UI	EvoLinkAI/awesome-gpt-image-2-prompts	Prompts y casos para GPT-Image 2	Usuarios de AI Art y prompts
faster-whisper	faster-whisper: motor Whisper más rápido para transcripción	SYSTRAN/faster-whisper	Speech-to-text de alto rendimiento	Usuarios de subtítulos, transcripción y voz
Pixelle-Video	Pixelle-Video: motor AI open source para generar videos cortos desde un tema	AIDC-AI/Pixelle-Video	Flujo para generar videos cortos desde un tema	Creadores de videos cortos y AIGC
AiToEarn	¿Demasiadas plataformas de contenido? AiToEarn usa Agents para ahorrar trabajo	yikart/AiToEarn	Distribución multicanal y automatización para creadores	Operadores de contenido y creadores

Modelos locales e inferencia

Esta categoría se centra en ejecución local de modelos y experimentos de inferencia. Actualmente tiene menos proyectos, con 1 proyecto.

Proyecto	Artículo	GitHub	Uso principal	Para quién
ds4	Ejecutar DeepSeek 4 localmente: Antirez ds4 en Apple Silicon Mac	antirez/ds4	Experimentar con DeepSeek 4 en Apple Silicon	Usuarios de modelos locales e inferencia

Aplicaciones verticales y automatización

Esta categoría aplica Agents o AI a finanzas, trading, navegadores, escritorio, monitoreo de comercio electrónico y otros escenarios concretos. Incluye 7 proyectos.

Proyecto	Artículo	GitHub	Uso principal	Para quién
TradingAgents-CN	TradingAgents-CN: framework multi-agent para investigación de trading financiero en chino	hsliuping/TradingAgents-CN	Framework multi-agent de investigación financiera	Investigadores quant, financieros y de Agents
FinceptTerminal	FinceptTerminal: terminal financiero open source, investigación quant y workspace AI Agent	Fincept-Corporation/FinceptTerminal	Terminal financiero, investigación quant y workspace Agent	Analistas financieros y usuarios quant
Anthropic financial-services	Anthropic financial-services: plantillas reutilizables para escenarios Agent financieros	anthropics/financial-services	Plantillas de Agents para servicios financieros	Usuarios que crean soluciones AI financieras
ai-goofish-monitor	ai-goofish-monitor: sistema open source de monitoreo AI para productos de Xianyu	Usagi-org/ai-goofish-monitor	Monitoreo de productos y automatización de Xianyu	Usuarios de monitoreo de segunda mano
CloakBrowser	CloakBrowser: navegador más humano para Playwright y Puppeteer	CloakHQ/CloakBrowser	Entorno de automatización de navegador más humano	Automatización de navegador y operación Agent
UI-TARS-desktop	¿Dejar que AI use el ordenador? UI-TARS-desktop conecta escritorio, navegador y herramientas	bytedance/UI-TARS-desktop	Agent para operar escritorio, navegador y herramientas	Usuarios que quieren que AI opere el ordenador
AI-Trader	Qué es AI-Trader: plataforma para señales y simulación de trading con Agents	HKUDS/AI-Trader	Señales de trading y simulación con AI Agent	Investigadores de trading y Agents financieros

Infraestructura para aplicaciones de AI

Esta categoría ofrece componentes base para construir aplicaciones de AI y toolchains Agent. Incluye 5 proyectos.

Proyecto	Artículo	GitHub	Uso principal	Para quién
Prompt Optimizer	Prompt Optimizer: optimización, pruebas y herramientas MCP open source	linshenkx/prompt-optimizer	Optimización de prompts, pruebas y MCP	Usuarios de prompt engineering y ajuste de apps
Playwright CLI	Playwright CLI: instalación, skills, sesiones y comandos comunes	microsoft/playwright-cli	CLI de automatización de navegador para coding agents	Usuarios Agent que necesitan operar navegador
Vercel AI SDK	Qué es Vercel AI SDK: toolkit unificado para apps AI en TypeScript	vercel/ai	SDK para aplicaciones AI en TypeScript	Desarrolladores front-end y full-stack
CLIProxyAPI	CLIProxyAPI: envolver Codex, Claude Code y Gemini CLI como APIs unificadas	router-for-me/CLIProxyAPI	Envolver varias CLI de AI y estados OAuth como APIs compatibles	Usuarios que quieren acceso unificado a Codex, Claude Code y Gemini CLI
CLIProxyAPI Management Center	CLIProxyAPI Management Center: una consola visual para administrar CLIProxyAPI	router-for-me/Cli-Proxy-API-Management-Center	Interfaz web para configuración, cuentas, logs y OAuth de CLIProxyAPI	Usuarios que usan CLIProxyAPI como gateway de equipo o pool de cuentas

No subas API Keys a GitHub: guía para evitar fugas de secretos al programar con IA

Sat, 16 May 2026 16:26:50 +0800

La programación con IA reduce la barrera para crear software, pero también lleva muchos problemas de seguridad de ingeniería a principiantes y usuarios no técnicos.

Uno de los incidentes más comunes es subir a un repositorio público un API Key, Secret, Token, cadena de conexión a una base de datos o archivo .env. En local, estos archivos parecen simples configuraciones para que la aplicación funcione. En un repositorio público de GitHub, se convierten en credenciales que pueden ser escaneadas, llamadas y abusadas automáticamente.

Las fugas de secretos no son raras. El informe 2026 de GitGuardian indica que los commits públicos de GitHub en 2025 contenían unos 28,65 millones de nuevas credenciales hardcodeadas, y que las fugas de credenciales relacionadas con servicios de IA crecieron un 81% interanual. El problema ya no es solo descuido: la programación con IA, los prototipos rápidos y el alojamiento público están amplificando la escala.

Por qué los principiantes filtran claves con más facilidad

Muchos agentes de IA y pequeñas herramientas tienen dos “repositorios”: uno en el disco local y otro visible para todo el mundo en GitHub. El problema es que los principiantes a menudo no distinguen bien esa frontera.

Durante el desarrollo local, config.json, .env y settings.yaml pueden contener API keys. Después de ejecutar git add ., git commit y git push, esos archivos pueden subirse completos. Cuando el repositorio es público, los bots de escaneo no necesitan entender tu negocio: solo necesitan detectar un patrón de secreto.

La programación con IA agrava esto:

Los ejemplos generados por IA pueden poner OPENAI_API_KEY = "sk-..." directamente en el código fuente.
Para “hacer que funcione”, los principiantes tienden a hardcodear secretos en frontend, scripts o archivos de configuración.
Muchas plataformas de vibe coding despliegan aplicaciones directamente sin pasar por la protección de push de GitHub.
El usuario puede no saber qué archivos, APIs o permisos predeterminados existen dentro del proyecto generado por IA.

En resumen, la IA puede ayudarte a crear algo que funciona más rápido. No asume automáticamente la responsabilidad de seguridad.

`.gitignore` no es decoración

Git gestiona el historial de versiones, GitHub aloja el código y .gitignore le dice a Git qué archivos no deben entrar en ese historial.

Un proyecto básico de IA debería ignorar al menos:

.env
.env.*
*.key
*.pem
config.local.*
secrets.*
credentials.*

Pero .gitignore no basta. Solo evita que archivos no rastreados se añadan en el futuro. Si un archivo con secretos ya fue committeado, añadirlo después a .gitignore no lo elimina del historial.

Un hábito más seguro:

Crear .gitignore al inicio del proyecto.
Guardar API keys solo en variables de entorno o configuración local.
Proporcionar .env.example con placeholders, no secretos reales.
Ejecutar un escáner de secretos antes de hacer commit, como gitleaks, trufflehog o GitHub Secret Scanning.

Borrar el archivo no basta

Si una clave ya llegó a un repositorio público, la primera reacción no debería ser “borro el archivo y hago otro commit”. Primero revoca o rota la clave.

Git registra el historial. Aunque el último commit elimine el archivo, los commits antiguos, forks, clones, cachés y sistemas de escaneo pueden conservarlo. La documentación de GitHub también recomienda revocar o rotar contraseñas, tokens y credenciales como primer paso.

Orden recomendado:

Revoca la clave antigua en el panel del proveedor y genera una nueva.
Revisa facturación, registros de uso, IPs sospechosas y tráfico inusual.
Elimina secretos hardcodeados y usa variables de entorno o un gestor de secretos.
Limpia archivos sensibles del historial con git filter-repo o BFG.
Activa GitHub Secret Scanning y Push Protection.
Revisa CI/CD, plataformas de despliegue, funciones cloud y artefactos frontend por si contienen la clave antigua.

En servicios como OpenAI, Anthropic, DeepSeek, proveedores cloud, pagos, correo o bases de datos, una clave filtrada puede provocar algo más que una factura inesperada: lectura de datos, abuso del servicio, contaminación de la cadena de suministro o bloqueo de cuentas.

Los secretos reales no van en el frontend

Muchos principiantes ponen API keys en JavaScript del frontend porque la página funciona:

`1`	`const apiKey = "sk-xxxxxxxx";`

Eso equivale prácticamente a publicarlas. El código del navegador, las peticiones de red, los Source Map y los artefactos de build se pueden inspeccionar. Cualquier clave que deba ser secreta no debe aparecer en el cliente.

La forma correcta es que el frontend llame a tu propio backend, y que el backend lea variables de entorno y llame a la API externa:

// frontend
await fetch("/api/chat", {
  method: "POST",
  body: JSON.stringify({ message })
});

El servidor usa la variable de entorno:

1
2

// server
const apiKey = process.env.OPENAI_API_KEY;

Esto mantiene el secreto en el entorno del servidor y evita exponerlo a todos los visitantes.

Vibe Coding no elimina la responsabilidad de seguridad

El problema del vibe coding no se limita a GitHub. Muchas aplicaciones se publican directamente desde plataformas de programación con IA a internet, sin revisión de código, escaneo de repositorio ni pruebas de seguridad tradicionales.

Investigaciones recientes de RedAccess encontraron una gran cantidad de activos públicos generados o alojados por herramientas de programación con IA, y algunos exponían datos corporativos, información personal o archivos internos. La lección es clara: cuando “se puede desplegar” se vuelve demasiado fácil, se olvida preguntar “¿debería ser público?”, “¿debería ser solo interno?” y “¿tiene control de acceso?”.

Antes de publicar una app generada por IA, pregunta:

¿Esta aplicación necesita realmente acceso público?
¿Tiene login, autenticación y separación de permisos?
¿Expone URLs de bases de datos, API keys, tokens o webhooks en el frontend?
¿Tiene límites de cuota, dominio, permisos y caducidad para APIs externas?
¿Puedes desactivar claves y revertir despliegues rápidamente tras un incidente?

El código generado por IA también necesita revisión de seguridad. Cuanto menos código hayas escrito personalmente, menos deberías asumir que es seguro.

Comprobaciones para hacer ahora

Empieza por tu cuenta de GitHub. Busca tu usuario junto con:

API_KEY
SECRET
TOKEN
OPENAI_API_KEY
ANTHROPIC_API_KEY
DEEPSEEK_API_KEY
.env
config
credentials

Si encuentras una clave real, rota primero y limpia después. Si entró alguna vez en un repositorio público, trátala como filtrada.

Para futuros proyectos con IA, usa un proceso fijo:

Escribe .gitignore antes del código de negocio.
Usa .env.example para documentar las variables necesarias.
Pon todos los secretos en variables de entorno, no en el código fuente.
Da a las API keys permisos mínimos, cuotas y fechas de caducidad.
Activa GitHub Secret Scanning y Push Protection.
Pide a la IA una revisión de seguridad antes de publicar, pero no confíes solo en su conclusión.

El verdadero peligro de la programación con IA no es solo que escriba código incorrecto. Es que da a muchas personas, por primera vez, la capacidad de publicar rápidamente aplicaciones inseguras en internet. Escribir rápido no es el problema. Entregar secretos, datos y permisos sí lo es.

GitHub on KnightLi Blog

Qué es GitHub Spec Kit: usar el desarrollo guiado por especificaciones para encauzar la programación con IA

Qué es Spec Kit

Flujo básico de uso

Cambia el punto de entrada de la programación con IA

Cómo entender los comandos principales

/speckit.constitution

/speckit.specify

/speckit.clarify

/speckit.plan

/speckit.tasks

/speckit.implement

Por qué encaja con la programación con IA

Extensions y Presets

Para quién es adecuado

Mi lectura

Referencias

¿Qué es oh-my-pi? Un asistente de programación con IA que conecta la terminal, el IDE y el depurador

Qué problema intenta resolver

Instalación

Capacidades que conviene observar

1. Las llamadas a herramientas van más allá del shell

2. La integración LSP sirve en bases de código reales

3. El depurador es una herramienta de primera clase

4. Hashline reduce fallos de patch

5. Subagentes y aislamiento de workspace

6. Puede heredar reglas y configuraciones existentes

Cuatro formas de entrada

Para quién tiene sentido

Qué tener en cuenta

Resumen

Verificación de parches con poc-lab: confirma si las vulnerabilidades recientes de alta severidad están corregidas, incluidas Chrome CSSFontFeatureValuesMap UAF, NGINX Rift, Dirty Frag y Fragnesia

Contenido principal del proyecto

Estructura de directorios

Casos de uso adecuados

Qué tener en cuenta al usarlo

Por qué vale la pena seguir este tipo de repositorio

Resumen

Clasificación de proyectos open source de AI en GitHub: de Coding Agent a bases de conocimiento RAG

Resumen por categoría

AI Coding y Coding Agents

Skills y flujos Agent

RAG, bases de conocimiento y memoria

Multimodal y creación de contenido

Modelos locales e inferencia

Aplicaciones verticales y automatización

Infraestructura para aplicaciones de AI

No subas API Keys a GitHub: guía para evitar fugas de secretos al programar con IA

Por qué los principiantes filtran claves con más facilidad

.gitignore no es decoración

Borrar el archivo no basta

Los secretos reales no van en el frontend

Vibe Coding no elimina la responsabilidad de seguridad

Comprobaciones para hacer ahora

Referencias

`/speckit.constitution`

`/speckit.specify`

`/speckit.clarify`

`/speckit.plan`

`/speckit.tasks`

`/speckit.implement`

`.gitignore` no es decoración