mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-06-20 03:40:29 +08:00
db7f2a6fd5
The official Agent Skills spec (agentskills.io/specification) whitelists exactly 6 top-level frontmatter keys (name/description/license/compatibility/metadata/ allowed-tools). A top-level `origin` key fails the official validator (anthropics/skills quick_validate.py ALLOWED_PROPERTIES; skills-ref validate). This moves `origin: X` -> `metadata.origin: X` across the canonical skills/ tree, preserving each value verbatim. Frontmatter-only, minimal diff. - 251 SKILL.md updated (242 new metadata block, 9 appended to existing metadata) - origin values preserved verbatim (verified 251/251) - YAML validated on all changed files - scoped to canonical skills/ only (docs/<lang> translations + tool mirrors .cursor/.kiro/.agents left untouched; presumably regenerated from canonical) Addresses #2233
75 lines
2.3 KiB
Markdown
75 lines
2.3 KiB
Markdown
---
|
|
name: latency-critical-systems
|
|
description: Use for latency-sensitive systems such as realtime dashboards, market data, streaming agents, execution gateways, queues, caches, or HFT-like infrastructure where freshness and p95 latency matter.
|
|
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:
|
|
|
|
```text
|
|
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.
|