# Forge Reliability

> Audit timeouts, retries, overload, dependencies, degradation, consistency, and operational objectives.

- Skill: `is-bo/forge-reliability-3` (Agent Skill)
- Install (CLI): `npx skillmds@latest add is-bo/forge-reliability-3`
- Raw SKILL.md: https://api.skillmd.com/api/skills/is-bo/forge-reliability-3/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: is-bo (https://skillmd.com/u/is-bo)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/is-bo/forge-reliability-3

---


# forge-reliability: Reliability

Engine: Hybrid — Forge + Google, Addy Osmani Agent Skills, Sentry, Cloudflare

## Purpose

Audit timeouts, retries, overload, dependencies, degradation, consistency, and operational objectives.


## Deterministic runtime composition

Before loading any provider procedure, run:

Resolve `../../runtime/cli/src/composition-entry.js` relative to this `SKILL.md`, then run:

`node "<resolved-absolute-runner-path>" reliability compose --workflow audit --root "<repository-root>" --dry-run --json`

Add one repeatable `--request <provider-or-source>` flag for each explicit user request. Add
`--condition <task-condition>` or `--risk-surface <surface>` only for a task fact you directly
proved; never infer one from generic wording. The command above is the default for this
audit-oriented module; for implementation use `--workflow build`, and for a fix, retest, or
release gate use `--workflow fix`, `verify`, or `ship` respectively. Read the JSON response,
keep the Forge contract at index zero, and resolve paths against the absolute `runtime_root`
reported in that response. Read `eager[].runtimePath` when entering the module. The full
`selected[]` list is availability/provenance; load only `deferred[].runtimePath` when the task
reaches that concern, in tier order. Refuse any path that escapes the root. Respect every reported
suppression and context budget. If `missing` is non-empty, stop and report the installation as
damaged; do not improvise a prose fallback. The runner and specialist content may live in a plugin
cache or global installation; never assume they are inside the audited repository.


Resolve and read `../fullstack-forge/references/shared/module-contract.md` (applicability,
execution, mutation, verification, completion) and
`../fullstack-forge/references/shared/evidence-rules.md` (statuses, standards, tools, findings via
`../fullstack-forge/references/PROTOCOL.md`) relative to this module `SKILL.md` before reporting.

Never hide failed checks or claim that an operation ran when it did not.

## Automatic activation signals

Activate when a request or direct repository evidence involves reliability, when
the user explicitly names `forge-reliability`, or when discovery proves an applicable boundary.

- Services and critical workflows with availability or durability expectations

## When not to activate

- Disposable local-only utilities with no reliability objective

## Automated support

Relevant discovery inputs are:

- dependency graph
- SLOs
- failure handling and incident history

Deterministic support, bounded evidence only:

- `detect-project-commands`
- `run-project-command`

## Agent inspection procedure

1. Enumerate external dependencies and verify every remote call has a timeout, a bounded retry with idempotency, and a defined failure behavior.
2. Trace one dependency outage end to end: what the user sees, what degrades, and what data risks inconsistency.
3. Inspect health and readiness checks for truthfulness (they verify real dependencies) and safe shutdown for in-flight work.
4. Check retry-storm and thundering-herd protections at every retry site, and circuit breaking where cascades are possible.
5. Verify stated SLOs, recovery procedures, and consistency guarantees against implementation evidence, not documentation.

Manual inspection requirements:

- Review known failure modes and incident learnings
- Confirm provider SLAs and operator escalation paths

Stack-specific guidance:

- Align platform health and termination semantics with application lifecycle

## Evidence to collect

Standards used as criteria:

- Google SRE principles
- RFC 9110

## Common production failures

- Define user-visible service indicators and error-budget expectations
- Inspect timeout budgets, bounded retries, jitter, circuit behavior, health checks, overload, bulkheads, and dependency fallbacks
- Check graceful shutdown, deploy overlap, consistency, partial failure, idempotency, and clock assumptions

## Missing-control checks

Each item needs direct evidence or one reasoned status.

- Timeouts
- Retries
- Retry storms
- Circuit breaking
- Graceful degradation
- Health checks
- Readiness checks
- Dependency failures
- Partial outages
- Failover
- Idempotency
- Load shedding
- Safe shutdown
- Data consistency
- SLOs
- Recovery procedures
- Regional failures
- Feature degradation
- User-visible failure behavior

## Commands and tools

- Run `forge reliability audit --json` or `fullstack-forge reliability audit --json` when
  an explicit audit is requested and the CLI is installed. Normal feature work does not require it.

## Safe fixes

- Add bounded timeouts, retry classification, and graceful shutdown
- Add health checks that reflect readiness without exposing internals

## Approval-required changes

- Changing consistency, fail-open behavior, provider topology, or availability targets

## Verification

- Inject dependency, timeout, overload, and shutdown failures
- Confirm recovery without duplicate durable effects

## Completion contract

Follow `fullstack-forge/references/shared/completion.md` and the limitations below.

## Known limitations

- Availability claims require measured production evidence