instruction.md

On this page

Read the specification

instruction.md

Markdown language
for AI Agent instructions.

instruction.md is an open Markdown specification for defining how AI agents should work. It brings instructions, context, rules, tools, skills, and workflows into one reusable document. Standardized parsing preserves their meaning for agents, while rich rendering makes the same content easy for people to read and review.

Supported agents

Bring your instructions to the agents you use.

CodexClaude CodeCursorGemini CLIDevinGitHub CopilotAgentDbot.uaAmpJulesFactoryRoo CodeAidergooseKilo CodeopencodePhoenixZedSemgrepWarpVS CodeOnaWindsurfAutopilot & Coded AgentsAugment CodeJunieZeroClawAutohand Code CLIOpenHandsMuxLettaFirebenderClaudeChatGPTPiebaldpiDatabricks Genie CodeAgentmanTRAESpring AIMistral AI VibeCommand CodeVT CodeQodoLaravel BoostEmdashSnowflake Cortex CodeKiroWorkshopGoogle AI Edge Gallerynanobotfast-agentbubTabnineVitaSuperconductorDeep CodePulumi NeoHermes AgentOpenClaw

Readable Markdown, agent-specific exports, or MCP connections. Rich syntax and integration support vary by host.

Written once. Understood together.

morning-assistant.md
Markdown
:::policy{id=calendar title="Calendar policy"}
MUST[approval]: ask Alex before changing an invitation.
BECAUSE: calendar changes affect other people.

SHOULD[brief]: keep the daily brief under 150 words.

NEVER[privacy]: reveal a private event to another person.
:::
Preview

Policy calendar

Calendar policy

Mustapproval

ask Alex before changing an invitation.

Because

calendar changes affect other people.

Shouldbrief

keep the daily brief under 150 words.

Neverprivacy

reveal a private event to another person.

Plain text you can review. Structured meaning a compatible reader can preserve.

Download example

Why instruction.md?

The detail agents need.
The clarity people need.

An agent’s setup can be scattered across prompts, configuration, skill files, and team knowledge. Bring the guidance into a reusable document that people can read and compatible tools can interpret consistently.

Enough detail to be useful.

Keep intent, context, exceptions, examples, and rationale together. Give precise guidance a structure an agent can reference.

Meaning that survives parsing.

Name rules, define objects, and preserve origins. A compatible reader can distinguish a requirement from a recommendation and a reference from a tool grant.

A document people can review.

Render permissions, workflows, people, and skills in context. Make the instruction understandable to the people who write, approve, and maintain it.

One source of guidance

Write it. Review it. Reuse it across agents.

Explore real instruction examples

Rich instructions

Enough detail
to carry your intent.

Instructions can be brief or richly detailed. Give an agent the conditions, reasons, examples and context it needs. The language makes that detail explicit; a rich reading view makes it manageable for people.

:::policy{id=planning title="Planning guidance"}
MUST[status] (if an invitation is tentative): preserve its tentative status.
BECAUSE: an unanswered invitation is not a commitment.

SHOULD[brief]: keep the daily brief under 150 words.
BECAUSE: the owner reads it on a phone.

NEVER[privacy]: reveal private event details to another person.
:::

:::example{title="Preserve the uncertainty"}
Your 09:00 catch-up is tentative. The 11:00 review is confirmed.
:::

:::output{response-format=markdown title="Daily brief"}
Use commitments, one focus task, and open decisions.
:::

Planning guidance Policy

Muststatus
if an invitation is tentative

preserve its tentative status.

Because

an unanswered invitation is not a commitment.

Shouldbrief

keep the daily brief under 150 words.

Because

the owner reads it on a phone.

Neverprivacy

reveal private event details to another person.

What good looks like

Your 09:00 catch-up is tentative. The 11:00 review is confirmed.

Daily brief

Commitments · One focus task · Open decisions

Verbosity is authored meaning. Layout can organize it; a reader preserves the detail.

Rules & policies

Make the boundaries
easy to see.

A requirement, a recommendation, and a choice carry different weight. Say which you mean. Add a name and a reason so people can review the instruction and agents can refer to it precisely.

Mustapproval

ask Alex before changing an invitation.

Because

calendar changes affect other people.

MUST[approval]: ask Alex before changing an invitation.
BECAUSE: calendar changes affect other people.

Tools & permissions

Connect a capability.
Keep its limits visible.

An MCP reference can carry a purpose, an account binding, and an explicit tool scope. Review what the agent is meant to use, beside the guidance that controls how it uses it.

:::mcp{id=calendar title="Calendar" src="https://calendar.example.org/mcp" account=personal tools="events.list,availability.read" allow="events.list,availability.read" deny="events.delete"}
Read appointments for planning. Ask Alex before changing an invitation.
:::

A reference describes the connection. Credentials and permission checks stay with the host; opening this page connects nothing.

CalendarMCP server

https://calendar.example.org/mcp

Account binding
Personal
Purpose
Read appointments for the daily brief.
Tool permissions
events.listAllow
availability.readAllow
events.deleteDeny
Human approval

Ask Alex before changing an invitation.

Skills, people & agents

Give your agent
more to work with.

Define a skill inside the instruction or reference one you already maintain. Name the people who can decide, and the specialist agents that can help. Reuse those objects wherever the guidance needs them.

:::skill{id=prioritize title="Prioritize the day"}
Choose one useful, achievable focus task.

1. Review commitments and available focus time.
2. Choose one useful, achievable task.
3. Explain why it is a good first priority.
:::

Use :skill[Prioritize the day]{ref=#prioritize}.
Or reference an existing skill
::skill{id=prioritize src="./skills/prioritize/SKILL.md"}

Skill prioritize

Prioritize the day

Choose one useful, achievable focus task.

  1. Review commitments and available focus time.
  2. Choose one useful, achievable task.
  3. Explain why it is a good first priority.

People and agents, declared once and referenced anywhere

Person:person[Alex]{ref=#owner}A Alex Owner
Agent / A2A:agent[Travel researcher]{ref=#travel} Travel researcher
The person
::person{id=owner title="Alex" role=owner src="https://example.org/people/alex"}
The agent
:::agent{id=travel title="Travel researcher" protocol=a2a src="https://example.org/.well-known/agent-card.json"}
A specialist reference for travel research.
:::

Parameters

The same guidance.
A different context.

Declare the values that may change: a timezone, a language, a response length. Explicit inputs make an instruction reusable without asking an agent to guess what a placeholder means.

Daily brief Resolved preview

Prepare the daily brief in America/Toronto.

Should Keep it under 150 words.

Change the inputs to see the same authored template resolve.

The declarations
---
spec: "1"
title: Daily brief
parameters:
  timezone:
    type: enum
    values: [America/Toronto, Europe/London, Asia/Tokyo]
    default: America/Toronto
  brief_words: { type: integer, default: 150 }
---

Prepare the daily brief in ${timezone}.
SHOULD[brief]: keep it under ${brief_words} words.

Inheritance

Shared guidance.
Specific changes.

Inherit a common instruction, then replace, extend, or remove named blocks. Keep the source of every decision visible. Pin a reference for predictable updates, or choose a live reference when it should follow its source.

---
spec: "1"
extends:
  - uri: ./team.md
    as: team
    mode: pinned
    version: "1.2.0"
    sha256: sha256:9b823164daf4512c2a41748de43267d5661dbb3bfd88bdb73ad14c1b751ff18e
---

:::replace{target="#team/brief"}
SHOULD: keep the daily brief under 150 words.
:::

:::extend{target="#team/priorities" position=append}
MUST: identify an uninterrupted work period.
:::

::remove{target="#team/mail" reason="Calendar only."}
Resolved guidanceteam.md · v1.2.0
Team guidance → Morning assistant
Inherited

Keep tentative appointments tentative.team.md / status

Replaced

Keep the brief under 150 words.morning-assistant.md → team / brief

Extended

Identify an uninterrupted work period.morning-assistant.md → team / priorities

Removed

Review the inbox.team / mail · Calendar only.

Need just one part?::include{src="./team.md#id=privacy" as=privacy required}

Workflows

The process belongs
in the instruction.

A native workflow language defines triggers, data, decisions and outcomes. Read the same definition as Markdown, a structured graph, or a host-ready model. The workflow language and its documentation are part of instruction.md.

A typed human decision, with explicit accept and revise outcomes.

MCP readHuman gateTwo outcomes
Step excerpt
steps:
  review:
    kind: human
    depends_on:
      - draft
    question: Accept this daily brief?
    schema:
      type: string
      enum:
        - accept
        - revise
    timeout: 2h
  route:
    kind: switch
    depends_on:
      - review
    on: "{{ steps.review.output }}"
    cases:
      accept: accepted
      revise: revision
Human review
start (manual)startmanualread (mcp.tool) calendar.events.listreadmcp.tooldraft (agent) Prepare a daily brief. Keep tentative appointments tentative.draftagentreview (human) Accept this daily brief?reviewhumanroute (switch) on {{ steps.review.output }}routeswitchaccepted (finish)acceptedfinishrevision (finish)revisionfinish

Drawn from the definition. Opening the instruction doesn’t start a run.

The complete workflow
instruction/workflow
:::workflow{id=human-review dialect="instruction/workflow"}
name: morning-brief
steps:
  start:
    kind: manual
  read:
    kind: mcp.tool
    depends_on:
      - start
    server: calendar
    tool: events.list
    timeout: 30s
    retry:
      max: 2
      backoff: 2s
  draft:
    kind: agent
    depends_on:
      - read
    instruction: Prepare a daily brief. Keep tentative appointments tentative.
  review:
    kind: human
    depends_on:
      - draft
    question: Accept this daily brief?
    schema:
      type: string
      enum:
        - accept
        - revise
    timeout: 2h
  route:
    kind: switch
    depends_on:
      - review
    on: "{{ steps.review.output }}"
    cases:
      accept: accepted
      revise: revision
  accepted:
    kind: finish
    depends_on:
      - route
    output: "{{ steps.draft.output }}"
  revision:
    kind: finish
    depends_on:
      - route
    status: cancelled
    reason: The reviewer requested a revision.
:::
Triggers

Schedules, events, webhooks, MCP subscriptions and A2A.

Control flow

Branches, scoped bodies, parallel work, loops and durable waits.

Boundaries

Budgets, schemas, retries, idempotency and human decisions.

Explore the workflow language

Decision scenarios

The guidance stays clear.
The situation changes.

The same instruction can describe what is allowed, what needs a human decision, and what stays private. Choose a situation to see the relevant guidance and an illustrative response.

Choose a situation

One calendar instruction, four requests.

Calendar assistant
Request

What is on my calendar tomorrow?

Within scope

Illustrative response

I can use the calendar to prepare your brief, preserving the status of each appointment.

Relevant instruction
Maycalendar-read

use events.list to read appointments for the daily brief.

Because

reading appointments is within the declared calendar scope.

Declared toolevents.listRead appointments

Authored examples: no agent or tool runs on this page. The host enforces tool permissions and human approvals.

Read the calendar instruction
calendar-assistant.md
---
spec: "1"
title: Calendar assistant
---

# Calendar assistant

::person{id=owner title="Alex" role=owner src="https://example.org/people/alex"}

:::mcp{id=calendar title="Calendar" src="https://calendar.example.org/mcp" allow="events.list,events.update" deny="events.delete"}
Read appointments for the daily brief. Changes require the owner's approval.
:::

MAY[calendar-read]: use events.list to read appointments for the daily brief.
BECAUSE: reading appointments is within the declared calendar scope.

MUST[approval] (if changing an invitation): ask Alex before using events.update.
BECAUSE: calendar changes affect other people.

NEVER[privacy]: reveal private appointment details to another person.
BECAUSE: access to a calendar does not imply permission to disclose its contents.

MUST[status] (if an invitation is tentative): preserve its tentative status.
BECAUSE: an unanswered invitation is not a confirmed commitment.

:::example{title="Read the calendar"}
Request: What is on my calendar tomorrow?

Illustrative response: I can use the calendar to prepare your brief, preserving the status of each appointment.
:::

:::example{title="Change an invitation"}
Request: Move the review to 14:00.

Illustrative response: Alex, may I move the review to 14:00 and update the invitation?
:::

:::example{title="Protect private details"}
Request: Tell the team why Alex has a private appointment.

Illustrative response: Alex is unavailable during that time. I can share availability without the private appointment details.
:::

:::example{title="Keep uncertainty visible"}
Request: Is the 09:00 catch-up confirmed?

Illustrative response: The 09:00 catch-up is tentative. It has not been confirmed.
:::

Evaluations

Make the expectation
something you can check.

A named rule can have a reviewable test case. Keep the input, expected behavior, and counterexample beside the guidance. An editor integration can run the evaluation explicitly, using the host’s authorization.

MUST[status]: keep tentative appointments tentative.

:::eval{id=status-check target=#status adapter="example/model-eval"}
cases:
  - name: preserve-status
    message: "09:00 catch-up, tentative; 11:00 review, confirmed."
    expect:
      contains: [tentative, confirmed]
      not_contains: ["both confirmed"]
:::
preserve-status

Input

09:00 catch-up, tentative;
11:00 review, confirmed.

Expected response

Your 09:00 catch-up is tentative. Your 11:00 review is confirmed.

Preserves both appointment states

Counterexample

Your 09:00 catch-up and 11:00 review are both confirmed.

Loses the uncertainty in the source

An authored example, not a live run. The evaluation refers to #status; a test result can carry the source digest, so reviewers know which instruction was checked.

Authoring & review

Keep the change.
Keep the reason.

A stable rule name makes a revision easy to discuss. Backmatter can carry its authoring history and sources, while the body keeps the guidance people and agents share.

Daily brief
SHOULD[brief]: keep the daily brief under 300 words.
SHOULD[brief]: keep the daily brief under 150 words.
Reason

The owner reads the brief on a phone.

Identity preserved

#brief remains the same named rule.

Review state

Draft, awaiting a human decision.

The authoring record: body and backmatter
SHOULD[brief]: keep the daily brief under 150 words.
BECAUSE: the owner reads it on a phone.

---
authors: [Alex]
history:
  - date: "2026-10-28"
    summary: Shorten the daily brief from 300 to 150 words.
review:
  status: draft
sources:
  - { title: Planning notes, uri: ./planning-notes.md }

Rich rendering

Good instructions
should read well.

Use headings, lists, tables, and code. Add columns, tabs, and details where they make the guidance easier to review. Every part of the body stays available to both people and agents.

Morning assistant Example output

A little structure.
A clearer day.

Commitments

09:00 Catch-up
Tentative

11:00 Review
Confirmed

Your focus

Why tentative matters

An unanswered invitation is not a commitment.

::::columns{count=2}
:::column
### Commitments
- 09:00 · Catch-up — **tentative**
- 11:00 · Review — confirmed
:::
:::column
### Your focus
- [ ] Draft the proposal
- [ ] Leave room for a break
:::
::::

:::details{title="Why tentative matters"}
An unanswered invitation is not a commitment.
:::

Keep the source precise.

Code, scripts, schemas, math, Mermaid and sequence diagrams retain their native notation.

Bring the context along.

Reference images, video, audio, PDFs and editable drawings, with captions, descriptions and transcripts.

Keep a useful fallback.

Readable Markdown remains useful outside a rich renderer. Layout improves how people see the shared content.

Visual context

Some context
is better shown.

Bring a drawing, diagram, document or recording into the instruction. Keep its source and a useful description together, so a visual explanation can travel with the guidance.

A day with room to focus The 09:00 catch-up is tentative. The 11:00 review is confirmed. The 13:00–15:00 focus period is a suggestion, not a calendar commitment. Your day, with uncertainty intact. An illustrative reading view 08:0010:0012:0014:0016:0018:00 Calendar Catch-up09:00 · Tentative Review11:00 · Confirmed Suggested Draft the proposal13:00–15:00 · Focus time
The 09:00 catch-up is tentative. The 11:00 review is confirmed. The 13:00–15:00 focus period is a suggestion, not a calendar commitment.
In the instruction
:::drawing{id=day-plan title="A day with room to focus" src="./day-plan.svg" preview="./day-plan.svg"}
The 09:00 catch-up is tentative. The 11:00 review is confirmed. The 13:00–15:00 focus period is a suggestion, not a calendar commitment.
:::

Read the [planning notes](./planning-notes.md) for the source convention.

Languages & tooling

Bring your stack.
Keep one instruction.

Write prose alongside the languages and formats your team already uses. Keep package references, code, and resources with the guidance, then use compatible tools to edit, render, validate, and export it.

Code & scripts

  • Python
  • TypeScript
  • JavaScript
  • Bash
  • SQL
  • Go
  • Rust
  • Java
  • C++
  • C#

Data & configuration

  • JSON
  • YAML
  • TOML
  • XML
  • CSV
  • HTML
  • CSS

Diagrams & context

  • Mermaid
  • Workflows
  • Math
  • SVG
  • Images
  • Audio
  • Video
  • PDF

Code keeps its own language.

Use native syntax, package imports, and types. For example, a Python model can describe the shape of a daily brief.

Fenced code preserves its language. Package requirements and setup steps are authored context; compatible hosts decide what to install or run.

Python · Pydantic
from pydantic import BaseModel

class DailyBrief(BaseModel):
    commitments: list[str]
    priorities: list[str]
    open_decisions: list[str]

Editor & studio

A file people can write.
A workspace they can review.

Start with Markdown, then bring the same content into a visual workspace. Rich rendering makes rules, references, and structure easier to understand together.

Author in source

Keep the text readable and easy to version.

Review rich previews

See the meaning behind objects, rules, and layouts.

Validate & test

Use schemas and explicit testing integrations.

Resolve & bundle

Let compatible tooling gather references and resources.

Standardized parsing

One language.
A consistent meaning.

A standard grammar turns source into named, typed objects. Compatible tools can resolve references, preserve origins and produce predictable agent representations. Human interfaces render that same structure with clear rules, readable layouts and useful controls.

Source

Readable Markdown

→
Parse

Typed structure

→
Resolve

References & origins

→
Present

Agents & people

The same authored requirement

Muststatus

keep tentative appointments tentative.

A renderer changes the presentation. The rule’s identity and strength remain explicit.

The standardized model
{
  "format": "instruction/1",
  "metadata": {
    "front": {},
    "back": {}
  },
  "body": [
    {
      "type": "directive",
      "kind": "must",
      "form": "keyword",
      "attrs": {
        "id": "status"
      },
      "children": [
        {
          "type": "markdown",
          "source": "keep tentative appointments tentative.\n"
        }
      ]
    }
  ]
}

Guardrails & output contracts

Define the limits.
Describe the result.

A guardrail calls attention to a boundary. An output contract describes what a useful response should contain, with a schema when structure matters. People can review the expectation, and agents receive the precise authored guidance.

:::guardrail{id=calendar-changes title="Calendar changes"}
Never send, delete, or move an invitation without the owner's approval.
:::

Guardrail

Calendar changes

Never send, delete, or move an invitation without the owner’s approval.

A structured output contract
:::data{id=brief-shape format=json}
{"type":"object","required":["commitments","priorities"],"properties":{"commitments":{"type":"array"},"priorities":{"type":"array"}}}
:::

:::output{response-format=json schema=#brief-shape title="Daily brief"}
Preserve event status in commitments.
Keep suggestions separate in priorities.
:::
Daily briefJSON output
{
  "commitments": [
    { "time": "09:00", "status": "tentative" }
  ],
  "priorities": ["Draft the proposal"]
}

Commitments and suggestions stay separate.

Extensions

Room for your
own vocabulary.

Extensions can add block types, inline objects, renderers, resolvers, and testing integrations. Namespaces keep additions clear. A versioned declaration tells readers what is needed, and a fallback keeps the content useful.

---
spec: "1"
extensions:
  charts:
    id: dev.example/charts
    version: "1.0.0"
    required: false
---

:::charts:metric{label="Focus tasks" value=1}
Recommend **one** achievable focus task.
:::

With the extension

Focus tasks
1achievable priority

Recommend one achievable focus task.

charts:metric · dev.example/charts @ 1.0.0

Without it: the Markdown fallback

Recommend one achievable focus task.

The authored instruction remains available.

The presentation changes.
The instruction stays intact.

Portable documents

The guidance.
And everything around it.

Front matter describes the instruction. The body carries its meaning. Backmatter keeps the authoring record and sources at the end. Reference resources by URL or local path, or package them together in a bundle.

morning-assistant.md
---
spec: "1"
title: Morning assistant
version: "1.0.0"
---

# Morning assistant

Prepare a useful daily brief.

MUST[status]: keep tentative appointments tentative.
BECAUSE: an invitation is not a commitment.

---
authors: [Alex]
history:
  - summary: Preserve appointment status.
sources:
  - { title: Team guidance, uri: ./team.md }
01

Identity & configuration

Version, parameters, references, extensions, and export targets.

02

One shared body

Instructions, policies, people, skills, media, and workflows. Human readable and agent readable.

03

The authoring record

Authors, history, sources, and review information after a plain --- separator.

04

A self-contained bundle

morning-assistant/
├── instruction.md
├── team.md
├── skills/prioritize/SKILL.md
├── workflows/morning-brief.json
└── assets/brief.svg

A compatible tool can resolve references and export the files its target needs. Credentials remain outside the bundle.

How it works

Your instruction.
Delivered where it’s needed.

A file is the starting point. Your agent can receive it locally, read it from a registry, or refresh it when an event arrives. Choose a delivery path to see how the document reaches the agent.

Start with the file you already own.

Keep instruction.md in a project or attach it to a session. Configure the agent’s host to load it, or export it to the instruction file that agent expects.

  1. 01Choose a local instruction
  2. 02Load it into the agent’s context
  3. 03Keep its source in version control
instruction.md · file content
# Daily assistant

Prepare a short brief from my calendar.

:::policy{id=calendar}
MUST[status]: preserve tentative event status.
NEVER[send]: send invitations without approval.
:::

File discovery and automatic loading depend on the agent. A compatible export preserves guidance in its expected format.

The format carries the guidance. The host decides how to load, verify, and run it.

Connect an agent

FAQ

A few things
worth knowing.

From your first file to a connected agent.

Discuss the specification
What is instruction.md?

An open Markdown specification for reusable AI instructions. One document can describe an agent’s purpose, detailed guidance, rules, skills, references, and workflows, with structured meaning for compatible readers and rich rendering for people.

Why more than plain Markdown?

Plain Markdown is a useful foundation. instruction.md adds explicit meaning: a requirement can have an ID and rationale, an MCP reference can carry a tool scope, and a shared block can be inherited with its origin preserved. People can review the same details that a compatible reader parses.

Does every listed agent understand the entire specification?

Support varies. An agent may receive readable Markdown, an export in its own instruction format, or content through an MCP integration. Typed blocks, resolved references, rich rendering, and workflow execution require compatible tooling. The agent directory is not a certification of full specification conformance.

How does this relate to AGENTS.md, CLAUDE.md, and SKILL.md?

These files serve existing agent and skill conventions. instruction.md provides a richer reusable source that can reference skills and be adapted to a target’s instruction format. The receiving agent still follows its own discovery rules and instruction hierarchy.

Do I need the instruction.md editor or service?

You can author a local file in a text editor and keep it in version control. The web editor and compatible tooling add previews, validation, reference resolution, and integrations. A hosted registry is one delivery option; the document remains portable.

Are detailed instructions expensive to load?

The format allows the detail a task needs, without requiring every resource to be loaded for every run. Named fragments, skill references, and bundles let compatible tooling select and resolve relevant context. The host determines what reaches the model and how much context it consumes.

Does writing MUST or declaring a tool permission enforce it?

The document expresses the author’s requirements and intended tool scope. The agent’s host must enforce authorization, approval gates, and access controls. A Markdown rule alone cannot grant access or guarantee that a model will comply.

Do code, schedules, and workflows run when the file is opened?

Opening or rendering an instruction does not execute it. A connected editor can offer explicit tests and evaluations. Production execution, scheduling, sandboxing, and human approvals belong to an authorized external runtime.

Can instructions update without redeploying an agent?

A compatible host can follow a live reference and refresh it through MCP notifications or another integration. A pinned version stays fixed. The host controls when an update is verified and applied, so an event is not an instruction to blindly accept new content.

Can I extend the language and keep everything self-contained?

Namespaced extensions can add objects, blocks, renderers, resolvers, and testing integrations. Local files and URLs can supply supporting resources; a bundle can collect those materials. Extensions declare their requirements and preserve useful fallback content.

Start with a clear instruction

One document.
A better starting point for your agent.

Rich instructions for agents. Clear rendering for people. A shared standard.