onboarding-dev

Skill: Onboarding Dev — Buddy IA

Seguridad: @docs/rules/domain/autonomous-safety.md — el buddy IA NO toma decisiones, solo orienta. Basado en: Guía de Onboarding con IA de Manfred (v3.0) — modelo de agente en 3 capas. Complementa: team-onboarding (RGPD, evaluación) — esta skill se enfoca en onboarding técnico.

Cuándo usar esta skill

• Se incorpora un nuevo desarrollador al proyecto
• Se quiere acelerar el ramp-up de 4-8 semanas a 5-10 días
• Se necesita generar documentación del proyecto automáticamente
• Se busca reducir la dependencia del buddy humano para preguntas repetitivas

Qué produce

Fase 1: Auto-análisis (10-12 documentos)

projects/{proyecto}/onboarding/
├── 01-arquitectura-alto-nivel.md       ← Diagrama + explicación de servicios y flujos
├── 02-mapa-equipos-ownership.md        ← Quién lleva cada área/sistema
├── 03-glosario-interno.md              ← Vocabulario, siglas, nombres de proyectos
├── 04-herramientas-accesos.md          ← Checklist de configuraciones y accesos
├── 05-setup-local.md                   ← Guía paso a paso + troubleshooting típico
├── 06-flujos-pr-estandares.md          ← Convenciones de commit, PR, review, CI/CD
├── 07-como-se-despliega.md             ← Entornos, releases, rollback, permisos
├── 08-decisiones-tecnicas-clave.md     ← Por qué se eligió X, qué trade-offs se aceptaron
├── 09-historico-incidencias.md         ← Incidencias importantes y postmortems resumidos
├── 10-faq-onboarding.md               ← Preguntas más repetidas y sus respuestas
├── 11-calidad-procesos.md              ← Linting, formato, patrones, anti-patrones, DoD
└── 12-expectativas-rampup.md           ← Qué se espera a los 7 días, 30 días, 90 días

Fase 2: Plan personalizado

projects/{proyecto}/onboarding/
├── {nombre}-plan-30-60-90.md           ← Objetivos medibles por periodo
├── {nombre}-checklist-accesos.md       ← Checklist personalizada de accesos y configuraciones
└── {nombre}-primer-pr.md              ← Guía para el primer PR (paso a paso)

Fase 3: Buddy IA activo

El agente queda disponible como buddy interactivo para responder preguntas del nuevo miembro usando la documentación generada como base de conocimiento.

Prerequisitos

1. Proyecto configurado en projects/{nombre}/CLAUDE.md    → si no: ❌ ABORT
2. Acceso al repositorio del proyecto                       → si no: ❌ ABORT
3. equipo.md actualizado con miembros actuales              → si no: ⚠️ continuar con limitaciones

Flujo completo

PM ejecuta /onboarding-dev {nombre} --rol {rol} --seniority {jr|mid|sr} --proyecto {nombre}
    ↓
Validar prerequisitos
    ↓
═══ FASE 1: AUTO-ANÁLISIS DEL PROYECTO ═══
    ↓
Analizar repositorio:
  - Leer CLAUDE.md del proyecto
  - Escanear estructura de directorios
  - Identificar tecnologías (package.json, .csproj, requirements.txt, etc.)
  - Leer README, CONTRIBUTING, ARCHITECTURE si existen
  - Analizar git log (últimos 3 meses) para entender actividad reciente
  - Identificar decisiones técnicas en ADRs si existen
    ↓
Generar los 10-12 documentos en projects/{proyecto}/onboarding/
    ↓
Mostrar resumen de documentos generados → PM valida
    ↓
═══ FASE 2: PLAN PERSONALIZADO ═══
    ↓
Adaptar según rol y seniority:
  - Junior: más detalle, más checkpoints, tareas más pequeñas, más pair programming
  - Mid: balance entre autonomía y guía, primer PR en día 2-3
  - Senior: high-level overview, primer PR en día 1-2, foco en decisiones técnicas
    ↓
Generar:
  - Plan 30/60/90 con objetivos medibles
  - Checklist de accesos personalizada (GitHub, Jira, SonarCloud, VPN, Figma, etc.)
  - Guía de primer PR paso a paso
    ↓
═══ FASE 3: BUDDY IA ACTIVO ═══
    ↓
Configurar agente buddy con:
  - Base de conocimiento: documentos generados en Fase 1
  - System prompt con guardarraíles de Manfred (ver abajo)
  - Disponible vía /onboarding-ask {pregunta}

Buddy IA — Comportamiento (Manfred v3.0)

El agente buddy responde con explicaciones breves y accionables, cita fuentes internas (archivo + sección), señala nivel de confianza (alto/medio/bajo), y deriva a personas cuando el tema es sensible (seguridad, compliance). No inventa políticas ni detalles técnicos.

3 capas: Orientación (quién/dónde) → Ejecución (setup/PR/deploy) → Contexto (decisiones técnicas pasadas y trade-offs).

Guardarraíles anti-patrón: No usar IA para decidir sin entender. Validar decisiones de arquitectura con el equipo. Si no puedes explicar el código, no lo subas. Preguntar primero a la IA, luego al equipo.

Métricas de ramp-up

Cuándo NO usar

• El miembro ya lleva >2 semanas productivo (usar /team-evaluate para actualizar perfil)
• Para perfiles no técnicos (usar team-onboarding genérico)
• Si no existe CLAUDE.md del proyecto (crear primero con /project-new)

Almacenamiento

Documentación generada en projects/{proyecto}/onboarding/ — directorio en .gitignore por defecto (puede contener info sensible del proyecto).

Plan personalizado en projects/{proyecto}/onboarding/{nombre}-*.md — igualmente git-ignorado.