Votre premier projet

Après vous être connecté, vous arrivez sur l’écran de sélection de projet. Si vous êtes déjà à l’intérieur d’un projet, cliquez sur le nom de votre projet dans l’en-tête de la sidebar pour revenir au sélecteur de projet. Cliquez sur New Project.

Fournissez les informations suivantes :

• Nom du projet- Un nom lisible pour votre projet, p. ex., “E-commerce Backend” ou “Design System”
• URL du repository GitHub- (Optionnel) L’URL HTTPS du repository sur lequel vous voulez que les agents travaillent, p. ex., https://github.com/your-org/your-repo. Cela permet la création automatique de branches et la génération de PR.

Le slug du projet est généré automatiquement à partir du nom. Par exemple, “E-commerce Backend” devient e-commerce-backend. Ce slug est utilisé dans toutes les URL du projet.

Cliquez sur Create Project. CodeCourier crée l’enregistrement du projet, vous définit comme owner, initialise les paramètres du projet avec des valeurs par défaut et vous redirige vers le dashboard du projet. Le dashboard affiche initialement des compteurs à zéro pour les sandboxes, runs, workflows et membres.

Cliquez sur New Context et sélectionnez le type de session issue. Écrivez le system prompt que l’agent de scan d’issues doit recevoir, en incluant les priorités de votre projet, les zones de préoccupation et tous les patterns qu’il doit rechercher :

You are scanning a TypeScript/Next.js codebase for issues.
Focus on:
- Type safety violations and implicit any usage
- Missing error boundaries and unhandled promise rejections
- N+1 query patterns in data fetching
- Accessibility regressions in UI components
- Missing or inadequate test coverage

Prioritize issues that would affect production stability.
Generate specific, actionable titles and descriptions.

Enregistrez le contexte. CodeCourier crée la version 1 de ce document et l’associe aux sessions d’issues de votre projet.

Créez un autre contexte pour le type de session learning. Ce contexte indique à l’agent d’extraction de learnings comment identifier et catégoriser les learnings des runs terminés :

You are extracting learnings from an AI agent's completed coding session.
Focus on:
- Mistakes the agent made that were corrected
- Project-specific patterns or conventions that emerged
- Tool usage gotchas specific to this codebase
- Architectural decisions with rationale

Categorize each learning as: preference, pattern, gotcha, tool, or architecture.
Only extract learnings that would be actionable in future sessions.

Répétez pour tout autre type de session que vous utilisez : merging, answering, evaluating et judging. Chaque type de contexte est indépendant ; vous pouvez les ajouter à mesure que vous introduisez chaque capacité dans votre workflow.

Cliquez sur New Skill. Donnez au skill un nom (p. ex., “Project Conventions”) et ajoutez un ou plusieurs fichiers. Chaque fichier a un nom et un contenu :

# Project Conventions

## TypeScript
- All files must use strict mode
- Never use `any` - use `unknown` and narrow it
- Prefer interface over type for object shapes

## Database (Convex)
- Never call .collect() on large tables
- Use paginate() for lists longer than 100 items
- Batch writes use ctx.scheduler.runAfter

## Testing
- All new functions need a Vitest unit test
- Integration tests go in __tests__/integration/
- Use MSW for HTTP mocking, never mock fetch directly

Enregistrez le skill. Il est désormais disponible pour être rattaché aux personas et aux session configurations.

Créez des commands pour vos opérations d’agent les plus courantes. Par exemple :

• Name : run-tests - Expression : npx vitest run --reporter=verbose
• Name : typecheck - Expression : npx tsc --noEmit
• Name : lint - Expression : npx eslint . --ext .ts,.tsx

Les commands donnent aux agents des alias stables et spécifiques au projet qui restent cohérents même si votre configuration d’outillage change.

Les scripts sont optionnels mais utiles pour l’automatisation avant ou après le run. Par exemple, un script pré-run pourrait cloner le repository vers un état connu, ou un script post-run pourrait exécuter une dernière passe de lint et committer les problèmes corrigés automatiquement.

Rendez-vous dans Issue Session dans Project Settings. Ici, vous pouvez :

• Rattacher un contexte - Sélectionnez le contexte d’issue que vous avez créé plus tôt. Ce document de contexte sera injecté automatiquement dans chaque session de scan d’issues.
• Sélectionner des skills- Choisissez quels packages de skill sont disponibles dans les sessions d’issues. Votre skill “Project Conventions” est une bonne sélection par défaut.
• Sélectionner des commands - Ajoutez vos commandsrun-tests et typecheck pour que l’agent de scan puisse valider ses trouvailles.
• Définir le prompt de session d’issues - Un prompt en texte libre supplémentaire préfixé au prompt de découverte de l’utilisateur.

Ouvrez l’onglet de configuration Learning Session. Rattachez votre document de contexte de learning et sélectionnez les skills ou commands pertinents pour l’extraction de learnings. L’agent de learning utilisera ces ressources lors de l’analyse des sessions terminées.

Répétez le processus de rattachement pour les sessions Merge, Answering, Evaluator et Judge à mesure que vous adoptez ces capacités. Chaque type de session est pleinement indépendant - vous pouvez les configurer de façon incrémentale à mesure que votre workflow mûrit.

Cliquez sur Members dans la sidebar sous la section Insights. Cette page affiche tous les membres actuels et les invitations en attente.

Cliquez sur Invite Member. Saisissez l’adresse e-mail de la personne que vous voulez inviter et sélectionnez son rôle :

• Admin - Peut gérer toutes les ressources et paramètres du projet, inviter d’autres membres
• Member - Peut créer et gérer ses propres sandboxes, runs et workflows

L’invitation est créée immédiatement. La personne invitée verra une invitation en attente lorsqu’elle se connectera à CodeCourier. Une fois qu’elle accepte, son statut passe de “pending” à “accepted” et elle obtient l’accès à toutes les ressources du projet selon son rôle.

Depuis la page des membres, vous pouvez changer le rôle d’un membre ou le retirer du projet. L’owner du projet ne peut pas être retiré mais peut transférer la propriété en faisant d’un autre membre l’owner.

Cliquez sur Personas dans la sidebar. Cette page affiche toutes les personas configurées pour le projet.

Cliquez sur New Persona et configurez-la :

• Name: “Senior Developer”
• Type : Designer
• Model : Choisissez votre modèle préféré (p. ex., claude-sonnet-4-6 pour la vitesse ou claude-opus-4-6 pour la qualité)
• Thinking effort : Medium ou High
• Instructions :

You are a senior full-stack developer. Follow these principles:
- Write clean, well-documented TypeScript code
- Prefer composition over inheritance
- Write tests for all new functions
- Use existing project patterns and conventions
- Keep changes focused and minimal

• Skills: Sélectionnez votre skill “Project Conventions” et tout autre skill pertinent
• Commands : Activez run-tests, typecheck et lint
• Learnings : Activez pour inclure les learnings du projet dans le contexte

Créez une seconde persona pour la revue de code :

• Name: “Code Reviewer”
• Type : Checker
• Model : Utilisez un modèle puissant pour la revue ( claude-opus-4-6 recommandé)
• Thinking effort : High
• Instructions :

You are a thorough code reviewer. Evaluate the changes against:
- Correctness: Does the code do what was asked?
- Type safety: Are there any TypeScript errors or any-typed values?
- Edge cases: Are error states and boundary conditions handled?
- Testing: Are tests present and meaningful?
- Style: Does the code follow project conventions?

Return pass: true only if ALL criteria are met.
If rejecting, provide specific, actionable feedback.

Envisagez de créer des personas supplémentaires pour des rôles spécifiques :

• Investigator - Pour les tâches de recherche qui explorent les codebases avant de modifier
• Planner - Pour les sessions d’issues et l’analyse de codebase avec des principes architecturaux spécifiques
• Reviewer - Axée sur la lisibilité, la maintenabilité et la rigueur de la revue de code
• Deep-dive - Pour les tâches d’analyse approfondie nécessitant un raisonnement étendu

Rendez-vous dans Sandboxes dans la sidebar et cliquez sur New Sandbox. Configurez le sandbox template, le timeout et les ressources. Donnez-lui un nom descriptif comme “Explore codebase” et fournissez un prompt initial.

Les sandboxes autonomes sont utiles pour les tâches ponctuelles : investiguer un bug, prototyper une solution ou tester un changement de configuration avant de l’encoder dans un workflow.

Une fois la sandbox en cours d’exécution, vous pouvez voir le stream de messages de l’agent en temps réel. La page de détail affiche l’historique complet de la conversation, le statut de la sandbox et tout statut de PR ou d’extraction de learnings.

Rendez-vous dans Workflows et créez un nouveau workflow Persona Pipeline :

• Name: “Full Review Pipeline”
• Type : Persona Pipeline
• Steps: Ajoutez votre persona “Senior Developer” comme première étape, puis votre persona “Code Reviewer” comme seconde étape. Configurez éventuellement une boucle entre elles avec un nombre maximal d’itérations.
• Template : Sélectionnez le sandbox template correspondant à votre préférence d’outil CLI
• Timeout : 30 minutes par étape

Cliquez sur Run sur votre nouveau workflow. Saisissez un prompt décrivant la fonctionnalité ou le correctif que vous voulez :

Add a reusable DateRangePicker component to
components/ui/date-range-picker.tsx. It should:

1. Accept startDate, endDate, and onChange props
2. Use the existing react-day-picker dependency
3. Support both controlled and uncontrolled modes
4. Include proper TypeScript types
5. Follow the existing shadcn/ui component patterns
6. Add a Storybook story file

Spécifiez un nom de branche (p. ex., feat/date-range-picker) et confirmez l’URL du repository GitHub si nécessaire. Cliquez sur Start Run.

Observez la progression du run depuis la page de détail du run :

1. La persona designer reçoit votre prompt, explore le repository et implémente la fonctionnalité
2. La persona checker relit l’implémentation au regard de vos critères et approuve ou fournit du feedback
3. En cas de rejet, le designer itère avec le feedback jusqu’à l’approbation ou l’atteinte du nombre maximal d’itérations
4. Les scores de qualité sont enregistrés pour chaque étape - vous pouvez voir les scores de correction, sûreté de typage, style de code, couverture de tests et complétude dans les détails de l’étape
5. À la fin, CodeCourier crée une PR sur la branche spécifiée

Rendez-vous dans Issues dans la sidebar et cliquez sur New Issue Session. Sélectionnez la branche que vous voulez analyser et fournissez un prompt de découverte (ou appuyez-vous sur le document de contexte que vous avez configuré plus tôt). Démarrez la session.

La session utilisera le contexte et les assets de Issue Session que vous avez configurés dans Project Settings. Une fois terminée, vous verrez une liste d’issues générées avec titres, descriptions et priorités.

Certaines issues peuvent s’accompagner de questions ouvertes ou d’hypothèses non résolues - par exemple, “Ce cache miss est-il acceptable, ou devons-nous pré-chauffer le cache ?” Lorsque vous voyez de telles questions rattachées à une issue, cliquez sur Start Answering Session.

L’Answering Session crée une sandbox en utilisant votre contexte d’Answering Session configuré. L’agent reçoit les questions ouvertes et les traite, produisant des réponses structurées qui sont rattachées à l’issue. Ces réponses sont ensuite transmises au run d’implémentation, de sorte que la persona designer n’a pas besoin de deviner.

Une fois les questions résolues, cliquez sur Run sur une issue (ou sélectionnez plusieurs issues et créez une work chain). Le run d’implémentation reçoit le prompt suggéré de l’issue plus toutes les réponses de l’Answering Session.