swe-workflow-skills 0.1.0

package/skills/ml-pipeline-design/SKILL.md

@@ -0,0 +1,162 @@
+---
+name: ml-pipeline-design
+description: "Design reproducible ML training and data pipelines — ingestion, validation, feature engineering, training, evaluation, continuous training orchestration. Triggers: training pipeline, data pipeline, feature engineering, ETL for ML, continuous training, data validation, feature store, preprocessing, notebook to pipeline, orchestrate training, Airflow, Kubeflow, pipeline DAG."
+model: opus
+allowed-tools: Read, Grep, Glob, Write, Edit, Bash
+---
+
+# ML Pipeline Design
+
+Design reproducible, automated ML pipelines that transform notebooks into production-grade workflows. A pipeline is the difference between "I ran this notebook and got good results" and "this system produces, validates, and deploys models automatically."
+
+## Why Pipelines Matter
+
+Manual ML workflows break in predictable ways:
+- **Undocumented steps**: "You need to run cell 7 before cell 3, but skip cell 5"
+- **Hidden state**: Notebook variables carry state between cells that isn't captured
+- **No validation**: Bad data enters silently and produces silently bad models
+- **No automation**: Retraining requires a human to re-run the notebook
+- **No lineage**: "Which data produced this model?" becomes unanswerable
+
+Pipelines solve all of these by making each step explicit, validated, and reproducible.
+
+## Workflow
+
+### Step 1: Map the Pipeline Stages
+
+Every ML pipeline follows this general DAG (Directed Acyclic Graph):
+
+```
+Data Ingestion → Data Validation → Feature Engineering → Data Split
+                                                            ↓
+Model Evaluation ← Model Training ← Hyperparameter Config
+      ↓
+Model Validation → Model Registration → (Optional) Deployment
+```
+
+Identify which stages the user's workflow needs. Not every project needs every stage — a simple model might skip feature stores and hyperparameter tuning.
+
+### Step 2: Design Each Stage
+
+**Data Ingestion:**
+- Where does raw data come from? (Database, API, files, streaming)
+- How is it versioned? (DVC, Delta Lake, immutable snapshots)
+- What's the trigger? (Schedule, event, data arrival)
+
+**Data Validation:**
+- Schema validation: Do columns exist? Are types correct?
+- Statistical validation: Are distributions within expected ranges?
+- Freshness checks: Is the data recent enough?
+- Completeness checks: Missing value rates within tolerance?
+
+Use frameworks like Great Expectations, Pandera, or TensorFlow Data Validation. See [references/pipeline-components.md](references/pipeline-components.md).
+
+**Feature Engineering:**
+- Transform raw data into model-ready features
+- Document every transformation (input → output, rationale)
+- Ensure transformations are deterministic and reproducible
+- Consider a feature store for features reused across models (Feast, Tecton)
+- **Critical**: Use the same feature code for training and serving to prevent training-serving skew
+
+**Data Split:**
+- Train/validation/test split with consistent strategy
+- Time-based splits for temporal data (no future leakage)
+- Stratified splits for imbalanced classes
+- Document the split ratios and method
+
+**Model Training:**
+- Parameterized: hyperparameters passed as config, not hardcoded
+- Tracked: all runs logged to experiment tracker (use `ml-experiment-tracking` skill)
+- Resource-aware: specify compute requirements (GPU type, memory)
+
+**Model Evaluation:**
+- Evaluate on held-out test set (never used during training or tuning)
+- Compute all relevant metrics (not just accuracy)
+- Compare against baseline model (the one currently in production)
+- Check for fairness across segments if applicable
+- **Gate**: Only promote models that beat the baseline by a defined threshold
+
+**Model Validation (pre-deployment):**
+- Inference latency meets SLA
+- Model size fits the deployment target
+- No prediction anomalies on a validation dataset
+- Input/output schema matches the serving contract
+
+### Step 3: Choose the Orchestrator
+
+| Tool | Best For | Complexity |
+|------|----------|------------|
+| **Simple scripts + cron** | Single-model, small team | Low |
+| **Airflow / Dagster** | Data engineering teams, complex DAGs | Medium |
+| **Kubeflow Pipelines** | Kubernetes-native, large scale | High |
+| **Vertex AI / SageMaker Pipelines** | Cloud-native, managed | Medium |
+| **Prefect** | Python-native, modern alternative to Airflow | Medium |
+| **GitHub Actions** | Simple CI/CD-triggered training | Low |
+
+Start simple: scripts + cron or GitHub Actions for early-stage ML. Move to Airflow/Dagster when you have multiple pipelines and complex dependencies.
+
+### Step 4: Implement
+
+Write each pipeline stage as an independent, testable component:
+
+```python
+# Each stage is a function with clear inputs and outputs
+def ingest_data(source_config: dict) -> pd.DataFrame:
+    """Ingest data from configured source."""
+    ...
+
+def validate_data(df: pd.DataFrame, schema: Schema) -> ValidationResult:
+    """Validate data against expected schema and statistics."""
+    ...
+
+def engineer_features(df: pd.DataFrame, feature_config: dict) -> pd.DataFrame:
+    """Apply feature transformations."""
+    ...
+
+def train_model(X_train, y_train, hyperparams: dict) -> Model:
+    """Train model with given hyperparameters."""
+    ...
+
+def evaluate_model(model: Model, X_test, y_test) -> dict:
+    """Evaluate model and return metrics dict."""
+    ...
+```
+
+This pattern makes each stage unit-testable, composable, and replaceable.
+
+### Step 5: Add Data Validation Gates
+
+Data validation is the most overlooked and most valuable pipeline component. Bad data in → bad model out, silently.
+
+```python
+import pandera as pa
+
+# Define expected schema
+schema = pa.DataFrameSchema({
+    "user_id": pa.Column(int, nullable=False),
+    "amount": pa.Column(float, pa.Check.in_range(0, 100000)),
+    "category": pa.Column(str, pa.Check.isin(["A", "B", "C"])),
+    "timestamp": pa.Column(pd.Timestamp, nullable=False),
+})
+
+# Validate before training
+validated_df = schema.validate(raw_df)  # Raises on failure
+```
+
+### Step 6: Validate and Document
+
+- [ ] Pipeline runs end-to-end from raw data to registered model
+- [ ] Each stage can be run independently for debugging
+- [ ] Data validation catches bad data before training
+- [ ] Experiment tracking captures all runs
+- [ ] Model evaluation gates prevent worse models from being promoted
+- [ ] Pipeline configuration is version-controlled (not hardcoded)
+- [ ] Feature transformations are shared between training and serving
+
+## Principles Applied
+
+- **DRY**: Share feature engineering code between training pipeline and serving. One transformation definition, used everywhere.
+- **KISS**: Start with a linear script, refactor into a DAG when complexity demands it. Don't adopt Kubeflow for one model.
+- **YAGNI**: Don't build a feature store for 3 features. Build it when you have 50+ features shared across multiple models.
+- **Functional Independence**: Each pipeline stage is an independent component with defined inputs and outputs. Replace any stage without rewriting the pipeline.
+- **Fail fast**: Validate data at ingestion, not after 2 hours of training.

package/skills/ml-pipeline-design/evals/evals.json

@@ -0,0 +1,34 @@
+{
+  "skill_name": "ml-pipeline-design",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "I have a Jupyter notebook that trains a customer churn prediction model. It loads data from a PostgreSQL database, does feature engineering (one-hot encoding, aggregations), trains an XGBoost model, and evaluates it. I want to turn this into a proper automated pipeline that retrains weekly. We use Python and have access to AWS.",
+      "expected_output": "Should design a pipeline DAG with separate stages, add data validation, recommend an appropriate orchestrator, ensure feature engineering is shared with serving, and set up scheduling.",
+      "assertions": [
+        "Breaks the notebook into discrete pipeline stages (ingest, validate, features, train, evaluate)",
+        "Adds data validation between ingestion and feature engineering",
+        "Recommends appropriate orchestrator for the team size (not Kubeflow for one model)",
+        "Ensures feature engineering code is reusable for serving",
+        "Parameterizes hyperparameters and data source config",
+        "Includes model evaluation gate (only register if better than current)",
+        "Sets up weekly scheduling",
+        "Includes experiment tracking integration"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "Our training pipeline keeps producing bad models. Sometimes the accuracy drops from 92% to 60% overnight. We suspect it's a data issue but we're not sure. How do we prevent this?",
+      "expected_output": "Should diagnose as missing data validation and recommend adding validation gates at ingestion. Should design specific checks for the kinds of data issues that cause 30% accuracy drops.",
+      "assertions": [
+        "Identifies missing data validation as the root cause",
+        "Recommends schema validation (column existence, types)",
+        "Recommends statistical validation (distribution checks, null rates)",
+        "Recommends volume checks (row count within expected range)",
+        "Suggests comparing incoming data against a training baseline",
+        "Recommends the pipeline should FAIL on bad data, not train on it",
+        "Provides concrete implementation (Great Expectations or Pandera)"
+      ]
+    }
+  ]
+}

package/skills/ml-pipeline-design/references/pipeline-components.md

@@ -0,0 +1,174 @@
+# Pipeline Components
+
+## Contents
+- Data validation frameworks
+- Feature store patterns
+- Pipeline testing strategies
+- Notebook-to-pipeline migration
+
+## Data Validation Frameworks
+
+### Great Expectations
+```python
+import great_expectations as gx
+
+context = gx.get_context()
+
+# Define expectations
+suite = context.add_expectation_suite("training_data_suite")
+
+# Column existence and types
+suite.add_expectation(gx.expectations.ExpectColumnToExist(column="user_id"))
+suite.add_expectation(gx.expectations.ExpectColumnValuesToBeBetween(
+    column="amount", min_value=0, max_value=100000
+))
+suite.add_expectation(gx.expectations.ExpectColumnValuesToNotBeNull(column="user_id"))
+suite.add_expectation(gx.expectations.ExpectColumnDistinctValuesToBeInSet(
+    column="category", value_set=["A", "B", "C"]
+))
+
+# Statistical expectations
+suite.add_expectation(gx.expectations.ExpectColumnMeanToBeBetween(
+    column="amount", min_value=50, max_value=500
+))
+
+# Run validation
+results = context.run_checkpoint(checkpoint_name="training_data_check")
+if not results.success:
+    raise ValueError(f"Data validation failed: {results}")
+```
+
+### Pandera (lightweight, Pandas-native)
+```python
+import pandera as pa
+
+schema = pa.DataFrameSchema(
+    columns={
+        "user_id": pa.Column(int, nullable=False, unique=True),
+        "amount": pa.Column(float, checks=[
+            pa.Check.in_range(0, 100000),
+            pa.Check(lambda s: s.mean() > 10, error="Mean amount suspiciously low")
+        ]),
+        "label": pa.Column(int, checks=pa.Check.isin([0, 1])),
+    },
+    checks=[
+        pa.Check(lambda df: len(df) > 1000, error="Dataset too small for training"),
+    ]
+)
+
+validated_df = schema.validate(raw_df)
+```
+
+### What to Validate
+
+| Check Type | Example | Why |
+|-----------|---------|-----|
+| Schema | All expected columns exist with correct types | Catches upstream schema changes |
+| Completeness | Null rate < 5% for critical columns | Prevents silent data loss |
+| Range | Amount between 0 and 100K | Catches data corruption or unit changes |
+| Distribution | Mean within 2σ of historical baseline | Catches data drift before training |
+| Freshness | Most recent record within last 24 hours | Catches stale data pipelines |
+| Volume | Row count within expected range | Catches missing or duplicated data |
+| Uniqueness | No duplicate IDs in primary key columns | Catches join explosions |
+
+## Feature Store Patterns
+
+### When to use a feature store
+
+Use a feature store when:
+- Multiple models share the same features
+- Training-serving skew is a known problem
+- Features require complex computation (aggregations over time windows)
+- You need point-in-time correctness for training data
+
+Don't use a feature store when:
+- You have one model with simple features
+- Features are raw columns with minimal transformation
+- The overhead of running a feature store exceeds the benefit
+
+### Feast (open-source) minimal setup
+```python
+# feature_store.yaml
+project: my_ml_project
+registry: data/registry.db
+provider: local
+online_store:
+  type: sqlite
+  path: data/online_store.db
+
+# feature_definitions.py
+from feast import Entity, FeatureView, Field, FileSource
+from feast.types import Float32, Int64
+
+user = Entity(name="user", join_keys=["user_id"])
+
+user_features = FeatureView(
+    name="user_features",
+    entities=[user],
+    schema=[
+        Field(name="avg_transaction_amount_30d", dtype=Float32),
+        Field(name="transaction_count_7d", dtype=Int64),
+        Field(name="days_since_last_login", dtype=Int64),
+    ],
+    source=FileSource(path="data/user_features.parquet", timestamp_field="event_timestamp"),
+)
+```
+
+## Pipeline Testing Strategies
+
+### Unit tests for pipeline components
+```python
+def test_feature_engineering():
+    """Test that feature engineering produces expected output."""
+    input_df = pd.DataFrame({
+        "amount": [100, 200, 300],
+        "timestamp": pd.to_datetime(["2025-01-01", "2025-01-02", "2025-01-03"]),
+    })
+    result = engineer_features(input_df)
+    assert "amount_log" in result.columns
+    assert "day_of_week" in result.columns
+    assert result["amount_log"].iloc[0] == pytest.approx(np.log1p(100))
+
+def test_data_validation_rejects_bad_data():
+    """Test that validation catches corrupt data."""
+    bad_df = pd.DataFrame({"amount": [-100, None, 999999999]})
+    with pytest.raises(pa.errors.SchemaError):
+        schema.validate(bad_df)
+```
+
+### Integration tests for pipeline
+```python
+def test_pipeline_end_to_end():
+    """Test full pipeline with small sample data."""
+    result = run_pipeline(
+        data_source="tests/fixtures/sample_data.csv",
+        config={"max_epochs": 2, "test_mode": True}
+    )
+    assert result.model is not None
+    assert result.metrics["accuracy"] > 0.5  # Sanity check, not quality check
+    assert result.artifacts_saved
+```
+
+## Notebook-to-Pipeline Migration
+
+### Step-by-step process
+
+1. **Extract functions**: Every cell block that does a distinct thing becomes a function with typed inputs and outputs.
+
+2. **Eliminate hidden state**: If cell 7 depends on a variable defined in cell 3, make it an explicit function parameter.
+
+3. **Add data validation**: Between ingestion and feature engineering, between feature engineering and training.
+
+4. **Parameterize**: Hardcoded paths, hyperparameters, and thresholds become config parameters.
+
+5. **Add logging**: Replace print statements with proper logging. Log to experiment tracker.
+
+6. **Write tests**: Test each extracted function independently with known inputs/outputs.
+
+7. **Orchestrate**: Chain functions in a pipeline script or DAG definition.
+
+### What to preserve from notebooks
+
+- **Visualizations**: Move to a separate analysis notebook or generate as pipeline artifacts
+- **EDA code**: Keep in a separate exploration notebook, not in the pipeline
+- **Scratch experiments**: Archive in an experiments directory, don't delete

package/skills/observability-design/SKILL.md

@@ -0,0 +1,162 @@
+---
+name: observability-design
+description: "Design production observability — SLIs, SLOs, SLAs, error budgets, OpenTelemetry traces/metrics/logs, structured logging, alerting, dashboards. Triggers: SLO, SLI, SLA, error budget, observability, monitoring, OpenTelemetry, OTel, tracing, distributed tracing, structured logging, alerting, dashboard, metrics, correlation ID, alert fatigue."
+model: sonnet
+allowed-tools: Read, Grep, Glob, Write, Edit
+---
+
+# Observability Design
+
+Design observability systems that answer "is the system healthy?" before users complain, and "why is it broken?" when they do. Good observability means you don't need to add more instrumentation to debug an issue — the signals are already there.
+
+## The Three Pillars + Reliability Framework
+
+Observability has three signal types (metrics, logs, traces) and one decision framework (SLIs/SLOs/error budgets). This skill covers all four.
+
+```
+SLIs/SLOs/Error Budgets → WHAT to measure and WHEN to act
+Metrics                  → HOW MUCH is happening (counters, gauges, histograms)
+Logs                     → WHAT happened in detail (events, errors, context)
+Traces                   → WHERE time was spent across services (request flow)
+```
+
+## Workflow: SLI/SLO Design
+
+### Step 1: Identify Critical User Journeys
+
+Before defining metrics, identify the 3-5 user-facing interactions that matter most:
+
+- What does a user do when the service is "working"? (Load a page, complete a checkout, send a message)
+- What would a user notice if the service degraded? (Slow responses, errors, stale data)
+
+SLIs must reflect user experience. Internal metrics (CPU usage, queue depth) are useful for debugging but should not be SLIs — users don't care about CPU.
+
+### Step 2: Define SLIs
+
+For each critical journey, define 1-2 SLIs. Express each SLI as a ratio:
+
+```
+SLI = (good events / total events) × 100%
+```
+
+Common SLI types:
+
+| SLI Type | Formula | Good For |
+|----------|---------|----------|
+| **Availability** | Successful requests / Total requests | APIs, web apps |
+| **Latency** | Requests < threshold / Total requests | User-facing endpoints |
+| **Quality** | Correct responses / Total responses | Data pipelines, ML serving |
+| **Freshness** | Data updated within threshold / Total checks | Caches, dashboards, feeds |
+
+Measure SLIs at the point closest to the user — load balancer logs or client-side metrics, not server-side process metrics.
+
+### Step 3: Set SLO Targets
+
+An SLO is the target value for an SLI over a rolling time window:
+
+```
+"99.9% of requests will succeed within 300ms over a 30-day rolling window"
+```
+
+Setting the right target:
+
+- **Don't base SLOs on current performance** — you'll lock yourself into an unsustainable target
+- **Start with user expectations** — what would cause a user to complain or leave?
+- **Leave room for innovation** — 99.99% uptime allows 4.3 minutes/month of downtime. 99.9% allows 43 minutes. That difference is engineering velocity.
+- **Set SLOs tighter than SLAs** — your SLO should trigger action before you breach your SLA
+
+See [references/slo-framework.md](references/slo-framework.md) for the nines table, error budget calculations, and SLO examples by service type.
+
+### Step 4: Calculate Error Budget
+
+```
+Error Budget = 100% - SLO target
+```
+
+If your SLO is 99.9% availability over 30 days:
+- Error budget = 0.1% = 43.2 minutes of downtime per month
+- Each incident consumes a portion of this budget
+
+Error budget policies define what happens when the budget runs low:
+
+- **Budget > 50% remaining**: Ship features normally
+- **Budget 25-50%**: Reduce deployment velocity, increase review rigor
+- **Budget < 25%**: Freeze non-critical deploys, focus on reliability
+- **Budget exhausted**: Full reliability focus until budget replenishes
+
+### Step 5: Document and Communicate
+
+Save the SLO document using the template at [templates/slo-document.md](templates/slo-document.md). Share with engineering, product, and on-call teams.
+
+## Workflow: OpenTelemetry Instrumentation
+
+### Step 1: Choose What to Instrument
+
+Don't instrument everything — instrument what matters:
+
+**Always instrument:**
+- HTTP/gRPC request handling (latency, status codes, paths)
+- Database queries (duration, query type, table)
+- External API calls (duration, status, endpoint)
+- Queue operations (publish, consume, processing time)
+- Authentication events (success, failure, method)
+
+**Instrument when needed:**
+- Business-specific operations (checkout, search, upload)
+- Cache operations (hit/miss ratio, latency)
+- Background jobs (duration, success/failure)
+
+### Step 2: Implement the Three Signals
+
+**Metrics** (aggregated measurements over time):
+- Use counters for events that only go up (requests, errors, bytes sent)
+- Use histograms for distributions (latency, request size)
+- Use gauges for point-in-time values (queue depth, active connections)
+- Follow OpenTelemetry semantic conventions for naming
+
+**Traces** (request flow across services):
+- Auto-instrument HTTP frameworks, database clients, and message queues
+- Add custom spans for business-critical operations
+- Propagate trace context across service boundaries (W3C Trace Context)
+- Add attributes (user ID, order ID, feature flag) to spans for filtering
+
+**Logs** (detailed event records):
+- Use structured JSON format, never unstructured text
+- Include trace ID and span ID in every log for correlation
+- Define consistent log levels (see [references/logging-patterns.md](references/logging-patterns.md))
+- Redact sensitive data (passwords, tokens, PII) before logging
+
+### Step 3: Set Up Alerting
+
+Alerts should be actionable. Every alert should answer: "What happened? Is it urgent? What should I do?"
+
+**Alert design rules:**
+- Alert on SLO burn rate, not raw metric thresholds — this catches meaningful degradation while ignoring noise
+- Every alert must link to a runbook
+- Use severity levels: Page (wake someone up) vs Notify (review next business day)
+- Set up multi-window burn rate alerts (fast burn = 1h window, slow burn = 6h window)
+- Test alerts — an untested alert is an alert that won't fire when needed
+
+See [references/logging-patterns.md](references/logging-patterns.md) for alerting patterns.
+
+### Step 4: Design Dashboards
+
+Dashboards should answer "is the system healthy?" in 5 seconds:
+
+**Service overview dashboard:**
+- SLO status and error budget remaining (the single most important panel)
+- Request rate, error rate, and latency percentiles (P50, P95, P99)
+- Active alerts
+
+**Debug dashboard (per service):**
+- Latency breakdown by dependency (database, cache, external APIs)
+- Error rate by error type/code
+- Resource utilization (CPU, memory, connections)
+- Recent deployments overlaid on metrics
+
+## Principles Applied
+
+- **KISS**: Start with availability and latency SLIs. Add quality and freshness only when needed.
+- **YAGNI**: Don't instrument everything on day one. Instrument the critical paths, add more when debugging reveals gaps.
+- **DRY**: Use OpenTelemetry auto-instrumentation for common frameworks. Only add manual instrumentation for business-specific operations.
+- **Functional Independence**: Each service owns its SLOs. Don't create SLOs that depend on another team's service — those become SLAs between teams.

package/skills/observability-design/evals/evals.json

@@ -0,0 +1,52 @@
+{
+  "skill_name": "observability-design",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "We're launching a B2B SaaS API that processes invoices. We need to define SLOs before launch. Our customers expect the API to be fast and reliable — they integrate it into their accounting workflows. We use Express.js, PostgreSQL, and deploy on AWS ECS. Help us design our SLOs.",
+      "expected_output": "Should identify critical user journeys (submit invoice, retrieve invoice, list invoices), define SLIs as ratios (availability, latency), set appropriate SLO targets, calculate error budgets, define error budget policies, and produce an SLO document.",
+      "assertions": [
+        "Identifies critical user journeys before defining metrics",
+        "Defines SLIs as good events / total events ratios",
+        "Sets availability SLO (e.g., 99.9%) with justification",
+        "Sets latency SLO with specific threshold (e.g., 99% < 500ms)",
+        "Calculates error budget in concrete terms (minutes or requests)",
+        "Defines error budget policy with escalating actions",
+        "Does NOT set SLOs at 99.99% without justifying the cost",
+        "Recommends measuring SLIs at the load balancer, not just app-side",
+        "Produces an SLO document using the template"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "We have a Node.js microservices architecture (5 services) and zero observability beyond console.log statements. Our CTO wants distributed tracing and proper monitoring. Where do we start?",
+      "expected_output": "Should recommend starting with OpenTelemetry auto-instrumentation on one service, then expanding. Should prioritize: structured logging → metrics → traces. Should not suggest instrumenting everything at once.",
+      "assertions": [
+        "Recommends starting with ONE service, not all five",
+        "Suggests OpenTelemetry auto-instrumentation as the quickest win",
+        "Prioritizes structured logging first (replacing console.log)",
+        "Recommends adding trace context to logs for correlation",
+        "Suggests an OTel Collector rather than direct-to-backend export",
+        "Does NOT recommend building custom instrumentation",
+        "Provides concrete Node.js OTel setup code",
+        "Suggests a backend for receiving telemetry (Jaeger, Grafana stack, etc.)",
+        "Applies KISS — not all 5 services on day one"
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "Our on-call engineers are getting 50+ alerts per week and most of them are noise. They're burned out and missing real incidents. How do we fix our alerting?",
+      "expected_output": "Should diagnose alert fatigue, recommend switching to SLO-based burn rate alerting, help classify alerts by severity, and suggest an alert review process.",
+      "assertions": [
+        "Identifies 50+/week as severe alert fatigue",
+        "Recommends auditing existing alerts (what fires, how often, what action was taken)",
+        "Suggests removing or silencing alerts that are never actionable",
+        "Recommends burn rate alerting instead of raw threshold alerting",
+        "Distinguishes between page-worthy (urgent) and ticket-worthy (can wait) alerts",
+        "Requires every alert to link to a runbook",
+        "Suggests a monthly alert review cadence",
+        "Does NOT just say 'raise the thresholds' — addresses root cause"
+      ]
+    }
+  ]
+}