- A system prompt (the agent’s instructions)
- Whether the agent can edit files (
can_edit: true/false) - The output mode (code changes on a branch, or a markdown artifact)
Role Config Structure
Roles are defined in TOML files:Fields
| Field | Type | Description |
|---|---|---|
name | String | Unique identifier (e.g., "researcher", "bug_fixer") |
label | String | Human-readable name (e.g., "Researcher") |
description | String | Short summary of the role’s purpose |
system_prompt | String | Full instructions sent to the agent |
can_edit | Boolean | Whether the agent can modify project files (default: true) |
output | String | "branch" (code changes) or "artifact" (markdown file, no merge) |
Output Modes
Roles have one of two output modes:OutputMode::Branch
The agent produces code changes on a git branch. When the worker finishes:- Changes are committed to
task/<id> - The refinery merges the branch into the default branch
- Dependent steps receive the merged code
OutputMode::Artifact
The agent produces a markdown artifact (no code changes). When the worker finishes:- Output is saved to
.enki/artifacts/<execution_id>/<step_id>.md - No merge occurs (worker skips the refinery)
- Dependent steps receive the artifact content as
upstream_outputs
Artifact agents can’t edit files: Roles with
output = "artifact" automatically have can_edit = false. Trying to edit files will fail.Role Cascade: Builtin → Global → Project
Roles load in three layers:- Builtin roles (shipped with Enki)
- Global overrides (
~/.enki/roles/*.toml) - Project overrides (
<project>/.enki/roles/*.toml)
~/.enki/roles/researcher.toml, it replaces the builtin researcher role.
Builtin Roles
Enki ships with five builtin roles:feature_developer
Implements new features. Four-phase workflow: Explore, Design, Implement, Self-Review. Output: branch.
ralph
Iterative verify-fix loop worker. Grinds through test failures until verification passes. Output: branch.
bug_fixer
Diagnoses root causes, writes surgical fixes and regression tests. Output: branch.
researcher
Read-only investigation agent. Explores code, traces paths, reports findings. Output: artifact.
code_referencer
Fetches external code from GitHub repos and docs. Read-only, cleans up after itself. Output: artifact.
feature_developer
Output:branch | Can edit: true
A general-purpose coding agent. Follows a structured four-phase workflow:
- Explore: Study existing code, find similar features, read docs
- Design: Choose an approach, commit to it
- Implement: Write production code, tests, handle errors
- Self-Review: Re-read changes, check for bugs, simplify
ralph
Output:branch | Can edit: true
An iterative worker for tasks with clear programmatic success criteria (tests, builds, linters). Runs in a tight loop:
- Verify: Run the check (tests, build, lint)
- Assess: Read the output, identify the first failure
- Fix: Make a minimal change to fix that failure
- Repeat: Go back to step 1 until everything passes
bug_fixer
Output:branch | Can edit: true
Specialized for debugging. Focuses on:
- Understanding the bug (reproduce mentally)
- Finding the root cause (not just symptoms)
- Writing a minimal surgical fix
- Adding a regression test
researcher
Output:artifact | Can edit: false
A read-only investigation agent. Reports findings in structured markdown:
- Reads files, traces execution paths
- Searches for patterns, APIs, implementations
- Includes file paths, line numbers, code snippets
- Saves output to
.enki/artifacts/<exec>/<step>.md
code_referencer
Output:artifact | Can edit: false
Fetches external code and docs from GitHub and the web. Reports relevant patterns, APIs, and snippets:
- Uses
git clone --depth 1for shallow checkouts - Cleans up cloned repos when done
- Cites sources (repo URLs, file paths)
- Saves findings to
.enki/artifacts/<exec>/<step>.md
Assigning Roles to Steps
When creating an execution, you can assign a role to any step:Creating Custom Roles
Example: A Custom “documenter” Role
Create.enki/roles/documenter.toml:
role: Some("documenter") to a step:
Example: A Custom “security_reviewer” Artifact Role
Create~/.enki/roles/security_reviewer.toml:
.enki/artifacts/<exec>/security_review.md. The execution pauses (checkpoint) for you to review before continuing.
Role Resolution
When a step specifiesrole: Some("ralph"), Enki:
- Looks up
"ralph"in the final role map (after cascade) - Retrieves the
RoleConfig - Sends the
system_promptto the ACP agent - Enforces
can_edit(file edit tools are hidden iffalse) - Enforces
outputmode (branch vs artifact)
Role not found? If a step references a role that doesn’t exist, Enki falls back to the default system prompt (general coding agent).
MCP Tool Access by Role
Enki filters MCP tools based on role:- Planner role (coordinator): Full tool access (
PLANNER_TOOLS) - Worker roles with
can_edit = true: Standard worker tools (WORKER_TOOLS) - Worker roles with
can_edit = false: Read-only worker tools (WORKER_TOOLS_NO_EDIT) - Merger role (conflict resolution): Minimal merge tools (
MERGER_TOOLS)
enki_execution_create.
Best Practices
Keep system prompts focused: A good role prompt defines how to work, not what to build. The task description provides the “what”. The role provides the “how”.
Next Steps
Merge Queue
Learn how branch output is merged
DAG Execution
Understand task dependencies and scheduling
