claude-config-self-optimize-analysis-after-runlisted

# Self-optimise suggestions A run that leaves logs nobody reads is a run that teaches nothing. This reads them and says what to change. ## What it is for, and what it is not **This skill judges ONE run's execution.** Was the work cut well, did the slices balance, was anything done twice, did fanning out pay for itself. It is not `/sk:claude-config-self-development-research`, which audits the whole config against outside practice on a quarterly cadence. Different input (a run log vs the internet), different cadence (per run vs quarterly), different output (a partition change vs a config change). When a finding here turns out to be about the config rather than the run, hand it to `/sk:claude-config-update`. ## Method **1. Run the mechanical analysis first.** It is deterministic and free, so never hand-derive what it already computes: ```bash python3 ~/.claude/bin/superspeed-analyse.py <run-dir> ``` That yields idle capacity, imbalance ratio, cache read/write ratio, achieved concurrency, ownership leaks, duplicated reads, reconcile rework, failed slices, and a fan-out-worth-it verdict. **Clear the durable backlog, not just the newest run.** Every dispatch records a `runs` row with `optimized: false` in the `dotclaude` store, so an un-analysed run is never lost when you skip this step. When you do run it, also pull the backlog and analyse it in aggregate — a finding that recurs across runs is a config defect, not a one-off: ```bash ~/.config/claude-metrics-venv/bin/pyth