stability-patterns
When a service calls other processes or holds queues and pools, bound connect and read deadlines, retries, circuit breakers, bulkheads, and buffers so one failed or slow dependency cannot exhaust the process. Use when adding or reviewing a remote call, pool, queue, cache, or retry. Use saga-orchestration for multi-step compensation, designing-sdks for a client library's retry API, and using-message-queues for broker setup.
- License 许可
- MIT
- 最近更新
- 2026-11-14
- Stars
- ★ 0
- Forks
- 0
01 前言 Front Matter
- name
- stability-patterns
- license
- MIT
- description
- When a service calls other processes or holds queues and pools, bound connect and read deadlines, retries, circuit breakers, bulkheads, and buffers so one failed or slow dependency cannot exhaust the process. Use when adding or reviewing a remote call, pool, queue, cache, or retry. Use saga-orchestration for multi-step compensation, designing-sdks for a client library's retry API, and using-message-queues for broker setup.
02 资源文件 3
- 许可证LICENSE1.3 KB
- 参考文档references/rules.md3.0 KB
- 参考文档references/sources.md4.1 KB
03 SKILL.md 正文
Stability patterns
One failed or slow dependency must not take the process down. Bound the wait, the retry, the concurrency, and the buffer.
When to Use
Use when a service calls another process, or when you add or change a queue, a pool, a cache, a buffer, or a retry.
Skip an in-process pure call. Skip installing a broker. Skip designing a multi-step compensation.
Other skills keep their jobs:
designing-sdksowns the public retry surface of a client library.designing-apisowns idempotency and rate-limit fields on a network contract.saga-orchestrationowns compensation across services.using-message-queuesowns the broker.observability-and-instrumentationowns metrics and alerts.backend-patternsis a Node snippet file. Its sample retry is not this policy.
Before the edit
- Read references/rules.md. Apply it to every call, pool, and buffer you add or change.
- Name the dependency, the resource it can exhaust, and the critical function that must still run.
- Find the bound that already exists in a mesh, a gateway, or a pool. Do not add a second copy of that same bound.
- Do not invent a threshold from a sample. Use the project's numbers. Put the unit in the name.
While editing
- Set an explicit connect deadline and an explicit read deadline on every cross-process call.
- Retry only idempotent or idempotency-keyed work, at one layer, with a hard attempt cap, capped backoff, and jitter.
- When a dependency's recent failure rate crosses its threshold, fail immediately. Admit a few probes before full traffic.
- Give each upstream its own pool or concurrency limit.
- Cap every queue, cache, and buffer. When it is full, reject or slow the producer.
- Reclaim logs, rows, temp files, and cache entries in application code.
- Reject bad input, and a dependency already known to be down, before taking a lock, a connection, or a worker slot.
- Under overload, shed or degrade low-value work first. Keep a path that still serves the critical function.
Stop
Stop when each call and buffer you touched has a named bound, and one stalled dependency cannot hold every thread, connection, or worker. Do not tune unrelated calls.
Report
For each dependency: deadlines, retry rule, breaker threshold, pool or concurrency limit, and buffer cap. Name the critical path you kept. Name any bound the platform already enforced, and any number the project did not supply.
Limitations
This skill does not choose a product, write a load test, or design compensation. It does not copy sample timeouts from a source. Cite references/sources.md. Conflict winners live only in that file.
04 同仓库更多 Skills
wiki-builder
Create and maintain a local Markdown research wiki (sources with provenance, compiled concept/source pages, index, maintenance log) driven by a per-wiki config. Use when the user wants to start a wiki or knowledge base, ingest sources into one, or query and update it; use wiki-page-writer for a single code deep-dive page.
refactoring-guru
Diagnose a named code smell and apply the smallest behavior-preserving refactoring, with verification before and after and an explicit stop condition. Use for structural refactors (extract, move, consolidate, change ownership), not for feature or bug work; for readability cleanup of recent changes use code-simplification.
legacy-seams
When changing untested legacy code, pin the observed results with characterization tests and open the smallest seam that substitutes only the blocking dependency, separate from any later logic change. Use when a clock, random source, I/O, global, or hidden constructor blocks a test or a safe edit. Use test-driven-development for a new behavior or a bug, refactoring-guru for one named structural refactor after the seam exists, and code-refactoring-tech-debt to choose which legacy to replace.
idea-refine
Refine a raw idea into a one-page brief (problem statement, recommended direction, assumptions to validate, MVP scope, not-doing list) through divergent then convergent thinking. Use when an idea is still vague or you want options and a stress test before committing; use interview-me when the goal itself is unclear and spec-driven-development once the direction is chosen.
code-review-and-quality
Review rubric and approval standard for any change before merge, including code written by you, another agent, or a human: five axes (correctness, readability, architecture, security, performance), change sizing, structural remedies, severity labels, and feedback technique. Use to judge whether a change is fit to merge; use code-review to run a PR or diff review end to end.
code-perfection
Smell and style gate for code you write or change. Bans known code smells (long method, large class, primitive obsession, long parameter list, data clumps, duplicate code, dead code, feature envy, shotgun surgery, flag arguments, message chains) and enforces behavior-preserving structure. On Scala files, enforces worxbend style. Use while implementing, reviewing a diff for smells, or when a smell or style violation is suspected. Routine construction stays with code-complete. SOLID and DRY stay with clean-code-guard. One named structural refactor stays with refactoring-guru.