Crée des slash commands personnalisées pour automatiser les workflows et standardiser les pratiques de l'équipe.

Pour commencer, tape / dans Bob Shell pour voir toutes les commandes disponibles, ou crée les tiennes en ajoutant un fichier markdown dans .bob/commands/ ou ~/.bob/commands/.

Commandes intégrées

Bob Shell inclut les slash commands intégrées suivantes :

Commande	Alias	Description
`/help`		Afficher toutes les slash commands disponibles
`/clear`		Effacer l'écran et réinitialiser l'historique de conversation
`/condense`		Condenser intelligemment la fenêtre de contexte pour libérer de l'espace
`/copy`		Copier un élément de l'historique de conversation dans le presse-papiers
`/mode`		Changer le mode actif (ouvre un sélecteur)
`/resume`		Parcourir et reprendre une conversation précédente
`/settings`		Voir et modifier les paramètres de Bob Shell
`/mcp`		Gérer les serveurs MCP configurés
`/manage-secrets`		Gérer les secrets utilisés dans les configurations de serveurs MCP
`/skills`		Insérer une référence de skill dans le prompt
`/init`		Initialiser Bob dans l'espace de travail actuel
`/status`	`/info`	Voir le statut de la session, l'utilisation et les informations de version
`/team`		Sélectionner une équipe
`/logs`		Ouvrir le dernier fichier de log avec le visualiseur système
`/docs`		Ouvrir la documentation de Bob Shell dans ton navigateur
`/bug`		Soumettre un rapport de bug
`/exit`	`/quit`, `/close`	Quitter le CLI

Sous-commandes `/manage-secrets`

Les secrets te permettent de stocker des valeurs sensibles (comme des clés API) et de les référencer dans les configurations de serveurs MCP sans les coder en dur.

Sous-commande	Utilisation	Description
`set`	`/manage-secrets set KEY VALUE`	Stocker une valeur secrète
`list`	`/manage-secrets list`	Lister toutes les clés secrètes stockées
`rm`	`/manage-secrets rm KEY`	Supprimer un secret stocké

Les secrets sont stockés chiffrés dans ~/.bob/settings/ et peuvent être référencés dans les configurations de serveurs MCP en utilisant la syntaxe ${KEY}.

Pourquoi utiliser les slash commands ?

Les slash commands offrent plusieurs avantages clés :

Automatisation des workflows : Transforme des processus complexes en plusieurs étapes en commandes simples

Standardisation de l'équipe : Partage des commandes avec ton équipe pour des pratiques cohérentes

Préservation du contexte : Inclut du contexte spécifique au projet dans chaque commande

Accès rapide : Recherche floue et autocomplétion pour une découverte instantanée des commandes

Comment fonctionnent les slash commands

Quand tu tapes / dans Bob Shell, un menu apparaît affichant toutes les commandes disponibles. Ces commandes proviennent de deux sources :

Type de commande	Source	Objectif
Commandes de workflow personnalisées	`.bob/commands/` ou `~/.bob/commands/`	Automatisation créée par l'utilisateur pour des tâches spécifiques
Commandes de mode	Modes intégrés et personnalisés	Changer le contexte opérationnel de Bob

Créer des commandes personnalisées

Les commandes personnalisées étendent les fonctionnalités de Bob en ajoutant des fichiers markdown dans des répertoires spécifiques :

Emplacement	Portée	Chemin
Spécifique au projet	Disponible dans le projet actuel seulement	`.bob/commands/` dans ta racine d'espace de travail
Global	Disponible dans tous les projets	`~/.bob/commands/` dans ton répertoire personnel

Le nom du fichier devient le nom de la commande. Par exemple :

.bob/commands/
├── review.md         → /review
├── test-api.md       → /test-api
└── deploy-check.md   → /deploy-check

Traitement des noms de commandes

Lors de la création de commandes via l'UI, Bob Shell traite automatiquement les noms de commandes :

Convertit en minuscules

Remplace les espaces par des tirets

Supprime les caractères spéciaux

Supprime les tirets en début et fin

Exemple : "My Cool Command!" devient my-cool-command

Format de commande de base

Crée une commande simple en ajoutant un fichier markdown :

Help me review this code for security issues and suggest improvements.

Commande avancée avec frontmatter

Ajoute des métadonnées avec le frontmatter pour des fonctionnalités améliorées :

---
description: Create a new API endpoint
argument-hint: <endpoint-name> <http-method>
---
Create a new API endpoint called $1 that handles $2 requests.
Include proper error handling and documentation.

Champs du frontmatter

Champ	Objectif	Exemple
`description`	Apparaît dans le menu de commandes	"Create a new API endpoint"
`argument-hint`	Affiche les arguments attendus	"`<endpoint-name>` `<http-method>`"

Dialogue d'approbation d'outil

Quand Bob Shell demande à utiliser un outil, une boîte de dialogue d'approbation apparaît. La boîte de dialogue offre les options suivantes :

Option	Description
Approve Once	Autoriser cet appel d'outil spécifique à continuer. Tu seras à nouveau invité pour les appels futurs.
Approve `<group>` tools for task	Autoriser tous les outils du même groupe d'outils pour le reste de la tâche. Non affiché pour les outils MCP.
Always Allow Command for task	Autoriser une commande shell spécifique pour le reste de la tâche.
Reject	Refuser l'appel d'outil. Bob Shell ne continue pas avec l'action.

Tu peux aussi ajouter une note optionnelle lors de l'approbation ou du refus d'un appel d'outil. La note est incluse dans le contexte de la conversation pour que Bob Shell puisse adapter son comportement en conséquence.

Pour interrompre une réponse en cours de diffusion avant que Bob Shell ait fini, appuie sur Esc.

Gestion des commandes dans Bob Shell

Bob Shell prend en charge les mêmes slash commands que Bob IDE. Bien que Bob Shell ne fournisse pas d'UI dédiée pour gérer les commandes, tu peux :

Créer des fichiers de commandes manuellement dans le répertoire .bob/commands/ de ton projet ou ~/.bob/commands/ dans ton répertoire personnel

Modifier les fichiers de commandes existants avec n'importe quel éditeur de texte

Utiliser les slash commands

Tape / dans Bob Shell pour voir un menu unifié contenant les types de commandes suivants :

Menu unifié : Les commandes personnalisées et les commandes de changement de mode apparaissent ensemble

Autocomplétion : Commence à taper pour filtrer les commandes (p. ex., /sam affiche sample-command-name)

Recherche floue : Trouve les commandes même avec des correspondances partielles

Aperçu de description : Voir les descriptions des commandes dans le menu

Indicateurs visuels : Les commandes de mode se distinguent des commandes personnalisées par des icônes spéciales

/mode code     Switch to Code mode
/mode ask      Switch to Ask mode
/review        Review code for security issues
/api-endpoint  <endpoint-name> <http-method>

Conseils sur les arguments

Les conseils d'arguments fournissent une aide instantanée pour les slash commands, t'indiquant quel type d'information fournir quand une commande attend une saisie supplémentaire.

Quand tu tapes / pour ouvrir le menu de commandes, les commandes qui attendent des arguments affichent un conseil en gris clair à côté d'elles. Ce conseil t'indique quel type d'argument la commande attend.

Par exemple :

/mode <mode_slug> - Le conseil <mode_slug> indique que tu dois fournir un nom de mode comme code ou debug

/api-endpoint <endpoint-name> <http-method> - Indique que tu as besoin d'un nom de point de terminaison et d'une méthode HTTP

Après avoir sélectionné la commande, elle est insérée dans la saisie du chat suivie d'un espace. Le conseil n'est pas inséré ; c'est uniquement un guide visuel pour t'aider à savoir quoi taper ensuite. Tu dois ensuite taper manuellement l'argument après la commande.

Ajouter des conseils d'arguments aux commandes personnalisées

Tu peux ajouter des conseils d'arguments à tes commandes personnalisées en utilisant le champ argument-hint dans le frontmatter :

---
description: Create a new API endpoint
argument-hint: <endpoint-name> <http-method>
---
Create a new API endpoint called $1 that handles $2 requests.
Include proper error handling and documentation.

Cela s'affichera comme /api-endpoint <endpoint-name> <http-method> dans le menu de commandes.

Bonnes pratiques pour les conseils d'arguments

Sois précis : Utilise des espaces réservés descriptifs comme <file-path> plutôt que des génériques comme <arg>

Montre plusieurs arguments : Si ta commande a besoin de plusieurs entrées, montre-les toutes : <source> <destination>

Utilise un format cohérent : Entoure toujours les espaces réservés de chevrons : <placeholder>

Reste concis : Les conseils doivent être brefs et clairs

Questions courantes sur les arguments

Question	Réponse
Que se passe-t-il si je ne fournis pas l'argument ?	La commande pourrait ne pas fonctionner comme prévu, ou elle pourrait te demander plus d'informations. Le conseil est là pour t'aider à bien faire du premier coup.
Toutes les commandes ont-elles des conseils ?	Non, seules les commandes conçues pour prendre des arguments afficheront des conseils. Les commandes qui fonctionnent sans entrée supplémentaire n'afficheront pas de conseils.
Puis-je utiliser une commande sans remplacer le conseil ?	Le texte du conseil (comme `<mode_slug>`) doit être remplacé par des valeurs réelles. Laisser le texte du conseil entraînera probablement un échec de la commande ou un comportement inattendu.

Bonnes pratiques

Nommage des commandes

Utilise des noms descriptifs orientés action

Garde les noms concis mais clairs

Utilise des tirets pour les commandes composées

Évite les noms génériques comme help ou test

Note : Les noms sont automatiquement slugifiés (minuscules, caractères spéciaux supprimés)

L'extension .md est automatiquement ajoutée/supprimée selon les besoins

Contenu des commandes

Commence par une directive claire

Utilise des formats structurés (listes, sections)

Inclut des exigences spécifiques

Référence les conventions du projet

Garde les commandes focalisées sur une seule tâche

Organisation

Groupe les commandes associées dans des sous-répertoires

Utilise des modèles de nommage cohérents

Documente les commandes complexes

Mets tes commandes sous contrôle de version

Partage les commandes d'équipe dans le repository du projet

Dépannage

Commandes n'apparaissant pas

Si tes commandes n'apparaissent pas dans le menu :

Vérifie l'emplacement du fichier : Assure-toi que les fichiers de commandes personnalisées sont dans .bob/commands/ ou ~/.bob/commands/

Vérifie l'extension de fichier : Les commandes personnalisées doivent être des fichiers .md

Commande introuvable

Quand une slash command n'est pas trouvée, le LLM verra :

The slash command '/unknown-command' was not found. Please check the command name and try again.

Conflits de commandes

Les commandes personnalisées du projet remplacent les commandes personnalisées globales du même nom

Utilise des noms uniques pour éviter les conflits

Lors de la création de noms dupliqués via l'UI, des numéros sont ajoutés (p. ex., new-command-1, new-command-2)

À propos des commandes de mode

Le menu slash inclut des commandes de changement de mode (comme /mode code, /mode ask) qui changent fondamentalement le mode opérationnel de l'IA — elles n'injectent pas seulement du texte mais changent tout le contexte de l'IA. Les modes personnalisés que tu crées apparaissent également comme slash commands (p. ex., un mode avec le slug reviewer devient /reviewer). Ces commandes de mode ne peuvent pas être remplacées par des commandes de workflow personnalisées.

Compatibilité multiplateforme

Les slash commands fonctionnent de manière identique dans Bob Shell et Bob IDE. Cela signifie que :

Les commandes créées dans un environnement peuvent être utilisées dans l'autre

La même syntaxe et le même comportement de commande s'appliquent dans les deux environnements

Les commandes partagées en équipe fonctionnent de manière cohérente quel que soit l'interface utilisée par les membres de l'équipe

Slash commands