observability-engineering

Generates and manages platform/backend-agnostic observability artifacts, including alerts, dashboards, and SLAs, from a central model.

Updated Apr 11, 2026
One-click install
npx skills add https://github.com/jetteim/platform-workstation-bootstrap --skill observability-engineering-jetteim
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: observability-engineering
Source: https://github.com/jetteim/platform-workstation-bootstrap/tree/main/agents/skills/codex-curated/observability-engineering
Command: npx skills add https://github.com/jetteim/platform-workstation-bootstrap --skill observability-engineering-jetteim

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Observability engineering provides a neutral, model-driven approach to defining and implementing platform and service telemetry, SLOs, dashboards, and alerting artifacts, enabling consistent guardrails and governance across teams.

Core Features & Use Cases

  • Define OpenTelemetry-based semantic conventions and org-wide attributes to ensure consistent telemetry across services.
  • Generate and manage backend artifacts such as alerts, dashboards, SLOs, and policy checks from a neutral intent model.
  • Migrate or align legacy monitoring rules to the backend-neutral SLO/alert model, improving reliability and auditability.
  • Use bundled references or a private observability-model to drive intent-driven instrumentation and validation.

Quick Start

Load the observability model, define your intent, and generate the corresponding dashboards, alerts, and backend artifacts.

Frequently Asked Questions about observability-engineering

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I define OpenTelemetry semantic conventions for service observability?

OpenTelemetry semantic conventions for service observability are defined using a neutral intent model that standardizes org-wide attributes and telemetry data across services. This ensures consistent guardrails and governance across teams.

What is the best way to generate SLOs and alerting rules from a single model?

Generating SLOs and alerting rules is handled by a model-driven approach that produces backend artifacts from a neutral intent definition. This allows you to manage alerts, dashboards, and policy checks consistently.

How do I migrate legacy monitoring rules to a backend-neutral SLO and alert model?

Migrating legacy monitoring rules involves aligning them to the backend-neutral SLO and alert model. This improves reliability and auditability by standardizing alert context contracts and decision dashboard intents.

Can I use a private observability-model to drive intent-driven instrumentation?

Yes, you can use a private observability-model to drive intent-driven instrumentation. You can load your custom model alongside bundled references to validate and generate specific telemetry artifacts.

How does a generated artifact manifest work for platform observability?

A generated artifact manifest works by satisfying OpenTelemetry-based semantic conventions, org attributes, and alert context contracts to produce a tracked inventory of dashboards, alerts, and SLOs.

Do I need specific backend tools to manage dashboards and alerts with this approach?

No specific backend tools are required as dependencies. The approach uses a backend-neutral intent model to generate artifacts, allowing you to apply the outputs to your existing infrastructure and service observability platforms.