Skip to main content
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: 
<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 variables: Use `setenv NAME value` to persist variables across bash commands.
See the agent commands reference for details.
</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

<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 for details on the params field.

​
Credential Context

<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 for all credential types and their injected context.

​
Environment

<environment>
Filesystem: The root filesystem is read-only. `/tmp` is the only writable directory.
...
Environment variables: Use `setenv NAME value` to persist variables across bash commands.
</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, the agent’s working directory is /tmp/al-runs/<instance-id>/. The setenv command persists environment variables in both modes. See Environment Commands for setenv details, and 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

<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 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: 
<user-prompt>
Your prompt text here
</user-prompt>

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

​
Agent Call

<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 `al-return` to send back your result.
Contains the calling agent’s name and the context string it passed. See the Subagents Guide for details on agent-to-agent calls.

​
Skills

If your agent enables skills like lock or subagent, additional instruction blocks are injected between the <environment> block and the trigger context. These teach the agent the commands it can use — rlock/runlock for resource locks, or al-subagent/al-subagent-wait for subagent calls. 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 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.”