ln-31-performance-optimizer

Name: ln-31-performance-optimizer
Author: levnikolaevich

520stars73forks

How to install ln-31-performance-optimizer?

levnikolaevich/claude-code-skills/ln-31-performance-optimizer

$npx -y skills add levnikolaevich/claude-code-skills --skill ln-31-performance-optimizer

Installs into the current project.

Summary

Optimizes a measured latency, throughput, memory, CPU, or I/O problem through profiling and keep-or-discard experiments. Use for a known bottleneck; not unbiased A/B comparison.

Files · 1

View on GitHub

SKILL.md

1	# Performance Optimizer
2
3	Goal: Optimize only measured problems. Preserve correctness, isolate experiments, and retain a change only when comparable evidence shows that it improves the agreed metric without unacceptable regressions.
4
5	Execution contract: Treat the ordered checkbox workflow below as this skill's Definition of Done. Work through every item in order, and mark it complete only when its action and required evidence are complete. `N/A`, skipped, unavailable, or delegated items remain incomplete.
6	Before returning, apply this skill's verdict, decision, and approval rules to every incomplete item and prepend Checklist: X/Y complete<br>Incomplete: None \| section/item — reason; outcome impact; exact next action; list every incomplete item.
7
8	## Tool Routing
9
10	\| Need \| Preferred tool \| Use it when \| Fallback \|
11	\|---\|---\|---\|---\|
12	\| Repository state and safe edit boundary \| Git status, diff, branch or worktree inspection, and repository instructions \| Always before profiling or editing \| Stop if user changes cannot be isolated safely \|
13	\| Baseline and final metric \| Existing benchmark, load test, reproducible command, or production-like replay \| The metric and workload reflect the reported problem \| Create the smallest local benchmark that reproduces the behavior without inventing production scale \|
14	\| Bottleneck evidence \| Existing profiler, tracing, query diagnostics, allocation tools, or OS-level metrics \| Locating CPU, memory, I/O, lock, query, network, or scheduler cost \| Targeted instrumentation with cleanup plan \|
15	\| Code path and blast radius \| Language server or host-native code intelligence \| Following hot symbols, callers, implementations, and affected contracts \| Narrow search plus direct inspection of definitions and consumers \|
16	\| Correctness and regressions \| Repository-defined tests, build, lint, type, and smoke commands \| Before and after every retained experiment \| Add a focused safety test when current coverage cannot detect the likely regression \|
17	\| Runtime and dependency semantics \| Official documentation, release notes, and specifications matching installed versions \| A hypothesis depends on optimizer, runtime, database, framework, or library behavior \| Primary-source web research; otherwise mark the hypothesis `UNVERIFIED` \|
18	\| Independent challenge \| One native subagent or advisor when policy and scope allow \| Competing hypotheses, unfamiliar runtime behavior, or high-risk change needs independent scrutiny \| Separate adversarial hypothesis review \|
19
20	Do not optimize by aesthetic preference or benchmark a different workload from the reported problem. Never discard user changes, use destructive Git reset, or run uncontrolled load against production.
21
22	## Evidence Rules
23
24	- Define the primary metric and acceptance threshold before editing; do not move the goal after seeing results.
25	- Compare the same workload, environment, build mode, data, warmup, and measurement method before and after.
26	- Use repeated runs and report distribution or variance; a single faster run is not proof.
27	- Separate cold-start, warm steady-state, and saturated-load behavior when the reported problem can occur in more than one regime.
28	- Profile contribution and end-to-end impact separately: a hot function can improve while the user-visible metric does not.
29	- Treat profiler estimates, synthetic workloads, and production observations as different evidence classes and label them.
30	- Correctness, resource safety, and operational stability are hard constraints, not secondary metrics.
31
32	## Checklist
33
34	### 1. Define the Problem and Protect the Workspace
35
36	- [ ] Resolve the user-visible problem, affected workflow, target metric, workload, environment, constraints, and acceptance threshold.
37	- [ ] Run the wrong-tool gate: confirm the symptom is a performance problem rather than correctness, configuration, capacity, dependency, or observability failure.
38	- [ ] Read repository instructions and inspect Git state, branches, uncommitted changes, ignored artifacts, and available isolation mechanisms.
39	- [ ] Preserve user work and isolate experiments in a safe branch or worktree when changes, benchmarks, or generated artifacts could interfere.
40	- [ ] Start a run-owned resource ledger with every created absolute path, worktree, process ID, cache, profile, and temporary artifact; never register pre-existing resources as cleanup targets.
41	- [ ] Identify correctness, security, memory, cost, compatibility, and operational constraints that no optimization may violate.
42	- [ ] Locate existing benchmarks, profiles, performance tests, production traces, service-level objectives, and known environmental variability.
43
44	### 2. Establish a Reproducible Baseline
45
46	- [ ] Use the same metric type as the observed problem:

levnikolaevichPublisher · 19 listings

Preview

levnikolaevich/claude-code-skills

# Performance Optimizer

**Goal:** Optimize only measured problems. Preserve correctness, isolate experiments, and retain a change only when comparable evidence shows that it improves t

**Execution contract:** Treat the ordered checkbox workflow below as this skill's Definition of Done. Work through every item in order, and mark it complete onl

Before returning, apply this skill's verdict, decision, and approval rules to every incomplete item and prepend **Checklist: X/Y complete**<br>**Incomplete: Non

Repolevnikolaevich/claude-code-skills

LicenseMIT

TypeSkills

CategoryCoding

UpdatedJul 2026

Repo stars520

First seenJul 22, 2026

People who liked this also viewed

6 picks

Type

ln-31-performance-optimizer

520stars73forks

View on GitHub

How to install ln-31-performance-optimizer?

levnikolaevich/claude-code-skills/ln-31-performance-optimizer

$npx -y skills add levnikolaevich/claude-code-skills --skill ln-31-performance-optimizer

Installs into the current project.

Summary

Optimizes a measured latency, throughput, memory, CPU, or I/O problem through profiling and keep-or-discard experiments. Use for a known bottleneck; not unbiased A/B comparison.

Files · 1

View on GitHub

SKILL.md

1	# Performance Optimizer
2
3	Goal: Optimize only measured problems. Preserve correctness, isolate experiments, and retain a change only when comparable evidence shows that it improves the agreed metric without unacceptable regressions.
4
5	Execution contract: Treat the ordered checkbox workflow below as this skill's Definition of Done. Work through every item in order, and mark it complete only when its action and required evidence are complete. `N/A`, skipped, unavailable, or delegated items remain incomplete.
6	Before returning, apply this skill's verdict, decision, and approval rules to every incomplete item and prepend Checklist: X/Y complete<br>Incomplete: None \| section/item — reason; outcome impact; exact next action; list every incomplete item.
7
8	## Tool Routing
9
10	\| Need \| Preferred tool \| Use it when \| Fallback \|
11	\|---\|---\|---\|---\|
12	\| Repository state and safe edit boundary \| Git status, diff, branch or worktree inspection, and repository instructions \| Always before profiling or editing \| Stop if user changes cannot be isolated safely \|
13	\| Baseline and final metric \| Existing benchmark, load test, reproducible command, or production-like replay \| The metric and workload reflect the reported problem \| Create the smallest local benchmark that reproduces the behavior without inventing production scale \|
14	\| Bottleneck evidence \| Existing profiler, tracing, query diagnostics, allocation tools, or OS-level metrics \| Locating CPU, memory, I/O, lock, query, network, or scheduler cost \| Targeted instrumentation with cleanup plan \|
15	\| Code path and blast radius \| Language server or host-native code intelligence \| Following hot symbols, callers, implementations, and affected contracts \| Narrow search plus direct inspection of definitions and consumers \|
16	\| Correctness and regressions \| Repository-defined tests, build, lint, type, and smoke commands \| Before and after every retained experiment \| Add a focused safety test when current coverage cannot detect the likely regression \|
17	\| Runtime and dependency semantics \| Official documentation, release notes, and specifications matching installed versions \| A hypothesis depends on optimizer, runtime, database, framework, or library behavior \| Primary-source web research; otherwise mark the hypothesis `UNVERIFIED` \|
18	\| Independent challenge \| One native subagent or advisor when policy and scope allow \| Competing hypotheses, unfamiliar runtime behavior, or high-risk change needs independent scrutiny \| Separate adversarial hypothesis review \|
19
20	Do not optimize by aesthetic preference or benchmark a different workload from the reported problem. Never discard user changes, use destructive Git reset, or run uncontrolled load against production.
21
22	## Evidence Rules
23
24	- Define the primary metric and acceptance threshold before editing; do not move the goal after seeing results.
25	- Compare the same workload, environment, build mode, data, warmup, and measurement method before and after.
26	- Use repeated runs and report distribution or variance; a single faster run is not proof.
27	- Separate cold-start, warm steady-state, and saturated-load behavior when the reported problem can occur in more than one regime.
28	- Profile contribution and end-to-end impact separately: a hot function can improve while the user-visible metric does not.
29	- Treat profiler estimates, synthetic workloads, and production observations as different evidence classes and label them.
30	- Correctness, resource safety, and operational stability are hard constraints, not secondary metrics.
31
32	## Checklist
33
34	### 1. Define the Problem and Protect the Workspace
35
36	- [ ] Resolve the user-visible problem, affected workflow, target metric, workload, environment, constraints, and acceptance threshold.
37	- [ ] Run the wrong-tool gate: confirm the symptom is a performance problem rather than correctness, configuration, capacity, dependency, or observability failure.
38	- [ ] Read repository instructions and inspect Git state, branches, uncommitted changes, ignored artifacts, and available isolation mechanisms.
39	- [ ] Preserve user work and isolate experiments in a safe branch or worktree when changes, benchmarks, or generated artifacts could interfere.
40	- [ ] Start a run-owned resource ledger with every created absolute path, worktree, process ID, cache, profile, and temporary artifact; never register pre-existing resources as cleanup targets.
41	- [ ] Identify correctness, security, memory, cost, compatibility, and operational constraints that no optimization may violate.
42	- [ ] Locate existing benchmarks, profiles, performance tests, production traces, service-level objectives, and known environmental variability.
43
44	### 2. Establish a Reproducible Baseline
45
46	- [ ] Use the same metric type as the observed problem:

levnikolaevichPublisher · 19 listings

Preview

levnikolaevich/claude-code-skills

# Performance Optimizer

**Goal:** Optimize only measured problems. Preserve correctness, isolate experiments, and retain a change only when comparable evidence shows that it improves t

**Execution contract:** Treat the ordered checkbox workflow below as this skill's Definition of Done. Work through every item in order, and mark it complete onl

Before returning, apply this skill's verdict, decision, and approval rules to every incomplete item and prepend **Checklist: X/Y complete**<br>**Incomplete: Non

Repolevnikolaevich/claude-code-skills

LicenseMIT

TypeSkills

CategoryCoding

UpdatedJul 2026

Repo stars520

First seenJul 22, 2026

People who liked this also viewed

6 picks

Type