home / skills / plurigrid / asi / scum-score

scum-score skill

/skills/scum-score

This skill helps you identify and constrain resource-hogging processes using SCUM scoring to optimize system performance.

npx playbooks add skill plurigrid/asi --skill scum-score

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
3.5 KB
---
name: scum-score
description: 'SCUM Score Skill'
version: 1.0.0
---

# SCUM Score Skill

> **S**ystem **C**onsumer **U**tilization **M**etrics - Identify and terminate resource-hogging processes

## Overview

SCUM Score quantifies process resource consumption using GF(3) triadic classification:

| Trit | Category | CPU Range | Memory Range | Action |
|------|----------|-----------|--------------|--------|
| **+1** | SCUM | >30% CPU or >5% MEM | High | Kill candidate |
| **0** | Normal | 1-30% CPU | 0.5-5% MEM | Monitor |
| **-1** | Idle | <1% CPU | <0.5% MEM | Ignore |

## SCUM Score Formula

```
SCUM(p) = 0.6 * (cpu% / 100) + 0.3 * (mem% / 100) + 0.1 * (runtime_hrs / 24)
```

Threshold: **SCUM(p) > 0.35** = SCUM process

## Quick Commands

### View Current SCUM
```bash
# Top 10 SCUM processes with scores
ps axo pid,comm,%cpu,%mem,time | awk 'NR>1 {
  scum = 0.6*($3/100) + 0.3*($4/100);
  if (scum > 0.1) printf "%.3f SCUM %5d %s\n", scum, $1, $2
}' | sort -rn | head -10
```

### Kill SCUM (Interactive)
```bash
# Identify and offer to kill
ps axo pid,comm,%cpu,%mem | awk 'NR>1 && $3>30 {print $1, $2, $3"%"}' | while read pid name cpu; do
  echo "Kill $name (PID $pid) using $cpu CPU? [y/N]"
  read ans
  [[ "$ans" == "y" ]] && kill -9 $pid && echo "Killed $name"
done
```

### Babashka SCUM Analysis
```clojure
#!/usr/bin/env bb
(require '[babashka.process :refer [shell]])
(require '[clojure.string :as str])

(defn parse-ps []
  (->> (shell {:out :string} "ps axo pid,comm,%cpu,%mem")
       :out
       str/split-lines
       rest
       (map #(str/split % #"\s+"))
       (map (fn [[_ pid comm cpu mem]]
              {:pid (parse-long pid)
               :comm comm
               :cpu (parse-double cpu)
               :mem (parse-double mem)
               :scum (+ (* 0.6 (/ (parse-double cpu) 100))
                        (* 0.3 (/ (parse-double mem) 100)))}))
       (filter #(> (:scum %) 0.1))
       (sort-by :scum >)))

(doseq [p (take 10 (parse-ps))]
  (printf "%.3f SCUM [%d] %s (%.1f%% CPU, %.1f%% MEM)\n"
          (:scum p) (:pid p) (:comm p) (:cpu p) (:mem p)))
```

## GF(3) Process Classification

```
Process Trit Assignment:
  trit(p) = sign(SCUM(p) - 0.15) where:
    SCUM > 0.35  → +1 (SCUM - kill candidate)
    0.15 < SCUM ≤ 0.35 → 0 (NORMAL - monitor)
    SCUM ≤ 0.15 → -1 (IDLE - ignore)

Conservation: Σ trit(processes) should approach 0 for healthy system
```

## Integration with Resource Sharing

SCUM processes are candidates for:
1. **Throttling** via `renice` or `cpulimit`
2. **Migration** to other machines via LocalSend/Tailscale
3. **Termination** if unresponsive

## Sophie Lipkid Resource Sharing Protocol

Named after the "all category resource sharing machines" principle:

```
ResourceShare(p, target) = {
  if SCUM(p) > 0.35:
    migrate(p, least_loaded_peer())
  elif SCUM(p) > 0.2:
    throttle(p, 50%)
  else:
    allow(p)
}
```

## Justfile Recipes

```just
# View SCUM scores
scum-view:
  ps axo pid,comm,%cpu,%mem | awk 'NR>1 {s=0.6*($3/100)+0.3*($4/100); if(s>0.1) printf "%.3f %s\n",s,$2}' | sort -rn | head -15

# Kill all SCUM (DANGEROUS)
scum-kill:
  ps axo pid,%cpu | awk 'NR>1 && $2>50 {print $1}' | xargs -r kill -9

# Throttle high CPU
scum-throttle:
  ps axo pid,%cpu | awk 'NR>1 && $2>30 && $2<50 {print $1}' | xargs -I{} renice +10 {}
```

---

**Skill Name**: scum-score  
**Trit**: -1 (MINUS - Validator/Constrainer)  
**GF(3) Role**: Identifies and constrains resource hogs  
**Integration**: resource-sharing, localsend-mcp, tailscale-mesh

Overview

This skill quantifies and classifies process resource consumption using a lightweight SCUM Score to identify CPU- and memory-heavy processes. It provides simple commands and scripts to list, throttle, migrate, or terminate problematic processes. The goal is fast, actionable detection so operators can reclaim system capacity or migrate load to peers.

How this skill works

It computes SCUM(p) = 0.6*(cpu%/100) + 0.3*(mem%/100) + 0.1*(runtime_hrs/24) and maps scores to three triadic categories: SCUM (kill candidate), Normal (monitor), and Idle (ignore). The skill offers shell, justfile, and Babashka snippets to inspect processes, sort by score, interactively confirm kills, and apply throttling or migration policies.

When to use it

  • Investigating sudden CPU or memory spikes on a host
  • Automating detection of long-running resource-hogging processes
  • Before manually terminating processes to prioritize candidates
  • When load should be redistributed across a mesh of peers
  • As part of lightweight site reliability workflows or maintenance windows

Best practices

  • Run the SCUM view regularly but avoid aggressive automated kills without confirmation
  • Combine SCUM detection with process ownership and service metadata before terminating
  • Prefer throttling (renice/cpulimit) or migration over immediate kill for production services
  • Adjust thresholds for specialized workloads (e.g., batch jobs or scientific compute)
  • Log actions and maintain a brief cooldown window to avoid kill loops

Example use cases

  • Quickly list top SCUM processes and decide which to throttle or kill
  • Integrate SCUM checks into a maintenance script that migrates heavy tasks to idle peers
  • Use Babashka snippet for portable Python/CLI-free environments to generate human-readable SCUM reports
  • Add SCUM view to a monitoring dashboard to highlight candidates for scaling or migration
  • Run justfile recipes in admin shells to bulk-throttle or safely inspect suspects

FAQ

What SCUM score defines a kill candidate?

A process with SCUM(p) > 0.35 is considered a SCUM kill candidate; use caution before terminating.

Can I auto-kill SCUM processes?

Auto-killing is risky; prefer interactive confirmation or staged actions (throttle → migrate → kill) and restrict auto-kill to non-critical environments.