Context Blocks
How context blocks auto-expand into XML structures that give agents awareness of roles, pipelines, documents, skills, modes, and memory.
Context blocks are template variables that expand into structured XML. Unlike scalar variables (which insert a simple string), context blocks inject rich, multi-line XML structures built at runtime from the platform's current state.
How Context Blocks Work
Context blocks are computed eagerly -- the XML is always built before template rendering. However, the XML is only injected into the prompt where the template author placed the corresponding {{ context.* }} variable. If a variable is not referenced in any template, the computed XML is discarded.
The one exception is {{ context.modes }}: when a mode session is active, the mode context XML is auto-appended to the developer prompt regardless of whether the variable appears in a template.
context.roles
Expands into a listing of all available roles with their descriptions, assigned agents, and model information.
Variable: {{ context.roles }}
Output:
<available_roles>
<role id="uuid-1" name="developer" description="Writes and maintains code" agent="dev-agent" model="claude-sonnet-4-20250514" />
<role id="uuid-2" name="reviewer" description="Reviews code for quality" agent="review-agent" model="gpt-4o" />
<role id="uuid-3" name="architect" description="Designs system architecture" />
</available_roles>Roles without a description are excluded. The agent and model attributes are only included when the role has an assigned agent. This block is useful for roles that need to be aware of the team composition, for example when deciding which agent to delegate work to.
context.pipelines
Expands into a listing of active pipelines.
Variable: {{ context.pipelines }}
Output:
<available_pipelines>
<pipeline name="Default" id="uuid-1" description="Standard development workflow" />
<pipeline name="Review" id="uuid-2" description="Code review pipeline" />
</available_pipelines>Only active pipelines (is_active = true) are included. This gives agents awareness of available workflows for routing and orchestration decisions.
context.documents
Expands into a listing of project documents synced to the workspace.
Variable: {{ context.documents }}
Output:
<project_documents path="project-uuid">
<doc name="architecture.md" size="12.5 KB" />
<doc name="api-spec.yaml" size="45.2 KB" />
<doc name="requirements.pdf" size="1.2 MB" />
</project_documents>The listing is built from the document manifest on disk. It includes file names and human-readable sizes but not file contents. Agents can use this listing to decide which documents to read with their file tools.
Returns empty if no documents are synced for the project.
context.skills
Expands into skill-specific instructions, guidelines, and cached reference documentation.
Variable: {{ context.skills }}
Output:
<skill_context>
<!-- You ONLY have access to these 2 skill(s): github, linear. Other skills returned by query tools (e.g. nenjo_list_skills) belong to other roles -- do not claim access to them. -->
<skill name="github">
<instructions>Use the GitHub API for all repository operations...</instructions>
<guidelines>
- Always create feature branches from main
- Use conventional commit messages
</guidelines>
<reference url="https://docs.github.com/api">API reference content...</reference>
</skill>
<skill name="linear">
<instructions>Use Linear for issue tracking...</instructions>
</skill>
</skill_context>Only skills that have at least one of instructions, guidelines, or cached reference docs are included. Tool schemas from skills are not listed here -- they are registered as tools and discovered by the LLM through the standard tool-use interface.
The access boundary comment at the top prevents agents from claiming access to tools from skills assigned to other roles.
context.modes
Expands into the active mode session context. Unlike other context blocks, this is auto-appended to the developer prompt when a mode session is active.
Variable: {{ context.modes }}
Output:
<mode_context name="prd" session_id="uuid" turn="3/50">
<guidelines>
- Focus on user requirements, not implementation details
- Ask clarifying questions before proceeding
- Structure the PRD with sections: Overview, Goals, Requirements, Success Metrics
</guidelines>
<artifact_schema format="markdown">{"type":"object",...}</artifact_schema>
<exit_commands>/exit, /done, /finish</exit_commands>
</mode_context>The mode context includes:
- Session metadata: Mode name, session ID, current turn number out of max turns
- Guidelines: Behavioral rules specific to this mode
- Artifact schema: Expected output format (if the mode produces artifacts)
- Exit commands: Commands that end the mode session
If the mode has an in-progress artifact draft, it is also appended:
<mode_artifact_draft>
{
"title": "Feature Requirements",
"sections": [...]
}
</mode_artifact_draft>The mode's system_addon prompt is handled separately -- it is appended to the developer prompt text before template rendering, not included in the XML block.
context.memory
Expands into relevant memories retrieved from the agent's memory store.
Variable: {{ context.memory }}
Output: The exact format depends on the memory manager implementation. Memories are retrieved based on the current task context, filtered by the role's memory_profile.priority_categories, and truncated to fit within max_injection_tokens.
This block is empty when:
- No memory manager is configured for the agent
- No relevant memories exist
- Memory retrieval fails (fails silently with an empty string)
Usage Patterns
Minimal Template
A simple chat_task template that only needs the user message and memories:
{{ context.memory }}
{{ chat.message }}Full Context Template
A ticket_task template that gives the agent full platform awareness:
## Task
{{ ticket.title }}: {{ ticket.description }}
## Platform Context
{{ context.roles }}
{{ context.pipelines }}
{{ context.documents }}
## Relevant Knowledge
{{ context.memory }}
## Skills
{{ context.skills }}Selective Injection
You control what context the agent receives by choosing which variables to include. An agent that should only focus on its task without awareness of other roles:
{{ ticket.title }}: {{ ticket.description }}
{{ context.documents }}No {{ context.roles }} or {{ context.pipelines }} means the agent has no knowledge of the broader team structure.