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.

8 min lire
commandsscriptsassets

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

command-data-model.ts
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 :

.claude/commands/run-tests.md
# 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
.claude/commands/security-review.md
# 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
.claude/commands/deploy-check.md
# 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

1

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.

2

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).

3

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
4

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

Le champ 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

script-data-model.ts
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

setup-environment.sh
#!/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"
run-e2e.sh
#!/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

1

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.

2

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.

3

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 :

designer-instructions.md
## 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.
4

Publier le script

Cliquez sur Publier pour créer la version 1 et rendre le script disponible pour l’attribution.

Permissions des Scripts

Les Scripts sont placés dans le système de fichiers de la sandbox avec des permissions d’exécution. Assurez-vous que vos scripts commencent par la bonne ligne shebang (#!/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 -e dans 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 -f sur 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

Les Commands personnalisées ne fonctionnent qu’avec l’outil CLI Claude Code. Si une persona utilise un outil CLI différent (OpenCode, Codex), les commandes placées dans .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