메뉴
Gestion des dépendances du monorepo via le catalog pnpm (source de vérité unique des versions). À utiliser pour ajouter, mettre à jour ou auditer une dépendance, ou pour décider entre catalog et version locale dans un package.json.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | dependency-management |
| description | Gestion des dépendances du monorepo via le catalog pnpm (source de vérité unique des versions). À utiliser pour ajouter, mettre à jour ou auditer une dépendance, ou pour décider entre catalog et version locale dans un package.json. |
Le catalog pnpm est la source de vérité unique pour les versions des dépendances partagées. Une seule ligne à changer dans pnpm-workspace.yaml met à jour une dépendance partout.
# pnpm-workspace.yaml
packages:
- 'apps/*'
- 'packages/*'
catalog:
typescript: '^5.5.0'
zod: '^3.23.0'
# back-end, front-end, qualité du code...
eslint: '^9.0.0'
prettier: '^3.3.0'
{
"dependencies": { "zod": "catalog:", "@nestjs/core": "catalog:" },
"devDependencies": { "typescript": "catalog:", "eslint": "catalog:" }
}
# 1. Modifier la version dans pnpm-workspace.yaml
# 2. pnpm install
pnpm outdated --recursive # voir les mises à jour disponibles
"catalog:" — jamais la version en dur pour une dep partagée.pnpm-workspace.yaml uniquement, puis pnpm install.pnpm install --frozen-lockfile en CI.* ou latest — toujours une version sémantique avec range (^).pnpm add sans vérifier si la dep devrait être dans le catalog.Elle peut rester en version en dur dans son package.json. Le catalog est réservé aux dépendances partagées.
⚠️ Ajouter une nouvelle dépendance npm nécessite la validation du Squad Lead.
Structure et règles back-end NestJS (DDD + Clean Architecture). À utiliser pour créer ou modifier du code back-end — use-cases, controllers, repositories, services infra, mappers, errors — ou pour savoir dans quelle couche placer un fichier.
Simplifies code for clarity. Use when refactoring code for clarity without changing behavior. Use when code works but is harder to read, maintain, or extend than it should be. Use when reviewing code that has accumulated unnecessary complexity.
Guides systematic root-cause debugging. Use when tests fail, builds break, behavior doesn't match expectations, or you encounter any unexpected error. Use when you need a systematic approach to finding and fixing the root cause rather than guessing.
Builds production-quality UIs. Use when building or modifying user-facing interfaces. Use when creating components, implementing layouts, managing state, or when the output needs to look and feel production-quality rather than AI-generated.
Delivers changes incrementally. Use when implementing any feature or change that touches more than one file. Use when you're about to write a large amount of code at once, or when a task feels too big to land in one step.
Optimizes application performance. Use when performance requirements exist, when you suspect performance regressions, or when Core Web Vitals or load times need improvement. Use when profiling reveals bottlenecks that need fixing.