| name | embedded-hot-path-review |
| description | Use when reviewing embedded or target-local loops, polling, sampling, collectors, recorders, sub-100ms work, per-iteration I/O, repeated serialization, or hot-path allocation. Do not use for non-embedded application request/render/job paths; use performance-review there. |
| metadata | {"short-description":"Embedded hot-path review","templates":["templates/hot-path-review.md"]} |
Purpose
Use this skill to review the steady-state cost of target-local hot paths before they become production defaults.
It answers one question:
Can this loop, sampler, poller, collector, recorder, or target-local hot path run without hidden CPU, wakeup, allocation, storage, or latency cost?
When to use
Use this skill when a change includes:
- loop, polling, sampling, collector, recorder, or watcher behavior on a target
- sub-100ms periodic work
- per-sample or per-iteration filesystem, network, database, or IPC work
- repeated JSON serialization, regex, sorting, directory scans, allocation, or blocking syscalls in a hot path
- ring buffers, queues, or retention logic on a resource-constrained target
Do not use it for cold-path setup, non-embedded backend request handlers, frontend render paths, pure tests, pure schema changes, or one-shot scripts without target-local steady-state cost. Use performance-review for non-embedded request/render/job path costs.
Do not use for host-side CLIs, batch tools, servers, or ordinary daemons that have no physical target constraint. Work is embedded only when an actual constraint exists: battery/power budget, thermal limit, flash-wear limit, real-time deadline, constrained target CPU/RAM, or a physically separate target device. Logger/recorder/collector/sampler/polling vocabulary alone does not make work embedded; when in doubt and no physical constraint is named, treat the work as non-embedded and use the general skills (, ).
