sched-claw-product-readiness

Sterne1

Forks0

Aktualisiert23. April 2026 um 04:57

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.

Installation

Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.

Quelle

DarkHighness

DarkHighness/nanoclaw

GitHub-Repository öffnen Creator-Repositorys ansehen

Download

Verwandte BerufeSOC

Basierend auf der SOC-Berufsklassifikation

Netzwerk- und ComputersystemadministratorenInformatik- und Mathematikberufe·SOC 15-1244

Datei-Explorer

3 Dateien

SKILL.md

readonly

name	sched-claw-product-readiness
description	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.
aliases	["product-readiness"]
tags	["sched-claw","product","readiness"]

sched-claw Product Readiness

When to use

Decide whether the current host can support sched-claw end to end.
Explain why an agent run, build, verifier probe, daemon rollout, or demo launch is blocked.
Stage a system before starting real autotune work.

Read before acting

references/readiness-matrix.md
references/harness-engineering.md

Workflow

Start from the requested capability, not a generic checklist.
- Distinguish analysis-only, build-and-verify, privileged rollout, and demo execution.
- State which one is blocked.
Run the host readiness surface first.
- Prefer sched-claw doctor --style plain or --style table.
- Treat the output as the product-facing readiness summary, not as a model-only heuristic.
Classify failures by layer.
- runtime: provider credentials and model bootstrap
- skills: builtin skill bundle, helper scripts, and shared Linux perf skills
- toolchain: clang, bpftool, perf, uv, python3
- kernel: BTF, cgroup support, and perf_event_paranoid visibility
- daemon: privileged rollout reachability plus bounded collect_perf support
Keep the harness split clean.
- normal tools plus repo scripts handle collection, analysis, plotting, and code generation
- the daemon handles privileged sched-ext lifecycle plus bounded attach-style perf capture
- if a task needs deterministic automation, prefer an explicit script over a new host workflow command
Convert gaps into an operator plan.
- State which failures block all progress and which only block a specific demo or rollout phase.
- Keep remediation explicit and minimal.
Re-run readiness after the operator changes the host.
- Do not assume a missing dependency is fixed until sched-claw doctor says so.

Rules

Do not invent hidden prerequisites. Use the doctor surface and the real launcher scripts.
Do not claim the product is ready when build, daemon, or provider bootstrap is blocked.
Keep optional demo gaps separate from core autotune gaps.

Output checklist

current readiness summary
blocking gaps vs optional gaps
exact remediation steps
the next command to rerun for confirmation

Reference Material

references/readiness-matrix.md
references/harness-engineering.md

Mehr aus diesem Repository

gleiches Repository

sched-ext-build-verify

DarkHighness/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.

2026-04-231

sched-ext-run-evaluation

DarkHighness/nanoclaw

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.

2026-04-231

sched-workload-contract

DarkHighness/nanoclaw

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.

2026-04-231

sched-ext-rollout-safety

DarkHighness/nanoclaw

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.

2026-04-231

sched-perf-analysis

DarkHighness/nanoclaw

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.

2026-04-231

sched-perf-collection

DarkHighness/nanoclaw

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.

2026-04-231

name	sched-claw-product-readiness
description	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.
aliases	["product-readiness"]
tags	["sched-claw","product","readiness"]

sched-claw Product Readiness

When to use

Decide whether the current host can support sched-claw end to end.
Explain why an agent run, build, verifier probe, daemon rollout, or demo launch is blocked.
Stage a system before starting real autotune work.

Read before acting

references/readiness-matrix.md
references/harness-engineering.md

Workflow

Start from the requested capability, not a generic checklist.
- Distinguish analysis-only, build-and-verify, privileged rollout, and demo execution.
- State which one is blocked.
Run the host readiness surface first.
- Prefer sched-claw doctor --style plain or --style table.
- Treat the output as the product-facing readiness summary, not as a model-only heuristic.
Classify failures by layer.
- runtime: provider credentials and model bootstrap
- skills: builtin skill bundle, helper scripts, and shared Linux perf skills
- toolchain: clang, bpftool, perf, uv, python3
- kernel: BTF, cgroup support, and perf_event_paranoid visibility
- daemon: privileged rollout reachability plus bounded collect_perf support
Keep the harness split clean.
- normal tools plus repo scripts handle collection, analysis, plotting, and code generation
- the daemon handles privileged sched-ext lifecycle plus bounded attach-style perf capture
- if a task needs deterministic automation, prefer an explicit script over a new host workflow command
Convert gaps into an operator plan.
- State which failures block all progress and which only block a specific demo or rollout phase.
- Keep remediation explicit and minimal.
Re-run readiness after the operator changes the host.
- Do not assume a missing dependency is fixed until sched-claw doctor says so.

Rules

Do not invent hidden prerequisites. Use the doctor surface and the real launcher scripts.
Do not claim the product is ready when build, daemon, or provider bootstrap is blocked.
Keep optional demo gaps separate from core autotune gaps.

Output checklist

current readiness summary
blocking gaps vs optional gaps
exact remediation steps
the next command to rerun for confirmation

Reference Material

references/readiness-matrix.md
references/harness-engineering.md