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 --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)execute: Execute terminal commands (commandis accepted as a legacy alias)browser: Fetch public web pages (experimental; requiresexperiments.webFetch)mcp: Access MCP serversskill: Activate skillstodo: Update the todo listsubagent: Spawn subagentsmode: Switch modes
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/settings/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
- execute
- 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
- executeCommand-line mode selection
Specify a mode when starting Bob Shell:
# Start Bob Shell in a specific mode
bob --mode shell-debug
# Combine with other options
bob --mode deploy-helper --max-turns 20Interactive mode switching
In interactive mode, type /mode to open the mode picker, then select your custom mode. Custom modes appear in the picker alongside the built-in Agent, Plan, and Ask modes.
Shell-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 execute 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
- executeCommand running permissions
Restricting command access
Control whether a mode can run commands by omitting the execute 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 execute or edit groups - read-only modeAllowing specific commands
To auto-approve specific commands, add "execute" to approval.allowed_permissions and list the commands in approval.allowedExecutors for the execute_command tool in ~/.bob/settings/settings.json:
{
"approval": {
"allowed_permissions": ["read", "execute"],
"allowedExecutors": [
{
"toolId": "execute_command",
"approvedCommands": ["git status", "git log", "git diff"],
"deniedCommands": []
}
]
}
}Setting allowedExecutors replaces the default list of approved commands, so include any defaults you want to keep. For details, see Approval settings.
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
- executeNon-interactive usage
Use modes in non-interactive mode:
# Use a mode designed for automation
bob run --mode test-runner "Run the test suite and report failures"
# Combine with output processing
bob run --mode test-runner --format json "Run tests" > results.jsonMode-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 existConfiguration precedence
If two modes share a slug, Bob Shell uses the first one it finds, in this order:
- Built-in modes (
agent,plan,ask) - User-level modes (
~/.bob/settings/custom_modes.yaml) - Project-level modes (
.bob/custom_modes.yaml)
Use a unique slug for each custom mode. The --mode flag only selects which mode to start in.
Migrating 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 | Mode selector dropdown | /mode picker or --mode CLI flag |
| 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
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
- execute # Added for git operations
- browser