القائمة
Usar para documentar API con endpoints, parámetros y ejemplos. Activar ante: documentar API, endpoints, OpenAPI, Swagger, parametros, respuestas de la API
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Alias global /alfred para abrir el asistente contextual de Alfred Dev sin escribir el namespace completo. Activar solo cuando el usuario invoque explicitamente /alfred.
Protocolo de respuesta ante incidentes en produccion: triaje, mitigacion, causa raiz y postmortem. Usar ante caidas, errores criticos, incidentes de seguridad o degradacion de servicio.
Usar para refactorizar código con tests como red de seguridad. Activar cuando el usuario quiera limpiar código, reducir complejidad, extraer función, mejorar nombres, eliminar duplicación, resolver un code smell o reorganizar la estructura interna sin cambiar comportamiento.
Generar Dockerfile optimizado. Activar cuando el usuario quiera crear contenedor, generar imagen Docker, configurar Docker Compose, contenerizar aplicacion o crear un Dockerfile multi-stage.
Planificar y ejecutar releases: inventario de cambios, versionado semantico, changelog, notas de release y publicacion. Usar antes de cada version nueva.
Auditar accesibilidad WCAG 2.1 nivel AA con checklist y correcciones. Activar ante: accesibilidad web, WCAG, lector de pantalla, contraste, navegacion por teclado, a11y
| name | api-docs |
| description | Usar para documentar API con endpoints, parámetros y ejemplos. Activar ante: documentar API, endpoints, OpenAPI, Swagger, parametros, respuestas de la API |
Este skill genera documentación completa de una API, cubriendo cada endpoint con sus parámetros, respuestas, códigos de error y ejemplos de uso. La documentación de API es el contrato entre el backend y sus consumidores (frontend, servicios externos, desarrolladores de terceros); si está mal documentada, genera confusión, bugs y soporte innecesario.
El formato puede ser Markdown para documentación legible o OpenAPI (Swagger) para documentación interactiva y generación automática de clientes.
Identificar los endpoints a documentar. Revisar el código del proyecto para listar todas las rutas expuestas. Agruparlas por recurso o dominio funcional.
Para cada endpoint, documentar:
/users/{id}).Cubrir los códigos de respuesta principales:
| Código | Significado | Cuándo se devuelve |
|---|---|---|
| 200 | OK | Petición exitosa (GET, PUT, PATCH) |
| 201 | Created | Recurso creado exitosamente (POST) |
| 204 | No Content | Operación exitosa sin cuerpo de respuesta (DELETE) |
| 400 | Bad Request | Datos de entrada inválidos |
| 401 | Unauthorized | Falta autenticación o token inválido |
| 403 | Forbidden | Autenticado pero sin permisos |
| 404 | Not Found | Recurso no existe |
| 409 | Conflict | Conflicto con el estado actual (duplicado, versión desactualizada) |
| 422 | Unprocessable Entity | Datos válidos pero no procesables por reglas de negocio |
| 429 | Too Many Requests | Rate limit excedido |
| 500 | Internal Server Error | Error inesperado del servidor |
Incluir ejemplos con curl. Para cada endpoint, al menos un ejemplo funcional:
curl -X POST https://api.ejemplo.com/users \
-H "Authorization: Bearer <token>" \
-H "Content-Type: application/json" \
-d '{"name": "Ana", "email": "ana@ejemplo.com"}'
Documentar códigos de error personalizados. Si la API devuelve errores con códigos propios, listarlos con su significado y la acción recomendada para el consumidor.
Si se usa OpenAPI, generar el fichero de especificación. Formato YAML o JSON compatible con OpenAPI 3.x. Incluir schemas reutilizables en components/schemas.
Verificar la documentación contra el código. Comprobar que cada endpoint documentado existe en el código y que los parámetros y respuestas coinciden. La documentación desactualizada es peor que no tener documentación.