Observability Designer (POWERFUL)
Design production-ready observability strategies combining metrics, logs, and traces.
How to use it
Claude Code
- Run the line below. It pulls the whole folder into
~/.claude/skills/observability-designer, including the files SKILL.md points to. - Describe your job in plain words. Claude Code follows the skill from there.
Claude Code — installs the whole folder, not just SKILL.md
npx degit alirezarezvani/claude-skills/engineering/skills/observability-designer#main ~/.claude/skills/observability-designerFor one project only, change the path to .claude/skills/observability-designer. This skill also uses slo_designer.py, dashboard_generator.py, alert_optimizer.py, dashboard.json, dashboard.md, alerts.json — copying SKILL.md alone won't be enough. See the folder on GitHub.
Claude (web or desktop app)
- On this page open ⋯ → Download .md.
- Save it as SKILL.md in a folder, zip the folder, then Customize → Skills → + → Create skill → Upload a skill.
- Pick the file and Save. Claude shows the name and description and runs a security scan.
- Check the skill is switched on.
- Start a new chat and describe your job in plain words. The AI follows the skill from there.
ChatGPT or another app
- ChatGPT: make a Project and paste it into Instructions.
- Neither? Paste it at the top of a new chat — it works for that chat.
Not working?
- Check which app you pasted it into — the steps above name the right one.
- Some skills need the paid tier of Claude or ChatGPT.
Paste into Claude, ChatGPT or Cursor.
Source of Observability Designer (POWERFUL)
Show the full text273 lines
| name | description |
|---|---|
| observability-designer | Design production-ready observability strategies combining metrics, logs, and traces. Includes SLI/SLO design, golden-signals monitoring, alert optimization. Use when adding observability to a new service, refactoring alerting that is too noisy, or designing an SLO program before scaling production load. |
Observability Designer (POWERFUL)
Category: Engineering
Tier: POWERFUL
Description: Design comprehensive observability strategies for production systems including SLI/SLO frameworks, alerting optimization, and dashboard generation.
Overview
Observability Designer creates production-ready dashboards, alert configurations, and monitoring strategies across the three pillars (metrics, logs, traces).
When NOT to use → slo-architect. For SLO/SLI design with error-budget math, multi-window burn-rate alerting thresholds, and SLO review gates, route to slo-architect — it is the authoritative skill for that half. This skill's slo_designer.py produces a quick scaffold only. This skill's lane: dashboards (dashboard_generator.py) and alert-noise reduction (alert_optimizer.py).
Quick Start
# Dashboard spec (Grafana JSON + docs) for a service
python3 scripts/dashboard_generator.py --service-type api --name payments --criticality critical --role sre --format grafana -o dashboard.json --doc-output dashboard.md
# Analyze an existing alert config for noise, duplicates, and coverage gaps
python3 scripts/alert_optimizer.py --input alerts.json --analyze-only --report alert_report.json
# ...then emit the optimized config once the report is reviewed:
python3 scripts/alert_optimizer.py --input alerts.json --output alerts_optimized.json
# Quick SLO scaffold (hand off to slo-architect for the real error-budget work)
python3 scripts/slo_designer.py --service-type api --criticality high --user-facing true --service-name payments -o slo_scaffold.json
Verification loop: after deploying optimized alerts, track the report's noise metrics for one on-call rotation — if the actionable-alert ratio didn't improve, re-run --analyze-only against the live config and iterate. Import the generated dashboard into Grafana and confirm every golden-signal panel renders with live data before closing the task.
Core Competencies
SLI/SLO/SLA Framework Design
- Service Level Indicators (SLI): Define measurable signals that indicate service health
- Service Level Objectives (SLO): Set reliability targets based on user experience
- Service Level Agreements (SLA): Establish customer-facing commitments with consequences
- Error Budget Management: Calculate and track error budget consumption
- Burn Rate Alerting: Multi-window burn rate alerts for proactive SLO protection
Three Pillars of Observability
Metrics
- Golden Signals: Latency, traffic, errors, and saturation monitoring
- RED Method: Rate, Errors, and Duration for request-driven services
- USE Method: Utilization, Saturation, and Errors for resource monitoring
- Business Metrics: Revenue, user engagement, and feature adoption tracking
- Infrastructure Metrics: CPU, memory, disk, network, and custom resource metrics
Logs
- Structured Logging: JSON-based log formats with consistent fields
- Log Aggregation: Centralized log collection and indexing strategies
- Log Levels: Appropriate use of DEBUG, INFO, WARN, ERROR, FATAL levels
- Correlation IDs: Request tracing through distributed systems
- Log Sampling: Volume management for high-throughput systems
Traces
- Distributed Tracing: End-to-end request flow visualization
- Span Design: Meaningful span boundaries and metadata
- Trace Sampling: Intelligent sampling strategies for performance and cost
- Service Maps: Automatic dependency discovery through traces
- Root Cause Analysis: Trace-driven debugging workflows
Dashboard Design Principles
Information Architecture
- Hierarchy: Overview → Service → Component → Instance drill-down paths
- Golden Ratio: 80% operational metrics, 20% exploratory metrics
- Cognitive Load: Maximum 7±2 panels per dashboard screen
- User Journey: Role-based dashboard personas (SRE, Developer, Executive)
Visualization Best Practices
- Chart Selection: Time series for trends, heatmaps for distributions, gauges for status
- Color Theory: Red for critical, amber for warning, green for healthy states
- Reference Lines: SLO targets, capacity thresholds, and historical baselines
- Time Ranges: Default to meaningful windows (4h for incidents, 7d for trends)
Panel Design
- Metric Queries: Efficient Prometheus/InfluxDB queries with proper aggregation
- Alerting Integration: Visual alert state indicators on relevant panels
- Interactive Elements: Template variables, drill-down links, and annotation overlays
- Performance: Sub-second render times through query optimization
Alert Design and Optimization
Alert Classification
- Severity Levels:
- Critical: Service down, SLO burn rate high
- Warning: Approaching thresholds, non-user-facing issues
- Info: Deployment notifications, capacity planning alerts
- Actionability: Every alert must have a clear response action
- Alert Routing: Escalation policies based on severity and team ownership
Alert Fatigue Prevention
- Signal vs Noise: High precision (few false positives) over high recall
- Hysteresis: Different thresholds for firing and resolving alerts
- Suppression: Dependent alert suppression during known outages
- Grouping: Related alerts grouped into single notifications
Alert Rule Design
- Threshold Selection: Statistical methods for threshold determination
- Window Functions: Appropriate averaging windows and percentile calculations
- Alert Lifecycle: Clear firing conditions and automatic resolution criteria
- Testing: Alert rule validation against historical data
Runbook Generation and Incident Response
Runbook Structure
- Alert Context: What the alert means and why it fired
- Impact Assessment: User-facing vs internal impact evaluation
- Investigation Steps: Ordered troubleshooting procedures with time estimates
- Resolution Actions: Common fixes and escalation procedures
- Post-Incident: Follow-up tasks and prevention measures
Incident Detection Patterns
- Anomaly Detection: Statistical methods for detecting unusual patterns
- Composite Alerts: Multi-signal alerts for complex failure modes
- Predictive Alerts: Capacity and trend-based forward-looking alerts
- Canary Monitoring: Early detection through progressive deployment monitoring
Golden Signals Framework
Latency Monitoring
- Request Latency: P50, P95, P99 response time tracking
- Queue Latency: Time spent waiting in processing queues
- Network Latency: Inter-service communication delays
- Database Latency: Query execution and connection pool metrics
Traffic Monitoring
- Request Rate: Requests per second with burst detection
- Bandwidth Usage: Network throughput and capacity utilization
- User Sessions: Active user tracking and session duration
- Feature Usage: API endpoint and feature adoption metrics
Error Monitoring
- Error Rate: 4xx and 5xx HTTP response code tracking
- Error Budget: SLO-based error rate targets and consumption
- Error Distribution: Error type classification and trending
- Silent Failures: Detection of processing failures without HTTP errors
Saturation Monitoring
- Resource Utilization: CPU, memory, disk, and network usage
- Queue Depth: Processing queue length and wait times
- Connection Pools: Database and service connection saturation
- Rate Limiting: API throttling and quota exhaustion tracking
Distributed Tracing Strategies
Trace Architecture
- Sampling Strategy: Head-based, tail-based, and adaptive sampling
- Trace Propagation: Context propagation across service boundaries
- Span Correlation: Parent-child relationship modeling
- Trace Storage: Retention policies and storage optimization
Service Instrumentation
- Auto-Instrumentation: Framework-based automatic trace generation
- Manual Instrumentation: Custom span creation for business logic
- Baggage Handling: Cross-cutting concern propagation
- Performance Impact: Instrumentation overhead measurement and optimization
Log Aggregation Patterns
Collection Architecture
- Agent Deployment: Log shipping agent strategies (push vs pull)
- Log Routing: Topic-based routing and filtering
- Parsing Strategies: Structured vs unstructured log handling
- Schema Evolution: Log format versioning and migration
Storage and Indexing
- Index Design: Optimized field indexing for common query patterns
- Retention Policies: Time and volume-based log retention
- Compression: Log data compression and archival strategies
- Search Performance: Query optimization and result caching
Cost Optimization for Observability
Data Management
- Metric Retention: Tiered retention based on metric importance
- Log Sampling: Intelligent sampling to reduce ingestion costs
- Trace Sampling: Cost-effective trace collection strategies
- Data Archival: Cold storage for historical observability data
Resource Optimization
- Query Efficiency: Optimized metric and log queries
- Storage Costs: Appropriate storage tiers for different data types
- Ingestion Rate Limiting: Controlled data ingestion to manage costs
- Cardinality Management: High-cardinality metric detection and mitigation
Scripts Overview
This skill includes three powerful Python scripts for comprehensive observability design:
1. SLO Designer (slo_designer.py)
Generates complete SLI/SLO frameworks based on service characteristics:
- Input: Service description JSON (type, criticality, dependencies)
- Output: SLI definitions, SLO targets, error budgets, burn rate alerts, SLA recommendations
- Features: Multi-window burn rate calculations, error budget policies, alert rule generation
2. Alert Optimizer (alert_optimizer.py)
Analyzes and optimizes existing alert configurations:
- Input: Alert configuration JSON with rules, thresholds, and routing
- Output: Optimization report and improved alert configuration
- Features: Noise detection, coverage gaps, duplicate identification, threshold optimization
3. Dashboard Generator (dashboard_generator.py)
Creates comprehensive dashboard specifications:
- Input: Service/system description JSON
- Output: Grafana-compatible dashboard JSON and documentation
- Features: Golden signals coverage, RED/USE methods, drill-down paths, role-based views
Integration Patterns
Monitoring Stack Integration
- Prometheus: Metric collection and alerting rule generation
- Grafana: Dashboard creation and visualization configuration
- Elasticsearch/Kibana: Log analysis and dashboard integration
- Jaeger/Zipkin: Distributed tracing configuration and analysis
CI/CD Integration
- Pipeline Monitoring: Build, test, and deployment observability
- Deployment Correlation: Release impact tracking and rollback triggers
- Feature Flag Monitoring: A/B test and feature rollout observability
- Performance Regression: Automated performance monitoring in pipelines
Incident Management Integration
- PagerDuty/VictorOps: Alert routing and escalation policies
- Slack/Teams: Notification and collaboration integration
- JIRA/ServiceNow: Incident tracking and resolution workflows
- Post-Mortem: Automated incident analysis and improvement tracking
Advanced Patterns
Multi-Cloud Observability
- Cross-Cloud Metrics: Unified metrics across AWS, GCP, Azure
- Network Observability: Inter-cloud connectivity monitoring
- Cost Attribution: Cloud resource cost tracking and optimization
- Compliance Monitoring: Security and compliance posture tracking
Microservices Observability
- Service Mesh Integration: Istio/Linkerd observability configuration
- API Gateway Monitoring: Request routing and rate limiting observability
- Container Orchestration: Kubernetes cluster and workload monitoring
- Service Discovery: Dynamic service monitoring and health checks
Machine Learning Observability
- Model Performance: Accuracy, drift, and bias monitoring
- Feature Store Monitoring: Feature quality and freshness tracking
- Pipeline Observability: ML pipeline execution and performance monitoring
- A/B Test Analysis: Statistical significance and business impact measurement
Best Practices
Organizational Alignment
- SLO Setting: Collaborative target setting between product and engineering
- Alert Ownership: Clear escalation paths and team responsibilities
- Dashboard Governance: Centralized dashboard management and standards
- Training Programs: Team education on observability tools and practices
Technical Excellence
- Infrastructure as Code: Observability configuration version control
- Testing Strategy: Alert rule testing and dashboard validation
- Performance Monitoring: Observability system performance tracking
- Security Considerations: Access control and data privacy in observability
Continuous Improvement
- Metrics Review: Regular SLI/SLO effectiveness assessment
- Alert Tuning: Ongoing alert threshold and routing optimization
- Dashboard Evolution: User feedback-driven dashboard improvements
- Tool Evaluation: Regular assessment of observability tool effectiveness
| 1 | |
| 2 | name "observability-designer" |
| 3 | description "Design production-ready observability strategies combining metrics, logs, and traces. Includes SLI/SLO design, golden-signals monitoring, alert optimization. Use when adding observability to a new service, refactoring alerting that is too noisy, or designing an SLO program before scaling production load." |
| 4 | |
| 5 | |
| 6 | # Observability Designer (POWERFUL) |
| 7 | |
| 8 | **Category:** Engineering |
| 9 | **Tier:** POWERFUL |
| 10 | **Description:** Design comprehensive observability strategies for production systems including SLI/SLO frameworks, alerting optimization, and dashboard generation. |
| 11 | |
| 12 | ## Overview |
| 13 | |
| 14 | Observability Designer creates production-ready dashboards, alert configurations, and monitoring strategies across the three pillars (metrics, logs, traces). |
| 15 | |
| 16 | **When NOT to use → slo-architect.** For SLO/SLI design with error-budget math, multi-window burn-rate alerting thresholds, and SLO review gates, route to `slo-architect` — it is the authoritative skill for that half. This skill's `slo_designer.py` produces a quick scaffold only. This skill's lane: dashboards (`dashboard_generator.py`) and alert-noise reduction (`alert_optimizer.py`). |
| 17 | |
| 18 | ## Quick Start |
| 19 | |
| 20 | |
| 21 | # Dashboard spec (Grafana JSON + docs) for a service |
| 22 | python3 scripts/dashboard_generator.py --service-type api --name payments --criticality critical --role sre --format grafana -o dashboard.json --doc-output dashboard.md |
| 23 | |
| 24 | # Analyze an existing alert config for noise, duplicates, and coverage gaps |
| 25 | python3 scripts/alert_optimizer.py --input alerts.json --analyze-only --report alert_report.json |
| 26 | # ...then emit the optimized config once the report is reviewed: |
| 27 | python3 scripts/alert_optimizer.py --input alerts.json --output alerts_optimized.json |
| 28 | |
| 29 | # Quick SLO scaffold (hand off to slo-architect for the real error-budget work) |
| 30 | python3 scripts/slo_designer.py --service-type api --criticality high --user-facing true --service-name payments -o slo_scaffold.json |
| 31 | |
| 32 | |
| 33 | **Verification loop:** after deploying optimized alerts, track the report's noise metrics for one on-call rotation — if the actionable-alert ratio didn't improve, re-run `--analyze-only` against the live config and iterate. Import the generated dashboard into Grafana and confirm every golden-signal panel renders with live data before closing the task. |
| 34 | |
| 35 | ## Core Competencies |
| 36 | |
| 37 | ### SLI/SLO/SLA Framework Design |
| 38 | **Service Level Indicators (SLI):** Define measurable signals that indicate service health |
| 39 | **Service Level Objectives (SLO):** Set reliability targets based on user experience |
| 40 | **Service Level Agreements (SLA):** Establish customer-facing commitments with consequences |
| 41 | **Error Budget Management:** Calculate and track error budget consumption |
| 42 | **Burn Rate Alerting:** Multi-window burn rate alerts for proactive SLO protection |
| 43 | |
| 44 | ### Three Pillars of Observability |
| 45 | |
| 46 | #### Metrics |
| 47 | **Golden Signals:** Latency, traffic, errors, and saturation monitoring |
| 48 | **RED Method:** Rate, Errors, and Duration for request-driven services |
| 49 | **USE Method:** Utilization, Saturation, and Errors for resource monitoring |
| 50 | **Business Metrics:** Revenue, user engagement, and feature adoption tracking |
| 51 | **Infrastructure Metrics:** CPU, memory, disk, network, and custom resource metrics |
| 52 | |
| 53 | #### Logs |
| 54 | **Structured Logging:** JSON-based log formats with consistent fields |
| 55 | **Log Aggregation:** Centralized log collection and indexing strategies |
| 56 | **Log Levels:** Appropriate use of DEBUG, INFO, WARN, ERROR, FATAL levels |
| 57 | **Correlation IDs:** Request tracing through distributed systems |
| 58 | **Log Sampling:** Volume management for high-throughput systems |
| 59 | |
| 60 | #### Traces |
| 61 | **Distributed Tracing:** End-to-end request flow visualization |
| 62 | **Span Design:** Meaningful span boundaries and metadata |
| 63 | **Trace Sampling:** Intelligent sampling strategies for performance and cost |
| 64 | **Service Maps:** Automatic dependency discovery through traces |
| 65 | **Root Cause Analysis:** Trace-driven debugging workflows |
| 66 | |
| 67 | ### Dashboard Design Principles |
| 68 | |
| 69 | #### Information Architecture |
| 70 | **Hierarchy:** Overview → Service → Component → Instance drill-down paths |
| 71 | **Golden Ratio:** 80% operational metrics, 20% exploratory metrics |
| 72 | **Cognitive Load:** Maximum 7±2 panels per dashboard screen |
| 73 | **User Journey:** Role-based dashboard personas (SRE, Developer, Executive) |
| 74 | |
| 75 | #### Visualization Best Practices |
| 76 | **Chart Selection:** Time series for trends, heatmaps for distributions, gauges for status |
| 77 | **Color Theory:** Red for critical, amber for warning, green for healthy states |
| 78 | **Reference Lines:** SLO targets, capacity thresholds, and historical baselines |
| 79 | **Time Ranges:** Default to meaningful windows (4h for incidents, 7d for trends) |
| 80 | |
| 81 | #### Panel Design |
| 82 | **Metric Queries:** Efficient Prometheus/InfluxDB queries with proper aggregation |
| 83 | **Alerting Integration:** Visual alert state indicators on relevant panels |
| 84 | **Interactive Elements:** Template variables, drill-down links, and annotation overlays |
| 85 | **Performance:** Sub-second render times through query optimization |
| 86 | |
| 87 | ### Alert Design and Optimization |
| 88 | |
| 89 | #### Alert Classification |
| 90 | **Severity Levels:** |
| 91 | **Critical:** Service down, SLO burn rate high |
| 92 | **Warning:** Approaching thresholds, non-user-facing issues |
| 93 | **Info:** Deployment notifications, capacity planning alerts |
| 94 | **Actionability:** Every alert must have a clear response action |
| 95 | **Alert Routing:** Escalation policies based on severity and team ownership |
| 96 | |
| 97 | #### Alert Fatigue Prevention |
| 98 | **Signal vs Noise:** High precision (few false positives) over high recall |
| 99 | **Hysteresis:** Different thresholds for firing and resolving alerts |
| 100 | **Suppression:** Dependent alert suppression during known outages |
| 101 | **Grouping:** Related alerts grouped into single notifications |
| 102 | |
| 103 | #### Alert Rule Design |
| 104 | **Threshold Selection:** Statistical methods for threshold determination |
| 105 | **Window Functions:** Appropriate averaging windows and percentile calculations |
| 106 | **Alert Lifecycle:** Clear firing conditions and automatic resolution criteria |
| 107 | **Testing:** Alert rule validation against historical data |
| 108 | |
| 109 | ### Runbook Generation and Incident Response |
| 110 | |
| 111 | #### Runbook Structure |
| 112 | **Alert Context:** What the alert means and why it fired |
| 113 | **Impact Assessment:** User-facing vs internal impact evaluation |
| 114 | **Investigation Steps:** Ordered troubleshooting procedures with time estimates |
| 115 | **Resolution Actions:** Common fixes and escalation procedures |
| 116 | **Post-Incident:** Follow-up tasks and prevention measures |
| 117 | |
| 118 | #### Incident Detection Patterns |
| 119 | **Anomaly Detection:** Statistical methods for detecting unusual patterns |
| 120 | **Composite Alerts:** Multi-signal alerts for complex failure modes |
| 121 | **Predictive Alerts:** Capacity and trend-based forward-looking alerts |
| 122 | **Canary Monitoring:** Early detection through progressive deployment monitoring |
| 123 | |
| 124 | ### Golden Signals Framework |
| 125 | |
| 126 | #### Latency Monitoring |
| 127 | **Request Latency:** P50, P95, P99 response time tracking |
| 128 | **Queue Latency:** Time spent waiting in processing queues |
| 129 | **Network Latency:** Inter-service communication delays |
| 130 | **Database Latency:** Query execution and connection pool metrics |
| 131 | |
| 132 | #### Traffic Monitoring |
| 133 | **Request Rate:** Requests per second with burst detection |
| 134 | **Bandwidth Usage:** Network throughput and capacity utilization |
| 135 | **User Sessions:** Active user tracking and session duration |
| 136 | **Feature Usage:** API endpoint and feature adoption metrics |
| 137 | |
| 138 | #### Error Monitoring |
| 139 | **Error Rate:** 4xx and 5xx HTTP response code tracking |
| 140 | **Error Budget:** SLO-based error rate targets and consumption |
| 141 | **Error Distribution:** Error type classification and trending |
| 142 | **Silent Failures:** Detection of processing failures without HTTP errors |
| 143 | |
| 144 | #### Saturation Monitoring |
| 145 | **Resource Utilization:** CPU, memory, disk, and network usage |
| 146 | **Queue Depth:** Processing queue length and wait times |
| 147 | **Connection Pools:** Database and service connection saturation |
| 148 | **Rate Limiting:** API throttling and quota exhaustion tracking |
| 149 | |
| 150 | ### Distributed Tracing Strategies |
| 151 | |
| 152 | #### Trace Architecture |
| 153 | **Sampling Strategy:** Head-based, tail-based, and adaptive sampling |
| 154 | **Trace Propagation:** Context propagation across service boundaries |
| 155 | **Span Correlation:** Parent-child relationship modeling |
| 156 | **Trace Storage:** Retention policies and storage optimization |
| 157 | |
| 158 | #### Service Instrumentation |
| 159 | **Auto-Instrumentation:** Framework-based automatic trace generation |
| 160 | **Manual Instrumentation:** Custom span creation for business logic |
| 161 | **Baggage Handling:** Cross-cutting concern propagation |
| 162 | **Performance Impact:** Instrumentation overhead measurement and optimization |
| 163 | |
| 164 | ### Log Aggregation Patterns |
| 165 | |
| 166 | #### Collection Architecture |
| 167 | **Agent Deployment:** Log shipping agent strategies (push vs pull) |
| 168 | **Log Routing:** Topic-based routing and filtering |
| 169 | **Parsing Strategies:** Structured vs unstructured log handling |
| 170 | **Schema Evolution:** Log format versioning and migration |
| 171 | |
| 172 | #### Storage and Indexing |
| 173 | **Index Design:** Optimized field indexing for common query patterns |
| 174 | **Retention Policies:** Time and volume-based log retention |
| 175 | **Compression:** Log data compression and archival strategies |
| 176 | **Search Performance:** Query optimization and result caching |
| 177 | |
| 178 | ### Cost Optimization for Observability |
| 179 | |
| 180 | #### Data Management |
| 181 | **Metric Retention:** Tiered retention based on metric importance |
| 182 | **Log Sampling:** Intelligent sampling to reduce ingestion costs |
| 183 | **Trace Sampling:** Cost-effective trace collection strategies |
| 184 | **Data Archival:** Cold storage for historical observability data |
| 185 | |
| 186 | #### Resource Optimization |
| 187 | **Query Efficiency:** Optimized metric and log queries |
| 188 | **Storage Costs:** Appropriate storage tiers for different data types |
| 189 | **Ingestion Rate Limiting:** Controlled data ingestion to manage costs |
| 190 | **Cardinality Management:** High-cardinality metric detection and mitigation |
| 191 | |
| 192 | ## Scripts Overview |
| 193 | |
| 194 | This skill includes three powerful Python scripts for comprehensive observability design: |
| 195 | |
| 196 | ### 1. SLO Designer (`slo_designer.py`) |
| 197 | Generates complete SLI/SLO frameworks based on service characteristics: |
| 198 | **Input:** Service description JSON (type, criticality, dependencies) |
| 199 | **Output:** SLI definitions, SLO targets, error budgets, burn rate alerts, SLA recommendations |
| 200 | **Features:** Multi-window burn rate calculations, error budget policies, alert rule generation |
| 201 | |
| 202 | ### 2. Alert Optimizer (`alert_optimizer.py`) |
| 203 | Analyzes and optimizes existing alert configurations: |
| 204 | **Input:** Alert configuration JSON with rules, thresholds, and routing |
| 205 | **Output:** Optimization report and improved alert configuration |
| 206 | **Features:** Noise detection, coverage gaps, duplicate identification, threshold optimization |
| 207 | |
| 208 | ### 3. Dashboard Generator (`dashboard_generator.py`) |
| 209 | Creates comprehensive dashboard specifications: |
| 210 | **Input:** Service/system description JSON |
| 211 | **Output:** Grafana-compatible dashboard JSON and documentation |
| 212 | **Features:** Golden signals coverage, RED/USE methods, drill-down paths, role-based views |
| 213 | |
| 214 | ## Integration Patterns |
| 215 | |
| 216 | ### Monitoring Stack Integration |
| 217 | **Prometheus:** Metric collection and alerting rule generation |
| 218 | **Grafana:** Dashboard creation and visualization configuration |
| 219 | **Elasticsearch/Kibana:** Log analysis and dashboard integration |
| 220 | **Jaeger/Zipkin:** Distributed tracing configuration and analysis |
| 221 | |
| 222 | ### CI/CD Integration |
| 223 | **Pipeline Monitoring:** Build, test, and deployment observability |
| 224 | **Deployment Correlation:** Release impact tracking and rollback triggers |
| 225 | **Feature Flag Monitoring:** A/B test and feature rollout observability |
| 226 | **Performance Regression:** Automated performance monitoring in pipelines |
| 227 | |
| 228 | ### Incident Management Integration |
| 229 | **PagerDuty/VictorOps:** Alert routing and escalation policies |
| 230 | **Slack/Teams:** Notification and collaboration integration |
| 231 | **JIRA/ServiceNow:** Incident tracking and resolution workflows |
| 232 | **Post-Mortem:** Automated incident analysis and improvement tracking |
| 233 | |
| 234 | ## Advanced Patterns |
| 235 | |
| 236 | ### Multi-Cloud Observability |
| 237 | **Cross-Cloud Metrics:** Unified metrics across AWS, GCP, Azure |
| 238 | **Network Observability:** Inter-cloud connectivity monitoring |
| 239 | **Cost Attribution:** Cloud resource cost tracking and optimization |
| 240 | **Compliance Monitoring:** Security and compliance posture tracking |
| 241 | |
| 242 | ### Microservices Observability |
| 243 | **Service Mesh Integration:** Istio/Linkerd observability configuration |
| 244 | **API Gateway Monitoring:** Request routing and rate limiting observability |
| 245 | **Container Orchestration:** Kubernetes cluster and workload monitoring |
| 246 | **Service Discovery:** Dynamic service monitoring and health checks |
| 247 | |
| 248 | ### Machine Learning Observability |
| 249 | **Model Performance:** Accuracy, drift, and bias monitoring |
| 250 | **Feature Store Monitoring:** Feature quality and freshness tracking |
| 251 | **Pipeline Observability:** ML pipeline execution and performance monitoring |
| 252 | **A/B Test Analysis:** Statistical significance and business impact measurement |
| 253 | |
| 254 | ## Best Practices |
| 255 | |
| 256 | ### Organizational Alignment |
| 257 | **SLO Setting:** Collaborative target setting between product and engineering |
| 258 | **Alert Ownership:** Clear escalation paths and team responsibilities |
| 259 | **Dashboard Governance:** Centralized dashboard management and standards |
| 260 | **Training Programs:** Team education on observability tools and practices |
| 261 | |
| 262 | ### Technical Excellence |
| 263 | **Infrastructure as Code:** Observability configuration version control |
| 264 | **Testing Strategy:** Alert rule testing and dashboard validation |
| 265 | **Performance Monitoring:** Observability system performance tracking |
| 266 | **Security Considerations:** Access control and data privacy in observability |
| 267 | |
| 268 | ### Continuous Improvement |
| 269 | **Metrics Review:** Regular SLI/SLO effectiveness assessment |
| 270 | **Alert Tuning:** Ongoing alert threshold and routing optimization |
| 271 | **Dashboard Evolution:** User feedback-driven dashboard improvements |
| 272 | **Tool Evaluation:** Regular assessment of observability tool effectiveness |
| 273 |
Discussion
Professional Full-Stack Developer for Network Mapping & Monitoring ApplicationAct as a professional full-stack developer tasked with building a web application for mapping and monitoring networks using Mikrotik Netwatch API. Implement multi-user role-based management to handle devices, monitor their status, and manage user subscriptions.Prompt refinerHigh-end Prompt Engineering & Prompt Refiner skill. Transforms raw or messy user requests into concise, token-efficient, high-performance master prompts for systems like GPT, Claude, and Gemini. Use when you want to optimize or redesign a prompt so it solves the problem reliably while minimizing tokens.Constraint driven developmentEstablishes a project's quality bar as a written contract and stops agents quietly lowering it. Interviews the user on which dimensions matter, supplies sane default thresholds when they have no number in mind, records everything in CONSTRAINTS.md, and watches the diff for a weakened bar — new @ts-ignore or eslint-disable suppressions, skipped or deleted tests, assertions stripped out, unimplemented stubs, thresholds edited down. Use when no quality bar is written down, when the user says "set up constraints" or "define our standards", when the user wants dimensions they care about — accessibility, web performance, coverage — set up as enforced constraints, when an agent keeps silencing checks or skipping tests to get to green, when you need a coverage or performance threshold and don't know what number to pick, or when an agent writes more code than anyone will read.Observability and instrumentationInstruments code so production behavior is visible and diagnosable. Use when adding logging, metrics, tracing, or alerting. Use when shipping any feature that runs in production and you need evidence it works. Use when production issues are reported but you can't tell what happened from the available data.
Browse more free Claude skills or everything in Development.