LEVEL11

Docs

Rules and MCP

The four rule layers (global settings, ~/.level11/system.md, AGENT.md, .level11/rules.md), agent presets with their own system prompts, and MCP servers.

The four rule layers

The agent's system prompt is built from LEVEL11's base instructions, environment facts (workspace path, OS, shell, date) and the work-mode text, with your rules layered on top. The Rules tool shows and edits all four layers on one screen.

Layer Where Scope
Global rules User rules in Settings every workspace
System prompt additions ~/.level11/system.md every workspace on this computer
AGENT.md <workspace>/AGENT.md this project; instructions for coding agents in general (the AGENTS.md convention)
Project rules <workspace>/.level11/rules.md this project, LEVEL11-specific

From top to bottom the scope narrows and becomes more specific. Each layer goes into the prompt under its own heading, in the order ~/.level11/system.md, AGENT.md, .level11/rules.md, then the global rules, so the rules closest to a project act most specifically within it. Write conventions, forbidden commands and preferred tooling in free form. Rule files live only on your machine; they are never uploaded.

An example .level11/rules.md:

- Use pnpm only. Never run npm install.
- Commit messages in English, subject under 50 characters.
- Read but never modify anything under src/legacy/.

Agent presets

The Agents tool is where you create agents for different jobs. Each preset has a name, a system prompt, a model override (or "use the session model") and a default mode (or "keep the session mode"). The preset's system prompt is appended after the rule layers as an # Agent: <name> section. Pick a preset per session from the composer and switch when the job changes.

Five presets are built in:

  • Planner: investigates the codebase before any edit and writes a numbered implementation plan with todo_write (files to touch, risks, how the result will be verified).
  • Code Reviewer: reads changes and reviews them.
  • Test Writer: writes tests.
  • Docs Writer: writes documentation.
  • 커머스 빌더 (Commerce Builder): follows the official SDKs and REST conventions of Toss Payments, NICEPAY, PayPle, Cafe24, NHN Cloud, NAVER Cloud and Megazone, never hard-codes secret keys and reads them from the environment variables injected by Integrations. Answers in Korean.

A model override of local makes only that preset use a local model.

MCP servers

Model Context Protocol servers run as local processes (stdio), and the tools they expose become the agent's tools. The configuration file is ~/.level11/mcp.json:

{
  "mcpServers": {
    "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/dir"] },
    "disabled-example": { "command": "my-server", "disabled": true }
  }
}

The MCP tool adds servers, enables or disables them and refreshes their connection state. Presets for filesystem (files outside the workspace), github (issues, PRs, repositories), playwright (browser automation) and postgres (database queries) can be added in one step. The status bar shows "MCP: connected/total".

MCP tool calls ask for approval in Builder mode, run without asking in Auto-Run, and are not attached in Chat mode. Plugins and OAuth connectors are in preparation.