antioch-platform
Skill1 starsChanged 16 days agoApache-2.0View on GitHub
Use for Antioch projects, CLI and Python client commands, antioch.yaml, sessions, services, builds, source sync, streams, assets, scenarios, suites, run history, and authentication. Explains the platform model and routes to detailed references; native engine code belongs to the Isaac skills and ROS 2 stacks to ros2.
In this repository6 other files it gives its agents.
- agentic-simulationSkill
- antioch-researchSkill
- isaac-lab-3Skill
- isaac-sim-6Skill
- ros2Skill
- scenario-designSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 1 is distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 15
Use the nearest antioch.yaml in the current directory or its parents.
- Very specific: line 58
Keep simulator imports inside functions or TYPE_CHECKING blocks so local discovery works without Isaac.
- Distinctive: line 96
Use agentic simulation for the experiment loop, research for native APIs, Isaac Sim or Isaac Lab for engine code, and [scenario
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Antioch
Antioch runs your Python on cloud GPUs. The local SDK supplies the CLI, Python APIs, and editor types; remote images contain the simulator. No local Isaac installation or GPU is needed. Keep native engine APIs in the project.
Find the project
Use the nearest antioch.yaml in the current directory or its parents.
Preserve its identity, engine, dependencies, and user changes. Run commands
from that root with its Python environment active; launch the agent there too
so the CLI and MCP adapters use the same SDK. Installed --help and SDK
models are the authority for options. antioch version --json reports
component versions and the deployment; ANTIOCH_TRACE=1 explains command timing.
Work within the request. A question needs no compute; an access error does not authorize changing identity. Continue useful local work when remote access is blocked and report which checks remain unrun.
Choose how to work
A project is a source directory with antioch.yaml, Python dependencies, and image recipes. Its services are containers for the simulator and supporting software. Antioch builds their images remotely and saves them for reuse across the organization. A revision freezes the images and manifest. A session runs that revision on temporary compute. Organization identity scopes shared assets and run history; sessions belong to the person using them.
| Need | Start here |
| Run a script in an existing session | antioch service exec -- python src/main.py |
| Iterate without restarting the simulator | Jupyter kernel |
| Record inputs, checks, results, and artifacts | antioch scenario run NAME; scenario design |
| Run a named selection of scenarios and cases | antioch suite run NAME; suite YAML |
antioch session new builds when needed and adds a session. Direct commands
never allocate compute: use --session SESSION_ID, --run RUN_ID for a
session a run used while that session remains live, or your only running session of this project that you
started. Ambiguous selection is refused. Scenario and suite dispatch can
obtain compute or target a session explicitly. Without a target, Antioch reuses sessions it started for your runs, never one you started yourself. Both count toward the same session quota. See sessions for selection, concurrency, and release.
A scenario is a typed Python evaluation; a case supplies parameter
values. A suite selects scenarios and cases in YAML. Each execution
creates run records and uploaded evidence that survive the session.
A plain script creates no run history unless it calls a scenario;
antioch.Telemetry saves and streams its Rerun data without one.
Keep code and compute in sync
Image or dependency changes need a new session. Source edits use the
manifest's sync mappings to /workspace/project: scripts, shells, and
notebooks copy local files before starting and keep syncing while attached. Submitted runs
carry a frozen source bundle and apply it when they start; reruns reuse the
saved images and bundle. A command can overwrite files even while a run is
executing, so avoid concurrent edits when preserving its inputs matters.
Keep simulator imports inside functions or TYPE_CHECKING blocks so local
discovery works without Isaac. Closing Python or an MCP connection does not
release compute; save remote outputs before releasing a session you own.
Share results
Share a run by its console link. antioch scenario show SCENARIO_RUN_ID and
antioch suite show SUITE_RUN_ID print it on the console row, with the
organization it belongs to. The console serves only these record links:
| Share | Link |
| A scenario run | <console>/scenarios/<scenario_run_id> |
| A suite run | <console>/suites/<suite_run_id> |
| A project's scenario runs | <console>/scenarios?project=<project_id> |
| A project's suite runs | <console>/suites?projectFilter=<project_id> |
There is no project page. Never compose any other console path.
Capability guides
Load the guide for the operation you need:
| Task | Guide |
init, setup, version: install tools, create projects, inspect versions, change images | Environment |
| Services, resources, routes, source mappings | Manifest |
session, service, jupyter: inspect/use/release compute, sync files, forward ports, open streams | Sessions |
scenario: collect, dispatch, filter, download, cancel, delete, or rerun evaluations | Scenarios |
suite: collect, run, summarize, compare, cancel, delete, or repeat groups | Suites |
asset: find, load, publish, verify, or repair reusable content | Assets |
auth, including auth registry: identity and image access | Authentication |
| ROS bridge and cross-service traffic | ROS 2 |
| ROS 2 nodes, tf2, Nav2, MoveIt 2, ros2_control against the simulator | ROS 2 |
| Script startup, native state, and rendering configuration | Simulation code |
| Automate sessions, commands, submissions, and history in Python | Python client |
| Diagnose a failed workflow | Troubleshooting |
Use agentic simulation for the experiment loop, research for native APIs, Isaac Sim or Isaac Lab for engine code, and scenario design for measured verdicts and telemetry.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.