daqifi-loop

name

daqifi-loop

description

Start the autonomous daqifi-desktop work loop — a recurring cron that shepherds the user's open PRs through Qodo/CI and continuously works the backlog, opening one validated PR after another (up to a concurrency cap), picking up the next ticket after each, and doing self-directed improvements when the defined backlog is dry. NEVER merges. Use when the user wants to (re)start autonomous daqifi-desktop work while away, e.g. "start the loop", "resume the autonomous loop", "keep working on desktop while I'm out", "/daqifi-loop".

DAQiFi autonomous work loop (desktop)

Sets up and kicks off a recurring cron loop that does productive, non-destructive work on this repo while the user is away, handing each result back for their review. It never merges — the user merges when they return (and can authorize a merge run explicitly).

This skill is the generic DAQiFi loop with a single REPO PROFILE block (below) that carries everything repo-specific. To retarget another .NET DAQiFi repo (e.g. daqifi-core), copy this file and change only that block. The body self-locates the repo (git rev-parse) and auto-discovers the board, so the file is machine-agnostic — but this repo's test gate only runs on Windows (its net*-windows test projects abort at run time on macOS; see the OS note in the profile), so the loop should be run on Windows.

REPO PROFILE — the only repo-specific facts

• Repo slug (gh): daqifi/daqifi-desktop
• Default branch: main
• Repo kind: .NET WPF desktop app (Windows). A thin wrapper being migrated over Daqifi.Core.
• Build/test gate (the unit gate — this is what every fire must pass): dotnet build, then the fast unit gate per CLAUDE.md — dotnet test --filter "TestCategory!=Ui&FullyQualifiedName!~WindowsFirewallWrapperTests". Do NOT run the whole solution's dotnet test unfiltered: it pulls in Daqifi.Desktop.UITest (FlaUI GUI automation, device-dependent) and the firewall-wrapper tests (need admin), which hang or fail in an unattended loop.
• App-launch smoke gate (RUN EVERY FIRE that builds or changes code): dotnet test Daqifi.Desktop.UITest --filter "FullyQualifiedName~Launch_MainWindowAppears_AndIsResponsive" — launches the REAL WPF app in DAQIFI_TEST_MODE (no UAC, no modal prompts) via FlaUI and asserts the main window appears and is responsive. This is the "did our change break the app booting?" check the unit gate cannot give. It is device-free (the smoke test does not connect hardware), so it runs whether or not a board is attached. Requires an interactive, unlocked Windows session — it launches a real GUI, so it cannot run on a locked workstation / disconnected RDP / headless. If it can't launch (times out or errors on session grounds), log "GUI smoke skipped — no interactive session" and proceed on the unit gate; NEVER fail the fire for this. Run it after the unit gate passes and before pushing any commit / opening any PR. (It briefly pops a window and steals focus — fine while the user is away.)
• Device bench (CONDITIONAL — only when a board is attached AND the change has device-observable behavior): run the matching RequiresDevice UITest scenario(s) for the changed area (see the scenario table in Daqifi.Desktop.UITest/README.md — e.g. AddDeviceTests = connect, LoggingSessionTests = streaming/live-plot, ConfigureLoggingTests = frequency/channels, DigitalOutputTests/PwmOutputTests = DIO/PWM), or a genuinely headless Daqifi.Core path. Run ONLY the scenario(s) relevant to the change — never the whole dotnet test Daqifi.Desktop.UITest suite in the loop. Never ad-hoc / hand-script the WPF UI — validation goes through the FlaUI UITest scenarios or a headless Core path only. Same interactive-session requirement as the smoke gate. If no board is discovered, or the change has no device-observable behavior, or there's no interactive session → skip and note the reason; never a failure. Read the README's DAQIFI_TEST_MODE + gotchas sections before running.
• Post bench results on the PR (mirror to the issue when useful): after opening or updating a PR, gh pr comment a short BENCH RESULTS block — the unit-gate result, the launch-smoke result, and either the device-bench scenario(s) + pass/fail or the explicit skip reason (no board / no interactive session / not device-relevant). Factual and short. Screenshot/image upload is OUT OF SCOPE: GitHub exposes no API to attach images to a comment (tracked upstream — cli/cli #12960, community #28219), so the loop posts text only. Do NOT commit screenshots to the repo to work around this.
• Bench serialization (one GUI + one board): only one process may drive the app/board at a time. Loop fires are already serialized (one awaited subagent per fire), so the every-fire launch smoke is safe. But before the device-bench step, guard against colliding with the user's own manual use: if a non-test DAQiFi instance is already running or the board is already claimed, skip the device bench this fire and note it rather than fighting for the port.
• Board discovery (do NOT hardcode a port): each fire, discover the connected board dynamically via the app's/Core's serial discovery (a headless discovery entry point if the repo exposes one, else Daqifi.Core's SerialDeviceFinder / the Core example CLI --discover). Capture whatever serial/COM port it reports. If discovery finds nothing → skip the device-bench step this fire (the launch smoke and the loop still run).
• Destructive-op denylist (never do these unattended): no firmware/WiFi-module flash, no --sd-format/--sd-delete, no device reboot/power-cycle, no destructive SD ops; skip live SD:GET while heap is low. On Windows, HID/firmware paths DO work (unlike macOS) — that makes them tempting and MORE dangerous to trigger; stay read/stream-only.
• OS / PATH note: run the loop on Windows — the unit gate's net*-windows test projects only execute on Windows (on macOS they compile but dotnet test aborts at run time, exit 1; full validation there needs Windows or the windows-latest CI). Do NOT prepend /opt/homebrew/bin (macOS-only). Just ensure dotnet, git, and gh resolve on PATH.

Optional args

• Interval (e.g. 20m, 1h, 10m) — cadence. Default 10m when the backlog looks active; suggest longer once things saturate. Convert to cron: Nm→*/N * * * * (N≤59), 1h→13 * * * *, Nh→13 */N * * *.
• A scope note (e.g. "bug-fixes only", "no new features", "also do X", "up to 5 open PRs", "include the god-class decompose") — fold verbatim into the loop prompt. A cap phrase overrides the default concurrency cap of 5.

The loop keeps moving through the backlog — it shepherds open PRs, keeps starting the next ticket after each, and when no defined ticket is eligible it does self-directed improvements (researches → files a tracked issue → works it). It only idles at true saturation, and it still never merges.

Steps

1. Survey state and report a short (≤6 line) summary to the user.

   • Repo root: git rev-parse --show-toplevel. If the gh remote isn't daqifi/daqifi-desktop (the REPO PROFILE slug), tell the user this skill instance targets desktop and stop.
   • Board: discover dynamically per the REPO PROFILE (do not hardcode). Note the discovered port, or "no board" if none — the loop still runs, just skips bench steps.
   • My open PRs + status: gh pr list --repo daqifi/daqifi-desktop --state open --author @me --json number,title; for each, unresolved qodo threads + CI.
   • Backlog: gh issue list --repo daqifi/daqifi-desktop --state open (candidate work to implement).

2. Create the recurring loop with CronCreate (recurring: true, the cron expression from the interval). Pass exactly the prompt in the block below, substituting <REPO_ROOT> (from step 1) and appending any scope note. (CronCreate/CronDelete are deferred tools — load them via ToolSearch first.)

   DISPATCHER — autonomous daqifi-desktop work loop (user away; repo = <REPO_ROOT>; board = auto-discovered per fire). To keep this long-lived session's context small over many hours, do NOT do the work inline. Each fire: spawn exactly ONE subagent with the Agent tool (subagent_type: general-purpose, run_in_background: false) and pass it the TASK below verbatim as its prompt. Wait for it, then relay ONLY its short summary to the user and end the turn. Do NOT run git/gh/dotnet/bench commands yourself — that heavy I/O (builds, full test runs, diffs, Qodo comment bodies) belongs in the subagent's own context, which is discarded when it returns, so only a few lines per fire reach this session. If the subagent errors or returns nothing, say so in one line and end — the next fire re-triages.

   ══════════ TASK (the subagent's prompt) ══════════ You are ONE fire of the autonomous daqifi-desktop work loop (user away). Repo: <REPO_ROOT> (gh slug daqifi/daqifi-desktop, default branch main). Run on Windows — the test gate's net*-windows projects only execute there; ensure dotnet/git/gh are on PATH (do NOT prepend /opt/homebrew/bin). The unit gate for every fire is dotnet test --filter "TestCategory!=Ui&FullyQualifiedName!~WindowsFirewallWrapperTests" (per CLAUDE.md) — NEVER the unfiltered solution dotnet test, which runs the FlaUI GUI/UITest + admin firewall tests and will hang unattended. Your job is CONTINUOUS PROGRESS: shepherd open PRs AND keep implementing work, one unit after another. Do ONE focused unit of work this fire, in the priority order below; the NEXT fire picks up the next unit. Read <REPO_ROOT>/SESSION_LOG.md first for continuity — if it doesn't exist yet, create it with a one-line header (# daqifi-desktop loop session log + repo root) before reading/appending — and re-derive live state from gh (don't trust stale notes). Board is NOT hardcoded — discover it this fire via Core/serial discovery; if none is found, skip the device-bench step (the launch smoke still runs).

   GATES (apply on EVERY fire that builds or changes code — priorities 1, 3, 4, 5): after dotnet build + the unit gate pass, and BEFORE pushing a commit or opening/updating a PR, ALSO run the app-launch smoke gate — dotnet test Daqifi.Desktop.UITest --filter "FullyQualifiedName~Launch_MainWindowAppears_AndIsResponsive" — to prove the app still boots after your change. It is device-free but needs an interactive unlocked Windows session; if it can't launch, log "GUI smoke skipped — no interactive session" and proceed on the unit gate — NEVER fail the fire for it. When a board IS attached AND the change has device-observable behavior, ALSO run the matching RequiresDevice UITest scenario(s) for the changed area (device bench — the relevant scenario(s) ONLY, never the whole UI suite; see the UITest README scenario table); skip+note if no board / not device-relevant / no interactive session / board already claimed by a non-test instance. Then post a short BENCH RESULTS comment on the PR via gh pr comment (unit gate + launch smoke + device-bench result-or-skip-reason). TEXT ONLY — no screenshots (GitHub has no image-attach API). NEVER ad-hoc script the WPF UI; validate only through the UITest scenarios or a headless Core path.

   1. PENDING QODO on my open PRs: git fetch; gh pr list --repo daqifi/daqifi-desktop --state open --author @me. For each, check for NEW unresolved qodo-code-review review threads. Valid finding → fix on the PR branch (build + affected tests + the unit gate green: dotnet test --filter "TestCategory!=Ui&FullyQualifiedName!~WindowsFirewallWrapperTests" + the GATES launch smoke), commit, push, re-comment /agentic_review, and update the BENCH RESULTS comment. False positive → reply explaining why + resolve the thread. NEVER merge.
   2. READY PRs: a PR just went Qodo-clean (0 unresolved) + CI green and isn't noted → add a one-line "ready for review" note.
   3. CI REGRESSION on a previously-green PR: inspect the failing test. Unrelated flake → gh run rerun --failed, don't modify the PR. Real regression from my change → fix it.
   4. NEXT DEFINED TICKET — whenever this fire has no actionable item in 1–3 AND you're under the concurrency cap. An open PR merely awaiting the user's review does NOT block this: start the next ticket in parallel. Pick the next UNCLAIMED open issue (no open PR, no pushed branch), preferring bugs, then small validatable features. SKIP only: breaking-API tickets (unless the user opted in), pure-investigation tickets with no code deliverable, and tickets that can only be validated via destructive/disruptive board ops or GUI-only manual steps. If a candidate is infeasible/risky on inspection, note why in SESSION_LOG.md and move to the NEXT candidate — walk the backlog until you find one you can do or the eligible list is exhausted. Branch from origin/main, implement with tests matching repo conventions, build, unit gate green (dotnet test --filter "TestCategory!=Ui&FullyQualifiedName!~WindowsFirewallWrapperTests"), run the GATES (launch smoke every time + device bench when the change is device-observable and a board is attached), open a PR (base main, "closes #N", note "not merging — for review"), comment /agentic_review, and post the BENCH RESULTS comment. DO NOT MERGE.
   5. SELF-DIRECTED IMPROVEMENT — the default when 1–4 yield nothing AND you're under the cap. Do NOT idle or manufacture a marginal bench-only PR. RESEARCH the codebase for ONE concrete, high-confidence improvement (a latent bug, correctness/robustness fix, dedup/cleanup, a genuine test-coverage gap, or a small non-breaking feature) that you can defend as correct, non-breaking, and test-validatable. If you find one you're GENUINELY confident in: FILE a GitHub issue for it FIRST (gh issue create — problem + proposed fix + why it's safe), THEN work it as a normal ticket exactly per priority 4 (branch, tests, unit gate green, open PR "closes #", /agentic_review, NOT merging). Track every self-directed unit as its own issue so nothing lands untracked. Hold the same bar as any ticket — correctness over volume; do NOT invent low-value churn. Only if research surfaces nothing you're confident in → ONE light non-destructive validation pass, OR append "nothing confident to propose this fire" to SESSION_LOG.md and end.

   CONCURRENCY CAP: keep at most 5 loop-opened PRs awaiting the user's review at once (defined-ticket AND self-directed both count). Under the cap → priorities 4/5 keep opening new work. At the cap → don't start new tickets; just shepherd (1–3) and log. As the user merges/closes PRs, resume. (If the appended scope note names a different cap, use that.)

   Rules: never destructive board ops (no firmware/WiFi flash, --sd-format/--sd-delete, reboot/power-cycle); skip live SD:GET while heap is low; never script the WPF UI. Append this fire's outcome to <REPO_ROOT>/SESSION_LOG.md. Restore the working tree to the branch it started on before finishing. Correctness over volume. When done, RETURN a ≤4-line summary — the unit of work done, PR/issue #s touched, and the test + launch-smoke + device-bench result (or skip reason) — and NOTHING else; your full transcript stays in your own context and only this summary reaches the loop session. ══════════ END TASK ══════════

3. Confirm to the user: the returned cron job id, the cadence, that it works continuously (keeps opening new tickets/self-directed work after each, up to the cap of ~5 unreviewed PRs — adjustable), that every code-changing fire runs the app-launch smoke gate (and the matching device-bench scenario when the board's attached + the change is device-observable) and posts a BENCH RESULTS comment on the PR (text only — GitHub has no image-attach API, so no screenshots), that the GUI steps need an interactive unlocked Windows session and degrade gracefully (skip + note, never fail) when one isn't available, that it's session-only (dies when this session closes and auto-expires after 7 days), that it never merges, and that to stop it they run CronDelete <job id>.

4. Run the first iteration now — don't wait for the first cron fire. Follow the dispatcher pattern: spawn ONE general-purpose subagent (run_in_background: false) with the TASK block as its prompt, wait for it, relay its ≤4-line summary, then end the turn.

Notes

• Context hygiene via subagent delegation. The cron fires into one long-lived session, so its context would otherwise accumulate every fire's builds, full test runs, diffs, and Qodo comment bodies until it fills. Each fire therefore spawns a single fresh general-purpose subagent to do the actual work; the subagent burns its own (discarded) context and returns only a ≤4-line summary, so the loop session grows a few lines per fire. This works because the loop is nearly stateless per fire — it re-derives PR/CI/ticket state from gh and uses SESSION_LOG.md on disk as durable memory. The subagent runs on the same machine, so it reaches the local board and checkout. If the session still fills over a long run, /clear (or a new session) and re-invoke this skill — SESSION_LOG.md + the open PRs preserve continuity.
• Session-only + local. The loop lives in a Claude Code session on THIS machine; keep it open. It cannot be moved to another machine — re-invoke this skill in a session there to re-establish it.
• Desktop bench model. Three layers, hardest to softest: (1) the unit gate (dotnet test --filter "TestCategory!=Ui&FullyQualifiedName!~WindowsFirewallWrapperTests") is the always-required gate. (2) The app-launch smoke gate (Launch_MainWindowAppears_AndIsResponsive) runs on every code-changing fire — device-free, proves the app still boots, needs an interactive unlocked Windows session. (3) The device bench (matching RequiresDevice UITest scenario) runs only when a board is attached and the change is device-observable. Layers 2–3 need an interactive GUI session and degrade gracefully — skip + note, never fail the fire — when the session is locked / no board / not device-relevant. WPF still has no clean headless drive, so never hand-script the UI: all GUI/board validation goes through the FlaUI UITest scenarios (or a headless Core path). Each fire posts a BENCH RESULTS comment on its PR (text only — GitHub has no image-attach API, tracked at cli/cli #12960 + community #28219).
• Merging is out of scope for the loop. When the user says to merge, do it separately (squash; verify merged main builds + full-suite-green afterward, especially if --admin bypass skips the combined CI check).
• Re-invoking this skill in a new session re-establishes the loop from scratch (crons are session-only, not persisted).