> ## Documentation Index
> Fetch the complete documentation index at: https://docs.actionllama.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Runtime Context

> What your agent sees when it runs — the full prompt structure assembled at runtime

When your agent runs, Action Llama assembles a prompt from several sources and passes it to the LLM as a single user message. Your `SKILL.md` body becomes the system prompt; everything below is the **user prompt** your agent receives alongside it.

Understanding this structure helps you write better `SKILL.md` instructions — you can reference the injected blocks by name, avoid duplicating information that's already provided, and tailor your instructions to complement the runtime context.

## Prompt Structure

Here's the full user prompt for a webhook-triggered agent with a GitHub token credential:

```xml theme={null}
<agent-config>
{"repo":"acme/widgets","labels":["bug","triage"]}
</agent-config>

<credential-context>
Credential files are mounted at `/credentials/` (read-only).

Environment variables already set from credentials:
- `GITHUB_TOKEN` / `GH_TOKEN` — use `gh` CLI and `git` directly

Use standard tools directly: `gh` CLI, `git`, `curl`.

Git clone protocol: Always clone repos via SSH...

Anti-exfiltration policy:
[security instructions omitted]
</credential-context>

<environment>
Filesystem: The root filesystem is read-only. `/tmp` is the only writable directory.
Use `/tmp` for cloning repos, writing scratch files, and any other disk I/O.
Your working directory is `/app/static` which contains your agent files.
</environment>

<webhook-trigger>
{"source":"github","event":"issues","action":"opened","repo":"acme/widgets",
 "number":42,"title":"Login button broken on Safari","body":"Steps to reproduce...",
 "url":"https://github.com/acme/widgets/issues/42","author":"jdoe",
 "labels":["bug"],"sender":"jdoe","timestamp":"2026-03-24T14:30:00Z",
 "receiptId":"wh_abc123"}
</webhook-trigger>

A webhook event just fired. Review the trigger context above and take appropriate action.
```

Let's walk through each section.

## Agent Config

```xml theme={null}
<agent-config>
{"repo":"acme/widgets","labels":["bug","triage"]}
</agent-config>
```

This is the JSON serialization of the `params` field from your agent's `config.toml`. Use it to pass configuration values that your agent's instructions can reference — repo names, label filters, thresholds, or any structured data your agent needs.

Your `SKILL.md` instructions can reference this directly, e.g.: *"Read the repo and labels from `<agent-config>` to determine which issues to process."*

See [Agent Config Reference](/reference/agent-config#params) for details on the `params` field.

## Credential Context

```xml theme={null}
<credential-context>
Credential files are mounted at `/credentials/` (read-only).

Environment variables already set from credentials:
- `GITHUB_TOKEN` / `GH_TOKEN` — use `gh` CLI and `git` directly

Use standard tools directly: `gh` CLI, `git`, `curl`.
...
</credential-context>
```

This block tells the agent which credentials are available and how to use them. Each credential type defines its own context line — for example, a GitHub token credential explains that `GITHUB_TOKEN` is set and the `gh` CLI is ready to use.

The block also includes SSH clone instructions and a **security policy** that instructs the agent never to leak credentials in logs, comments, or API calls.

You don't need to repeat any of this in your `SKILL.md`. The agent already knows it can use `gh` and `git` — your instructions just need to say *what* to do, not *how* to authenticate.

See [Credentials Reference](/reference/credentials) for all credential types and their injected context.

## Environment

```xml theme={null}
<environment>
Filesystem: The root filesystem is read-only. `/tmp` is the only writable directory.
...
</environment>
```

Describes the filesystem constraints. In Docker mode, the agent learns that `/tmp` is writable and the root filesystem is read-only. In [host-user mode](/reference/agent-config#runtime), the agent's working directory is its CWD.

See [Container Filesystem](/concepts/agents#container-filesystem) for the full mount table.

## Trigger Context

The final section varies by how the agent was triggered. This is the only part of the prompt that changes between runs.

### Webhook

```xml theme={null}
<webhook-trigger>
{"source":"github","event":"issues","action":"opened","repo":"acme/widgets",...}
</webhook-trigger>

A webhook event just fired. Review the trigger context above and take appropriate action.
```

Contains the full webhook payload as JSON — source, event type, action, repo, issue/PR details, sender, timestamp, and a receipt ID for replay. Your `SKILL.md` instructions should describe how to handle the events your agent subscribes to.

See [Webhooks Reference](/reference/webhooks) for the full payload schema.

### Scheduled

```
You are running on a schedule. Check for new work and act on anything you find.
```

No structured data — the agent is expected to go find work on its own (poll for open issues, check a queue, etc.).

### Manual

```
You have been triggered manually. Check for new work and act on anything you find.
```

Same as scheduled. If you pass a prompt to `al run`, the agent instead receives:

```xml theme={null}
<user-prompt>
Your prompt text here
</user-prompt>

You have been given a specific task. Complete the task described above.
```

### Agent Call

```xml theme={null}
<agent-call>
{"caller":"orchestrator","context":"Find competitors for Acme in the CRM space"}
</agent-call>

You were called by the "orchestrator" agent. Review the call context above,
do the requested work, and use the `return_value` tool to send back your result.
```

Contains the calling agent's name and the context string it passed. See the [Subagents Guide](/guides/subagents) for details on agent-to-agent calls.

## Skills

If your agent enables [skills](/reference/agent-config#skills) like `lock` or `subagent`, additional guideline blocks are injected between the `<environment>` block and the trigger context. These teach the agent behavioral rules for using the scheduler tools — `acquire_lock`/`release_lock` for [resource locks](/concepts/resource-locks), or `call_agent`/`check_call` for [subagent calls](/guides/subagents).

Skill blocks only appear when explicitly enabled in your `SKILL.md` frontmatter.

## Dynamic Context Injection

Beyond the assembled prompt, you can inject runtime data into your `SKILL.md` body using the `` !`command` `` syntax. This runs shell commands during container startup and replaces the markers with their output — useful for fetching live data before the LLM session begins.

See the [Dynamic Context Guide](/guides/dynamic-context) for details.

## Writing Better Instructions

Now that you know what the agent receives automatically, here are some tips:

* **Don't repeat what's injected.** You don't need to tell the agent about `GITHUB_TOKEN` or filesystem constraints — it already knows.
* **Reference injected blocks by name.** Say *"Read the config from `<agent-config>`"* rather than hardcoding values.
* **Handle your trigger types.** If your agent subscribes to both cron and webhooks, your instructions should cover both paths — the trigger context tells the agent which one fired.
* **Keep instructions focused on behavior.** The runtime context handles the "how" (credentials, environment, tools). Your `SKILL.md` should focus on the "what" and "why."