System Role

What is the system role?

The system role is a special built-in agent role that acts as the platform's guide. Unlike other roles (manager, architect, dev, devops), the system role is not designed to write code or execute pipelines. Its purpose is to help users understand, configure, and optimize their Nenjo setup.

Every user gets their own editable copy of the system role, seeded from the system template at account creation. This means you can customize the system role's prompts while still receiving upstream improvements when new template versions are released.

Embedded platform knowledge

The system role's system_prompt contains a comprehensive reference to the entire Nenjo resource model, injected as structured XML blocks. This gives the system assistant deep knowledge of:

• Resource types -- Projects, roles, agents, pipelines (DAG steps and edges), councils, skills, modes, tickets, and executions, including their relationships and lifecycles.
• Prompt template system -- All available template variables ({{ ticket.title }}, {{ context.roles }}, {{ git.branch }}, etc.) and how they are expanded at runtime by the worker.
• Worker tools -- The full set of built-in tools (shell, file_read, file_write, file_edit, web_search, web_fetch, git_operations, delegation) and how mode allow/deny lists control them.
• Context blocks -- How {{ context.roles }}, {{ context.pipelines }}, {{ context.documents }}, {{ context.skills }}, {{ context.modes }}, and {{ context.memory }} are auto-expanded from project and role data.

The system prompt also includes live context blocks so the assistant can reference the user's actual configuration:

{{ context.roles }}
{{ context.pipelines }}
{{ context.skills }}
{{ context.modes }}
{{ context.memory }}

Developer prompt

The developer_prompt provides behavioral guidelines for the system assistant:

• Query before recommending -- Always use NenjoRead tools to inspect the current state of resources rather than guessing configurations.
• Reference actual resources -- When discussing a user's setup, cite resources by name and ID.
• Concrete examples -- Instead of generic advice, provide specific, actionable instructions (e.g., "add a gate step after the dev step that checks for test coverage").
• Pipeline DAG descriptions -- Describe flows as step A -> step B -> step C, including edge conditions.
• Mode escalation -- If the user asks to create or modify resources, suggest entering /the-creator mode for write access.

Memory profile

The system role defines a memory_profile that guides the brain LLM on what to extract and remember from interactions:

Core focus areas

• Preferred model providers and model names for different role types
• Prompt engineering patterns (template structures, variable usage, instruction styles)
• Common pipeline DAG patterns (step sequences, gate criteria, council strategies)
• Platform conventions (naming schemes, tag taxonomies, role specializations)
• Recurring troubleshooting patterns and resolutions
• Skill and mode configurations

Project focus areas

• Pipeline assignments and their rationale
• Role-agent mappings and why they were chosen
• Template customizations specific to the project
• Ticket structuring patterns (tag conventions, complexity norms)
• Repository and git workflow preferences

Priority categories

pipeline_design, role_configuration, prompt_engineering, platform_setup, troubleshooting, workflow_preferences

The /the-creator mode

The system role ships with a single mode: /the-creator. This is an authoring-type mode that grants the system assistant full write access to platform resources.

How it works

By default, the system role only has read access to the platform (via MCP platform tools filtered by platform_scopes). When a user activates /the-creator, the mode's tool configuration kicks in:

• Deny list -- shell, file_write, file_edit, git_operations are blocked. The creator mode is for platform resources, not code.
• Scope escalation -- The mode's additional_scopes (or legacy additional field) grants nenjo-write access, giving the assistant tools to create, update, and delete any platform resource.

Behavioral contract

The mode injects a system_addon prompt that establishes ground rules:

1. Always explain what you are about to do before doing it.
2. For pipeline DAGs, describe steps and edge connections before creating them.
3. Confirm destructive operations (deletes) with the user.
4. Report created resource IDs so the user can verify in the dashboard.
5. Follow the recommended creation order: project -> roles -> agents -> pipeline -> assignments.

Session management

• Max turns: 100
• Exit commands: /done, /exit, /finish
• Entry and exit messages confirm mode activation and summarize what was changed.

See MCP for details on platform scopes and how MCP tools are filtered per role.