Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

scheduling-findings

Estrelas4

Forks2

Atualizado1 de julho de 2026 às 22:47

Produce severity-ranked Kubernetes workload placement findings across a ConfigHub fleet with the cub-scheduling CLI. v1 flags controllers that tolerate a taint but do not constrain where they land (no nodeSelector and no required node affinity), so they may schedule onto general nodes. Use for "what placement problems do we have?", "which workloads tolerate a taint but do not pin a node pool?", "placement findings for the ml component". Not for the raw placement report (use scheduling-audit), fixing placement (use scheduling-place), or availability spread (use workload-manager); analysis is over ConfigHub-managed Units only.

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ê.

Executar no Manus

Fonte

confighub

confighub/examples

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

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

2 arquivos

SKILL.md

readonly

name	scheduling-findings
description	Produce severity-ranked Kubernetes workload placement findings across a ConfigHub fleet with the cub-scheduling CLI. v1 flags controllers that tolerate a taint but do not constrain where they land (no nodeSelector and no required node affinity), so they may schedule onto general nodes. Use for "what placement problems do we have?", "which workloads tolerate a taint but do not pin a node pool?", "placement findings for the ml component". Not for the raw placement report (use scheduling-audit), fixing placement (use scheduling-place), or availability spread (use workload-manager); analysis is over ConfigHub-managed Units only.
phase	verify
allowed-tools	Bash(cub-scheduling --help) Bash(cub-scheduling * --help) Bash(cub auth status) Bash(cub-scheduling preflight) Bash(cub-scheduling findings) Bash(cub-scheduling findings *)

scheduling-findings

Report placement anti-patterns across the fleet, most-severe first. Read-only.

Why this matters

v1 flags the tractable, high-signal anti-pattern that needs no cluster facts: a controller that tolerates a taint but doesn't constrain where it lands (no nodeSelector and no required node affinity). Adding a toleration only permits scheduling onto tainted nodes; without a matching nodeSelector or node affinity the pod may still land on general nodes — usually not the intent. Analysis is over ConfigHub-managed Units only.

Checks that need cluster node-pool / taint facts (a nodeSelector for a pool no cluster advertises; a nodeSelector onto a tainted pool with no matching toleration) are deferred until those Target facts exist.

When to use

"What placement problems do we have?" → findings.
"Which workloads tolerate a taint but don't pin a node pool?" → findings (the v1 analyzer).
"Placement findings for the ml component / in prod." → findings --component ml / --environment prod.

Do not load for

The raw per-workload placement report — use scheduling-audit (placement).
Fixing placement — use scheduling-place.
Availability (pod anti-affinity / topology spread) — use workload-manager.

Preflight gates

cub-scheduling preflight succeeds. If it fails, ask the user to run cub auth login (interactive) and retry.

The toolkit

cub-scheduling findings -o table — severity-ranked placement findings (--severity, --cluster, --namespace).

Server-side --where + label shorthands scope the fleet; --cluster / --namespace are client-side.

Stop conditions

Zero findings — report the fleet is clean for that scope.
The user wants to fix something — hand off to scheduling-place.

Tool boundary

Read-only. Never use kubectl to answer a ConfigHub-state question.

References

cub-scheduling findings --help.
Companion skills: scheduling-audit, scheduling-place.

Mais deste repositório

mesmo repositório

cost-management-app-operator

confighub/examples

Operate the Cost Management App app through its generated CLI and browser surface. Use for "Turn fleet cost findings into governed recommendations, approvals, and receipts.", Variant review, proof gaps, preview, approval scope, and receipt checks. Read-only first; live mutation requires the app commit command to prove real ConfigHub bindings.

2026-07-124

add-on-manager-operator

confighub/examples

Operate the Add-on Manager app through its generated CLI and browser surface. Use for "Install, upgrade, review, and prove platform add-ons through governed ConfigHub delivery paths.", Variant review, proof gaps, preview, approval scope, and receipt checks. Read-only first; live mutation requires the app commit command to prove real ConfigHub bindings.

2026-07-024

autoscale-audit

confighub/examples

Inventory and report Kubernetes autoscaling stored in ConfigHub across a fleet with the cub-autoscale CLI — HorizontalPodAutoscalers and KEDA ScaledObjects: each one's scale target, min/max replicas, and whether it is pinned (min == max). Use for "what autoscalers do we have?", "list our HPAs / ScaledObjects", "which workloads are autoscaled?", "per-cluster autoscaler counts", "is autoscaler X pinned?". Not for autoscaling findings/anti-patterns (use autoscale-findings), edits or HPA→KEDA conversion (use autoscale-edit), or live cluster state (use kubectl); analysis is over ConfigHub-managed Units only.

2026-07-024

autoscale-edit

confighub/examples

Set Kubernetes autoscaling as config-as-data with the cub-autoscale CLI — edit a HorizontalPodAutoscaler's min/max replicas and cpu/memory targets, convert an HPA to a KEDA ScaledObject, apply reusable autoscaling profiles to one Unit or across a whole selector, and promote changes downstream. Use for "raise the HPA max to 20", "set cpu target to 60%", "convert this HPA to KEDA", "make every prod HPA scale out earlier", "apply the hpa-range profile", "roll the autoscaling change downstream". Dry-run by default; requires --commit --change-desc. Not for read-only checks (use autoscale-audit / autoscale-findings) or enforcement Triggers (use autoscale-guardrails).

2026-07-024

autoscale-findings

confighub/examples

Produce severity-ranked Kubernetes autoscaling findings across a ConfigHub fleet with the cub-autoscale CLI. Flags autoscalers that are pinned (min == max, can't scale), workloads with no HPA/ScaledObject, and the cross-resource case where a PodDisruptionBudget's minAvailable blocks all voluntary eviction at the autoscaler's minReplicas. Use for "what autoscaling problems do we have?", "which HPAs can't scale?", "which workloads lack an autoscaler?", "is any PDB blocking scale-down?". Not for the raw autoscaler inventory (use autoscale-audit), fixing autoscaling (use autoscale-edit), or live cluster state (use kubectl); analysis is over ConfigHub-managed Units only.

2026-07-024

autoscale-guardrails

confighub/examples

Install and inspect the autoscaling enforcement pack with the cub-autoscale CLI — an autoscale-policy Space with two Warn=true Triggers: a vet-cel rule that flags any HPA/ScaledObject that is pinned (min == max), and a vet-schemas rule that schema-validates every mutation (the post-convert check for convert-keda output, since keda.sh is in the schema catalog) — wired to in-scope Spaces via a shared Trigger Filter. guardrails install (dry-run by default) and status (Units with ApplyWarnings/Gates). Use for "enforce that no HPA is pinned", "make sure converted ScaledObjects pass schema validation", "which autoscalers are flagged?". Not for read-only findings (use autoscale-findings) or fixing autoscaling (use autoscale-edit).

2026-07-024

name	scheduling-findings
description	Produce severity-ranked Kubernetes workload placement findings across a ConfigHub fleet with the cub-scheduling CLI. v1 flags controllers that tolerate a taint but do not constrain where they land (no nodeSelector and no required node affinity), so they may schedule onto general nodes. Use for "what placement problems do we have?", "which workloads tolerate a taint but do not pin a node pool?", "placement findings for the ml component". Not for the raw placement report (use scheduling-audit), fixing placement (use scheduling-place), or availability spread (use workload-manager); analysis is over ConfigHub-managed Units only.
phase	verify
allowed-tools	Bash(cub-scheduling --help) Bash(cub-scheduling * --help) Bash(cub auth status) Bash(cub-scheduling preflight) Bash(cub-scheduling findings) Bash(cub-scheduling findings *)

scheduling-findings

Report placement anti-patterns across the fleet, most-severe first. Read-only.

Why this matters

When to use

"What placement problems do we have?" → findings.
"Which workloads tolerate a taint but don't pin a node pool?" → findings (the v1 analyzer).
"Placement findings for the ml component / in prod." → findings --component ml / --environment prod.

Do not load for

The raw per-workload placement report — use scheduling-audit (placement).
Fixing placement — use scheduling-place.
Availability (pod anti-affinity / topology spread) — use workload-manager.

Preflight gates

cub-scheduling preflight succeeds. If it fails, ask the user to run cub auth login (interactive) and retry.

The toolkit

cub-scheduling findings -o table — severity-ranked placement findings (--severity, --cluster, --namespace).

Server-side --where + label shorthands scope the fleet; --cluster / --namespace are client-side.

Stop conditions

Zero findings — report the fleet is clean for that scope.
The user wants to fix something — hand off to scheduling-place.

Tool boundary

Read-only. Never use kubectl to answer a ConfigHub-state question.

References

cub-scheduling findings --help.
Companion skills: scheduling-audit, scheduling-place.