sched-claw-product-readiness

Étoiles1

Forks0

Mis à jour23 avril 2026 à 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

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Source

DarkHighness

DarkHighness/nanoclaw

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Métiers associésSOC

Basé sur la classification professionnelle SOC

Administrateurs de réseaux et de systèmes informatiquesProfessions informatiques et mathématiques·SOC 15-1244

Explorateur de fichiers

3 fichiers

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

Plus depuis ce dépôt

même dépôt

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