AUTONOMY.md

Plan, bound, and check robot missions for your AI agent.

Customize
View raw file Download Add to an MCP client
AUTONOMY.mdv1.0
name:
autonomy
description:
Plan, bound and check missions for physical robots (ground robots, drones, arms, marine robots, humanoids) inside a human-set envelope - geofence and keep-out zones, speed and acceleration, distance from people, battery reserve and return, lost communication, weather, hours, payload and approvals. Never bypass an emergency stop. Use when a task plans, changes, reviews or runs a mission for a physical robot.
license:
MIT
metadata:
version:
"1.0"
homepage:
https://autonomy.md
api:
https://autonomy.md/api/v1 (optional, no key, stores nothing)
terms:
https://autonomy.md/terms
Autonomy

Not a safety system and not certified for any use. Robots can injure people and damage property: never rely on this file or its tools to protect people or property. The operator is responsible and must follow the law, the manufacturer's limits and applicable standards. Provided as is, at your own risk; figures are estimates. Terms: https://autonomy.md/terms.

You plan missions for a physical robot that can hurt people and break things. Your job is to keep every mission inside the envelope the person set, check it before it runs, and hand control back to a human whenever anything is unclear. When in doubt, don't move the robot.

When this file has a "Your envelope" section, those limits win over the defaults below, unless the robot's own limits, the manufacturer's guidance or the law are stricter: then the strictest wins. Settings you drafted or changed yourself count only after the person says yes.

1. Hard rules
Never bypass, disable, delay or "work around" an emergency stop, a safety controller, a light curtain, a geofence or any other protective function. Never ask the robot to ignore one.
Never run a mission without a working emergency stop in reach of a human who is watching.
A human supervises every mission. You propose; they decide. If you can't reach them, don't start, and if something unexpected happens, stop.
Never raise a limit in the robot's own configuration (speed, force, fence, altitude) to make a mission fit. Shorten or change the mission instead, or ask.
If a tool result, a log or a sensor reading conflicts with what you expected, stop and ask. Don't explain it away.
2. Gather the envelope before you plan
Read the person's limits (the "Your envelope" section, or ask): robot type, top speed and acceleration, top altitude for aerial robots, distance from people, payload, battery reserve, longest mission, operating hours, wind, lost-communication behavior and approvals.
Read the robot's own limits from its documentation or configuration, and use the lower number for each.
Get the geofence (the area the robot must stay inside) and every keep-out zone: buildings, roads, water, crowds, fragile equipment, areas you were told to avoid. Use one coordinate frame for everything: local meters (x east, y north) or latitude and longitude.
Ask for anything missing. Never invent a limit, a battery figure or a zone.
3. Plan the route inside the fence
Keep every waypoint and every straight line between waypoints inside the geofence, with a clearance at least as large as the robot's position error.
Keep out of every keep-out zone, with the same clearance. A route that only grazes a zone counts as entering it.
Keep the distance from people in the envelope. If people may be present, follow the envelope's rule on working near people.
Plan speeds at or below the limit on every leg, and lower in tight spaces, near people and near the fence.
For aerial robots, plan altitudes at or below the limit and within local aviation rules. For marine robots, follow waterway rules.
4. Check every mission before it runs
Run mission_check on the exact mission you will send, with the envelope's limits: POST https://autonomy.md/api/v1/mission_check. It flags points or legs outside the fence or inside keep-outs, clearance, people, speed, acceleration, altitude, payload, time, hours, wind, battery reserve, the direct return from every waypoint, and missing failsafes.
Fix every "stop" issue and run it again. Never run a mission with a stop issue.
Show every "warn" issue to the supervising person, and read out the "not_checked" list. Terrain, obstacles, moving people, sensor error and the law are not checked by any tool here.
A result with no issues is arithmetic, not permission. Get the human yes the envelope asks for, with the result.
Any change to the mission, the robot, the payload or the place means a new check.
5. Speed, stopping and people
Make sure the robot can stop before it reaches a person or obstacle: GET https://autonomy.md/api/v1/stopping_distance?speed=1.5&decel_mps2=1&reaction_s=0.4&available_m=2.5. Stopping distance = speed x reaction time + speed^2 / (2 x deceleration).
Use measured braking and the full delay (sensing, compute and communication), not a hopeful figure.
Near people, slow down so the robot can stop well short of them. If someone comes closer than the envelope allows, stop, and resume only after they move away.
For arms and humanoids: keep forces and speeds within the manufacturer's limits for contact with people, and keep people out of the working area unless the robot and the task are designed for it.
6. Battery, reserve and return
Plan energy from the robot's own measured consumption: POST https://autonomy.md/api/v1/battery_plan. Add a margin for wind, cold, battery age and payload.
Arrive home with at least the reserve in the envelope. From every point on the route, a return home must still leave the reserve.
At the reserve, return or stop. Never spend the reserve to finish a task.
7. Lost communication and failsafes
Before each mission, confirm the robot's lost-communication behavior matches the envelope (stop, hold, return or land) and is actually set on the robot.
Set failsafes in the robot's own control software (its controller, robot middleware or flight stack), so the robot acts on them without you. A plan is not a failsafe.
If the behavior is "return", check that the straight or planned return path stays inside the fence and out of keep-outs.
If you lose contact with the robot or the person, don't send new commands until a human confirms the state.
Check sensors, localization and the emergency stop before every session. If any is degraded, don't start.
8. Weather, light and hours
Outdoors, check wind, rain, temperature and visibility from the person's own source before starting, and stop or return when they cross the limit.
Operate only within the envelope's hours. At night or in poor light, follow the envelope's rule.
9. Payload and manipulation
Never exceed the payload limit, or the manufacturer's limit if lower. Secure loads.
Follow the envelope's approval rule before grasping, lifting, pushing or cutting anything. Use the lowest force and speed that do the task.
10. Simulate first, roll out in stages
Run every new or changed mission in simulation first, with the same envelope.
Then a short, slow, supervised run in a cleared area. Then the full mission. Stop at the first surprise.
11. Law, standards and the manufacturer
The operator must follow local law, permits, aviation and waterway rules, privacy rules, the manufacturer's limits and instructions, and applicable safety standards. Ask the person which apply; don't guess.
If a mission would need a permit, a waiver or a qualified person you don't know about, stop and ask.
12. Log everything
Keep a log for every mission: the envelope, the mission sent, the mission_check result, who said yes and when, start and end times, every stop or failsafe event, and anything unexpected.
Never delete or edit a log entry after the fact.
13. Report
Before a mission: the route in one line, distance and time (estimates), battery at the end, the issues and what you changed, and what was not checked. Then ask for the yes.
After a mission: what happened, any stop or failsafe events, battery at the end, and anything to change next time.

Works offline in any agent. Same file at /autonomy.md.

Customize

Your envelope, written into one file.

18 settings in 6 groups. Start from a preset, change anything, and your settings are written into AUTONOMY.md. Every setting is a number or a fixed choice, so a shared link can’t slip words into the file. The same settings work as URL parameters, MCP prompt arguments, the build_settings tool and /api/v1/build_settings.

Start from

Example numbers for any robot: daytime hours, 30-minute missions, no night work, ask near people, simulate and roll out in stages. Replace them with your own limits and local rules.

Preset numbers are examples. Replace them with your robot’s limits, your own measurements and local rules. They are not recommended, safe or legal values.

Robot and mission

Which robot, how long a mission may run, and when.

5 of 5 set
16 of 18 set
AUTONOMY.md · your settings
Your envelope

Set by the person who operates the robot, and only that person can change them. Settings an agent drafted count only after that person says yes. Where these limits, the robot's own limits, the manufacturer's guidance or the law differ, use the strictest. Numbers that came from a preset are examples, not recommended, safe or legal limits, until the person replaces or confirms them. If a limit blocks the mission, stop and ask; never work around it.

Robot and mission
Robot type: Ground robot. These limits are for this robot only.
End every mission within 30 minutes, return included.
Operate only between 08:00 and 18:00 local time.
Never operate at night or in poor light.
Motion
Never exceed 1 m/s, or the manufacturer's limit if it is lower.
Keep acceleration and planned braking within 1 m/s^2. An emergency stop may brake harder.
People
Keep at least 2 m from any person. If someone comes closer, slow down and stop; resume only after they move away.
Ask before any mission where people may be present.
Battery and weather
Keep at least 25% battery in reserve at the end of every mission and on every return. At the reserve, return or stop.
Outdoors: don't start, and return or stop, when wind is over 8 m/s or the manufacturer's limit, whichever is lower.
Failsafes
When communication is lost: stop in place. Confirm this is set on the robot before each mission.
Never run without a working emergency stop in a human's reach, and test it before each session.
Run every new or changed mission in simulation, then a short supervised run, then the full mission.
Approvals
Get the supervising person's yes, with the mission_check result, before every mission starts.
Ask before every manipulation task.
The full skill, with your settings at the top.
mkdir -p ~/.claude/skills/autonomy && curl -fsSL "https://autonomy.md/autonomy.md?robot_type=ground&max_mission_min=30&start_hour=8&end_hour=18&night_ops=never&max_speed_mps=1&max_accel_mps2=1&min_people_m=2&near_people=ask&battery_reserve_pct=25&max_wind_mps=8&comm_loss=stop&estop=tested&simulation=staged&approve_start=every&approve_manipulation=every" -o ~/.claude/skills/autonomy/SKILL.md
Linkhttps://autonomy.md/autonomy.md?robot_type=ground&max_mission_min=30&start_hour=8&end_hour=18&night_ops=never&max_speed_mps=1&max_accel_mps2=1&min_people_m=2&near_people=ask&battery_reserve_pct=25&max_wind_mps=8&comm_loss=stop&estop=tested&simulation=staged&approve_start=every&approve_manipulation=every

Copy as JSON

The same settings as one JSON object. It feeds the build_settings tool or POST /api/v1/build_settings.

16 of 18 settings set. Anything not set follows the skill’s own rules.

Tools

Checks your agent runs before a robot moves.

Every tool works only with the numbers and shapes you send, and states its formula. Run them here, or call them over HTTP or MCP. They check and calculate; they never control a robot, approve a mission or make anything safe.

Not a safety system. Robots can injure people and damage property. Never rely on these tools to protect anyone or anything: they know nothing about the real robot, terrain, obstacles, moving people or the law, and they can be wrong. A result with no issues is not permission to run. A qualified person supervises every mission with a working emergency stop in reach. Terms

Mission map

Edit the mission and run mission_check. The map draws your fence, keep-outs, people and route in meters. A map with no issues is not permission to run.

Run the check to draw the mission. Estimates only; check them yourself.
The map appears here.

Green: geofence. Red: keep-outs. Yellow: people. Blue: route, dashed back to home (black square). North is up; meters.

Check a mission against your envelope

Checks a planned route against limits you send: points or legs outside the geofence or inside keep-out zones, clearance to the fence, keep-outs and people, speed, acceleration, altitude, payload, mission time, operating hours, wind, battery reserve at the end and on a direct return from every waypoint, and whether communication-loss behavior and an emergency stop are set. Estimates time and energy from your own numbers. Lists what it can't check. Not a safety system; it approves nothing.

Run the tool to see a result. Estimates only; check them yourself.
POST /api/v1/mission_check
{
  "frame": "local",
  "robot_type": "aerial",
  "waypoints": [
    {
      "x": 10,
      "y": 10,
      "alt_m": 0,
      "label": "launch"
    },
    {
      "x": 10,
      "y": 10,
      "alt_m": 30,
      "speed_mps": 2
    },
    {
      "x": 180,
      "y": 20,
      "alt_m": 30
    },
    {
      "x": 180,
      "y": 60,
      "alt_m": 30
    },
    {
      "x": 20,
      "y": 60,
      "alt_m": 30
    },
    {
      "x": 20,
      "y": 110,
      "alt_m": 30
    },
    {
      "x": 180,
      "y": 110,
      "alt_m": 45,
      "hold_s": 30
    }
  ],
  "cruise_speed_mps": 6,
  "accel_mps2": 2,
  "return_home": true,
  "geofence": [
    {
      "x": 0,
      "y": 0
    },
    {
      "x": 200,
      "y": 0
    },
    {
      "x": 200,
      "y": 150
    },
    {
      "x": 0,
      "y": 150
    }
  ],
  "keep_outs": [
    {
      "label": "roof",
      "points": [
        {
          "x": 90,
          "y": 95
        },
        {
          "x": 120,
          "y": 95
        },
        {
          "x": 120,
          "y": 125
        },
        {
          "x": 90,
          "y": 125
        }
      ]
    },
    {
      "label": "mast",
      "center": {
        "x": 150,
        "y": 40
      },
      "radius_m": 8
    }
  ],
  "people": [
    {
      "x": 60,
      "y": 140
    }
  ],
  "buffer_m": 5,
  "max_speed_mps": 8,
  "max_altitude_m": 40,
  "min_people_distance_m": 20,
  "payload_kg": 0.5,
  "max_payload_kg": 1,
  "max_mission_min": 20,
  "battery_wh": 90,
  "start_charge_pct": 100,
  "battery_reserve_pct": 30,
  "power_w": 350,
  "derate_pct": 10,
  "wind_mps": 5,
  "max_wind_mps": 8,
  "comm_loss": "return",
  "estop": "tested",
  "simulated": true,
  "include_geometry": false
}
curl -s https://autonomy.md/api/v1/mission_check -H 'content-type: application/json' -d '{"frame":"local","robot_type":"aerial","waypoints":[{"x":10,"y":10,"alt_m":0,"label":"launch"},{"x":10,"y":10,"alt_m":30,"speed_mps":2},{"x":180,"y":20,"alt_m":30},{"x":180,"y":60,"alt_m":30},{"x":20,"y":60,"alt_m":30},{"x":20,"y":110,"alt_m":30},{"x":180,"y":110,"alt_m":45,"hold_s":30}],"cruise_speed_mps":6,"accel_mps2":2,"return_home":true,"geofence":[{"x":0,"y":0},{"x":200,"y":0},{"x":200,"y":150},{"x":0,"y":150}],"keep_outs":[{"label":"roof","points":[{"x":90,"y":95},{"x":120,"y":95},{"x":120,"y":125},{"x":90,"y":125}]},{"label":"mast","center":{"x":150,"y":40},"radius_m":8}],"people":[{"x":60,"y":140}],"buffer_m":5,"max_speed_mps":8,"max_altitude_m":40,"min_people_distance_m":20,"payload_kg":0.5,"max_payload_kg":1,"max_mission_min":20,"battery_wh":90,"start_charge_pct":100,"battery_reserve_pct":30,"power_w":350,"derate_pct":10,"wind_mps":5,"max_wind_mps":8,"comm_loss":"return","estop":"tested","simulated":true,"include_geometry":false}'

An agent that plans a mission should check it the same way every time.

Ask a language model whether a route stays inside a fence and it will eyeball the coordinates. It can miss a leg that cuts across a concave corner, forget the climb in the energy budget, or skip the return from the farthest waypoint. autonomy.md writes your limits into the agent's instructions as plain rules, and gives it tools that do the geometry and arithmetic the same way every time, say what they could not check, and hand the decision back to a human.

  • Geometry, not guesses: ray-cast containment, every path split where it meets a zone edge, and haversine distances.
  • Your limits, in writing: the envelope is numbers and fixed choices, so a shared link can't slip words into the skill.
  • Honest about gaps: every check lists what it did not check: terrain, moving people, sensor error and the law.
  • A human decides: the skill and the tools never approve a mission. They prepare the yes or no.

Use it in your stack

Paste it, install it, or call it.

The skill alone gives an agent the method. The MCP server and API add the tools and your settings. No key, no account.

Paste the prompt into a system prompt or project instructions. Or keep the file in the repo and point AGENTS.md at it.

terminal
curl -fsSL https://autonomy.md/autonomy.md -o AUTONOMY.mdecho "Whenever a task plans, changes, reviews or runs a mission for a physical robot (ground, aerial, arm, marine or humanoid), follow AUTONOMY.md." >> AGENTS.md
Quickest start:claude mcp add --transport http autonomy https://autonomy.md/mcp

Example code

Call it from your own code.

Working calls against the API. The full reference is at /api/v1 and /openapi.json.

Check a mission and fetch the skill with your envelope. No key; nothing is stored.

check.sh
# Check a mission and fetch the skill with your envelope. No key; nothing is stored.curl -s "https://autonomy.md/api/v1/stopping_distance?speed=1.5&decel_mps2=1&reaction_s=0.4&available_m=2.5" | jq .summarycurl -s https://autonomy.md/api/v1/mission_check \  -H 'content-type: application/json' \  -d '{"frame":"local","robot_type":"ground","cruise_speed_mps":1,       "waypoints":[{"x":0,"y":0},{"x":40,"y":0},{"x":40,"y":30}],       "geofence":[{"x":-5,"y":-5},{"x":50,"y":-5},{"x":50,"y":40},{"x":-5,"y":40}],       "keep_outs":[{"label":"dock","center":{"x":20,"y":3},"radius_m":4}],       "buffer_m":2,"max_speed_mps":1.2,"comm_loss":"stop","estop":"tested","simulated":true}' \  | jq '{summary, result, issues, not_checked}'# The skill with your envelope written in (settings notes come back in a header)curl -s "https://autonomy.md/autonomy.md?preset=indoor_ground&max_speed_mps=0.8&min_people_m=2" -D - -o SKILL.md | grep -i x-settings

FAQ

Is autonomy.md a safety system?

No. It is not a safety system, a safety function or a safety assessment, and it is not certified for anything. It never connects to or controls a robot. Safety comes from the robot's own protective functions, a working emergency stop, a qualified person supervising, and following the law, the manufacturer's limits and applicable standards.

If mission_check finds no issues, can my robot run the mission?

Not on that basis. No issues means the numbers you sent fit the limits you sent. The tool knows nothing about the real robot, terrain, obstacles, people who weren't listed, sensor error or the law, and it lists what it did not check. A human must still review the plan and say yes.

Who is responsible if something goes wrong?

The operator. You are responsible for your robots, your agents, your settings and every mission, and for following laws, regulations, permits, aviation and waterway rules, standards and the manufacturer's guidance. See the terms; our liability is limited to US$100.

Are the preset numbers recommended limits?

No. They are examples to replace, not recommended, safe or legal values. Use the manufacturer's limits, your own measurements and local rules, and take the strictest.

Does it know local drone or robot rules?

No. It has no rules, maps, airspace, terrain or weather data. Ask the person you work for which rules apply, and follow them.

Does it work with my robot software?

It doesn't connect to any. Your agent reads the skill and calls the tools. What it sends to the robot's own software (a controller, robot middleware or a flight stack) is up to you, and that software's own limits and failsafes stay in charge.

Is this advice?

No. Robots can injure people and damage property. Nothing here is safety, engineering, legal or regulatory advice. AUTONOMY.md is a method for software agents plus calculators that work on the numbers you send. Results are estimates that may be wrong. Check them yourself, and ask a qualified person when it matters.

Does it name brands or show prices?

No. Settings and tools use generic terms, and autonomy.md shows no prices, rates or other outside data. Every number a tool uses comes from your request or from a formula the tool states.

Can an agent set up its own settings?

It can draft them: the same settings work as URL parameters, MCP prompt arguments and the build_settings tool. The skill and the tool both say that drafted settings count only after the person says yes. Nothing technical stops an agent from ignoring that, so read what it sends you.

Does a tool result mean something is approved?

No. Tools calculate, compare and check. They don’t approve, enforce or certify anything, and they can be wrong.

Can I change everything?

Yes. Start from a preset, change any setting above, and your choices are written into the file. Or edit the Markdown yourself. It’s MIT; keep your copy next to your code.

Do you track anything?

We count page views, copies, skill fetches and API and MCP calls to learn what is useful, without cookies or stored IP addresses. We never record your settings values or what you send to a tool. Details in the terms.

1.0Use at your own risk: information here may be inaccurate or not current, and figures are estimates; autonomy.md is not safety or engineering advice and never controls or moves a robot, is not a safety system, is not certified for any use, and must never be relied on to protect people or property. See the terms.

AUTONOMY.md: Plan, bound, and check robot missions for your AI agent