@h2loop/uav 1.0.0

package/commands/uav-batch-report.md

@@ -0,0 +1,20 @@
+---
+description: Analyze a directory of flights and produce one ranked anomaly report.
+subtask: true
+---
+Analyze every .bin under $1 (include .tlog/.ulog if present). For each log, call
+`uav_analyze` directly — the tool already keeps the decode, the ~1,117-param load, and the
+per-table SQL out of this window and returns only the rendered report, so no per-log subagent
+is needed. Run the logs as a fan-out (independent per file) and collect each report. One log
+that fails to decode (e.g. pymavlink missing for a .ulog) becomes a decode-error row; never
+abort the batch on one bad file. Only spawn `uav-investigate` for a specific log if a finding
+needs an open-ended drill-down beyond the standard checks.
+
+Collect the FAIL findings from each flight. Produce ONE report, sorties ranked
+worst-severity-first (CRITICAL > HIGH > clean). For every FAIL, list its check, measured
+value, the `threshold_used` it breached, and the guardrail source it cites (datasheet /
+rule-of-thumb / tuned / customer-stated) — the deterministic checks decide the verdict,
+you only rank and narrate. Collapse clean sorties to a count.
+
+End with a fleet summary line: `N sorties · X CRITICAL · Y HIGH · Z clean · E errored`.
+If a `.docx` deliverable is requested, the harness exports the Markdown via Pandoc.

package/commands/uav-compare.md

@@ -0,0 +1,14 @@
+---
+description: Compare two flights of one airframe and narrate the regression.
+agent: uav-compare
+subtask: true
+---
+Compare $1 and $2 (same airframe): fetch the server-side param + finding diff and narrate
+what changed and why.
+
+For each shifted finding, give its measured value on both flights, the direction and
+magnitude of the change, and the guardrail it relates to (citing the bound's source).
+Note the regime of each flight; if it is ambiguous, ask before attributing a shift to it.
+In the tuning phase the reference is the last flight; for a production vehicle it is the
+fixed guardrail — state which you are using. Rank the shifts by significance and leave the
+verdict to the engineer. See the `uav` skill's compare reference for the narration shape.

package/commands/uav-preflight.md

@@ -0,0 +1,12 @@
+---
+description: Decode a flight and produce the ranked anomaly report.
+---
+Analyze $1 with uav_analyze, then summarize the ranked anomalies and any param changes
+vs the prior flight for this airframe.
+
+For each anomaly, cite the guardrail bound it breached and that bound's source
+(OEM datasheet / rule-of-thumb / per-airframe tuned). If the log decoded only partially,
+say so at the top and caveat every check whose data window was cut. Surface and rank the
+anomalies; leave the final verdict to the engineer. uav_analyze already keeps the decode and
+per-table SQL out of this thread, so call it directly; only spawn uav-investigate if an
+anomaly needs an open-ended drill-down.

package/commands/uav-save-finding.md

@@ -0,0 +1,25 @@
+---
+description: Persist the grounded finding(s) from this investigation to the flight (calls uav_finding op:add).
+---
+Persist the confirmed finding(s) established in THIS conversation to the flight's record now.
+Optional arguments: $ARGUMENTS may name the flight_id and/or which finding to save; if absent,
+use the flight currently under analysis and the grounded conclusions you just reached.
+
+This is an explicit SAVE action — do NOT re-investigate, do NOT merely summarise. Do exactly:
+
+1. Identify the flight_id (from $ARGUMENTS or the flight you just analysed). If you cannot tell
+   which flight, ask for the flight_id and stop.
+2. Call `uav_finding op:"list" flight_id:<id>` to see what is already stored.
+3. For EACH conclusion from this investigation that (a) cleared an ABSOLUTE grounded bound —
+   not "N× the others" / relative-to-peers — and (b) is NOT already represented above (same
+   root cause, even if worded differently), call `uav_finding op:"add"` with:
+   - title: a short label
+   - severity: OK | HIGH | CRITICAL
+   - value + threshold_used: the measured metric and the absolute bound it breached
+   - detail: the evidence + the bound's source (datasheet / rule-of-thumb / tuned / customer)
+   If a conclusion supersedes a stored agent finding, pass supersedes_id.
+4. Report back the id of every finding you stored, plus any you skipped — for each skip say WHY
+   (already stored, or relative-only/within absolute tolerance).
+
+If there is no grounded, absolute-bound-clearing finding to save, say so plainly and store
+nothing — never invent a finding, and never persist a relative-only observation as a fault.

package/commands/uav-tune.md

@@ -0,0 +1,12 @@
+---
+description: Recommend harmonic-notch params (INS_HNTCH_*) from one flight's gyro/VIBE spectrum.
+---
+Run `uav_tune` on $1 to get the dominant gyro/VIBE peak and the recommended
+`INS_HNTCH_ENABLE/FREQ/BW/REF/HMNCS`. Consult the `uav` skill's tuning reference for how to
+read the spectrum.
+
+Return: the recommended param deltas, the spectral evidence (dominant peak Hz, sample rate,
+axis), and each param's verified range from apm.pdef.xml — never raw FFT bins, never a param
+or value out of range. Recommend only; pushing params over MAVLink and tagging the retest is
+a separate gated action (the param link with `--allow-param-write`) — never imply you applied
+them.