architecture-optimization
Skill1 starsChanged 49 days agoMITView on GitHub
Optimize an existing, already-working system architecture or deployment for cost, latency, or resource efficiency — right-sizing compute, caching strategy, autoscaling policy, service-boundary reconsideration. Use when cost or latency needs to come down on a system that already works, without a ground-up redesign. Distinct from designing a new system (use `architecture-design` for that) and from code-level refactoring (use `scale-refactor` for that) — this operates on infrastructure and deployment decisions.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- wondelai/skillstheir own version, first seen Jul 16, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- wondelai/skills★ 2.6ksame name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository32 other files it gives its agents.
- agent-system-designSkill
- api-contract-designSkill
- architecture-designSkill
- ci-speedupSkill
- code-handoffSkill
- cross-ai-handoffSkill
- crypto-storage-auditSkill
- database-designSkill
- dataset-sourcingSkill
- distributed-debuggerSkill
- embedded-constrained-codingSkill
- freedom-to-operate-analysisSkill
- frontend-architectureSkill
- github-masterSkill
- idea-finderSkill
- ieee-paper-drafterSkill
- memory-leak-hunterSkill
- ml-model-selectionSkill
- ml-security-auditSkill
- mobile-platform-architectureSkill
- observability-designSkill
- patent-drafterSkill
- patent-novelty-evaluatorSkill
- performance-optimizationSkill
- project-scaffoldingSkill
- researcher-evaluatorSkill
- researcherSkill
- safety-compliance-scopingSkill
- scale-refactorSkill
- secure-code-reviewSkill
- slow-query-optimizerSkill
- test-architectSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 23
Check that the scaling trigger metric actually correlates with real load — CPU-based autoscaling on an I/O-bound service is a common miss …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Architecture Optimization
Optimizing the component that's easiest to change instead of the one that's actually expensive or slow is the default failure mode here. This skill forces measurement before any lever gets pulled.
Step 1 — Measure before optimizing anything
Get the actual cost breakdown (spend per component, not a total) and the actual latency breakdown (where end-to-end time is really spent, via tracing — not assumption). Optimizing without this is optimizing a guess.
Step 2 — Check the high-leverage levers, in this order
- Caching — what's cacheable and isn't cached yet; for what's already cached, is invalidation actually correct, or is stale data being served past its real validity window?
- Right-sizing compute — always-on provisioning for bursty load (paying for peak 24/7) versus autoscaling or serverless fit for the actual traffic shape.
- Data locality — cross-region or cross-AZ calls that could be colocated, adding pure network latency with no other benefit.
- Batch vs. real-time — anything computed per-request that could be precomputed or batched without hurting the actual user-facing requirement.
Step 3 — Autoscaling policy correctness
Check that the scaling trigger metric actually correlates with real load — CPU-based autoscaling on an I/O-bound service is a common miss that either over- or under-scales. Check scale-down doesn't thrash (scale down, immediate re-scale up, repeat).
Step 4 — Reconsider service boundaries if the evidence points there
Sometimes the real optimization is that a service boundary adds network overhead without buying real isolation or independent-scaling benefit. State this explicitly if the measurements support it — it's an uncomfortable finding to raise, not a reason to avoid raising it.
Step 5 — Verify every change against the Step 1 measurement
Re-run the same cost/latency breakdown after each change and confirm it actually moved, on the metric that mattered — not a proxy metric that's easier to improve.
Output
State the ranked cost/latency breakdown from Step 1, which lever was pulled and why it was picked over the others, and the before/after measurement for each change.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

