Befehle und Skripte
Erfahren Sie, wie Befehle Claude Code um eigene Slash-Befehle erweitern und wie Skripte ausführbares Tooling in CodeCourier-Agenten-Sandboxes bereitstellen. Behandelt werden Erstellung, Versionierung und Zuweisung.
Neben Skills unterstützt CodeCourier zwei weitere Asset-Typen: Befehle und Skripte. Befehle ergänzen die Slash-Befehl-Registry von Claude Code innerhalb jeder Sandbox um eigene Erweiterungen. Skripte sind ausführbare Dateien, die Agenten zur Laufzeit für Setup-, Test- oder Hilfsaufgaben aufrufen können. Beide sind versioniert und können Personas und Sitzungstypen über dieselbe Hierarchie wie Skills zugewiesen werden.
Befehle
Was Befehle sind
Befehle sind Erweiterungen für Slash-Befehle in Claude Code. Sie werden als Markdown-Dateien im Verzeichnis .claude/commands/ der Sandbox abgelegt, wo die Claude Code CLI sie automatisch erkennt und registriert. Wenn ein Agent während einer Sitzung /{commandName} eingibt, führt Claude Code die in der Befehlsdatei definierten Anweisungen aus.
Befehle eignen sich ideal, um komplexe, mehrstufige Workflows zu standardisieren, die Agenten wiederholt durchführen. Anstatt darauf zu vertrauen, dass der Agent jedes Mal die richtige Schrittfolge für Tests, Deployment oder Sicherheitsprüfung herleitet, kodifizieren Sie diese Schritte einmal als Befehl und rufen ihn mit einem einzigen Slash auf.
Befehls-Datenmodell
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
}Beispielbefehle
Unten finden Sie Beispiele für Befehle, die sich in der Praxis bewährt haben:
# 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.Einen Befehl anlegen
Zum Asset-Bereich „Befehle“ navigieren
Navigieren Sie in der Projekt-Seitenleiste zum Bereich „Assets“ und wählen Sie Befehle. Klicken Sie auf + Befehl anlegen.
Befehlsdetails eingeben
Geben Sie einen Namen an (den Slash-Befehl-Bezeichner - Kleinbuchstaben mit Bindestrich, z. B. run-tests), eine Beschreibung, die zusammenfasst, was der Befehl tut, sowie den Inhalt (die Markdown-Anweisungen, die Claude Code beim Aufruf des Befehls ausführt).
Wirkungsvollen Befehlsinhalt schreiben
Befehlsinhalte sollten:
- Schritt für Schritt - nummerierte Schritte für sequenzielle Ausführung
- Explizit zum Ausgabeformat - dem Agenten vorgeben, wie er seine Antwort strukturieren soll
- Spezifisch zu Werkzeugen - die genauen CLI-Befehle benennen, die auszuführen sind
- Klar zur Fehlerbehandlung - angeben, wie mit Fehlern umzugehen ist
Befehl veröffentlichen
Klicken Sie auf Veröffentlichen, um Version 1 anzulegen. Der Befehl steht nun für die Zuweisung an Personas und Sitzungstypen zur Verfügung.
Befehlsbenennung
name wird zum Slash-Befehl-Bezeichner in Claude Code. Es muss kleingeschrieben sein, darf nur Buchstaben, Ziffern und Bindestriche enthalten und darf nicht mit den eingebauten Befehlen von Claude Code kollidieren. Claude Code registriert die in .claude/commands/ gefundenen Befehle automatisch beim Start.Befehle versionieren
Befehle folgen demselben Versionierungs-Lebenszyklus wie Skills. Jede Veröffentlichung erzeugt eine neue Version, aktiviert sie und deaktiviert die vorherige. Verwenden Sie neue Versionen, wann immer:
- Ein CLI-Befehl sich ändert (z. B. Wechsel von
npm testzubun test) - Das erwartete Ausgabeformat angepasst werden muss
- Neue Schritte zum Workflow hinzugefügt werden müssen
- Ein bestehender Schritt nachweislich falsche Ergebnisse produziert
Skripte
Was Skripte sind
Skripte sind ausführbare Dateien - Shell-Skripte, Python-Skripte, Node.js-Skripte oder ein beliebiges ausführbares Format -, die vor dem Start des Agenten in der Sandbox abgelegt werden. Anders als Skills (schreibgeschütztes Referenzmaterial) und Befehle (Schritt-für-Schritt-Anweisungen für den Agenten) sind Skripte ausführbare Artefakte, die der Agent direkt aufrufen kann.
Skripte eignen sich ideal für:
- Komplexe Umgebungseinrichtungen, die der Agent nicht jedes Mal selbst herleiten soll
- Standardisierte Ausführung von Testsuiten, die die richtigen Flags und Konfigurationen kapseln
- Hilfsoperationen mit mehreren CLI-Tools oder komplexem Piping, die manuell fehleranfällig wären
- Projektspezifische Deploy- oder Lint-Workflows mit ungewöhnlichen Konfigurationen
Skript-Datenmodell
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
}Beispielskripte
#!/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
Ein Skript anlegen
Zum Asset-Bereich „Skripte“ navigieren
Wählen Sie im Bereich „Assets“ in der Seitenleiste Skripte und klicken Sie auf + Skript anlegen.
Skriptdetails eingeben
Geben Sie einen Namen an (wird als Dateiname verwendet, z. B. setup-environment), eine Beschreibung, die erklärt, wann und warum das Skript auszuführen ist, sowie den vollständigen Inhalt des Skripts.
Skript in Persona-Anweisungen referenzieren
Anders als Skills und Befehle, die der Agent automatisch entdeckt, sollten Skripte in den Persona-Anweisungen explizit referenziert werden. Zum Beispiel:
## 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.Skript veröffentlichen
Klicken Sie auf Veröffentlichen, um Version 1 anzulegen und das Skript für die Zuweisung verfügbar zu machen.
Skriptberechtigungen
#!/bin/bash, #!/usr/bin/env python3 usw.), damit sie ausführbar sind. Skripte, die nicht sauber ausgeführt werden, können den Agenten daran hindern, seine Aufgabe abzuschließen.Best Practices für Skripte
- Verwenden Sie stets
set -ein Shell-Skripten - Dadurch beendet sich das Skript bei jedem Fehler sofort, sodass stille Teilausfälle vermieden werden, die schwer zu debuggen sind. - Protokollieren Sie jeden wichtigen Schritt - Verwenden Sie
echo "==> Schrittname..."vor jedem Abschnitt, damit der Agent den Fortschritt in der Terminalausgabe sehen kann. - Nutzen Sie Umgebungsvariablen statt fest codierter Werte - Referenzieren Sie
$REPO_URL,$CONVEX_URLusw. Diese werden aus den Projekteinstellungen und Sandbox-Umgebungsvariablen eingespielt, sodass Secrets nicht im Skriptinhalt landen. - Testen Sie Skripte zuerst lokal - Bevor Sie eine neue Skriptversion ausrollen, testen Sie sie in einer eigenständigen Sandbox, um zu prüfen, dass sie fehlerfrei läuft.
- Halten Sie Skripte idempotent - Schreiben Sie Skripte so, dass sie mehrfach ausgeführt werden können, ohne kaputt zu gehen. Verwenden Sie
-f-Flags bei destruktiven Befehlen und prüfen Sie auf vorhandenen Zustand, bevor Sie ihn neu erzeugen.
Zuweisung: Befehle und Skripte
Befehle und Skripte werden über denselben Mechanismus an Personas und Sitzungstypen zugewiesen wie Skills. Auf der Detailseite einer Persona ist der Skills-Tab in drei Bereiche unterteilt: Skills, Befehle und Skripte. Wählen Sie in jedem Bereich die gewünschten Assets aus.
Für Sitzungstyp-Standards navigieren Sie zum entsprechenden Setup-Tab in den Projekteinstellungen (z. B. /p/{id}/issues-setup) und konfigurieren Sie die Bereiche Befehle und Skripte zusammen mit den Skills.
Befehle erfordern Claude Code
.claude/commands/ zwar in der Sandbox vorhanden, werden jedoch nicht automatisch registriert. Stellen Sie sicher, dass Personas, die eigene Befehle verwenden, für Claude Code konfiguriert sind.Nächste Schritte
Skills
Lernen Sie Skills kennen - mehrdateige Wissenspakete, die in .claude/skills/ eingespielt werden.
Assets-Übersicht
Übersicht über das gesamte Asset-System, Einspielmodell und die Zuweisungshierarchie.
Persona-Konfiguration
Weisen Sie Personas im Skills-Tab Befehle und Skripte zu.
Projekteinstellungen
Konfigurieren Sie Standardwerte für Befehle und Skripte pro Sitzungstyp.