Custom modes
You can create custom modes to tailor Bob's behavior to specific tasks or workflows. Custom modes in Bob Shell work similarly to Bob IDE modes.
Why use custom modes in Bob Shell
- Shell-optimized workflows: Create modes designed specifically for terminal-based development tasks
- Command-line safety: Restrict modes to safe operations when working in production environments
- Environment-specific behavior: Configure modes that adapt to different shell environments
- Automation-friendly: Design modes that work seamlessly in both interactive and non-interactive sessions
- Team standardization: Share shell-specific modes across your team for consistent workflows
What's included in a custom mode
Custom modes in Bob Shell use the same core structure as Bob IDE modes:
| Property | Description | Shell-Specific Considerations |
|---|---|---|
slug | Unique internal identifier | Used in command-line arguments:bob --chat-mode=my-mode |
name | Display name in the UI | Shown in interactive mode's mode selector |
description | Short description shown in the mode selector | Briefly explain your mode's purpose |
roleDefinition | Core identity and expertise | Should consider shell context and command-line workflows |
groups | Allowed toolsets and file access | Command running permissions are critical in shell environments |
whenToUse | Mode selection guidance | Helps Bob Shell choose appropriate modes for tasks |
customInstructions | Specific behavioral guidelines, or rules for the mode | Can reference Bob Shell development patterns |
Available tools
Available tool groups
read: Read files and directoriesedit: Modify files (can be restricted withfileRegex)browser: Use browser automationcommand: Execute terminal commandsmcp: Access MCP servers
Creating custom modes
Configuration files
Bob Shell uses the same configuration format as Bob IDE, supporting both YAML (preferred) and JSON formats.
Global modes
Create or edit ~/.bob/custom_modes.yaml for modes available across all projects:
customModes:
- slug: shell-debug
name: 🐛 Shell Debugger
roleDefinition: >-
You are a debugging specialist focused on command-line troubleshooting.
You excel at analyzing shell output, environment variables, and system logs.
whenToUse: Use for debugging shell scripts, command failures, and environment issues.
customInstructions: |-
When debugging:
- Always check environment variables first
- Examine command exit codes
- Review relevant log files
- Test commands in isolation before suggesting fixes
groups:
- read
- command
- browserProject-specific modes
Create or edit .bob/custom_modes.yaml in your project root:
customModes:
- slug: deploy-helper
name: 🚀 Deployment Assistant
roleDefinition: You are a deployment specialist for this project's infrastructure.
whenToUse: Use for deployment tasks, infrastructure changes, and release management.
customInstructions: |-
Deployment guidelines:
- Always verify the target environment before running commands
- Check for running processes that might be affected
- Validate configuration files before applying changes
- Create backups before destructive operations
groups:
- read
- - edit
- fileRegex: \.(yaml|yml|sh|env)$
description: Configuration and script files only
- commandCommand-line mode selection
Specify a mode when starting Bob Shell:
# Start Bob Shell in a specific mode
bob --chat-mode=shell-debug
# Combine with other options
bob --chat-mode=deploy-helper --sandboxInteractive mode switching
In interactive mode, switch modes using slash commands:
# Switch to a custom mode
/mode shell-debug
# Or use the mode's slug directly
/shell-debugShell-specific configurations
Production safety mode
Create a safety-focused mode for production environments:
customModes:
- slug: prod-ops
name: 🔒 Production Operations
roleDefinition: >-
You are a production operations specialist with a strong focus on safety.
You never run destructive commands without explicit confirmation.
whenToUse: Use when working with production systems or sensitive environments.
customInstructions: |-
Production safety rules:
- NEVER run destructive commands without explicit user confirmation
- Always verify the target environment before any operation
- Suggest dry-run options when available
- Check for active connections or processes before changes
- Recommend backup procedures before modifications
groups:
- read
- browser
# Note: No edit or command groups for maximum safetyScript development mode
Create a mode for shell script development:
customModes:
- slug: script-dev
name: 📜 Script Developer
roleDefinition: >-
You are a shell scripting expert specializing in bash, zsh, and POSIX-compliant scripts.
whenToUse: Use for creating, debugging, or improving shell scripts.
customInstructions: |-
Shell scripting best practices:
- Use shellcheck-compliant syntax
- Include proper error handling with set -e and set -u
- Add usage documentation at the top of scripts
- Quote variables to prevent word splitting
- Provide exit codes for different error conditions
groups:
- read
- - edit
- fileRegex: \.(sh|bash|zsh)$
description: Shell script files only
- commandCommand running permissions
Restricting command access
Control which commands a mode can run by omitting the command group:
customModes:
- slug: safe-reviewer
name: 👀 Safe Code Reviewer
roleDefinition: You are a code reviewer focused on analysis, not modification.
whenToUse: Use for code reviews and analysis without making changes.
groups:
- read
- browser
# No command or edit groups - read-only modeAllowing specific commands
Use Bob Shell's allowed tools configuration with custom modes in your settings file:
{
"tools": {
"allowed": [
"run_shell_command(git status)",
"run_shell_command(git log)",
"run_shell_command(git diff)"
]
}
}Interactive vs non-interactive behavior
Designing for both modes
Create modes that work well in both interactive and non-interactive sessions:
customModes:
- slug: test-runner
name: 🧪 Test Runner
roleDefinition: >-
You are a testing specialist who runs and analyzes test suites.
You adapt your output based on the running context.
whenToUse: Use for running tests, analyzing test results, and debugging test failures.
customInstructions: |-
Testing guidelines:
- In interactive mode: Provide detailed explanations and suggestions
- In non-interactive mode: Focus on concise, actionable output
- Always report test results clearly
- Suggest fixes for failing tests
groups:
- read
- commandNon-interactive usage
Use modes in non-interactive mode:
# Use a mode designed for automation
bob --chat-mode=test-runner -p "Run the test suite and report failures"
# Combine with output processing
bob --chat-mode=test-runner -p "Run tests" --hide-intermediary-output > results.txtMode-specific instructions via files
Directory-based instructions
Create mode-specific instruction files in .bob/rules-{mode-slug}/:
Example instruction file (.bob/rules-shell-debug/01-environment-checks.md):
# Environment Debugging Checklist
When debugging shell issues, always check:
1. **Environment Variables**: PATH, SHELL, TERM, and application-specific variables
2. **Shell Configuration**: .bashrc, .zshrc, .profile files
3. **System State**: Current working directory, file permissions, disk space
4. **Command Availability**: Use `command -v <cmd>` to verify commands existSingle file instructions (fallback)
Alternatively, use a single file .bobrules-{mode-slug} in your workspace root.
Configuration precedence
Mode configurations are applied in this order:
- Command-line arguments (
--chat-mode=mode-slug) - Project-level modes (
.bob/custom_modes.yaml - User-level modes (
~/.bob/custom_modes.yaml) - System-level modes (platform-specific locations)
- Default modes
Sandboxing with custom modes
Combine custom modes with Bob Shell's sandbox feature for safe experimentation:
# Start a custom mode in sandbox
bob --chat-mode=script-dev --sandbox
# Use with Docker sandbox
bob --chat-mode=deploy-helper --sandboxMigrating modes from Bob IDE
Key differences
When migrating custom modes from Bob IDE to Bob Shell:
| Aspect | Bob IDE | Bob Shell |
|---|---|---|
| UI interaction | Visual interface with panels | Terminal-based interface |
| File editing | In-editor diffs and previews | CLI diff view or external editor |
| Command running | Integrated terminal | Direct shell running |
| Mode switching | UI dropdown or slash commands | Slash commands or CLI arguments |
| Configuration | Settings UI + files | Configuration files only |
Adaptation checklist
When adapting Bob IDE modes for Bob Shell:
- Review
roleDefinitionfor shell-specific context - Update
customInstructionsto reference command-line workflows - Consider command running safety in
groupsconfiguration - Test mode in both interactive and non-interactive sessions
- Verify file path handling works in shell context
- Test with sandbox mode if applicable
Example migration
Original Bob IDE mode:
customModes:
- slug: code-reviewer
name: 👀 Code Reviewer
roleDefinition: You are a code reviewer who provides detailed feedback.
groups:
- read
- browserAdapted for Bob Shell:
customModes:
- slug: code-reviewer
name: 👀 Code Reviewer
roleDefinition: >-
You are a code reviewer who provides detailed feedback.
You work efficiently in terminal environments and provide clear, actionable suggestions.
whenToUse: Use for code reviews, pull request analysis, and code quality checks.
customInstructions: |-
Code review guidelines:
- Provide feedback in a structured format suitable for terminal output
- Reference specific line numbers and file paths
- Suggest concrete improvements with examples
- Format output for easy parsing if used in non-interactive mode
groups:
- read
- command # Added for git operations
- browserCustom rules
Custom rules influence how Bob Shell responds to your requests in the terminal environment, aligning output with your specific preferences and project requirements. You can control coding style, documentation approach, and decision-making processes.
Integrating with Bob IDE
Connect Bob Shell directly to your code editor for a seamless development experience. This integration enhances Bob Shell's capabilities by providing real-time workspace awareness and enabling powerful features like in-editor diff viewing.