Integrations auth
AI-first workspace bootstrapper — installs skills, packs, agents, and disciplines into .agents/. Cross-compatible with Claude Code and OpenCode.
npx -y skills add LuchoC-Dev/agent-kits --skill integrations-authAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Define las integraciones con terceros, la mensajería/eventos, y la estrategia de autenticación y autorización. Trigger cuando el usuario quiera "integrar un servicio externo", "autenticación", "autorización", "JWT o sesiones", "OAuth", "roles y permisos", "RBAC", "webhooks", "mensajería" o necesite cerrar cómo el backend se conecta hacia afuera y cómo protege sus recursos.
SKILL.md
3.8 KB, 921 tokens by cl100k_base, as published. Nobody here has run it
Integrations & Auth
Rol
Sos un integration & security engineer. Tu trabajo es definir cómo el backend se conecta con el mundo externo y cómo protege sus recursos.
Parámetro de depth
light— no aparece en Basic mode.full— integraciones, mensajería, autenticación y autorización completas.
Precondición
api-contract y service-architecture aprobados. Si existe stakeholders-map (del pack context), los stakeholders externos (proveedores de pago, couriers, etc.) son candidatos a integraciones.
Workflow
Paso 1 — Integraciones con terceros
Por cada servicio externo: qué provee, cómo se integra (SDK, API REST, webhook), cómo se aísla del resto del código (patrón Adapter según code-conventions), qué pasa si falla.
Paso 2 — Mensajería y eventos (si aplica)
Si el sistema usa eventos o colas: broker elegido, eventos publicados/consumidos, garantías de entrega (at-least-once, exactly-once), manejo de mensajes muertos.
Si el
domain-modeltiene eventos de dominio, mapealos acá a eventos técnicos cuando corresponda.
Paso 3 — Autenticación
Estrategia de autenticación, decidida con criterio:
- Sesiones con cookie — apps web clásicas, server-rendered.
- JWT — APIs stateless, clientes múltiples. Cuidado con revocación.
- OAuth 2 / OIDC — login con terceros, delegación.
- API keys — comunicación servicio-a-servicio.
Definí: dónde se emiten/validan los tokens, expiración, refresh, revocación.
Paso 4 — Autorización
- Modelo: RBAC (roles), ABAC (atributos), o permisos por recurso.
- Dónde se chequea la autorización (middleware, capa de servicio, ambos).
- Mapa de roles/permisos contra los endpoints del
api-contract.
Paso 5 — Secretos y datos sensibles
Cómo se gestionan secretos (variables de entorno, secret manager), qué datos se cifran, qué se loguea y qué nunca.
Output — docs/backend-design/NN-integrations-auth.md
NN= prefijo numérico de dos dígitos que asigna el workflow según el orden real de ejecución. No lo inventes — tomalo de la tabla del workflow que te invoca.
---
pack: backend-design
artifact: integrations-auth
---
# Integrations & Auth
## Integraciones con terceros
| Servicio | Qué provee | Cómo se integra | Si falla |
|---|---|---|---|
| ... | ... | ... | ... |
## Mensajería y eventos
> Broker, eventos, garantías de entrega, dead-letter. (Omitir si no aplica.)
## Autenticación
**Estrategia:** <sesiones | JWT | OAuth | API keys> — <justificación>
- Emisión / validación / expiración / refresh / revocación.
## Autorización
**Modelo:** <RBAC | ABAC | permisos por recurso>
- Dónde se chequea: ...
| Rol | Endpoints permitidos |
|---|---|
| ... | ... |
## Secretos y datos sensibles
> Gestión de secretos, cifrado, política de logging.
Reglas duras
- Toda integración externa se aísla detrás de un adapter — nunca se llama un SDK de tercero directo desde la lógica de dominio.
- Toda integración tiene un plan de "si falla" — timeouts, retries, fallback.
- La autorización se mapea contra los endpoints reales del
api-contract— sin huecos. - Nunca loguear secretos ni datos sensibles — definirlo explícito.
Gives 0 of the 12 instructions most auth identity skills give in 921 tokens
Counted across 409 of the 410 authors here whose files we hold, read 2026-08-06
- hash passwords with bcrypt or argon2in 53 of 409, across 43 files
- use parameterized queriesin 47 of 409, across 39 files
- load SECRET_KEY from environment variablesin 23 of 409, across 14 files
- validate all input server-sidein 19 of 409, across 11 files
- refresh access tokens before expiryin 17 of 409, across 9 files
- store tokens in httponly cookiesin 17 of 409, across 16 files
- store refresh tokens securelyin 16 of 409, across 6 files
- validate webhook signatures before processingin 15 of 409, across 5 files
- sanitize user inputsin 15 of 409, across 9 files
- implement rate limiting on auth endpointsin 14 of 409, across 9 files
- encrypt sensitive data at restin 13 of 409, across 10 files
- validate uploaded file extensions and sizesin 12 of 409, across 5 files
Said here and by no other author read
- isolate external integrations behind adapter pattern
- define failure plan for every integration
- map authorization model against real endpoints
- define token issuance, validation, expiration, refresh, revocation
- map domain events to technical events if applicable
- take numeric prefix from invoking workflow
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.