SkillHub

Skills affaan-m ecc

latency-critical-systems

Use it when:
p95 latency, throughput or data freshness matters: realtime dashboards, market-data feeds, streaming agents, execution gateways, queues or caches.
It does:
Tracks p50, p95 and p99 latency, freshness age, queue depth and cache hit rate separately, and maps the path from source event to what the user sees.
Fixes in order:
Round trips first, then caching with freshness metadata, batching, moving compute closer, splitting hot and cold paths, and backpressure.
Verifies with:
Live readbacks of a deployed system: HTTP timings and headers, freshness timestamps, queue and cache state, browser checks and retry logs.
Won't:
Drop validation for speed, hide stale data behind fast cache hits, or run live orders or risky deploys without an approval gate.

TL;DR

A short engineering guide from ECC for systems where speed means freshness as much as response time. It asks the agent not to collapse everything into "fast" but to track each metric on its own: latency percentiles, throughput, freshness age, queue depth, cache hit rate, provider response time, browser render time, correctness under load and retry behavior. The agent writes out the hot path, for example source event, provider API, ingest worker, queue, cache, edge route, client stream and browser render, and measures each segment. Optimizations follow a fixed order, ending with streaming only where it helps freshness and canaries for stale data, degraded providers and bad cache state. For market-data or execution-adjacent paths it also checks orderbook age, VWAP assumptions, provider status and kill-switch behavior before calling the path ready. It covers HFT-like infrastructure but says it doesn't authorize live trading or give financial advice, and it keeps secrets and private payloads out of logs and benchmark artifacts.

Summarizes the skill at d2ef268.

npx skills add https://github.com/affaan-m/ecc --skill latency-critical-systems

skills.sh pageSource on GitHubAll skills from affaan-m/ecc

Weekly Downloads week to Nov 9, 2026
449
+69% in 8 weeks

More weekly downloads than 60% of skills

Weekly values
Week toInstalls
Sep 21266
Sep 28163
Oct 5142
Oct 12232
Oct 19411
Oct 26402
Nov 2471
Nov 9449
Total Downloads on skills.sh
5,300

Fewer downloads than 91% of skills

Repo stars affaan-m/ecc
299,776

More stars than 97% of repos

Age published May 25, 2026
5 months

Newer than 79% of skills

Category
category:debuggingcategory:software-engineering

Find root causes, review code and test what you built.

Everything for building software: planning, coding, debugging, design, frameworks, cloud, agents and skills.
Type
type:workflow

A multi-step process the agent follows: interview, debug, run a TDD loop, review.
Effect
effect:local

Its own steps create or change files, git state or local tools.
Needs
needs:none

Instructions only. Works in any agent that supports skills.
Publisher
by:community

Everyone else. Unverified vendor claims default to community.
Topics
performanceobservabilityverification

SKILL.md

From affaan-m/ecc at d2ef268. Checked daily, last changed Nov 6, 2026.

Frontmatter
name: latency-critical-systems
description: Optimize and verify latency-sensitive systems — realtime dashboards, market data feeds, streaming agents, execution gateways, queues, and caches — by tracking p50/p95/p99 latency, freshness age, and queue depth, mapping hot paths, and running live readbacks. Use when p95 latency, throughput, or data freshness matters.
license: MIT
metadata:
  origin: ECC
tools: Read, Write, Edit, Bash, Grep, Glob

Latency Critical Systems

Use this skill when the user cares about realtime behavior, hot paths, streaming freshness, or execution speed. This includes HFT-like infrastructure, but the skill is engineering-focused. It does not authorize live trading or financial advice.

Split The Metrics

Do not collapse everything into "fast." Track:

  • p50, p95, and p99 latency;
  • throughput;
  • freshness age;
  • queue depth;
  • cache hit rate;
  • provider/API response time;
  • browser render time;
  • correctness under load;
  • failure and retry behavior.

Map The Hot Path

Write the path from user/event to final visible state:

source event -> provider API -> ingest worker -> queue -> cache -> edge route
-> client stream -> browser render -> user-visible state

Then measure each segment separately.

Optimization Order

  1. Remove unnecessary round trips.
  2. Cache stable reads with freshness metadata.
  3. Batch small calls and writes.
  4. Move compute closer to the data or the user.
  5. Split hot and cold paths.
  6. Apply backpressure before queues grow unbounded.
  7. Use streaming only when it improves freshness or user experience.
  8. Add canaries for stale data, degraded providers, and bad cache state.

Verification

Use live readbacks when a deployed surface exists:

  • HTTP timing and response headers;
  • provider freshness timestamp;
  • queue or job state;
  • edge/cache state;
  • browser verification for actual UI freshness;
  • logs around retries and degraded mode.

For market-data or execution-adjacent paths, also verify orderbook age, VWAP assumptions, provider status, and kill-switch behavior before calling the path ready.

Guardrails

  • Do not optimize latency by dropping required validation.
  • Do not hide stale data behind fast cache hits.
  • Do not claim millisecond behavior from client labels without measurement.
  • Do not run live orders, destructive migrations, or customer-impacting deploys without an explicit approval gate.
  • Keep secrets and private payloads out of logs and benchmark artifacts.