Commands & Scripts
Scopri come le Commands estendono Claude Code con comandi slash personalizzati e come gli Scripts forniscono strumenti eseguibili nelle sandbox degli agenti CodeCourier. Copre creazione, versionamento e assegnazione.
Oltre alle Skills, CodeCourier supporta due tipi di asset aggiuntivi: Commands e Scripts. Le Commands aggiungono estensioni di comandi slash personalizzati al registro di Claude Code all’interno di ogni sandbox. Gli Scripts sono file eseguibili che gli agenti possono invocare a runtime per attività di configurazione, test o utilità. Entrambi sono versionati e assegnabili a personas e tipi di sessione usando la stessa gerarchia delle Skills.
Commands
Cosa sono le Commands
Le Commands sono estensioni di comandi slash di Claude Code. Vengono collocate nella directory .claude/commands/ della sandbox come file markdown, dove la CLI di Claude Code le scopre e le registra automaticamente. Quando un agente digita /{commandName} durante una sessione, Claude Code esegue le istruzioni definite nel file del comando.
Le Commands sono ideali per standardizzare workflow complessi in più fasi che gli agenti eseguono ripetutamente. Invece di affidarti all’agente per individuare la giusta sequenza di passaggi per eseguire test, deploy o audit di sicurezza ogni volta, codifichi quei passaggi una sola volta come comando e lo invochi con un singolo slash.
Modello dati delle 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
}Esempi di Commands
Di seguito alcuni esempi di comandi che funzionano bene nella pratica:
# 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.Creare una Command
Vai alla sezione asset Commands
Dalla barra laterale del progetto, vai alla sezione Assets e seleziona Commands. Clicca su + Crea comando.
Inserisci i dettagli del comando
Fornisci un nome (l’identificatore del comando slash - usa lettere minuscole con trattini, ad esempio, run-tests), una descrizione che riassuma cosa fa il comando e il contenuto (le istruzioni markdown che Claude Code esegue quando il comando viene invocato).
Scrivi contenuti di comando efficaci
Il contenuto del comando dovrebbe essere:
- Passo per passo - passaggi numerati per un’esecuzione sequenziale
- Esplicito sul formato di output - indica all’agente come strutturare la sua risposta
- Specifico sugli strumenti - nomina i comandi CLI esatti da eseguire
- Chiaro sulla gestione degli errori - specifica come gestire i fallimenti
Pubblica il comando
Clicca su Pubblica per creare la versione 1. Il comando è ora disponibile per l’assegnazione a personas e tipi di sessione.
Denominazione delle Commands
name diventa l’identificatore del comando slash in Claude Code. Deve essere in minuscolo, usare solo lettere, numeri e trattini e non deve entrare in conflitto con i comandi integrati di Claude Code. Claude Code registra automaticamente all’avvio i comandi trovati in .claude/commands/.Versionare le Commands
Le Commands seguono lo stesso ciclo di vita di versionamento delle Skills. Ogni pubblicazione crea una nuova versione, la attiva e disattiva la precedente. Usa nuove versioni ogni volta che:
- Un comando CLI cambia (ad esempio, passare da
npm testabun test) - Il formato di output atteso deve cambiare
- Nuovi passaggi devono essere aggiunti al workflow
- Un passaggio esistente si rivela produrre risultati errati
Scripts
Cosa sono gli Scripts
Gli Scripts sono file eseguibili - script shell, script Python, script Node.js o qualsiasi formato eseguibile - che vengono collocati nella sandbox prima dell’esecuzione dell’agente. A differenza delle Skills (che sono materiale di riferimento in sola lettura) e delle Commands (che codificano istruzioni passo per passo per l’agente), gli Scripts sono artefatti eseguibili che l’agente può lanciare direttamente.
Gli Scripts sono ideali per:
- Configurazioni d’ambiente complesse che non dovrebbero dipendere dall’agente che le individua ogni volta
- Eseguire suite di test in modo standardizzato che incapsula i flag e la configurazione corretti
- Operazioni di utilità che coinvolgono più strumenti CLI o piping complessi soggetti a errori se derivati manualmente
- Workflow di deploy o lint specifici del progetto con configurazioni non standard
Modello dati degli 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
}Esempi di 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
Creare uno Script
Vai alla sezione asset Scripts
Dalla sezione Assets nella barra laterale, seleziona Scripts e clicca su + Crea script.
Inserisci i dettagli dello script
Fornisci un nome (usato come nome del file, ad esempio, setup-environment), una descrizione che spieghi quando e perché eseguire lo script e il contenuto completo dello script.
Richiama lo script nelle istruzioni della persona
A differenza di Skills e Commands, che vengono scoperti automaticamente dall’agente, gli Scripts dovrebbero essere richiamati esplicitamente nelle istruzioni della persona. Ad esempio:
## 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.Pubblica lo script
Clicca su Pubblica per creare la versione 1 e rendere lo script disponibile per l’assegnazione.
Permessi degli Scripts
#!/bin/bash, #!/usr/bin/env python3, ecc.) affinché siano eseguibili. Gli script che non vengono eseguiti correttamente possono impedire all’agente di completare il suo task.Best practice per gli Scripts
- Usa sempre
set -enegli script shell - Questo fa uscire immediatamente lo script in caso di errore, evitando fallimenti parziali silenziosi difficili da debuggare. - Registra ogni passaggio principale - Usa
echo "==> Step name..."prima di ogni sezione affinché l’agente possa vedere l’avanzamento nell’output del terminale. - Usa variabili d’ambiente, non valori codificati in modo fisso - Richiama
$REPO_URL,$CONVEX_URL, ecc. Queste vengono iniettate dalle Impostazioni del progetto e dalle variabili d’ambiente della sandbox, mantenendo i segreti fuori dal contenuto dello script. - Testa prima gli script localmente - Prima di distribuire una nuova versione di script, testala in una sandbox autonoma per verificare che venga eseguita correttamente senza errori.
- Mantieni gli script idempotenti - Scrivi script che possano essere eseguiti più volte senza rompersi. Usa i flag
-fsui comandi distruttivi e controlla lo stato esistente prima di crearlo.
Assegnazione: Commands e Scripts
Sia le Commands che gli Scripts vengono assegnati a personas e tipi di sessione usando lo stesso meccanismo delle Skills. Nella scheda Skills della pagina di dettaglio della persona, la pagina è divisa in tre sezioni: Skills, Commands e Scripts. Seleziona gli asset desiderati in ciascuna sezione.
Per le impostazioni predefinite del tipo di sessione, vai alla relativa scheda di configurazione nelle Impostazioni del progetto (ad esempio, /p/{id}/issues-setup) e configura le sezioni Commands e Scripts accanto alle Skills.
Le Commands richiedono Claude Code
.claude/commands/ saranno presenti nella sandbox ma non verranno registrati automaticamente. Assicurati che le personas che usano Commands personalizzate siano configurate per usare Claude Code.Prossimi passi
Skills
Scopri le Skills - pacchetti di conoscenza multi-file iniettati in .claude/skills/.
Panoramica degli Assets
Rivedi il sistema completo di asset, il modello di iniezione e la gerarchia di assegnazione.
Configurazione delle personas
Assegna Commands e Scripts alle personas dalla scheda Skills.
Impostazioni del progetto
Configura le impostazioni predefinite di Command e Script per tipo di sessione.