Modes

8 built-in modes with tool guardrails — switch with /mode <name> or let kbcode auto-pick the right one.

code full access

The default mode. Full read, write, edit, and command execution. kbcode starts here and auto-switches into lighter modes when the task fits (asking a question, planning, debugging). Use this for any hands-on coding work.

Tools: all tools — read, write, edit, run, browser, notes, worklog
When: writing code, fixing bugs, refactoring, building features
Switch: /mode code or auto-selected on task detection

architect plan only

High-level design & planning. Reads the codebase and proposes architecture, but cannot edit or run anything. Perfect for planning a feature before implementing it. When auto_handoff is on, the plan seamlessly hands off to code mode for implementation.

Tools: read-only — no write_file, edit_file, or run_command
When: designing architecture, planning large changes, "how should I build X?"
Switch: /mode architect

ask read only

Read-only Q&A. Can read files, search the codebase, and answer questions — but never edits or runs commands. Safe for exploration and learning without risk of accidental changes.

Tools: read_file, search_code, repo_map, kb_read, web_search, fetch_url
When: "what does this function do?", "find all places that use X", "explain this code"
Switch: /mode ask

debug full access

Triage & systematic failure analysis. Reproduces the bug, isolates the root cause, then applies the smallest fix. Never guesses — reads code, runs diagnostics, and states the cause plainly before patching.

Tools: all tools — full access so it can reproduce and fix
When: "this is broken", crash reports, test failures, unexpected behaviour
Switch: /mode debug

driven requirements first

Gathers requirements before building. When a new goal or feature needs clarification, driven mode asks the right questions first — scope, constraints, preferences — then hands off to code mode once everything is clear. Never builds on assumptions.

Tools: read + switch_mode — asks, clarifies, then switches to code
When: new feature requests, ambiguous goals, "I want to add X but I'm not sure how"
Switch: /mode driven

pilot autonomous

Self-prompting autonomous mode. Plans todos with manage_todos and drives itself to completion — no waiting for user input between steps. Capped at 25 self-prompts per turn to prevent runaway loops.

Tools: all tools — plans, edits, runs, and verifies autonomously
When: "build this entire feature end-to-end", multi-step autonomous tasks
Switch: /mode pilot

orchestrator delegation

Decompose & delegate. Breaks a large job into independent pieces, delegates each to a specialist subagent (autopilot, code-explorer, fixer), and stitches the results into one report. Subagents run concurrently for speed.

Tools: read + run_subagent + manage_todos — no direct write/edit/run
When: large multi-file changes, "audit the whole codebase for X", cross-cutting work
Switch: /mode orchestrator

agi coordinator

Autonomous multi-phase execution. Breaks complex work into independent phases, verifies each result as it completes, and stitches everything together — no context pollution between phases. Ideal for large tasks that benefit from a clean slate at each step.

Tools: read + run_command + check_task + wait_for_task
When: independent verification, multi-phase work, cross-cutting changes
Switch: /mode agi

custom your rules

Create your own mode. Write a .kbcode/modes/<name>.md file with your own instructions and tool permissions. Pin a model to it so switching modes also switches the AI. kbcode hot-loads it — no restart needed.

Tools: you decide — pick from read, edit, exec, browser, notes, mistakes, worklog
When: team-specific workflows, restricted environments, "only HTML/CSS, never touch backend"
Create: /mode <name> in chat, or write the .md file directly