Commands & Scripts
Découvrez comment les Commands étendent Claude Code avec des commandes slash personnalisées et comment les Scripts fournissent un outillage exécutable dans les sandboxes d’agents CodeCourier. Couvre la création, le versionnement et l’attribution.
Aux côtés des Skills, CodeCourier prend en charge deux types d’assets supplémentaires : Commands et Scripts. Les Commands ajoutent des extensions de commandes slash personnalisées au registre Claude Code à l’intérieur de chaque sandbox. Les Scripts sont des fichiers exécutables que les agents peuvent invoquer à l’exécution pour des tâches de configuration, de test ou d’utilitaire. Les deux sont versionnés et attribuables aux personas et types de session en utilisant la même hiérarchie que les Skills.
Commands
Ce que sont les Commands
Les Commands sont des extensions de commandes slash de Claude Code. Elles sont placées dans le répertoire .claude/commands/ de la sandbox sous forme de fichiers markdown, où la CLI Claude Code les découvre et les enregistre automatiquement. Lorsqu’un agent tape /{commandName} pendant une session, Claude Code exécute les instructions définies dans le fichier de commande.
Les Commands sont idéales pour standardiser des workflows complexes en plusieurs étapes que les agents effectuent de manière répétée. Plutôt que de faire confiance à l’agent pour trouver la bonne séquence d’étapes pour exécuter des tests, déployer ou auditer la sécurité à chaque fois, vous codifiez ces étapes une seule fois sous forme de commande et l’invoquez avec un seul slash.
Modèle de données des Commands
commands: {
commandId: string // unique identifier
name: string // the slash-command name (e.g., "run-tests")
// invoked as /run-tests in Claude Code
description: string // what this command does
content: string // markdown instructions executed when command is invoked
isEnabled: boolean // whether this command is selectable
}
commandVersions: {
commandId: string
version: number // incrementing version number
name: string // name at time of publish
description: string // description at time of publish
content: string // full content at time of publish
status: "active" | "inactive"
publishedAt: number // Unix timestamp
publishedBy: string // user ID of publisher
}Exemples de Commands
Voici des exemples de commandes qui fonctionnent bien en pratique :
# Run Tests
Execute the full test suite and report results.
## Steps
1. Run `bun test --run` to execute all unit and integration tests
2. If tests fail, read the error output carefully and identify the root cause
3. Do NOT modify test files to make tests pass - fix the source code instead
4. After all tests pass, run `bun run build` to verify the TypeScript compiles
5. Report a summary: total tests run, passed, failed, and any build warnings# Security Review
Perform a targeted security audit on all files changed in the current session.
## Checklist
1. **Input validation** - Confirm all user-supplied inputs are validated before use
2. **SQL/command injection** - Verify no user input is interpolated into queries or shell commands
3. **Authentication** - Check that all API routes requiring auth are protected
4. **Secrets** - Scan for hardcoded API keys, passwords, or tokens (use environment variables instead)
5. **XSS** - Confirm no `dangerouslySetInnerHTML` usage without sanitization
6. **Dependencies** - Flag any newly added dependencies with known vulnerabilities
## Output
Return a structured report:
- PASS if no issues found
- FAIL with a numbered list of issues, each with the file path, line number, and recommended fix# Deploy Check
Verify the application is ready for deployment.
## Pre-deploy Verification Steps
1. Run `bun run build` - must exit with code 0
2. Run `bun run type-check` - zero TypeScript errors permitted
3. Run `bun run lint` - zero ESLint errors permitted (warnings are acceptable)
4. Run `bun test --run` - all tests must pass
5. Check for uncommitted changes with `git status`
6. Confirm the branch is up to date with main using `git log main..HEAD --oneline`
## Output
If all checks pass: respond with "DEPLOY_READY" and a brief summary of what was verified.
If any check fails: respond with "DEPLOY_BLOCKED", the specific check that failed, and the fix required.Créer une Command
Accéder à la section d’assets Commands
Depuis la barre latérale du projet, accédez à la section Assets et sélectionnez Commands. Cliquez sur + Créer une commande.
Saisir les détails de la commande
Fournissez un nom (l’identifiant de la commande slash - utilisez des minuscules avec des tirets, par exemple, run-tests), une description résumant ce que fait la commande, et le contenu (les instructions markdown que Claude Code exécute lorsque la commande est invoquée).
Rédiger un contenu de commande efficace
Le contenu de la commande doit être :
- Étape par étape - étapes numérotées pour une exécution séquentielle
- Explicite sur le format de sortie - dites à l’agent comment structurer sa réponse
- Spécifique sur les outils - nommez les commandes CLI exactes à exécuter
- Clair sur la gestion des erreurs - précisez comment gérer les échecs
Publier la commande
Cliquez sur Publier pour créer la version 1. La commande est désormais disponible pour l’attribution aux personas et types de session.
Nommage des Commands
name devient l’identifiant de la commande slash dans Claude Code. Il doit être en minuscules, n’utiliser que des lettres, des chiffres et des tirets, et ne doit pas entrer en conflit avec les commandes intégrées de Claude Code. Claude Code enregistre automatiquement au démarrage les commandes trouvées dans .claude/commands/.Versionner les Commands
Les Commands suivent le même cycle de vie de versionnement que les Skills. Chaque publication crée une nouvelle version, l’active et désactive la précédente. Utilisez de nouvelles versions chaque fois que :
- Une commande CLI change (par exemple, passer de
npm testàbun test) - Le format de sortie attendu doit changer
- De nouvelles étapes doivent être ajoutées au workflow
- Une étape existante s’avère produire des résultats incorrects
Scripts
Ce que sont les Scripts
Les Scripts sont des fichiers exécutables - scripts shell, scripts Python, scripts Node.js, ou tout format exécutable - qui sont placés dans la sandbox avant l’exécution de l’agent. À la différence des Skills (qui sont du matériel de référence en lecture seule) et des Commands (qui encodent des instructions étape par étape pour l’agent), les Scripts sont des artefacts exécutables que l’agent peut lancer directement.
Les Scripts sont idéaux pour :
- Une configuration d’environnement complexe qui ne devrait pas dépendre de l’agent la déterminant à chaque fois
- Exécuter des suites de tests de manière standardisée qui encapsule les bons flags et la bonne configuration
- Des opérations utilitaires impliquant plusieurs outils CLI ou du piping complexe difficile à dériver manuellement
- Des workflows de déploiement ou de lint spécifiques au projet avec des configurations non standard
Modèle de données des Scripts
scripts: {
scriptId: string // unique identifier
name: string // display name (e.g., "setup-environment")
description: string // what this script does and when to run it
content: string // full script content (shell, Python, etc.)
isEnabled: boolean // whether this script is selectable
}
scriptVersions: {
scriptId: string
version: number // incrementing version number
name: string // name at time of publish
description: string // description at time of publish
content: string // full script content at time of publish
status: "active" | "inactive"
publishedAt: number // Unix timestamp
publishedBy: string // user ID of publisher
}Exemples de Scripts
#!/bin/bash
# Setup Environment
# Run this script at the start of a new session to initialize the dev environment.
set -e # Exit on any error
echo "==> Cloning repository..."
cd /home/user
git clone "$REPO_URL" project
cd project
echo "==> Installing dependencies..."
bun install
echo "==> Setting up environment variables..."
cp .env.example .env.local
echo "NEXT_PUBLIC_CONVEX_URL=$CONVEX_URL" >> .env.local
echo "NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY=$CLERK_KEY" >> .env.local
echo "==> Running initial build to verify setup..."
bun run build
echo "==> Environment ready. Start dev server with: bun dev"
#!/bin/bash
# Run End-to-End Tests
# Starts the dev server, waits for readiness, then runs Playwright tests.
set -e
echo "==> Starting dev server in background..."
nohup bun dev > /tmp/devserver.log 2>&1 &
DEV_PID=$!
echo "==> Waiting for server to be ready..."
timeout 60 bash -c 'until curl -sf http://localhost:3000 > /dev/null; do sleep 2; done'
echo "==> Running Playwright E2E tests..."
bun run test:e2e
echo "==> Stopping dev server..."
kill $DEV_PID 2>/dev/null || true
Créer un Script
Accéder à la section d’assets Scripts
Depuis la section Assets de la barre latérale, sélectionnez Scripts et cliquez sur + Créer un script.
Saisir les détails du script
Fournissez un nom (utilisé comme nom de fichier, par exemple, setup-environment), une description expliquant quand et pourquoi exécuter le script, et le contenu complet du script.
Référencer le script dans les instructions de la persona
Contrairement aux Skills et aux Commands, qui sont découverts automatiquement par l’agent, les Scripts doivent être explicitement référencés dans les instructions de la persona. Par exemple :
## Setup
Before starting any task, run the setup script to initialize the environment:
```
bash /home/user/scripts/setup-environment.sh
```
The script clones the repository, installs dependencies, and configures environment variables.
Do NOT manually install dependencies or clone the repo - use the script.Publier le script
Cliquez sur Publier pour créer la version 1 et rendre le script disponible pour l’attribution.
Permissions des Scripts
#!/bin/bash, #!/usr/bin/env python3, etc.) afin qu’ils soient exécutables. Les scripts qui ne s’exécutent pas proprement peuvent empêcher l’agent de terminer sa tâche.Bonnes pratiques pour les Scripts
- Utilisez toujours
set -edans les scripts shell - Cela entraîne la sortie immédiate du script en cas d’erreur, empêchant les échecs partiels silencieux qui sont difficiles à déboguer. - Journalisez chaque étape majeure - Utilisez
echo "==> Step name..."avant chaque section afin que l’agent puisse voir la progression dans la sortie du terminal. - Utilisez des variables d’environnement, pas des valeurs codées en dur - Référencez
$REPO_URL,$CONVEX_URL, etc. Celles-ci sont injectées depuis les Paramètres du projet et les variables d’environnement de la sandbox, gardant les secrets hors du contenu du script. - Testez d’abord les scripts localement - Avant de déployer une nouvelle version de script, testez-la dans une sandbox autonome pour vérifier qu’elle s’exécute proprement sans erreurs.
- Gardez les scripts idempotents - Écrivez des scripts qui peuvent être exécutés plusieurs fois sans casser. Utilisez des flags
-fsur les commandes destructrices et vérifiez l’état existant avant de le créer.
Attribution : Commands et Scripts
Les Commands et les Scripts sont tous deux attribués aux personas et types de session en utilisant le même mécanisme que les Skills. Sur l’onglet Skills de la page de détail de la persona, la page est divisée en trois sections : Skills, Commands et Scripts. Sélectionnez les assets souhaités dans chaque section.
Pour les valeurs par défaut de type de session, accédez à l’onglet de configuration approprié dans les Paramètres du projet (par exemple, /p/{id}/issues-setup) et configurez les sections Commands et Scripts aux côtés des Skills.
Les Commands nécessitent Claude Code
.claude/commands/ seront présentes dans la sandbox mais ne seront pas auto-enregistrées. Assurez-vous que les personas utilisant des Commands personnalisées sont configurées pour utiliser Claude Code.Prochaines étapes
Skills
Découvrez les Skills - packages de connaissances multi-fichiers injectés dans .claude/skills/.
Vue d’ensemble des Assets
Passez en revue le système complet d’assets, le modèle d’injection et la hiérarchie d’attribution.
Configuration des personas
Attribuez des Commands et des Scripts aux personas depuis l’onglet Skills.
Paramètres du projet
Configurez les valeurs par défaut de Command et Script par type de session.