← Explanation

Skills as Runtime, Not Bundle

CUST/OS does not ship skills inside its APK. The plugin you install knows how to load and run skills, but it has zero knowledge of what skills exist until it scans /sdcard/atak/custos/skills/ at startup.

What this means

  1. The APK ships a runtime: a Lua sandbox, a tool registry, an inference router, an approval gate.
  2. The APK ships no skills.
  3. Skills are directories of SKILL.md + .lua files in an operator-writable location on disk.
  4. Adding a skill means dropping a directory. Editing one means saving a file.
  5. The runtime hot-reloads on every change.

The starter skills live in a separate open-source repo — github.com/nimbusxr/custos — and get pushed to /sdcard/atak/custos/skills/ by the kit's install.sh. They are not baked into the APK. You can wipe them, replace them, or augment them without touching the plugin.

Why this is the right call for tactical AI

Capability changes should not need a release cycle

Tactical needs change at mission cadence, not release cadence. A fix to how a skill places markers, a new SOP for casualty reports, a tweak to how illumination is calculated -- these are operator concerns, not engineering concerns. Forcing them through APK signing, distribution, and re-install is the wrong shape.

By making skills runtime artifacts, CUST/OS lets the operator iterate at the speed of their job. The in-app editor closes the loop entirely: edit, save, ask the agent, see the result.

The bill of materials is on disk, not in code

If you want to know exactly what a CUST/OS install can do, the answer is ls /sdcard/atak/custos/skills/. There is no hidden code path, no feature flag. The capability surface is a directory listing.

This matters for security review, for after-action audit, for handover when one operator passes the device to another.

Skills can ship without the plugin

A skill written for one operator's mission can be shared with another by sending a directory. No build, no signing, no release. Just push it to /sdcard/atak/custos/skills/ and it is live.

This makes skills the right granularity for distribution: operator-to-operator, mission-to-mission, classification level to classification level.

Runtime sandbox over compile-time trust

Skills are Lua, not native code. They run inside a sandbox with:

  • Java package allowlist
  • Method denylist
  • Filesystem path scoping
  • Per-execution instruction limits
  • Concurrency limits
  • PKI signing hook (WIP — the verifier exists but is not yet called from the skill loader, so security.requirePki is a declared intent rather than enforced behavior in this release)

A Lua skill has the trust level of the runtime that hosts it, which can deny unsafe operations regardless of where the skill came from. Skills from different sources (operator-authored, vendor-provided, community) can coexist with different trust levels enforced by the runtime.

The agent can write skills

The custos.skill_creator skill includes tools that let the agent author new skills at runtime. The agent reads the SKILL.md format, introspects ATAK Java APIs, writes a Lua file, and the runtime hot-reloads it. The new tool is callable on the next turn.

The cost

  • Performance -- Lua is slower than compiled JVM code. Most skills do not care, but tight loops do.
  • Tooling -- there is no compile-time type check on Lua. LDoc annotations and runtime validation compensate.
  • Discovery -- the agent must be told what skills exist. The skill selector (keyword + semantic matching) picks 1-3 relevant skills per turn.

Distribution patterns

Treating skills as data rather than code opens up distribution models:

  • Vendor-supplied skill packs -- intended to be signed with a publisher key and verified via security.requirePki (WIP — signature verification path is not yet wired into the loader)
  • Mission-specific skill loads -- the same plugin can run a different skill set for different missions by changing the directory contents at deploy time
  • Per-classification skill loads -- operators with different clearance levels can have different skills available without different APKs
  • Community skill libraries -- operators can share skills as zip files, no build chain needed

See also