Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add agents/pome223/missionos/turtlebot3-nav2-executiongit clone --depth 1 https://github.com/pome223/missionosWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/pome223/missionos/turtlebot3-nav2-execution)<a href="https://agentmods.dev/agents/pome223/missionos/turtlebot3-nav2-execution"><img src="https://agentmods.dev/badge/agents/pome223/missionos/turtlebot3-nav2-execution.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00000 | $0.00605 |
| Opus 5 | $0.00000 | $0.00302 |
| Sonnet 5 | $0.00000 | $0.00121 |
| Haiku 4.5 | $0.00000 | $0.00060 |
Grade A, and why
turtlebot3-nav2-execution scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 5d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 76 lines — stays where its author put it; the contents beside it link to each section on GitHub.
TurtleBot3 Nav2 Execution Boundary
src/runtime/turtlebot3_nav2_execution.py owns the bounded executor-facing
portion of the TurtleBot3 workflow. It is downstream of proposal, compilation,
rules validation, and human approval.
The module may:
- bind an already concrete
Nav2GoalPoseto an existing approval reference - send that goal through the opt-in ROS2/Nav2 bridge
- send a harness-authorized
cancel_goalrequest - project bridge state, odometry, obstacle, and sidecar observations
- return blocked adapter evidence when the bridge receipt is unavailable
It must not:
- generate or select a Recovery proposal
- mint, refresh, or broaden approval
- change the compiled goal
- infer motion from an ACK
- infer a stop from a cancel ACK
- infer completion from motion or status text alone
- decide that the remaining route may resume
- claim payload delivery or physical execution
Inputs
dispatch_nav2_goal receives individual authority and execution fields rather
than the full mission proposal:
- stable proposal identifier
- approval actor and approval artifact reference
- concrete Nav2 goal
- dispatch timestamp and bounded action suffix
- optional raw-log reference
- initial-pose and simulator-fault controls
This keeps the executor from interpreting a larger proposal artifact or creating authority from it. The mission coordinator remains responsible for validating the proposal/approval/checkpoint chain before calling this boundary.
Observation semantics
The bridge receipt keeps these facts separate:
dispatch_request_sent: the executor request crossed the bridge boundary- ACK fields: Nav2 accepted or rejected a request
robot_motion_observed: source-backed odometry changed- obstacle fields: the bridge or its state/progress result reported the fact
completion_claimed: the hardware adapter's Nav2-success plus motion contract
When the telemetry sidecar is configured, its time-window correlation is projected separately. An unreadable or mismatched sidecar blocks the correlated motion claim; it does not fall back to an unverified success.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 5d ago First seen · 76 lines · 0 tokens per session scan A 52f289022ed1
turtlebot3-nav2-execution is an agent published in the GitHub repository pome223/missionos (2 stars, last pushed today), licensed Apache-2.0. It costs nothing until one of its globs matches a file; then it loads 605 tokens. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other agents, from other repositories
homelab-architect
Designs home and small-lab network plans from hardware inventory, goals, and operator experience level, with safe staged changes and rollback guidance.
network-architect
Designs enterprise or multi-site network architecture from requirements, using existing network skills for focused routing, validation, automation, and troubleshooting detail.
network-config-reviewer
Reviews router and switch configurations for security, correctness, stale references, risky change-window commands, and missing operational guardrails.
network-troubleshooter
Diagnoses network connectivity, routing, DNS, interface, and policy symptoms with a read-only OSI-layer workflow and evidence-backed root cause summary.
agent_types
This document describes how the unified three-layer Device Agent architecture is implemented across different platforms. While the core framework (State, Processor, Command layers) remains consistent, each platform implements specialized agents optimized for their native control mechanisms and hierarchies.…
server_client_architecture
Device agents in UFO are partitioned into server and client components, separating high-level orchestration from low-level execution. This architecture enables safe, scalable, and flexible task execution across heterogeneous devices through the Agent Interaction Protocol (AIP).