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.
Readable Markdown, agent-specific exports, or MCP connections. Rich syntax and integration support vary by host.
Written once. Understood together.
morning-assistant.md:::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.
:::Policy calendar
Calendar policy
ask Alex before changing an invitation.
calendar changes affect other people.
keep the daily brief under 150 words.
reveal a private event to another person.
:::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.
:::MCP server calendar
Calendar
Read appointments for planning. Ask Alex before changing an invitation.
events.listAllowedavailability.readAllowedevents.deleteDenied:::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}.Skill prioritize
Prioritize the day
Choose one useful, achievable focus task.
- Review commitments and available focus time.
- Choose one useful, achievable task.
- Explain why it is a good first priority.
Use Prioritize the day.
Plain text you can review. Structured meaning a compatible reader can preserve.
Download exampleWhy 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.
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.
Planning guidance Policy
preserve its tentative status.
an unanswered invitation is not a commitment.
keep the daily brief under 150 words.
the owner reads it on a phone.
reveal private event details to another person.
Your 09:00 catch-up is tentative. The 11:00 review is confirmed.
Commitments · One focus task · Open decisions
Verbosity is authored meaning. Layout can organize it; a reader preserves the detail.
Instruction examples
Different responsibilities.
One shared language.
A personal assistant, a research partner, or a whole team can start with the same format. Choose an instruction, then switch between its reading view and the Markdown behind it.
Choose an instruction
Explore the guidance each role needs.
A thoughtful start to the day
Prepare a useful daily brief from commitments and available focus time.
preserve tentative appointment status.
an unanswered invitation is not a commitment.
ask the owner before changing an invitation.
Skill
Prioritize the day
Choose one useful, achievable focus task.
- Review commitments and available time.
- Choose one achievable task.
- Explain why it is a good first priority.
---
spec: "1"
title: Personal assistant
version: "1.0.0"
---
# A thoughtful start to the day
Prepare a useful daily brief from commitments and available focus time.
MUST[status]: preserve tentative appointment status.
BECAUSE: an unanswered invitation is not a commitment.
MUST[approval]: ask the owner before changing an invitation.
:::skill{id=prioritize title="Prioritize the day"}
Choose one useful, achievable focus task.
1. Review commitments and available time.
2. Choose one achievable task.
3. Explain why it is a good first priority.
:::Research that can be reviewed
Prepare a brief that helps a reader understand the evidence and its limits.
distinguish sourced facts from your own inference.
a reader needs to assess the basis of each conclusion.
invent a source, quotation, or citation.
Output
Research brief
Make the reasoning easy to follow.
- A summary with source links.
- Findings and the evidence behind them.
- Open questions and limitations.
---
spec: "1"
title: Research partner
version: "1.0.0"
---
# Research that can be reviewed
Prepare a brief that helps a reader understand the evidence and its limits.
MUST[evidence]: distinguish sourced facts from your own inference.
BECAUSE: a reader needs to assess the basis of each conclusion.
NEVER[citations]: invent a source, quotation, or citation.
:::output{response-format=markdown title="Research brief"}
Make the reasoning easy to follow.
- A summary with source links.
- Findings and the evidence behind them.
- Open questions and limitations.
:::A review with a clear purpose
Review a proposed change for defects that affect its behavior.
report defects you can substantiate from the change and its context.
identify the relevant file and line for each finding.
precise locations make a review easier to act on.
Output
Review findings
Keep each finding specific and actionable.
- The file and line involved.
- The defect and its practical impact.
- A suggested correction when one is clear.
---
spec: "1"
title: Code reviewer
version: "1.0.0"
---
# A review with a clear purpose
Review a proposed change for defects that affect its behavior.
MUST[findings]: report defects you can substantiate from the change and its context.
SHOULD[location]: identify the relevant file and line for each finding.
BECAUSE: precise locations make a review easier to act on.
:::output{response-format=markdown title="Review findings"}
Keep each finding specific and actionable.
- The file and line involved.
- The defect and its practical impact.
- A suggested correction when one is clear.
:::A shared product working brief
Turn an approved goal into a proposal the team can review and implement.
distinguish confirmed requirements from assumptions.
ask Alex before changing approved scope.
the product owner decides changes to the agreed goal.
Output
Proposal structure
Make the next decision clear.
- The goal and confirmed constraints.
- A proposal with acceptance criteria.
- Open decisions for the product owner.
---
spec: "1"
title: Product team
version: "1.0.0"
---
# A shared product working brief
Turn an approved goal into a proposal the team can review and implement.
MUST[assumptions]: distinguish confirmed requirements from assumptions.
MUST[scope]: ask Alex before changing approved scope.
BECAUSE: the product owner decides changes to the agreed goal.
:::output{response-format=markdown title="Proposal structure"}
Make the next decision clear.
- The goal and confirmed constraints.
- A proposal with acceptance criteria.
- Open decisions for the product owner.
:::
::person{id=product-owner title="Alex" role=owner src="https://example.org/people/alex"}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.
ask Alex before changing an invitation.
calendar changes affect other people.
keep the daily brief under 150 words.
the owner reads it on a phone.
suggest a focus task when time is available.
a free period can support useful work.
reveal a private event to another person.
access does not imply permission to share.
plan around it as a confirmed commitment.
the attendee has not accepted yet.
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.
A reference describes the connection. Credentials and permission checks stay with the host; opening this page connects nothing.
https://calendar.example.org/mcp
- Account binding
- Personal
- Purpose
- Read appointments for the daily brief.
events.listAllowavailability.readAllowevents.deleteDenyAsk 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 src="./skills/prioritize/SKILL.md"}Skill prioritize
Prioritize the day
Choose one useful, achievable focus task.
- Review commitments and available focus time.
- Choose one useful, achievable task.
- Explain why it is a good first priority.
People and agents, declared once and referenced anywhere
::person{id=owner title="Alex" role=owner src="https://example.org/people/alex"}:::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.
---
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.
Keep tentative appointments tentative.team.md / status
Keep the brief under 150 words.morning-assistant.md → team / brief
Identify an uninterrupted work period.morning-assistant.md → team / priorities
Review the inbox.team / mail · Calendar only.
::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.
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: revisionDrawn from the definition. Opening the instruction doesn’t start a run.
The complete 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.
:::Independent branches, bounded by one run budget, combine before the next step.
steps:
research:
kind: parallel
depends_on:
- start
branches:
calendar:
steps:
read:
kind: mcp.tool
server: calendar
tool: availability.read
args: {}
priorities:
steps:
read:
kind: agent
instruction: Identify one achievable focus task from the supplied context.Calendar availability ∥ Focus priorities
Drawn from the definition. Opening the instruction doesn’t start a run.
The complete workflow
:::workflow{id=parallel dialect="instruction/workflow"}
name: parallel-research
limits:
steps: 20
tokens: 6000
deadline: 10m
steps:
start:
kind: manual
research:
kind: parallel
depends_on:
- start
branches:
calendar:
steps:
read:
kind: mcp.tool
server: calendar
tool: availability.read
args: {}
priorities:
steps:
read:
kind: agent
instruction: Identify one achievable focus task from the supplied context.
brief:
kind: agent
depends_on:
- research
instruction: "Combine the research into a short brief: {{ steps.research.output }}"
done:
kind: finish
depends_on:
- brief
output: "{{ steps.brief.output }}"
:::Retries, rates, idempotency and replay policy describe different boundaries.
steps:
fetch:
kind: mcp.tool
depends_on:
- start
server: calendar
tool: events.list
args: {}
timeout: 30s
retry:
max: 3
backoff: 2s
breaker:
failures: 5
cooldown: 60s
rate: 10/1s
idempotency:
value: "{{ inputs.request_id }}"
on_replay: failDrawn from the definition. Opening the instruction doesn’t start a run.
The complete workflow
:::workflow{id=resilience dialect="instruction/workflow"}
name: reliable-read
inputs:
schema:
type: object
required:
- request_id
properties:
request_id:
type: string
steps:
start:
kind: manual
fetch:
kind: mcp.tool
depends_on:
- start
server: calendar
tool: events.list
args: {}
timeout: 30s
retry:
max: 3
backoff: 2s
breaker:
failures: 5
cooldown: 60s
rate: 10/1s
idempotency:
value: "{{ inputs.request_id }}"
on_replay: fail
done:
kind: finish
depends_on:
- fetch
output: "{{ steps.fetch.output }}"
:::A native schedule declares when a workflow may begin. Activation remains explicit.
steps:
weekday:
kind: schedule
cron: 0 8 * * 1-5Drawn from the definition. Opening the instruction doesn’t start a run.
The complete workflow
:::workflow{id=schedule dialect="instruction/workflow"}
name: weekday-brief
steps:
weekday:
kind: schedule
cron: 0 8 * * 1-5
draft:
kind: agent
depends_on:
- weekday
instruction: Prepare a weekday brief. Name uncertainty and keep it under 150 words.
done:
kind: finish
depends_on:
- draft
output: "{{ steps.draft.output }}"
:::A scoped body processes each item with bounded parallelism and a declared rate.
steps:
each:
kind: foreach
depends_on:
- start
over: "{{ inputs.items }}"
as: task
batch:
size: 1
parallel: 3
rate: 10/1s
body:
steps:
review:
kind: agent
instruction: "Summarize this task and identify its next decision: {{ task }}"A review step · 3 parallel lanes · explicit rate
Drawn from the definition. Opening the instruction doesn’t start a run.
The complete workflow
:::workflow{id=foreach dialect="instruction/workflow"}
name: review-items
inputs:
schema:
type: object
required:
- items
properties:
items:
type: array
steps:
start:
kind: manual
each:
kind: foreach
depends_on:
- start
over: "{{ inputs.items }}"
as: task
batch:
size: 1
parallel: 3
rate: 10/1s
body:
steps:
review:
kind: agent
instruction: "Summarize this task and identify its next decision: {{ task }}"
done:
kind: finish
depends_on:
- each
output: "{{ steps.each.output }}"
:::Schedules, events, webhooks, MCP subscriptions and A2A.
Branches, scoped bodies, parallel work, loops and durable waits.
Budgets, schemas, retries, idempotency and human decisions.
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.
What is on my calendar tomorrow?
Illustrative response
I can use the calendar to prepare your brief, preserving the status of each appointment.
use events.list to read appointments for the daily brief.
reading appointments is within the declared calendar scope.
Move the review to 14:00.
Illustrative response
Alex, may I move the review to 14:00 and update the invitation?
ask Alex before using events.update.
calendar changes affect other people.
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.
reveal private appointment details to another person.
access to a calendar does not imply permission to disclose its contents.
Is the 09:00 catch-up confirmed?
Illustrative response
The 09:00 catch-up is tentative. It has not been confirmed.
preserve its tentative status.
an unanswered invitation is not a confirmed commitment.
Authored examples: no agent or tool runs on this page. The host enforces tool permissions and human approvals.
Read the calendar instruction
---
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.
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 statesCounterexample
Your 09:00 catch-up and 11:00 review are both confirmed.
Loses the uncertainty in the sourceAn 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.
SHOULD[brief]: keep the daily brief under 300 words.SHOULD[brief]: keep the daily brief under 150 words.The owner reads the brief on a phone.
#brief remains the same named rule.
Draft, awaiting a human decision.
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.
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.
:::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
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.
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.
Readable Markdown
Typed structure
References & origins
Agents & people
The same authored requirement
keep tentative appointments tentative.
A renderer changes the presentation. The rule’s identity and strength remain explicit.
{
"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
Calendar changes
Never send, delete, or move an invitation without the owner’s approval.
:::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.
:::{
"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.
With the extension
Focus tasksRecommend one achievable focus task.
charts:metric · dev.example/charts @ 1.0.0Without 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.
---
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 }Identity & configuration
Version, parameters, references, extensions, and export targets.
One shared body
Instructions, policies, people, skills, media, and workflows. Human readable and agent readable.
The authoring record
Authors, history, sources, and review information after a plain --- separator.
A self-contained bundle
morning-assistant/
├── instruction.md
├── team.md
├── skills/prioritize/SKILL.md
├── workflows/morning-brief.json
└── assets/brief.svgA 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.
- 01Choose a local instruction
- 02Load it into the agent’s context
- 03Keep its source in version control
# 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.
One address. Two ways to read it.
People open a published instruction in the browser. An integration can request its Markdown and provide it to an agent. Choose a released version or a reference that follows updates.
- 01Publish an instruction
- 02Request the Markdown representation
- 03Load the selected version
curl -H 'Accept: text/markdown' \
https://instruction.md/instruction-md/code-reviewPrivate instructions use the host’s authenticated connection. A URL is a reference; the host decides when to retrieve it.
Make instructions available as context.
Connect an MCP client to the instruction registry. A host can discover instructions, read a resource by its URI, and include the selected content in the agent’s context.
- 01Connect an authorized MCP client
- 02Select an instruction resource
- 03Read and apply its content
{
"jsonrpc": "2.0",
"id": 1,
"method": "resources/read",
"params": {
"uri": "instruction://acme/support-agent@stable"
}
}The host chooses which resources become instructions. A connection does not automatically grant tools or permissions.
A change is a signal to read again.
A compatible client can follow instruction updates. A resource notification prompts it to retrieve and check the new content. Other MCP event integrations can trigger workflows when the host supports them.
- 01Follow the selected reference
- 02Receive a change notification
- 03Re-read, verify, then apply
{
"jsonrpc": "2.0",
"method": "notifications/resources/updated",
"params": {
"uri": "instruction://acme/support-agent@stable"
}
}Resource updates signal changed content; they are distinct from workflow events. Event and subscription support depend on the client and server.
Bring the right instruction to the event.
A webhook reaches your integration when something happens: an issue opens, a form arrives, or a review is requested. That integration selects an instruction, fetches it, and starts the agent with the event’s context.
- 01Receive and authenticate the event
- 02Resolve the chosen instruction
- 03Start a run through your host
event: issue.opened
instruction: instruction://acme/support-agent@stable
handoff:
- verify_event
- read_instruction
- provide_event_context
- start_authorized_runThis recipe describes a host integration, not a built-in instruction.md webhook endpoint or an executable document block.
Prepare once. Hand over the whole context.
Resolve inherited instructions, named fragments, skills, and local media before delivery. Package the resources with the document so a compatible host can load a known set of materials.
- 01Resolve references and inherited blocks
- 02Record versions and origins
- 03Deliver the document and resources
daily-assistant/
├── instruction.md
├── team.md
├── skills/prioritize/SKILL.md
├── workflows/daily-brief.json
└── assets/day-plan.svgBundling can make resources self-contained. Account bindings, credentials, and execution remain with the receiving host.
The format carries the guidance. The host decides how to load, verify, and run it.
Connect an agentWhat 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.