app-deployer
Deploy and manage user applications as managed systemd services
Black box flight recorder for the server. Capture system state snapshots for forensic analysis after incidents. Continuous telemetry ring buffer.
$ npx -y skills add bolivian-peru/os-moda --skill flight-recorder --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/flight-recorderContext preview
The summary Claude sees to decide when to auto-load this skill.
Black box flight recorder for the server. Capture system state snapshots for forensic analysis after incidents. Continuous telemetry ring buffer.
name: flight-recorder description: > Black box flight recorder for the server. Capture system state snapshots for forensic analysis after incidents. Continuous telemetry ring buffer. tools: - system_health - shell_exec - journal_logs - event_log - memory_store - memory_recall activation: auto
Continuous state capture for post-incident forensics.
Capture a lightweight system snapshot:
system_health()
shell_exec({ command: "ps aux --sort=-%mem | head -10" })
shell_exec({ command: "ss -s" }) # connection summaryStore as a compact memory entry:
memory_store({
summary: "Flight recorder: CPU 12%, RAM 4.1G, load 0.3, 142 connections",
detail: "Top processes: postgres 1.2G, openclaw 380M, node 210M. Net: 142 established, 12 listening.",
category: "system.config",
tags: "flight-recorder,snapshot,telemetry"
})When investigating "what happened at 3 AM":
memory_recall({ query: "flight-recorder snapshot", timeframe: "24h", max_results: 50 })journal_logs({ since: "2 hours ago", priority: "warning", lines: 100 })event_log({ limit: 50 })Present a forensic timeline:
Incident Report — Server Crash at 03:12 UTC Timeline: 02:00 Flight recorder: CPU 15%, RAM 5.2G (normal) 02:30 Flight recorder: CPU 23%, RAM 5.8G (rising) 02:47 Flight recorder: CPU 89%, RAM 7.1G (critical) 02:47 OOM killer triggered (killed: postgres worker) 02:48 PostgreSQL: 3 connections terminated 02:49 App health check failed → Caddy returned 502 02:51 systemd restarted PostgreSQL automatically 02:52 All services recovered 02:55 Flight recorder: CPU 12%, RAM 4.1G (normal) Root cause: PostgreSQL autovacuum on users table (12M rows) during traffic spike. Memory peaked at 7.4/7.6 GB. Recommendations: 1. Add 2GB swap (NixOS config change) 2. Schedule autovacuum for low-traffic hours 3. Consider 16GB RAM plan ($6/mo more on Hetzner) All data sourced from flight recorder snapshots, journal logs, and audit ledger. Chain verified.
Flight recorder snapshots are compact (~200 bytes each). At 5-minute intervals: 288/day, ~56KB/day, ~1.7MB/month. Keep 30 days of snapshots. Memory recall handles the rest.
An operating system built for AI agents — talk to your NixOS server instead of SSH-ing in. Typed, audited tool access with atomic rollback on every change. Research-grade; run it on a disposable box, not production.
Deploy and manage user applications as managed systemd services
Deploy and manage AI agent workloads with GPU checks, API key management, and health monitoring
Detect configuration drift — manual changes that exist outside NixOS management. Offer to bring imperative changes into…
Manage files and directories. List, find, search contents, read, write, move, copy, delete, permissions. Present directory…
NixOS generation-aware debugging and time-travel. Correlate system state changes with application failures. Query "what changed…
Generate a concise daily infrastructure briefing. Covers: service health, resource usage, security events, overnight incidents,…