nanoclaw

Use when sched-ext source has to be edited, then compiled, verifier-checked, and persisted with concrete artifacts. Covers build command hygiene, libbpf or verifier triage, and script-friendly artifact capture.

Use when baseline and candidate runs need to be executed and compared with reproducible artifacts instead of free-form notes. Covers repeated runs, metrics import, noise handling, and script-driven comparison instead of host-owned scoring.

Use when a tuning request needs to be turned into a durable workload contract before any sched-ext code is changed. Covers selectors, direct metrics, proxy metrics, guardrails, and saved contract hygiene.

Use when a sched-ext candidate is about to be activated through the privileged daemon. Covers rollout gates, daemon usage limits, rollback triggers, and how to keep deployment evidence attributable.

Use when collected scheduler evidence needs to be turned into explicit facts, inferences, unknowns, and candidate design implications. Covers repo helper scripts for uv-managed analysis environments, pandas or polars summaries, and matplotlib plots.

Use when scheduler-related performance evidence has to be collected reproducibly for a workload, target selector, or experiment phase. Covers low-overhead counters first, escalation to traces, and repo scripts that keep capture deterministic without baking a workflow into the host.

Use when a task requires collecting or interpreting Linux scheduling evidence before changing policy. Covers first-pass scheduler triage, evidence hygiene, and translating traces or counters into scheduler hypotheses.

Use when demonstrating or tuning a compile-heavy LLVM/clang build workload with sched-claw. Covers the demo launcher, direct build metrics, and the fallback path to IPC/CPI proxies.

Use when demonstrating or tuning a sysbench + MySQL workload with sched-claw. Covers the demo launcher, direct throughput and latency metrics, and workload-specific scheduler implications.

Use when the task requires turning workload evidence into a new sched-ext scheduler, validating it against CFS, and rolling it out through the privileged daemon with explicit rollback criteria.

Use when evidence has to be turned into explicit scheduler policy levers, invariants, and measurement hypotheses before code generation or rollout. Keeps policy reasoning reusable across workloads and candidate implementations.

Use when workload evidence has to be turned into concrete sched-ext code changes, reference scaffolds, policy levers, and buildable candidate state. Covers narrow code generation grounded in prior analysis without requiring the host to orchestrate codegen.

Use when the task is to decide whether a host is ready to run sched-claw as a real autotuning product. Covers readiness inspection, dependency gaps, daemon reachability, privileged perf capture prerequisites, and how to turn missing prerequisites into an explicit operator plan.

Use when a task requires writing, loading, or reasoning about eBPF programs for Linux performance analysis. Covers tool selection across bpftrace, BCC, and libbpf CO-RE, plus hook choice, build or load steps, map design, verification, and overhead control. Do not trigger for generic Linux perf analysis that can be handled without custom eBPF work.

Use when a task requires analyzing Linux performance evidence collected with perf, sysstat, or eBPF. Apply workload characterization, the USE method, top-down microarchitecture analysis, CPI or IPC interpretation, off-CPU analysis, and bottleneck ranking. Do not trigger for raw collection-only tasks without interpretation.

Use when a task requires collecting Linux performance evidence with perf, sysstat, or eBPF on a live host or benchmark run. Prefer low-overhead counters and first-pass triage before invasive tracing. Applicable to CPU, scheduler, memory, block I/O, and network collection. Do not trigger for pure code changes unless system evidence collection is part of the task.

Use when a task requires writing a Linux performance analysis report from perf, sysstat, benchmark, or eBPF evidence. Focus on evidence-backed findings, bottleneck ranking, explicit facts versus inferences, and clear next experiments. Do not trigger for generic prose editing unrelated to performance investigations.