tactical-ai-autonomy-developer

Original：🇺🇸 English

Translated

Guides edge and tactical autonomous systems—perception-planning-control under latency and safety constraints; behavior trees/state machines vs learned policies; human-on-the-loop; geofencing, no-strike rules, mission abort; sim and field testing; ROS2/middleware patterns; sensor fusion; degraded modes; autonomy audit logging. Use for UAS/autonomous stacks, safety rules, HITL, sim-to-field validation, fail-safe—not LLM products (ai-engineer), LLM red team (ai-redteam), safeguard serving (ml-infrastructure-engineer-safeguards), governance only (ai-risk-governance), MCU firmware without autonomy (embedded-real-time-software-engineer), plant PLC/DCS (control-software-developer), HIL security bench (hardware-in-the-loop-security-tester).

2installs

Sourcedaemon-blockint-tech/agentic-enteprises-skill

Added on2026-05-20

NPX Install

npx skill4agent add daemon-blockint-tech/agentic-enteprises-skill tactical-ai-autonomy-developer

SKILL.md Content

View Translation Comparison →

Tactical AI & Autonomy Developer

When to Use

Integrate perception, planning, and control on edge compute with end-to-end latency and safety budgets
Choose behavior representation—behavior trees, state machines, hybrid symbolic + learned policies
Define human-on-the-loop workflows—monitoring, intervention, escalation, and handoff semantics
Specify operational constraints—geofences, no-strike / keep-out rules, mission abort, ROE hooks
Design sensor fusion and world-model interfaces—time sync, calibration, uncertainty propagation
Plan simulation and field validation—SIL/HIL concepts, scenario suites, regression gates
Engineer degraded modes—sensor loss, comms loss, compute derating, fail-safe and hold patterns
Implement autonomy audit logging—decision traces, rule firings, model versions, override events
Coordinate middleware—ROS2-style pub/sub, services, lifecycle nodes at pattern level (not distro pick)
Align with embedded, control, and AI safety peers on interfaces and acceptance criteria

When NOT to Use

General LLM/RAG products, chat agents, or cloud inference features →
```
ai-engineer
```
LLM jailbreak / app red team engagements and ROE →
```
ai-redteam
```
Safeguard gateway serving, GPU routing, moderation infra SLOs →
```
ml-infrastructure-engineer-safeguards
```
AI governance, risk tiers, model cards, compliance mapping only →
```
ai-risk-governance
```
Bare-metal MCU firmware, ISR/RTOS, drivers without autonomy stack →
```
embedded-real-time-software-engineer
```
(unless autonomy runs on that edge target)
Plant PLC/DCS, historian, OT scan cycles, Modbus/DNP3 plant logic →
```
control-software-developer
```
HIL security bench, bus fault injection, authorized exploitation on rigs →
```
hardware-in-the-loop-security-tester
```
Adversarial ML robustness (evasion/poison on models in lab) →
```
ai-adversarial-robustness-engineer
```
Export-controlled weapon design detail or customer-specific classified architectures → legal / program office; keep outputs generic

Related skills

Need	Skill
Production LLM/RAG and agent features	`ai-engineer`
LLM red team and jailbreak policy	`ai-redteam`
Safeguard serving and inference platform	`ml-infrastructure-engineer-safeguards`
Governance, risk tiers, model cards	`ai-risk-governance`
MCU/RTOS, drivers, WCET on chip	`embedded-real-time-software-engineer`
PLC/DCS, OT protocols, plant control apps	`control-software-developer`
HIL security assessment on benches	`hardware-in-the-loop-security-tester`
Adversarial robustness on ML models	`ai-adversarial-robustness-engineer`

Core Workflows

1. Scope and platform constraints

Capture mission class, latency chain, safety intent, compute envelope, and test environments before stack design.

See
references/tactical_ai_autonomy_scope.md
.

2. Perception–planning–control stack

Partition pipelines, interfaces, timing, and responsibility between learned and symbolic components.

See
references/perception_planning_control_stack.md
.

3. Safety, rules, and human oversight

Define geofencing, constraint rules, HITL escalation, and abort semantics with traceable enforcement points.

See
references/safety_human_oversight_and_rules.md
.

4. Simulation and validation

Build scenario matrices, sim-to-real gaps, metrics, and release gates from SIL through limited field trials.

See
references/simulation_testing_and_validation.md
.

5. Degraded modes and fail-safe

Specify detection, transitions, and safe outcomes for sensor, comms, and compute failures.

See
references/degraded_modes_and_fail_safe.md
.

6. Deployment, logging, and audit

Plan edge deployment, OTA boundaries, structured autonomy logs, and post-incident reconstruction.

See
references/deployment_logging_and_audit.md
.

Outputs

Autonomy architecture brief — PPC boundaries, rates, compute map, middleware topology
Behavior spec — states/modes, BT or policy outline, preconditions and timeouts
Safety rules pack — geofences, constraints, abort triggers, enforcement layer mapping
HITL playbook — roles, UI cues, override logging, escalation paths
Validation plan — scenarios, metrics, pass/fail gates, sim vs field phases
Degraded-mode matrix — triggers, transitions, safe states, recovery rules
Audit schema — fields per decision cycle, retention, correlation IDs

Principles

Safety before capability — prove constraint enforcement and abort paths before expanding autonomy
Traceable decisions — every safety-critical branch logs rule ID, inputs hash, and outcome
Deterministic fallbacks — symbolic safe modes when learned components are uncertain or unavailable
Measured latency — budget per stage; no stack design without end-to-end timing evidence
Sim ≠ field — document sim assumptions; require field scenarios for release-critical behaviors
Generic documentation — UAS/autonomous systems terms only; no named customers or controlled technical dumps