senior-backend
alirezarezvani/claude-skills
Conçoit et met en œuvre des systèmes backend, notamment des API REST, des microservices, des architectures de bases de données, des processus d'authentification et des mesures de renforcement de la sécurité. Couvre le développement d'Node.js/Express/Fastify, l'optimisation de PostgreSQL, la sécurité des API et les modèles d'architecture backend.
...Développer toutIngénieur backend senior
Modèles de développement backend, conception d'API, optimisation des bases de données et pratiques de sécurité.
Démarrage rapide
# Generate API routes from OpenAPI spec
python scripts/api_scaffolder.py openapi.yaml --framework express --output src/routes/
# Analyze database schema and generate migrations
python scripts/database_migration_tool.py --connection postgres://localhost/mydb --analyze
# Load test an API endpoint
python scripts/api_load_tester.py https://api.example.com/users --concurrency 50 --duration 30
Présentation des outils
1. API Scaffolder
Génère des gestionnaires de routes API, des middlewares et des spécifications OpenAPI à partir de définitions de schémas.
Entrée : spécification OpenAPI (YAML/JSON) ou schéma de base de données Sortie : gestionnaires de routes, middleware de validation, types TypeScript
Utilisation :
# Generate Express routes from OpenAPI spec
python scripts/api_scaffolder.py openapi.yaml --framework express --output src/routes/
# Output: Generated 12 route handlers, validation middleware, and TypeScript types
# Generate from database schema
python scripts/api_scaffolder.py --from-db postgres://localhost/mydb --output src/routes/
# Generate OpenAPI spec from existing routes
python scripts/api_scaffolder.py src/routes/ --generate-spec --output openapi.yaml
Frameworks pris en charge :
- Express.js (
--framework express) - Fastify (
--framework fastify) - Koa (
--framework koa)
2. Outil de migration de bases de données
Analyse les schémas de base de données, détecte les modifications et génère des fichiers de migration avec prise en charge de la restauration.
Entrée : chaîne de connexion à la base de données ou fichiers de schéma Sortie : fichiers de migration, rapport de différences entre schémas, suggestions d'optimisation
Utilisation :
# Analyze current schema and suggest optimizations
python scripts/database_migration_tool.py --connection postgres://localhost/mydb --analyze
# Output: Missing indexes, N+1 query risks, and suggested migration files
# Generate migration from schema diff
python scripts/database_migration_tool.py --connection postgres://localhost/mydb \
--compare schema/v2.sql --output migrations/
# Dry-run a migration
python scripts/database_migration_tool.py --connection postgres://localhost/mydb \
--migrate migrations/20240115_add_user_indexes.sql --dry-run
3. Testeur de charge d’API
Effectue des tests de charge HTTP avec une concurrence configurable, en mesurant les centiles de latence et le débit.
Entrée : URL du point de terminaison de l’API et configuration du test Sortie : rapport de performances avec distribution de la latence, taux d’erreur et métriques de débit
Utilisation :
# Basic load test
python scripts/api_load_tester.py https://api.example.com/users --concurrency 50 --duration 30
# Output: Throughput (req/sec), latency percentiles (P50/P95/P99), error counts, and scaling recommendations
# Test with custom headers and body
python scripts/api_load_tester.py https://api.example.com/orders \
--method POST \
--header "Authorization: Bearer token123" \
--body '{"product_id": 1, "quantity": 2}' \
--concurrency 100 \
--duration 60
# Compare two endpoints
python scripts/api_load_tester.py https://api.example.com/v1/users https://api.example.com/v2/users \
--compare --concurrency 50 --duration 30
Workflows de développement backend
Workflow de conception d’API
À utiliser lors de la conception d’une nouvelle API ou de la refactorisation de points de terminaison existants.
Étape 1 : Définir les ressources et les opérations
# openapi.yaml
openapi: 3.0.3
info:
title: User Service API
version: 1.0.0
paths:
/users:
get:
summary: List users
parameters:
- name: "limit"
in: query
schema:
type: integer
default: 20
post:
summary: Create user
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/CreateUser'
Étape 2 : Générer la structure des routes
python scripts/api_scaffolder.py openapi.yaml --framework express --output src/routes/
Étape 3 : Implémenter la logique métier
// src/routes/users.ts (generated, then customized)
export const createUser = async (req: Request, res: Response) => {
const { email, name } = req.body;
// Add business logic
const user = await userService.create({ email, name });
res.status(201).json(user);
};
Étape 4 : Ajouter un middleware de validation
# Validation is auto-generated from OpenAPI schema
# src/middleware/validators.ts includes:
# - Request body validation
# - Query parameter validation
# - Path parameter validation
Étape 5 : Générer la spécification OpenAPI mise à jour
python scripts/api_scaffolder.py src/routes/ --generate-spec --output openapi.yaml
Workflow d'optimisation de la base de données
À utiliser lorsque les requêtes sont lentes ou que les performances de la base de données doivent être améliorées.
Étape 1 : Analyser les performances actuelles
python scripts/database_migration_tool.py --connection $DATABASE_URL --analyze
Étape 2 : Identifier les requêtes lentes
-- Check query execution plans
EXPLAIN ANALYZE SELECT * FROM orders
WHERE user_id = 123
ORDER BY created_at DESC
LIMIT 10;
-- Look for: Seq Scan (bad), Index Scan (good)
Étape 3 : Générer les migrations d'index
python scripts/database_migration_tool.py --connection $DATABASE_URL \
--suggest-indexes --output migrations/
Étape 4 : Tester la migration (simulation)
python scripts/database_migration_tool.py --connection $DATABASE_URL \
--migrate migrations/add_indexes.sql --dry-run
Étape 5 : Appliquer et vérifier
# Apply migration
python scripts/database_migration_tool.py --connection $DATABASE_URL \
--migrate migrations/add_indexes.sql
# Verify improvement
python scripts/database_migration_tool.py --connection $DATABASE_URL --analyze
Workflow de renforcement de la sécurité
À utiliser lors de la préparation d’une API pour la production ou après un audit de sécurité.
Étape 1 : Vérifier la configuration de l’authentification
// Verify JWT configuration
const jwtConfig = {
secret: process.env.JWT_SECRET, // Must be from env, never hardcoded
expiresIn: '1h', // Short-lived tokens
algorithm: 'RS256' // Prefer asymmetric
};
Étape 2 : Ajouter une limitation de débit
import rateLimit from 'express-rate-limit';
const apiLimiter = rateLimit({
windowMs: 15 * 60 * 1000, // 15 minutes
max: 100, // 100 requests per window
standardHeaders: true,
legacyHeaders: false,
});
app.use('/api/', apiLimiter);
Étape 3 : Valider toutes les entrées
import { z } from 'zod';
const CreateUserSchema = z.object({
email: z.string().email().max(255),
name: z.string().min(1).max(100),
age: z.number().int().positive().optional()
});
// Use in route handler
const data = CreateUserSchema.parse(req.body);
Étape 4 : Test de charge avec des scénarios d’attaque
# Test rate limiting
python scripts/api_load_tester.py https://api.example.com/login \
--concurrency 200 --duration 10 --expect-rate-limit
# Test input validation
python scripts/api_load_tester.py https://api.example.com/users \
--method POST \
--body '{"email": "not-an-email"}' \
--expect-status 400
Étape 5 : Vérifier les en-têtes de sécurité
import helmet from 'helmet';
app.use(helmet({
contentSecurityPolicy: true,
crossOriginEmbedderPolicy: true,
crossOriginOpenerPolicy: true,
crossOriginResourcePolicy: true,
hsts: { maxAge: 31536000, includeSubDomains: true },
}));
Documentation de référence
| Fichier | Contient | À utiliser lorsque |
|---|---|---|
references/api_design_patterns.md |
REST vs GraphQL, gestion des versions, gestion des erreurs, pagination | Conception de nouvelles API |
references/database_optimization_guide.md |
Stratégies d’indexation, optimisation des requêtes, solutions N+1 | Correction des requêtes lentes |
references/backend_security_practices.md |
OWASP Top 10, modèles d'authentification, validation des entrées | Renforcement de la sécurité |
Référence rapide des modèles courants
Format de réponse des API REST
{
"data": { "id": 1, "name": "John" },
"meta": { "requestId": "abc-123" }
}
Format des réponses d'erreur
{
"error": {
"code": "VALIDATION_ERROR",
"message": "Invalid email format",
"details": [{ "field": "email", "message": "must be valid email" }]
},
"meta": { "requestId": "abc-123" }
}
Codes d'état HTTP
| Code | Cas d'utilisation |
|---|---|
| 200 | Succès (GET, PUT, PATCH) |
| 201 | Créé (POST) |
| 204 | Pas de contenu (DELETE) |
| 400 | Erreur de validation |
| 401 | Authentification requise |
| 403 | Autorisation refusée |
| 404 | Ressource introuvable |
| 429 | Limite de débit dépassée |
| 500 | Erreur interne du serveur |
Stratégie d'indexation de la base de données
-- Single column (equality lookups)
CREATE INDEX idx_users_email ON users(email);
-- Composite (multi-column queries)
CREATE INDEX idx_orders_user_status ON orders(user_id, status);
-- Partial (filtered queries)
CREATE INDEX idx_orders_active ON orders(created_at) WHERE status = 'active';
-- Covering (avoid table lookup)
CREATE INDEX idx_users_email_name ON users(email) INCLUDE (name);
Commandes courantes
# API Development
python scripts/api_scaffolder.py openapi.yaml --framework express
python scripts/api_scaffolder.py src/routes/ --generate-spec
# Database Operations
python scripts/database_migration_tool.py --connection $DATABASE_URL --analyze
python scripts/database_migration_tool.py --connection $DATABASE_URL --migrate file.sql
# Performance Testing
python scripts/api_load_tester.py https://api.example.com/endpoint --concurrency 50
python scripts/api_load_tester.py https://api.example.com/endpoint --compare baseline.json
Hypothèses et critères de réussite vérifiables (méthode Karpathy)
Avant que cette compétence ne mette en place un échafaudage, ne recommande un modèle ou ne modifie un schéma, les quatre hypothèses suivantes DOIVENT être identifiées. Si l’une d’entre elles est inconnue, la compétence s’arrête et parcourt à la place la bibliothèque de questions de validation.
- Rapport lecture/écriture + QPS p99 sur un an — détermine les choix relatifs à la base de données, au cache, à la file d’attente et au partitionnement. Kleppmann, DDIA (2017).
- Modèle de location — locataire unique, multi-locataires partagé, multi-locataires isolé. Détermine le modèle d’accès aux données.
- Niveau de sensibilité des données — public / interne / informations personnelles identifiables (PII) / informations médicales protégées (PHI) / PCI. Détermine le seuil minimal de conformité.
- SLO + consommateur avec budget d’erreurs défini — référence du Google SRE Workbook. Pas de SLO = pas de hiérarchisation des tâches de fiabilité.
Critères de réussite vérifiables (Karpathy n° 4) — chaque recommandation émise par cette compétence doit inclure :
- Objectifs de latence (p50, p95, p99 en ms)
- Temps de disponibilité / objectif SLO
- RPO + RTO
Si l’un de ces trois éléments n’est pas précisé, la recommandation est incomplète — revenir à la question n° 7 de la bibliothèque de questions de vérification.
L’ scripts/backend_decision_engine.py outil intègre ces vérifications : il refuse de recommander un profil sans ratio lecture/écriture + QPS + nombre de locataires + sensibilité des données + préférence de modèle.
Profils de personnalisation
Quatre profils intégrés dans profiles/ calibrent chaque recommandation :
| Profil | Quand choisir | Modèle | Seuil de latence (p99) |
|---|---|---|---|
node-express |
Équipe TS, < 15 ingénieurs, SaaS en contact direct avec les clients | Monolithe modulaire sur Postgres | 600 ms |
fastapi-python |
Équipe Python, < 20 ingénieurs, en lien avec le ML | Monolithe modulaire sur Postgres (asynchrone) | 500 ms |
django-monolith |
CRUD riche en contenu + administration, < 25 ingénieurs | Monolithe modulaire sur Postgres | 800 ms |
go-or-rust-microservice |
Service extrait, ≥ 30 ingénieurs, équipe plateforme, QPS ≥ 1 000 | Service extrait | 200 ms |
Choisissez un profil via :
python scripts/backend_decision_engine.py \
--team-size 8 --qps-p99 50 --read-write-ratio 20 \
--tenancy shared-multi-tenant --data-sensitivity pii \
--pattern modular-monolith --language-preference typescript
L'outil renvoie le profil le plus adapté, le compromis le plus proche (si l'écart est inférieur à 15 %), les choix de pile, les anti-modèles, les validateurs désignés et le seuil minimal des SLO. Cet outil n'approuve jamais automatiquement.
Pour ajouter un profil personnalisé : copiez profiles/node-express.json vers profiles/ et ajustez constraints + success_thresholds + named_approver_chain.
la carte de composition
Cette compétence ne réimplémente PAS le périmètre appartenant aux spécialistes de niveau POWERFUL. Elle s'y branche. Voir references/composition_map.md pour consulter la table de routage complète. Principales bifurcations :
| Préoccupation | Bifurcation vers |
|---|---|
| Contrat API / risque de changement radical | engineering/skills/api-design-reviewer/ |
| Conception du schéma + ERD + indexation | engineering/skills/database-designer/ |
| Migration de schéma sans interruption de service | engineering/skills/migration-architect/ |
| SLO + SLI + budget d'erreurs | engineering/slo-architect/ |
| Observabilité / signaux clés | engineering/skills/observability-designer/ |
| Pipeline CI/CD | engineering/skills/ci-cd-pipeline-builder/ |
| Sécurité / modèle de menace | engineering-team/skills/senior-security/, adversarial-reviewer |
| Preuves de conformité (HIPAA / ISO 27001) | ra-qm-team/ |
| Révision Karpathy avant validation | engineering/karpathy-coder/ |
| Interrogatoire approfondi sur l’architecture avant le déploiement | engineering/grill-me/ |
L’ cs-backend-engineer agent orchestre ces bifurcations via context: fork. Appelez-le depuis un autre agent avec Agent({subagent_type: "cs-backend-engineer", prompt: "..."}) ou via la /cs:backend-review .
Bibliothèque de questions de décision (grill de Matt Pocock)
Avant de finaliser toute décision au niveau du backend, passez en revue les sept questions de vérification figurant dans references/forcing_questions.md. Règles :
- Une question par tour. Pas de regroupement.
- Recommandez toujours la réponse en citant le canon.
- Consignez les réponses dans
/tmp/backend-grill-..md - Si un critère d’exclusion est rempli, arrêtez-vous. Ne contournez pas une lacune non résolue.
- Après la question 7, passez
backend_decision_engine.pyavec les sept réponses.
Résumé :
- Rapport lecture/écriture + prévision du QPS p99 ?
- Modèle de tenancy — unique / partagé / isolé ?
- Synchrone / asynchrone / piloté par les événements — par défaut + exceptions ?
- Niveau de sensibilité des données — PII / PHI / PCI ?
- Monolithique / monolithique modulaire / microservices — justification en fonction de la taille de l’équipe ?
- RPO + RTO ?
- SLO + consommateur avec budget d’erreurs défini ?
Appel depuis d’autres agents et compétences
Trois interfaces :
- Commande « / » :
/cs:backend-review— grille complète + moteur de décision + routage de composition. - Sous-agent de l’agent :
Agent({subagent_type: "cs-backend-engineer", prompt: "..."})— crée une branche du contexte, renvoie un résumé de ≤ 200 mots. - Appel direct de l’outil :
python scripts/backend_decision_engine.py ...— correspondance déterministe de profil lorsque les entrées sont connues.
Voir agents/engineering/cs-backend-engineer.md pour le contrat d'invocation complet.
---
name: senior-backend
description: Designs and implements backend systems including REST APIs, microservices, database architectures, authentication flows, and security hardening. Covers Node.js/Express/Fastify development, PostgreSQL optimization, API security, and backend architecture patterns.
---
# Senior Backend Engineer
Backend development patterns, API design, database optimization, and security practices.
---
## Quick Start
```bash
# Generate API routes from OpenAPI spec
python scripts/api_scaffolder.py openapi.yaml --framework express --output src/routes/
# Analyze database schema and generate migrations
python scripts/database_migration_tool.py --connection postgres://localhost/mydb --analyze
# Load test an API endpoint
python scripts/api_load_tester.py https://api.example.com/users --concurrency 50 --duration 30
```
---
## Tools Overview
### 1. API Scaffolder
Generates API route handlers, middleware, and OpenAPI specifications from schema definitions.
**Input:** OpenAPI spec (YAML/JSON) or database schema
**Output:** Route handlers, validation middleware, TypeScript types
**Usage:**
```bash
# Generate Express routes from OpenAPI spec
python scripts/api_scaffolder.py openapi.yaml --framework express --output src/routes/
# Output: Generated 12 route handlers, validation middleware, and TypeScript types
# Generate from database schema
python scripts/api_scaffolder.py --from-db postgres://localhost/mydb --output src/routes/
# Generate OpenAPI spec from existing routes
python scripts/api_scaffolder.py src/routes/ --generate-spec --output openapi.yaml
```
**Supported Frameworks:**
- Express.js (`--framework express`)
- Fastify (`--framework fastify`)
- Koa (`--framework koa`)
---
### 2. Database Migration Tool
Analyzes database schemas, detects changes, and generates migration files with rollback support.
**Input:** Database connection string or schema files
**Output:** Migration files, schema diff report, optimization suggestions
**Usage:**
```bash
# Analyze current schema and suggest optimizations
python scripts/database_migration_tool.py --connection postgres://localhost/mydb --analyze
# Output: Missing indexes, N+1 query risks, and suggested migration files
# Generate migration from schema diff
python scripts/database_migration_tool.py --connection postgres://localhost/mydb \
--compare schema/v2.sql --output migrations/
# Dry-run a migration
python scripts/database_migration_tool.py --connection postgres://localhost/mydb \
--migrate migrations/20240115_add_user_indexes.sql --dry-run
```
---
### 3. API Load Tester
Performs HTTP load testing with configurable concurrency, measuring latency percentiles and throughput.
**Input:** API endpoint URL and test configuration
**Output:** Performance report with latency distribution, error rates, throughput metrics
**Usage:**
```bash
# Basic load test
python scripts/api_load_tester.py https://api.example.com/users --concurrency 50 --duration 30
# Output: Throughput (req/sec), latency percentiles (P50/P95/P99), error counts, and scaling recommendations
# Test with custom headers and body
python scripts/api_load_tester.py https://api.example.com/orders \
--method POST \
--header "Authorization: Bearer token123" \
--body '{"product_id": 1, "quantity": 2}' \
--concurrency 100 \
--duration 60
# Compare two endpoints
python scripts/api_load_tester.py https://api.example.com/v1/users https://api.example.com/v2/users \
--compare --concurrency 50 --duration 30
```
---
## Backend Development Workflows
### API Design Workflow
Use when designing a new API or refactoring existing endpoints.
**Step 1: Define resources and operations**
```yaml
# openapi.yaml
openapi: 3.0.3
info:
title: User Service API
version: 1.0.0
paths:
/users:
get:
summary: List users
parameters:
- name: "limit"
in: query
schema:
type: integer
default: 20
post:
summary: Create user
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/CreateUser'
```
**Step 2: Generate route scaffolding**
```bash
python scripts/api_scaffolder.py openapi.yaml --framework express --output src/routes/
```
**Step 3: Implement business logic**
```typescript
// src/routes/users.ts (generated, then customized)
export const createUser = async (req: Request, res: Response) => {
const { email, name } = req.body;
// Add business logic
const user = await userService.create({ email, name });
res.status(201).json(user);
};
```
**Step 4: Add validation middleware**
```bash
# Validation is auto-generated from OpenAPI schema
# src/middleware/validators.ts includes:
# - Request body validation
# - Query parameter validation
# - Path parameter validation
```
**Step 5: Generate updated OpenAPI spec**
```bash
python scripts/api_scaffolder.py src/routes/ --generate-spec --output openapi.yaml
```
---
### Database Optimization Workflow
Use when queries are slow or database performance needs improvement.
**Step 1: Analyze current performance**
```bash
python scripts/database_migration_tool.py --connection $DATABASE_URL --analyze
```
**Step 2: Identify slow queries**
```sql
-- Check query execution plans
EXPLAIN ANALYZE SELECT * FROM orders
WHERE user_id = 123
ORDER BY created_at DESC
LIMIT 10;
-- Look for: Seq Scan (bad), Index Scan (good)
```
**Step 3: Generate index migrations**
```bash
python scripts/database_migration_tool.py --connection $DATABASE_URL \
--suggest-indexes --output migrations/
```
**Step 4: Test migration (dry-run)**
```bash
python scripts/database_migration_tool.py --connection $DATABASE_URL \
--migrate migrations/add_indexes.sql --dry-run
```
**Step 5: Apply and verify**
```bash
# Apply migration
python scripts/database_migration_tool.py --connection $DATABASE_URL \
--migrate migrations/add_indexes.sql
# Verify improvement
python scripts/database_migration_tool.py --connection $DATABASE_URL --analyze
```
---
### Security Hardening Workflow
Use when preparing an API for production or after a security review.
**Step 1: Review authentication setup**
```typescript
// Verify JWT configuration
const jwtConfig = {
secret: process.env.JWT_SECRET, // Must be from env, never hardcoded
expiresIn: '1h', // Short-lived tokens
algorithm: 'RS256' // Prefer asymmetric
};
```
**Step 2: Add rate limiting**
```typescript
import rateLimit from 'express-rate-limit';
const apiLimiter = rateLimit({
windowMs: 15 * 60 * 1000, // 15 minutes
max: 100, // 100 requests per window
standardHeaders: true,
legacyHeaders: false,
});
app.use('/api/', apiLimiter);
```
**Step 3: Validate all inputs**
```typescript
import { z } from 'zod';
const CreateUserSchema = z.object({
email: z.string().email().max(255),
name: z.string().min(1).max(100),
age: z.number().int().positive().optional()
});
// Use in route handler
const data = CreateUserSchema.parse(req.body);
```
**Step 4: Load test with attack patterns**
```bash
# Test rate limiting
python scripts/api_load_tester.py https://api.example.com/login \
--concurrency 200 --duration 10 --expect-rate-limit
# Test input validation
python scripts/api_load_tester.py https://api.example.com/users \
--method POST \
--body '{"email": "not-an-email"}' \
--expect-status 400
```
**Step 5: Review security headers**
```typescript
import helmet from 'helmet';
app.use(helmet({
contentSecurityPolicy: true,
crossOriginEmbedderPolicy: true,
crossOriginOpenerPolicy: true,
crossOriginResourcePolicy: true,
hsts: { maxAge: 31536000, includeSubDomains: true },
}));
```
---
## Reference Documentation
| File | Contains | Use When |
|------|----------|----------|
| `references/api_design_patterns.md` | REST vs GraphQL, versioning, error handling, pagination | Designing new APIs |
| `references/database_optimization_guide.md` | Indexing strategies, query optimization, N+1 solutions | Fixing slow queries |
| `references/backend_security_practices.md` | OWASP Top 10, auth patterns, input validation | Security hardening |
---
## Common Patterns Quick Reference
### REST API Response Format
```json
{
"data": { "id": 1, "name": "John" },
"meta": { "requestId": "abc-123" }
}
```
### Error Response Format
```json
{
"error": {
"code": "VALIDATION_ERROR",
"message": "Invalid email format",
"details": [{ "field": "email", "message": "must be valid email" }]
},
"meta": { "requestId": "abc-123" }
}
```
### HTTP Status Codes
| Code | Use Case |
|------|----------|
| 200 | Success (GET, PUT, PATCH) |
| 201 | Created (POST) |
| 204 | No Content (DELETE) |
| 400 | Validation error |
| 401 | Authentication required |
| 403 | Permission denied |
| 404 | Resource not found |
| 429 | Rate limit exceeded |
| 500 | Internal server error |
### Database Index Strategy
```sql
-- Single column (equality lookups)
CREATE INDEX idx_users_email ON users(email);
-- Composite (multi-column queries)
CREATE INDEX idx_orders_user_status ON orders(user_id, status);
-- Partial (filtered queries)
CREATE INDEX idx_orders_active ON orders(created_at) WHERE status = 'active';
-- Covering (avoid table lookup)
CREATE INDEX idx_users_email_name ON users(email) INCLUDE (name);
```
---
## Common Commands
```bash
# API Development
python scripts/api_scaffolder.py openapi.yaml --framework express
python scripts/api_scaffolder.py src/routes/ --generate-spec
# Database Operations
python scripts/database_migration_tool.py --connection $DATABASE_URL --analyze
python scripts/database_migration_tool.py --connection $DATABASE_URL --migrate file.sql
# Performance Testing
python scripts/api_load_tester.py https://api.example.com/endpoint --concurrency 50
python scripts/api_load_tester.py https://api.example.com/endpoint --compare baseline.json
```
---
## Assumptions and Verifiable Success Criteria (Karpathy discipline)
Before this skill scaffolds, recommends a pattern, or modifies a schema, the following four assumptions MUST be surfaced. If any are unknown, the skill stops and walks the [Forcing-question library](#forcing-question-library-matt-pocock-grill) instead.
1. **Read/write ratio + one-year p99 QPS** — drives DB, cache, queue, and partitioning choices. Kleppmann, *DDIA* (2017).
2. **Tenancy model** — single-tenant, shared multi-tenant, isolated multi-tenant. Drives data-access pattern.
3. **Data sensitivity tier** — public / internal / PII / PHI / PCI. Drives compliance floor.
4. **SLO + named error-budget consumer** — Google SRE Workbook canon. No SLO = no reliability work prioritization.
**Verifiable success criteria** (Karpathy #4) — every recommendation this skill emits must include:
- Latency targets (p50, p95, p99 in ms)
- Uptime / SLO target
- RPO + RTO
If any of those three is not stated, the recommendation is incomplete — return to Q7 of the forcing-question library.
The `scripts/backend_decision_engine.py` tool encodes these checks: it refuses to recommend a profile without read/write ratio + QPS + tenancy + data sensitivity + pattern preference.
---
## Customization profiles
Four built-in profiles in `profiles/` calibrate every recommendation:
| Profile | When to pick | Pattern | Latency floor (p99) |
|---|---|---|---|
| `node-express` | TS team, < 15 eng, customer-facing SaaS | Modular monolith on Postgres | 600ms |
| `fastapi-python` | Python team, < 20 eng, ML-adjacent | Modular monolith on Postgres (async) | 500ms |
| `django-monolith` | Content-heavy CRUD + admin, < 25 eng | Modular monolith on Postgres | 800ms |
| `go-or-rust-microservice` | Extracted service, ≥ 30 eng, platform team, QPS ≥ 1000 | Extracted service | 200ms |
Pick a profile via:
```bash
python scripts/backend_decision_engine.py \
--team-size 8 --qps-p99 50 --read-write-ratio 20 \
--tenancy shared-multi-tenant --data-sensitivity pii \
--pattern modular-monolith --language-preference typescript
```
The tool returns the best-fit profile, runner-up tradeoff (if within 15%), stack picks, anti-patterns, named approvers, and SLO floor. **This tool never auto-approves.**
To add a custom profile: copy `profiles/node-express.json` to `profiles/<your-org>.json` and adjust `constraints` + `success_thresholds` + `named_approver_chain`.
---
## Composition map
This skill does NOT reimplement scope owned by the POWERFUL-tier specialists. It forks into them. See `references/composition_map.md` for the full routing table. Key forks:
| Concern | Fork into |
|---|---|
| API contract / breaking-change risk | `engineering/skills/api-design-reviewer/` |
| Schema design + ERD + indexing | `engineering/skills/database-designer/` |
| Zero-downtime schema migration | `engineering/skills/migration-architect/` |
| SLO + SLI + error-budget | `engineering/slo-architect/` |
| Observability / golden signals | `engineering/skills/observability-designer/` |
| CI/CD pipeline | `engineering/skills/ci-cd-pipeline-builder/` |
| Security / threat model | `engineering-team/skills/senior-security/`, `adversarial-reviewer` |
| Compliance evidence (HIPAA / ISO 27001) | `ra-qm-team/` |
| Pre-commit Karpathy review | `engineering/karpathy-coder/` |
| Pre-flight architecture grill | `engineering/grill-me/` |
The `cs-backend-engineer` agent orchestrates these forks via `context: fork`. Invoke it from another agent with `Agent({subagent_type: "cs-backend-engineer", prompt: "..."})` or via `/cs:backend-review <your problem>`.
---
## Forcing-question library (Matt Pocock grill)
Before locking any backend decision, walk the seven forcing questions in `references/forcing_questions.md`. Discipline:
1. One question per turn. No bundling.
2. Always recommend the answer with cited canon.
3. Track answers in `/tmp/backend-grill-<date>.md`.
4. If a kill criterion trips, stop. Don't scaffold around an unresolved gap.
5. After Q7, run `backend_decision_engine.py` with the seven answers.
Summary:
1. Read/write ratio + p99 QPS forecast?
2. Tenancy model — single / shared / isolated?
3. Sync / async / event-driven — default + exceptions?
4. Data sensitivity tier — PII / PHI / PCI?
5. Monolith / modular monolith / microservices — team-size justification?
6. RPO + RTO?
7. SLO + named error-budget consumer?
---
## Invocation from other agents and skills
Three surfaces:
1. **Slash command:** `/cs:backend-review <prompt>` — full grill + decision engine + composition routing.
2. **Agent subagent:** `Agent({subagent_type: "cs-backend-engineer", prompt: "..."})` — forks context, returns ≤ 200-word digest.
3. **Direct tool call:** `python scripts/backend_decision_engine.py ...` — deterministic profile match when inputs are known.
See `agents/engineering/cs-backend-engineer.md` for the full invocation contract.
Tous les fichiers
0 fichiersInstaller senior-backend
Téléchargez et décompressez les fichiers de compétences dans votre répertoire .claude/skills/.
Télécharger le ZIPClonez le dépôt et copiez les fichiers de compétence dans votre projet.
git clone https://github.com/alirezarezvani/claude-skills/tree/main/engineering-team/skills/senior-backend # Copy SKILL.md to your .claude/skills/ directory
Copier





Maison
