ForHosting KIT · Utilidades de desarrollo

Generar un README

Obtenga un README redactado a partir del código que de verdad publicó: el generador lee las carpetas, los archivos de dependencias, los scripts de compilación y pruebas y la licencia, y escribe las secciones de instalación y uso. Nunca adivina funciones por el nombre. Paga por uso, sin suscripción.

● BetaPor solicitud + por repositorio$0.003
Úselo desde WebAPIEmailTelegramApp pronto

Ejecute esto en nuestros servidores con su cuenta. Las herramientas gratuitas corren en su navegador; esta cobra de su saldo del KIT según el precio de arriba.

La mayoría de los README están ausentes, tienen tres años de desactualización, o son una plantilla copiada que nunca coincidió con el código real.

Por qué los README se quedan anticuados

La mayoría de los README no existen, llevan años sin tocarse o se copiaron de una plantilla que nunca encajó con el código. La deuda de documentación crece en silencio: un equipo publica funciones durante meses, aparecen scripts nuevos, un archivo de configuración cambia sus valores por defecto y el README sigue describiendo una herramienta de compilación que nadie usa desde hace un año. Quien llega nuevo clona el proyecto, sigue instrucciones que ya no valen y acaba rindiéndose o preguntando por el chat. Un generador que parte del propio repositorio cierra esa brecha, porque el borrador refleja el proyecto tal como está hoy.

Qué lee el generador y qué no hace

El borrador se basa en lo que hay en el repositorio. Los archivos que declaran el lenguaje y las dependencias indican lo que necesita el proyecto. La estructura de carpetas señala los puntos de entrada probables. Los scripts existentes muestran cómo se compila, se prueba y se ejecuta, y los archivos de licencia o configuración describen su intención. Con todo eso, el generador organiza un README con instalación, uso y otras secciones pertinentes. No inventa tecnologías ni supone funciones a partir del nombre del proyecto. Resulta especialmente útil a los equipos que crean muchos repositorios casi idénticos, cada uno con un README que nadie quiere escribir a mano.

La brecha entre el código y su documentación

La deuda de documentación crece en silencio. Un equipo entrega funciones durante meses, el archivo de dependencias suma scripts nuevos, un archivo de configuración cambia sus valores por defecto, y el README sigue diciendo que el proyecto usa una herramienta que nadie ha ejecutado en un año. Un colaborador nuevo clona el repositorio, sigue instrucciones que ya no aplican, y termina rindiéndose o preguntando en el chat del equipo. dev.readme apunta exactamente a ese momento: un repositorio que funciona pero se explica mal.

Actualización de forks por cliente

Una empresa que hace fork de un repositorio base para cada cliente regenera el README automáticamente después de cada fork para que refleje la configuración específica del cliente en vez del texto genérico de la plantilla original.

¿Realmente lee mi código, o solo adivina a partir del nombre del repositorio?

Lee archivos de manifiesto, dependencias, la estructura de carpetas y los scripts existentes para redactar el README a partir de lo que el repositorio realmente contiene.

¿Puede documentar un repositorio privado?

Sí, mientras usted proporcione una referencia a la que la tarea pueda acceder; el contenido del repositorio se elimina después del período de retención y nunca se usa para entrenamiento.

¿Qué pasa si el repositorio casi no tiene código todavía?

El borrador refleja lo que existe en el momento de la solicitud, así que un repositorio muy temprano obtendrá un README mínimo pero preciso, en lugar de uno inventado.

¿Qué incluye el README generado?

Un borrador ordenado con instalación, uso y otras secciones pertinentes. Cada una se construye con lo que muestra el repositorio: los archivos de dependencias, la estructura de carpetas para los puntos de entrada, los scripts existentes para compilar, probar y ejecutar, y los archivos de licencia o configuración.

¿Cuánto tarda en llegar el borrador?

Leer un repositorio lleva su tiempo, sobre todo si es grande, así que el borrador se entrega cuando está listo y no al instante. Después queda disponible mediante un enlace válido durante 24 horas.

Todo lo de esta página está disponible por programación. Esta sección es para equipos que quieren integrarlo en sus sistemas; el resto puede usar la herramienta de arriba sin más.

POSThttps://api.kit.forhosting.com/dev/readme

¿Prefiere automatizarlo? Un POST autenticado crea la tarea; el resultado llega por webhook o enlace firmado. La misma capacidad también se ejecuta aquí en la web, por email y desde Telegram — y pronto también desde nuestra app.

curl -X POST https://api.kit.forhosting.com/dev/readme \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"text":"El informe trimestral cerró con 1,2 M€ de ingresos."}'
{
  "text": "El informe trimestral cerró con 1,2 M€ de ingresos."
}
{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "dev.readme",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

La API es asíncrona: la llamada devuelve un task_id al instante y el resultado llega por webhook. El polling está limitado a 1 req/s por tarea.

Por solicitud$0.003
Por repositorio$0.0135

Precio publicado — sin tokens ni créditos inventados. Una tarea fallida no se cobra.

HTTPCódigoSignificado
401unauthorizedAPI key ausente o inválida.
402insufficient_balanceEl saldo no cubre el precio de la tarea.
404unknown_typeEl tipo de tarea no existe.
429rate_limitedDemasiadas peticiones. Use el webhook en vez de sondear.
422task_failedLa tarea falló tras 3 reintentos. No se cobra.

Este endpoint sí lee su repositorio — la estructura, las dependencias, los puntos de entrada — y redacta un README que describe el proyecto que usted realmente entregó, no el que una plantilla genérica asumió.

Qué inspecciona realmente el endpoint

No inventa una pila tecnológica ni adivina funciones a partir del nombre del proyecto; redacta a partir de lo que el código y sus metadatos realmente muestran, y organiza todo en un README estructurado con instalación, uso y las secciones que correspondan. Envíe POST a /dev/readme con una referencia al repositorio, y la tarea lee lo que en verdad está ahí: los archivos de manifiesto del lenguaje y sus dependencias, la estructura de carpetas para inferir los puntos de entrada probables, los scripts existentes para entender cómo se compila, prueba y ejecuta el proyecto, y cualquier archivo de licencia o configuración que revele su propósito.

Asíncrono por diseño, entregado cuando está listo

No hay que escribir un ciclo de sondeo ni arriesgarse a que un repositorio lento bloquee un hilo de solicitud. La llamada devuelve un task_id de inmediato, porque leer un repositorio —sobre todo uno grande— toma tiempo real; el borrador llega mediante una llamada de webhook firmada o un enlace firmado válido por 24 horas, según lo que su flujo ya esté escuchando.

Dónde encaja en un flujo automatizado

Los equipos que generan andamiaje, forks o repositorios de servicios internos de forma periódica terminan con decenas de proyectos casi idénticos, cada uno necesitando un README que nadie quiere escribir a mano. Conectar este endpoint a esa misma automatización significa que cada repositorio nuevo recibe un README real y actualizado en el momento en que se crea, cobrado por solicitud más por repositorio procesado, y un intento fallido no cuesta nada porque se reintenta automáticamente antes de cobrarse.

Una historia breve que vale la pena recordar

La convención del README se remonta a las primeras distribuciones de código fuente en Unix, donde un archivo de texto plano le explicaba a un desconocido cómo compilar y ejecutar el software antes de que existiera un gestor de paquetes que lo hiciera por él. Ese propósito original —orientar rápido a alguien que no sabe nada del proyecto— sigue siendo la vara con la que este endpoint redacta, décadas y muchísimos frameworks después.

Microservicios recién generados

Un equipo de plataforma genera un repositorio de servicio nuevo a partir de una plantilla cada vez que un equipo arranca un proyecto, y este endpoint completa el README con las dependencias y scripts reales del servicio en lugar del texto de relleno de la plantilla.

Incorporación a proyectos de código abierto

Un mantenedor hereda un repositorio sin documentación y lo pasa por este endpoint para obtener un primer borrador preciso, y edita desde ahí en lugar de partir de un archivo en blanco.

Herramientas internas a gran escala

Una organización con cientos de repositorios internos procesa este endpoint sobre todos ellos durante la noche para que cada herramienta tenga un README base, incluso las que nadie ha tocado en años.

¿Cómo funciona la API para generar README?

Envíe por POST una referencia a su repositorio a /dev/readme, guarde el task_id devuelto y reciba el README redactado por webhook o mediante un enlace firmado válido por 24 horas.

¿Es gratis la API para generar README?

No, no hay plan gratuito ni prueba; cuesta $0.003 por solicitud más $0.0135 por repositorio procesado, y una tarea fallida nunca se cobra.

¿Sobrescribirá mi README existente?

No, el endpoint devuelve un README redactado como resultado; aplicarlo o no al repositorio, y cómo hacerlo, depende enteramente de su propio flujo de trabajo.

¿Puedo generar README para muchos repositorios en lote?

Sí, envíe una tarea asíncrona por repositorio y reciba cada resultado por webhook a medida que termine, lo cual encaja bien en un flujo por lotes o programado.

¿Ya está disponible este endpoint?

Sí, /dev/readme está disponible y aceptando solicitudes ahora mismo.

Ver la documentación completa del KIT →