Prise en main
Replit est un environnement de développement cloud capable d’écrire et d’exécuter n’importe quel framework ou pile technologique. Pour créer un modèle personnalisé, deux approches sont recommandées :
- Importer depuis un fournisseur Git — Importez votre pile de démarrage existante (ou une correspondant à vos préférences) depuis GitHub, GitLab ou Bitbucket.
- Forker le modèle vide — Forkez le modèle vide pour partir de zéro avec un environnement de développement entièrement vide.
Des clients ont réussi à créer des modèles correspondant à Rust, Python, Java, C++ et bien d’autres piles — si ça tourne, ça peut tourner sur Replit.
Nous recommandons de travailler avec l’équipe Field Engineering de Replit lors de la création de vos premiers modèles. Ils ont une vaste expérience dans la configuration de modèles personnalisés pour un large éventail de piles et sont disponibles pour vous aider. Contactez votre Account Executive pour vous mettre en relation.
Les modèles personnalisés sont disponibles exclusivement sur le plan Enterprise. Seuls les administrateurs d’organisation peuvent épingler et gérer les modèles.
- Agent crée une nouvelle application en forkant le modèle (tous les fichiers sont copiés)
- Agent passe la phase de planification et va directement en mode construction
- Le fichier
custom_instruction/instructions.md du modèle est injecté dans le contexte d’Agent
- Les skills personnalisés de
.agents/skills/ sont découverts et rendus disponibles
- Le fichier
replit.md fournit le contexte de projet continu
Cela signifie que les standards, patterns et outils de votre organisation sont intégrés dès la toute première interaction.
Structure des fichiers du modèle
Voici la structure recommandée pour un modèle personnalisé :
my-template/
├── .replit # Configuration de l'application (commandes d'exécution, ports, modules)
├── replit.md # Mémoire d'Agent : présentation et préférences du projet
├── custom_instruction/
│ └── instructions.md # Instructions de l'entreprise injectées dans l'invite d'Agent
├── .agents/
│ └── skills/
│ └── my-skill/
│ └── SKILL.md # Skills personnalisés qu'Agent peut invoquer à la demande
└── ... # Le reste de la structure de votre dépôt
Créer l’application de base
Créez une nouvelle Replit App dans votre organisation. Configurez le projet avec tous les fichiers, dépendances et configuration dont vos builders ont besoin comme point de départ. Cela inclut :
- L’échafaudage du code source (composants, utilitaires, fichiers de configuration)
- Les dépendances pré-installées (
package.json, requirements.txt, etc.)
- La configuration de l’environnement dans le fichier
.replit
Si votre modèle repose sur des clés API, des jetons ou d’autres identifiants, ajoutez-les aux Secrets du modèle (sous le panneau Outils) avant d’épingler. Lorsqu’un builder crée une nouvelle application à partir du modèle, tous les secrets sont copiés dans la nouvelle application automatiquement, afin que les builders puissent commencer à travailler sans configurer eux-mêmes les identifiants.
Documentez chaque secret dans custom_instruction/instructions.md (ou dans un skill dédié) afin que les builders sachent ce qui est disponible et à quoi sert chaque clé.
Les secrets sont copiés au moment du fork, pas synchronisés dynamiquement. Si vous faites tourner une clé ou ajoutez un nouveau secret au modèle, les applications existantes précédemment forkées ne sont pas mises à jour. Les builders doivent ajouter ou mettre à jour les secrets manuellement dans ces applications.
Rédiger des instructions personnalisées
Créez un fichier à l’emplacement custom_instruction/instructions.md dans la racine du projet. C’est le fichier le plus important de votre modèle — il indique à Agent comment votre organisation crée des logiciels.
Le nom du dossier doit être custom_instruction (singulier), pas custom_instructions.
- Patterns d’architecture : Comment vos applications doivent être structurées
- Standards de codage : Conventions de nommage, règles d’organisation des fichiers, attentes en matière de linting
- Utilisation des composants : Quelles bibliothèques et composants utiliser (et lesquels éviter)
- Patterns d’API : Comment appeler vos services backend, gérer l’authentification, gérer les erreurs
- Exigences de test : Quels tests sont attendus et comment les exécuter
- Directives de déploiement : Configuration spécifique à l’environnement et flux de déploiement
# Company Engineering Standards
## Architecture
All web applications use React with TypeScript. Use functional components
with hooks exclusively. State management uses Zustand for local state
and React Query for server state.
## Component Library
Use our internal design system package `@acme/ui`. Never use raw HTML
elements for buttons, inputs, forms, or modals — always use the
corresponding component from `@acme/ui`.
Import components like this:
```tsx
import { Button, TextField, Modal } from '@acme/ui';
```
## API Integration
All API calls go through the `@acme/api-client` package. Never use
raw fetch or axios directly. Authentication is handled automatically
by the client.
## Testing
Every component must have a corresponding test file. Use Vitest
for unit tests and Playwright for integration tests.
.agents/skills/ plutôt que de tout conserver dans instructions.md. Les skills sont chargés à la demande lorsqu’ils sont pertinents, ils ne comptent donc pas dans la limite de taille des instructions et maintiennent vos instructions principales focalisées sur les règles de haut niveau.
Ajouter des skills personnalisés
Créez des skills dans le répertoire .agents/skills/ pour les flux de travail spécialisés qu’Agent doit suivre. Chaque skill est un répertoire contenant un fichier SKILL.md avec un frontmatter YAML.
.agents/skills/
├── use-design-system/
│ └── SKILL.md
├── api-integration/
│ └── SKILL.md
└── run-tests/
└── SKILL.md
SKILL.md a besoin d’un name et d’une description dans son frontmatter :
---
name: use-design-system
description: Use when building UI components. Provides component patterns, theming rules, and accessibility requirements for the Acme design system.
---
# Acme Design System
## Available components
- `Button` — Primary, secondary, and ghost variants
- `TextField` — Text input with validation support
- `Modal` — Dialog overlay with focus trapping
...
| Champ | Requis | Détails |
|---|
name | Oui | Maximum 64 caractères. Lettres minuscules, chiffres et traits d’union uniquement. |
description | Oui | Maximum 1 024 caractères. Décrit ce que fait le skill et quand l’utiliser. |
enabled | Non | Par défaut true. Définir sur false pour désactiver sans supprimer. |
name et la description dans son invite. Il lit le contenu complet de SKILL.md à la demande lorsque le skill est pertinent pour la tâche en cours. Cela signifie que la description est essentielle — rédigez-la pour qu’elle corresponde aux scénarios où Agent doit utiliser le skill.
Les skills peuvent également inclure des fichiers de support aux côtés de SKILL.md :
.agents/skills/use-design-system/
├── SKILL.md
├── references/
│ └── component-api.md
└── assets/
└── theme-tokens.json
replit.md dans la racine du projet avec la présentation de l’architecture de votre modèle. Ce fichier est toujours chargé dans le contexte d’Agent et sert de mémoire de projet continue.
Le fichier doit avoir ces quatre sections :
# Overview
Task management application built with React, TypeScript, and the Acme
design system. Uses Express.js backend with PostgreSQL.
# User Preferences
- Use TypeScript for all files
- Prefer functional components with hooks
- Follow Acme coding standards
# System Architecture
- Frontend: React + TypeScript + @acme/ui
- Backend: Express.js + TypeScript
- Database: PostgreSQL with Drizzle ORM
- Auth: Acme SSO via @acme/auth
# External Dependencies
- @acme/ui: Internal design system
- @acme/api-client: API integration layer
- @acme/auth: Authentication SDK
replit.md au fur et à mesure que le projet évolue. Si le fichier dépasse environ 4 000 tokens, Agent le résume automatiquement pour le maintenir ciblé et utile.
Pour plus de détails, consultez replit.md.
Épingler le modèle à votre organisation
Une fois votre modèle prêt :
- Accédez à l’application du modèle dans votre organisation
- Ouvrez le menu d’action de l’application (menu à trois points)
- Sélectionnez Pin to Agent input box
Seuls les administrateurs d’organisation (membres du rôle system_admins) peuvent épingler et désépingler les modèles.
Le modèle apparaît désormais comme une pastille sélectionnable sous la zone de saisie d’Agent pour chaque membre de votre organisation. Pour le supprimer, ouvrez le même menu et sélectionnez Unpin from Agent input box.
Contrôler l’accès au modèle
L’épinglage rend un modèle visible pour tous les membres de l’organisation. Pour une distribution plus ciblée, utilisez le bouton Invite sur l’application du modèle pour le partager avec des groupes ou des utilisateurs individuels spécifiques. Cela vous permet de limiter quelles équipes ou personnes peuvent voir et forker le modèle tout en le maintenant désépinglé de la zone de saisie à l’échelle de l’organisation.
Ce qui se passe lorsqu’un builder sélectionne un modèle
Lorsqu’un membre de l’organisation choisit un modèle épinglé dans la zone de saisie d’Agent :
- Fork : Une nouvelle application est créée comme copie du modèle, avec tous les fichiers inclus
- Ignorer la planification : Agent contourne la conversation de planification initiale et passe directement en mode construction
- Charger les instructions :
custom_instruction/instructions.md est lu et injecté dans l’invite système d’Agent en tant que directives fournies par l’entreprise
- Découvrir les skills : Les skills dans
.agents/skills/ sont identifiés et listés dans le contexte d’Agent pour un chargement à la demande
- Charger le contexte du projet :
replit.md est lu et injecté dans le contexte d’Agent (ou auto-généré s’il est absent)
- Hériter de la configuration : Le fichier
.replit, les dépendances et tous les fichiers du modèle sont transférés dans la nouvelle application
Le builder peut immédiatement commencer à inviter Agent avec ses exigences spécifiques, et Agent opère dans le cadre établi par le modèle.
Chaque fichier de configuration a un rôle distinct :
| Fichier | Objectif | Quand Agent le lit | Modifiable par Agent |
|---|
custom_instruction/instructions.md | Standards et règles de l’organisation | Toujours (injecté dans l’invite système) | Non |
.agents/skills/*/SKILL.md | Flux de travail et patterns spécialisés | À la demande (lorsque pertinent) | Oui (Agent peut aussi créer des skills) |
replit.md | Présentation et préférences du projet | Toujours (injecté dans l’invite système) | Oui (Agent le met à jour au fil du temps) |
.replit | Configuration du runtime | Lors de la configuration de l’application | Oui |
custom_instruction/instructions.md est votre source statique et faisant autorité pour les standards organisationnels. replit.md est le document vivant qu’Agent maintient à mesure que le projet évolue. Les skills sont du matériel de référence à la demande pour des flux de travail spécifiques.
Bonnes pratiques
Gardez les instructions ciblées
Rédigez custom_instruction/instructions.md pour les patterns qui comptent le plus. Concentrez-vous sur :
- Les décisions difficiles à inverser (architecture, modèles de données)
- Les patterns qui doivent être cohérents (utilisation des composants, conventions d’API)
- Les standards que le builder pourrait ne pas connaître (bibliothèques internes, conventions d’équipe)
Évitez d’inclure des journaux de modifications, des détails d’implémentation ou des informations qui changent fréquemment.
Rédigez des descriptions de skills découvrables
Le champ description dans le frontmatter de SKILL.md est ce qu’Agent utilise pour décider quand charger un skill. Rédigez des descriptions qui correspondent aux tâches où le skill est pertinent :
# Bien — décrit quand l'utiliser
description: Use when building forms or handling user input. Provides validation patterns, error display conventions, and accessible form layouts.
# Moins efficace — trop vague
description: Form utilities and helpers.
Organisez les skills par flux de travail
Regroupez les skills autour des flux de travail plutôt que des catégories techniques :
| Approche | Exemple |
|---|
| Par flux de travail | build-a-form, connect-to-api, add-auth |
| Par domaine technique | react-utils, api-helpers, auth-config |
Itérez sur votre modèle
Les modèles s’améliorent avec l’utilisation. Une fois que votre équipe commence à créer avec un modèle :
- Observez les patterns qu’Agent gère mal et ajoutez-les à
instructions.md
- Créez de nouveaux skills lorsqu’Agent résout bien un problème — capturez la solution
- Mettez à jour les dépendances de base et les configurations à mesure que votre pile évolue
- Testez les modifications en créant une nouvelle application à partir du modèle pour vérifier l’expérience
Mises à jour du modèle et applications existantes
Les modifications apportées à l’application du modèle se reflètent dans les nouvelles applications créées à partir de celui-ci. Les applications existantes précédemment forkées à partir du modèle sont des copies indépendantes et ne reçoivent pas les mises à jour.
Ressources associées
