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/action-feasibility-enginegit 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/action-feasibility-engine)<a href="https://agentmods.dev/agents/pome223/missionos/action-feasibility-engine"><img src="https://agentmods.dev/badge/agents/pome223/missionos/action-feasibility-engine.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.1 | $0.00000 | $0.02586 |
| Opus 5 | $0.00000 | $0.01293 |
| Sonnet 5 | $0.00000 | $0.00517 |
| Haiku 4.5 | $0.00000 | $0.00259 |
Grade A, and why
action-feasibility-engine 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 today.
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 — 246 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Action Feasibility Engine contract
This contract describes the deterministic multi-hazard verification boundary used by PX4 recovery proposals. It is a maintainer implementation contract, not a claim that the current simulation models are physically calibrated.
LLM judges.
Human approves.
Rules constrain.
Executor acts.
Verifier checks.
Repair loops.
The engine only constrains a proposed action. It never creates approval, dispatch authority, physical execution, progress, or completion.
Core contract and migration
missionos-core publishes the backend-neutral v1 API:
missionos_core_hazard_state.v1missionos_core_action_candidate.v1missionos_core_action_feasibility.v1missionos_core_action_revalidation.v1
Core owns observed-versus-derived fact semantics, source references and
freshness, opaque observation cursors, policy/model binding, uncertainty,
tri-state aggregation, and authority-free revalidation artifacts. A cursor's
payload is intentionally opaque. A backend adapter must implement a named
comparison contract and return before, equal, after, or incomparable;
Core never assumes that a field named sample_index is globally ordered.
Geometry, terrain, energy, and vehicle-performance calculations implement the
FeasibilityVerifierExtension protocol. An extension returns measurements,
assumptions, and blocked/unverified reasons. It cannot upgrade missing Core
evidence or create approval, dispatch, execution, progress, or completion.
The existing runtime v1 schemas below remain readable during migration. They
are not aliases for the Core schemas, and conversion must be explicit in a
backend adapter. Schema versions are additive within one major version.
Removing or changing field meaning requires a new major schema, a converter,
and corpus coverage for both the last supported input and the new output.
Unknown major versions fail closed as unverified.
The #100 corpus now runs through the Core conformance runner while retaining the existing backend calculation as its adapter. That proves the common invariants are executable; it does not yet prove the production recovery path uses Core. Production migration and removal of the shadow path belong to #102.
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.
- today Changed · +20 lines 41e428fa3213
- 5d ago First seen · 226 lines · 0 tokens per session scan A a10cec19d677
action-feasibility-engine 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 2,586 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
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).
antenna-engineer
Reasons from gain–directivity–efficiency, Chu–Harrington bandwidth limits, and array factor through HFSS/CST/FEKO synthesis, IEEE 149-2021 NF/FF/CATR metrology, CTIA TRP/TIS/ECC OTA, and Friis link budgets while treating ground-plane truncation, active impedance in arrays, range ripple, and S₁₁≠pattern conflation as…