Performance investigation

Skill pipipip169/fable5-handoff/sources/adamentwistle-fable-skills/performance-investigation

The retirement handoff of Claude Fable 5 - written by the model itself. Domain-neutral discipline files that transfer flagship working method to any model, any agent framework, any team.

Install

npx -y skills add pipipip169/fable5-handoff --skill performance-investigation

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

3 things to look at

28 days oldThe repository was created 28 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Measurement-first performance work — baseline, profile, fix by leverage (do less work → cache → parallelize → tune constants), verify with the same measurement. Use for any "make it faster", latency/memory investigation, or before adding caching/memoization on intuition.

SKILL.md

3.4 KB, 706 tokens by cl100k_base, as published. Nobody here has run it

Performance Investigation

The cardinal sin is optimizing unmeasured code. Intuition about bottlenecks is wrong more often than right — the discipline is a measurement loop, not a bag of tricks.

1. Define the metric and measure the baseline

Pick ONE number that captures the complaint: p95 latency of endpoint X, wall time of job Y, MB of heap after Z. Measure it reproducibly (same input, several runs, note variance) BEFORE touching code. No baseline → no proof of improvement.

Beware benchmark lies: cold vs warm caches, dev-mode builds (dev servers are not prod), tiny toy inputs, laptop-vs-prod hardware, and measuring the first iteration (JIT/warmup).

2. Profile to find where the time actually goes

Use the real instrument, not code-reading: CPU profiler/flamegraph for compute, query logs + EXPLAIN for DBs, network waterfall for pages, heap snapshots for memory, distributed traces for services. The bottleneck is a measurement result, not an opinion.

Expect the 80/20: one or two frames dominate. If the profile is flat, the problem is usually per-item overhead in a loop (allocation, serialization, sync IO) or the workload itself (doing N× more work than needed).

3. Fix in order of leverage

Do less work — the biggest wins are algorithmic: N+1 queries → batch/join; O(n²) scan → index/map lookup; recomputing invariants inside loops → hoist; fetching/serializing fields nobody reads → trim.
Do work once — cache/memoize, but only with an invalidation story; a stale cache is a correctness bug traded for speed.
Do work elsewhere/later — defer off the critical path (lazy, background, streaming first byte early).
Do work in parallel — after the above; parallelizing an N+1 is still N+1.
Tune constants last — micro-optimizations only with a profiler receipt that the line is hot.

4. Verify with the SAME measurement, and check for damage

Rerun the exact baseline measurement. Report before/after with units and conditions ("p95 420ms → 95ms, warm, prod build, dataset X"). Then run the correctness suite — perf fixes love to break edge cases (caching stale data, reordered effects, dropped errors in parallelized code).

If the number didn't move: revert the "optimization". Dead speedup code is complexity debt with no interest paid.

Common bottleneck signatures (check before deep-diving)

Latency scales with item count → N+1 (queries, HTTP calls, file reads per item).
Slow only in prod → missing index on prod data volume, cold cache, network hops dev doesn't have.
Grows over time → leak (unbounded cache/listener/array), fragmentation, log growth.
Occasional spikes → GC pauses, lock contention, batch jobs sharing resources, retry storms.
"Fast function, slow system" → serialization at boundaries, chatty protocols, sync-over-async.

Scope honesty

Performance work trades readability, memory, or freshness for speed. Name the trade in your report. And if the requested target is already met by the baseline measurement — report that and stop; unneeded optimization is scope creep.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most performance cost skills give in 706 tokens

Counted across 803 of the 1,058 authors here whose files we hold, read 2026-08-07

Keep skill files under 500 lines or tokensin 82 of 803, across 16 files
Use imperative form in instructionsin 80 of 803, across 9 files
Draft assertions while test runs are in progressin 75 of 803, across 9 files
Create two to three realistic test promptsin 74 of 803, across 9 files
Write skill descriptions to be pushyin 72 of 803, across 7 files
Save test cases to evals JSONin 72 of 803, across 6 files
Ask questions about edge cases and input formatsin 72 of 803, across 7 files
Save timing data immediately when runs completein 70 of 803, across 5 files
Include all trigger conditions in the skill descriptionin 69 of 803, across 3 files
Launch all test runs in a single turn or simultaneouslyin 69 of 803, across 3 files
Capture intent before writing a skillin 67 of 803, across 1 file
Import directly instead of barrel filesin 52 of 803, across 15 files

Said here and by no other author read

fix bottlenecks by order of leverage
reduce work before parallelizing it
run the correctness suite after performance fixes
name the tradeoffs made for speed
stop and report if the baseline already meets target

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.