Onboarding dev · guide premier commit en 5 jours

---
name: onboarding-nouveau-dev-projet
description: "Génère un guide d'onboarding structuré pour un nouveau développeur qui rejoint un projet existant : architecture en 1 page, conventions de code et de commits, accès et secrets à demander, parcours premier commit en 5 jours, liste des questions à poser au tech lead. À utiliser par un tech lead, staff engineer, CTO ou freelance senior qui accueille un dev backend, frontend, fullstack, DevOps ou data dans une stack TypeScript, Python, Go, Next.js, Supabase, ou similaire. Évite le syndrome du repo où le nouveau passe 3 semaines à chercher comment lancer le projet en local."
metadata:
  iaskills_title: "Onboarding dev · guide premier commit en 5 jours"
  metier_slug: dev
  metiers:
    - Devs et tech leads
  secteur: "Tech & DSI"
  tier: free
  compatible:
    - claude-code
    - cowork
    - cursor
    - codex
  version: "1.0.0"
  author: "iaskills"
  editorial:
    pitch: "Guide d'onboarding dev : archi en 1 page, conventions, accès, parcours premier commit en 5 jours. Le nouveau pousse une PR la semaine 1."
    long_description: "Le coût d'un onboarding raté pour un dev senior dépasse vite 10 000 € : 3 semaines à fouiller le repo, à demander en DM, à comprendre qui décide de quoi, et au final une PR qui casse trois conventions tacites. Ce skill génère un guide d'onboarding court (3 à 5 pages Markdown), calibré sur la stack et la culture du projet, qui permet au nouveau dev de cloner, lancer en local, comprendre l'architecture, et pousser un premier commit utile en moins de 5 jours ouvrés. Couvre les sections critiques : architecture 1 page, conventions de code et de commits, accès à demander, secrets locaux, environnements (dev, staging, prod), runbook minimal, et 10 questions à poser au tech lead. Aligné sur les stacks FR courantes : Next.js, Supabase, Vercel, Scaleway, OVH, Clever Cloud, Python FastAPI, Go, et les pratiques Anthropic Agent SDK quand le projet intègre du LLM."
    bullets:
      - "Architecture en 1 page (schéma + composants)"
      - "Conventions code, commits, branches"
      - "Accès et secrets à demander dès J1"
      - "Parcours premier commit en 5 jours"
      - "10 questions à poser au tech lead"
      - "Calibré stacks FR (Vercel, Scaleway, Supabase)"
    exemple_avant: "Un dev senior fullstack rejoint une scale-up SaaS. Premier jour : le README pointe vers une vieille doc Notion, les variables d'env ne sont pas listées, les accès sont en attente de validation IAM, et personne ne sait dire qui valide les PR sur le repo backend. Trois semaines plus tard, le dev a poussé deux commits triviaux et reste bloqué sur la stack RLS Supabase qu'il n'a jamais utilisée."
    exemple_apres: "Le tech lead génère le guide en 30 minutes (en répondant aux questions du skill), le partage en Notion. Le nouveau arrive J1 avec une vue claire : 4 services, 2 environnements, 8 conventions à respecter, accès demandés par avance. Premier PR poussé J4 sur une issue isolée. Cinq questions posées au tech lead en J3, toutes traitées en stand-up."
    recommended_metiers:
      - consultant
      - dirigeant-pme
    secteurs:
      - tech-dsi
      - startup-vc
      - conseil-audit
      - marketing-commerce
      - industrie-manufacture
      - assurance-banque
    metiers_individuels:
      - dev-backend
      - dev-frontend
      - devops
      - chef-de-projet-it
      - architecte-si
      - cto
      - scrum-master
      - product-manager
      - qa-engineer
      - data-scientist
    connecteurs:
      - notion
      - slack
      - gmail
---

# Onboarding dev · guide premier commit en 5 jours

## Quand utiliser ce skill

Déclencher quand un tech lead, staff engineer, CTO, freelance senior ou agence dev doit accueillir un nouveau développeur sur un projet existant et veut éviter l'onboarding sauvage. Cas typiques :

- Recrutement d'un dev backend, frontend, fullstack, DevOps, data, mobile sur un produit en place.
- Arrivée d'un freelance senior pour 1 à 6 mois sur un sprint produit.
- Passage de relais d'un ancien dev qui quitte le projet (offboarding doublé d'onboarding).
- Bascule d'un dev interne d'une équipe vers une autre, sur une stack différente.
- Internalisation d'un projet historiquement chez un prestataire externe.
- Onboarding sur un projet open source contributeur de longue date.

Ne pas utiliser pour :

- Un onboarding RH générique (paperasse, mutuelle, badge accès locaux), qui relève des RH.
- Un cours de formation initiale (apprentissage Next.js, Python, Go), qui demande un parcours pédagogique, pas un guide projet.
- Un audit de codebase pour décider d'un refacto, qui relève d'un autre skill.
- Un guide utilisateur d'une API publique, qui relève de la doc produit.

## Ce que tu dois faire

### Étape 1, collecter le contexte projet

Demander au tech lead, en une seule fois ou en série courte :

1. **Stack technique** : langages, frameworks, base de données, hébergement, outils LLM si applicable. Ex : Next.js 15 App Router, Supabase Postgres eu-west-3, Vercel, Anthropic SDK.
2. **Architecture haute** : monolithe, microservices, monorepo, repos séparés. Nombre de services, dépendances entre eux, point d'entrée principal.
3. **Environnements** : combien (local, dev, staging, prod), URLs ou patterns, qui déploie vers quoi.
4. **Outils SDLC** : versionning (GitHub, GitLab, Bitbucket), CI/CD (GitHub Actions, GitLab CI), tracking (Linear, Jira, GitHub Issues), doc (Notion, Slite, Confluence, Markdown dans le repo).
5. **Conventions** : style guide (Prettier, Ruff, gofmt, eslint config), nom de branches, commits (Conventional Commits ou autre), revue de code (1 reviewer obligatoire, code owners).
6. **Secrets et accès** : où sont stockés les secrets (Doppler, 1Password, Vault, .env partagé), accès cloud (AWS, GCP, OVH, Scaleway, Vercel), accès DB, accès observabilité (Sentry, Datadog, Logtail).
7. **Profil du nouveau dev** : poste, séniorité, expériences passées (stack identique ou différente), durée d'engagement (freelance 3 mois, CDI long terme).
8. **Cas d'usage premier commit** : 1 issue ou ticket simple à confier en semaine 1, déjà identifié ou à choisir.

Si l'utilisateur cite un repo précis, lire son README, son `package.json`, son `pyproject.toml`, son `go.mod`, ou équivalent pour ne rien inventer sur la stack.

### Étape 2, structurer le guide

Le guide se compose de 6 sections obligatoires, dans cet ordre :

1. **Mot d'accueil** (5 à 10 lignes) : qui est le tech lead référent, où trouver l'équipe (Slack channel, Notion workspace), le scope du projet, ce qui est attendu du nouveau en semaine 1.
2. **Architecture en 1 page** : description courte de chaque service ou composant, dépendances, schéma textuel ou lien vers un schéma existant. Pas plus d'une page.
3. **Conventions** : code (linter, formatter, style), commits (format), branches (nommage), PR (template, reviewers requis, taille max), tests (couverture attendue, frameworks).
4. **Accès à demander dès J1** : liste exacte des comptes à créer ou demander (GitHub org, cloud provider, DB, observabilité, Slack channels, Notion). Pour chaque accès, indiquer qui valide.
5. **Setup local en 30 minutes** : commandes exactes à exécuter (clone, install, env, run). Préciser les versions de runtime (Node 22, Python 3.12, Go 1.22). Lister les variables d'env à récupérer.
6. **Parcours premier commit en 5 jours** : day 1 (setup + lecture archi), day 2 (binôme sur une issue lue), day 3 (premier PR draft), day 4 (revue + ajustements), day 5 (merge + démo en stand-up).
7. **10 questions à poser au tech lead** : 10 questions précises calibrées sur la stack, à poser en stand-up ou en 1:1 dès la semaine 1.

### Étape 3, calibrer le ton et la longueur

Le guide doit tenir entre 1 500 et 3 500 mots. Si la stack est simple (mono-repo Next.js + Supabase), viser 1 500 mots. Si elle est complexe (microservices Python + Go + frontends multiples), viser 3 500 mots maximum. Au-delà, scinder en 2 documents (guide général + run book stack).

Ton : impératif court, factuel. Pas de superlatif marketing (rare, unique, magique). Pas de blagues internes que le nouveau ne comprendra pas. Pas d'em-dash.

### Étape 4, produire la sortie

Voir section **Format de sortie attendu**. Bloc Markdown unique, prêt à coller dans Notion, Slite, ou `docs/ONBOARDING.md` du repo.