sched-claw-product-readiness

Estrelas1

Forks0

Atualizado23 de abril de 2026 às 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.

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Fonte

DarkHighness

DarkHighness/nanoclaw

Abrir repositório GitHub Ver repositórios do creator

Download

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Administradores de redes e sistemas de computadorInformática e Matemática·SOC 15-1244

Explorador de arquivos

3 arquivos

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

Mais deste repositório

mesmo repositório

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