home / skills / tlabs-xyz / tbtc-v2-performance / global--error-handling

global--error-handling skill

/.codex/skills/global--error-handling

This skill enforces global error handling standards across the codebase, ensuring consistent responses and reliable observability.

npx playbooks add skill tlabs-xyz/tbtc-v2-performance --skill global--error-handling

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
387 B
---
name: global--error-handling
description: Apply the Agent OS standard for global error handling.
tags: [agent-os, standard, global]
---

# Global Error Handling

Use this skill when working on global error handling in this repo.

## Instructions

- Follow the standard in `agent-os/standards/global/error-handling.md`.

## References

- `agent-os/standards/global/error-handling.md`

Overview

This skill applies the Agent OS global error handling standard to TypeScript projects. It defines a consistent approach for capturing, classifying, and responding to errors across services and agent components. The goal is predictable behavior, better observability, and safer failure modes.

How this skill works

The skill inspects code paths to ensure global error handlers are present and properly configured. It enforces unified error shapes, centralized logging, and sanitized reports before external exposure. It also verifies integrations with monitoring, retry policies, and graceful shutdown behavior.

When to use it

  • When adding or auditing global error handling in an Agent OS-based TypeScript codebase.
  • When standardizing error shapes and propagation across microservices or agent modules.
  • When implementing observability: structured logs, error metrics, and alerting hooks.
  • When designing safe fallback and retry logic for transient failures.
  • When preparing an application for production reliability and incident response.

Best practices

  • Use a single global error handler entry point per process to centralize classification and logging.
  • Normalize errors to a defined shape that includes code, message, context, and safe metadata.
  • Avoid leaking sensitive data: sanitize stack traces and user inputs before external reporting.
  • Integrate with monitoring and alerting systems; emit structured metrics and severity labels.
  • Implement deterministic retry and backoff strategies for transient errors and circuit breakers for downstream faults.

Example use cases

  • Audit an existing TypeScript service and add a global handler that maps exceptions to HTTP responses and metrics.
  • Standardize error objects returned by different libraries and internal modules to improve traceability.
  • Add middleware to capture unhandled promise rejections and uncaught exceptions, then trigger graceful shutdown.
  • Verify that third-party SDK errors are wrapped with contextual information and classified for retries.
  • Configure logging to include correlation IDs and sanitized context for incident investigation.

FAQ

What should a normalized error include?

Include an error code, human message, deterministic classification (transient vs permanent), safe context fields, and an internal stack or reference for debugging.

How do I avoid exposing secrets in errors?

Sanitize inputs and context before logging or reporting, remove or redact tokens and PII, and provide only high-level messages to external clients.