Compétences environment-setup
📦

environment-setup

Risque moyen 🔑 Variables d’environnement⚙️ Commandes externes

Configurer les variables d'environnement pour les environnements de développement, staging et production

La gestion des variables d'environnement sur plusieurs environnements est sujette aux erreurs et prend du temps. Cette skill fournit des modèles et les meilleures pratiques pour les fichiers .env, la validation de configuration TypeScript et la gestion des environnement Docker afin que vous puissiez configurer correctement les environnements dès la première fois.

Prend en charge: Claude Codex Code(CC)
⚠️ 62 Médiocre
1

Télécharger le ZIP du skill

2

Importer dans Claude

Allez dans Paramètres → Capacités → Skills → Importer un skill

3

Activez et commencez à utiliser

Tester

Utilisation de "environment-setup". Créer un modèle .env pour une API Node.js

Résultat attendu:

Généré .env.example avec des sections pour Application, Base de données, Redis, Authentification, Email (SMTP), APIs externes (Stripe), AWS, Monitoring (Sentry) et Feature Flags. Chaque section inclut des commentaires expliquant le but de la variable.

Utilisation de "environment-setup". Ajouter la validation d'environnement avec Zod

Résultat attendu:

Créé config/env.ts avec un schéma Zod qui valide que DATABASE_URL est une URL valide, les secrets JWT font au moins 32 caractères, SMTP_PORT est un nombre et LOG_LEVEL est l'un des suivants : error/warn/info/debug. Lance des erreurs descriptives en cas d'échec de validation.

Utilisation de "environment-setup". Générer des règles .gitignore pour les fichiers d'environnement

Résultat attendu:

Ajouté des règles pour éviter de commiter les fichiers .env : .env, .env.local, .env.*.local et .env.production. Créé le contenu du .gitignore prêt à copier dans le projet.

Audit de sécurité

Risque moyen
v1 • 3/19/2026

This skill is a documentation/education resource that provides templates and best practices for environment configuration. Static analysis flagged many patterns (credential examples, dotenv usage, environment variable access) but these are all placeholder examples in documentation, not actual executable code. The skill declares Read Write Edit Bash permissions, which is appropriate for configuration management. No malicious intent detected - all flagged patterns are legitimate documentation content. Users should be aware this skill can modify configuration files.

2
Fichiers analysés
378
Lignes analysées
6
résultats
1
Total des audits
Problèmes à risque moyen (2)
SKILL.md:32-56
Educational Documentation Contains Credential Patterns
SKILL.md contains example .env templates with placeholder credentials (DATABASE_URL, AWS keys, SMTP passwords). These are documentation examples showing users how to structure their own configuration, not actual secrets. The skill does not exfiltrate or misuse these values.
SKILL.md:4
Broad Tool Permissions Declared
The skill declares allowed-tools: Read Write Edit Bash, providing broad file system and command execution capabilities. This is necessary for configuration management but means the skill could modify any file if given malicious instructions.
Problèmes à risque faible (2)
SKILL.md:169-189
Environment Variable Access in Documentation
Code examples show process.env usage patterns. These are educational examples teaching users how to access environment variables in TypeScript applications, not actual runtime environment access by the skill.
SKILL.md:29-61
Hardcoded URLs in Documentation Examples
Documentation contains example URLs (localhost:3000, sentry.io, myapp.com). These are placeholder examples showing URL formats, not actual network endpoints.

Facteurs de risque

🔑 Variables d’environnement (5)
SKILL.md:32 SKILL.md:55-56 SKILL.md:107 SKILL.md:127 SKILL.md:173
⚙️ Commandes externes (1)
SKILL.md:25-67

Motifs détectés

Heuristic: Documentation Pattern Confusion
Audité par: claude

Score de qualité

38
Architecture
100
Maintenabilité
87
Contenu
32
Communauté
51
Sécurité
91
Conformité aux spécifications

Ce que vous pouvez construire

Initialiser la configuration d'environnement pour un nouveau projet

Configurer une structure complète de configuration d'environnement incluant .env.example, la validation TypeScript et les configs par environnement pour assurer une configuration cohérente au sein de votre équipe.

Migrer une configuration legacy vers une gestion d'environnement typée

Remplacer l'accès ad-hoc process.env par des schémas Zod validés et une gestion centralisée de la configuration pour une fiabilité et une sécurité typée améliorées.

Préparer la configuration de déploiement en production

Créer des modèles d'environnement spécifiques à la production avec interpolation de variables pour l'injection de secrets depuis les pipelines CI/CD ou les gestionnaires de secrets.

Essayez ces prompts

Créer un modèle .env pour mon projet Node.js 
J'ai besoin d'un modèle .env.example pour une application Node.js qui utilise PostgreSQL, Redis et envoie des emails via SMTP. Incluez les variables courantes pour l'authentification, le pooling de base de données et les feature flags.
Ajouter la validation d'environnement à la config existante 
Ajoutez la validation Zod à notre config/index.ts existante pour garantir que toutes les variables d'environnement requises sont présentes et correctement formatées au démarrage. Incluez la gestion des erreurs avec des messages clairs.
Configurer une configuration Docker multi-environnements 
Créez un docker-compose.yml avec des configurations d'environnement séparées pour le développement et la production. Utilisez env_file pour le développement local et les variables d'environnement pour la production. Incluez les services PostgreSQL et Redis.
Implémenter la préparation de la rotation des secrets 
Configurez la gestion d'environnement qui supporte AWS Secrets Manager pour l'injection d'identifiants en production tout en utilisant des fichiers .env locaux en développement. Incluez la validation pour les deux scénarios.

Bonnes pratiques

  • Utilisez toujours .env.example comme modèle commité montrant les variables requises sans les secrets réels
  • Implémentez la validation au runtime avec Zod au démarrage de l'application pour détecter les configurations manquantes tôt
  • Utilisez des fichiers de configuration spécifiques à l'environnement pour garder la logique spécifique à chaque environnement organisée et maintenable

Éviter

  • Ne commitez pas les fichiers .env avec de vrais identifiants dans le contrôle de version
  • Évitez d'accéder directement aux variables d'environnement dans le code ; utilisez un module de configuration centralisé
  • N'utilisez pas de valeurs par défaut faibles pour les secrets ; exigez une configuration explicite en production

Foire aux questions

Comment garder mes secrets en sécurité en utilisant cette skill ?
Ne commitez jamais les fichiers .env avec de vrais identifiants. Utilisez .env.example comme modèle montrant les variables requises, puis copiez-le dans .env.local pour le développement local. En production, injectez les secrets depuis les variables d'environnement, AWS Secrets Manager ou HashiCorp Vault.
Cette skill peut-elle se connecter à ma base de données pour valider les identifiants ?
Non, cette skill génère des modèles de configuration et des exemples de code. Elle ne peut pas valider que vos identifiants de base de données fonctionnent réellement. Testez vos configurations manuellement après génération.
Quelle est la différence entre .env et .env.local ?
Les fichiers .env sont généralement commités comme modèles (sans secrets) pour montrer aux membres de l'équipe quelles variables sont nécessaires. Les fichiers .env.local contiennent les surcharges locales avec les secrets réels et doivent être dans .gitignore.
Comment gérer les différentes valeurs pour le développement vs la production ?
Utilisez des fichiers de configuration séparés comme config/environments/development.ts et config/environments/production.ts. Chargez celui qui convient en fonction de NODE_ENV. Dans docker-compose, utilisez environment: pour les valeurs de production et env_file: pour le développement local.
Pourquoi devrais-je utiliser Zod pour la validation d'environnement ?
Zod valide les variables d'environnement au runtime avec des messages d'erreur clairs. Cela détecte les erreurs de configuration tôt avant qu'elles ne provoquent des erreurs cryptiques dans la logique profonde de votre application. Cela fournit également l'inférence de type TypeScript.
Puis-je utiliser cette skill avec d'autres langages que TypeScript ?
La skill se concentre sur les exemples TypeScript mais les concepts de base s'appliquent à n'importe quel langage. Les modèles de fichiers .env, les configurations docker-compose et les règles .gitignore fonctionnent universellement. Vous adapteriez les schémas de validation au langage de votre choix.

Détails du développeur

Licence

MIT

Dépôt

https://github.com/supercent-io/skills-template/tree/main/.agent-skills/environment-setup/

Réf

main

Structure de fichiers

📄 SKILL.md

📄 SKILL.toon