From 5edcd47fbf8abb52aa7d36a487f6b0d50a9ab2dd Mon Sep 17 00:00:00 2001 From: Yordis Prieto Date: Thu, 2 Apr 2026 18:39:37 -0400 Subject: [PATCH 1/4] fix(trogonstack-datadog): reconcile Customer-Facing group with I/P/D prefix convention Closes #17 Signed-off-by: Yordis Prieto --- .../skills/datadog-review-dashboard/SKILL.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/plugins/trogonstack-datadog/skills/datadog-review-dashboard/SKILL.md b/plugins/trogonstack-datadog/skills/datadog-review-dashboard/SKILL.md index f98b330..44b288a 100644 --- a/plugins/trogonstack-datadog/skills/datadog-review-dashboard/SKILL.md +++ b/plugins/trogonstack-datadog/skills/datadog-review-dashboard/SKILL.md @@ -71,6 +71,8 @@ Check that every widget title uses the layer-priority prefix system: - `D0-N:` for domain (business metrics) - The number indicates priority within the layer (`0` = most critical) +**Customer-Facing group and the prefix system**: The Customer-Facing group is a cross-cutting view across layers, not a fourth layer. Widgets inside it retain their source-layer prefix (e.g., `P0: GraphQL Error Rate`, `D0: Purchase Success Rate`, `I0: Healthy Hosts`). The group name itself does not use a layer prefix — it is simply called "Customer-Facing" (or "Triage", "Overview", etc.). Query Value widgets in the Customer-Facing group do not need a prefix since they are big-number status indicators, not timeseries. + Focus on timeseries and query value widgets — these are the primary candidates for alert threshold markers. ### 3. Audit Alert Thresholds @@ -122,12 +124,13 @@ For each widget with a threshold: ### 5. Audit Customer-Facing Section -**Principle**: A dedicated "Customer-Facing" group should exist at the top of the dashboard with 5-8 key metrics for immediate outage identification. The specific metrics should reflect the product's business — not just generic traffic and error rates. +**Principle**: A dedicated "Customer-Facing" group should exist at the top of the dashboard with 5-8 key metrics for immediate outage identification. The specific metrics should reflect the product's business — not just generic traffic and error rates. This group is a cross-cutting view — its timeseries widgets keep their source-layer prefix (`I`, `P`, or `D`), and its query value widgets need no prefix. Check: - Does a "Customer-Facing" group exist? - Is it the first group on the dashboard? - Does it contain 5-8 metrics covering: traffic volume, API latency, error rates, key business transactions, and database health? +- Do timeseries widgets inside the group carry their source-layer prefix (not a new "CF" or unprefixed title)? - Can someone determine "are customers affected?" within 5 seconds of opening the dashboard? **Findings format**: @@ -219,7 +222,7 @@ Compile all findings into a structured report: ## Quality Checklist -- [ ] Every widget title uses the layer-priority prefix (`I0:`, `P1:`, `D0:`, etc.) +- [ ] Every timeseries widget title uses the layer-priority prefix (`I0:`, `P1:`, `D0:`, etc.) — including timeseries inside the Customer-Facing group (exception: query value widgets in Customer-Facing need no prefix) - [ ] Every timeseries widget audited for alert threshold markers - [ ] Threshold proximity checked (no large gaps between normal values and alert lines) - [ ] Customer-Facing group exists with 5-8 key metrics at the top From 136932a22ed089a002dc0307f0c4dfb055b27ddd Mon Sep 17 00:00:00 2001 From: Yordis Prieto Date: Thu, 2 Apr 2026 19:04:20 -0400 Subject: [PATCH 2/4] fix(trogonstack-datadog): introduce B (Business) as a proper 4th layer - Adds `B0-N:` prefix for customer-visible outcomes and business transactions - Corrects `D` (Domain) description from "business metrics" to logical domain units - Replaces the "Customer-Facing" cross-cutting view concept with the B layer - Renames Section 5 and all references from Customer-Facing to Business Signed-off-by: Yordis Prieto --- .../skills/datadog-review-dashboard/SKILL.md | 45 +++++++++---------- 1 file changed, 22 insertions(+), 23 deletions(-) diff --git a/plugins/trogonstack-datadog/skills/datadog-review-dashboard/SKILL.md b/plugins/trogonstack-datadog/skills/datadog-review-dashboard/SKILL.md index 44b288a..e923d72 100644 --- a/plugins/trogonstack-datadog/skills/datadog-review-dashboard/SKILL.md +++ b/plugins/trogonstack-datadog/skills/datadog-review-dashboard/SKILL.md @@ -2,8 +2,8 @@ name: datadog-review-dashboard description: >- Review existing Datadog dashboards for operational readiness. Audits alert - threshold markers, threshold proximity to normal traffic, customer-facing - section completeness, and zero-knowledge readability. Uses pup CLI to fetch + threshold markers, threshold proximity to normal traffic, business section + completeness, and zero-knowledge readability. Uses pup CLI to fetch dashboard definitions. Use when auditing dashboards before on-call handoff, after dashboard changes, or during operational reviews. Do not use for: (1) designing new dashboards from scratch, (2) monitor/alert rule design, @@ -13,7 +13,7 @@ allowed-tools: AskUserQuestion, Read, Shell # Review Datadog Dashboard -Audit an existing Datadog dashboard against operational readiness principles. The core principles are: graphs should earn their place with alert thresholds, thresholds should sit close to normal traffic, a customer-facing section should exist, and the dashboard should be readable by someone with zero service knowledge. +Audit an existing Datadog dashboard against operational readiness principles. The core principles are: graphs should earn their place with alert thresholds, thresholds should sit close to normal traffic, a business section should exist at the top, and the dashboard should be readable by someone with zero service knowledge. These are guiding principles — not a rigid checklist. Apply judgment based on the product and business context. A context-providing metric (like deployment events) may earn its place without a threshold. A service with unusual traffic patterns may need different proximity rules. @@ -33,7 +33,7 @@ These are guiding principles — not a rigid checklist. Apply judgment based on 2. **Business Context** — "Can you tell me what this service does for customers? Are there codebases or docs I can read to understand the product?" - Impact: Understanding the domain lets the review focus on whether the right metrics are being tracked, not just whether generic rules are followed -3. **Focus** — "Is there anything specific you want me to focus on? (A) Full review, (B) Alert thresholds only, (C) Customer-facing section, (D) Layout and readability" +3. **Focus** — "Is there anything specific you want me to focus on? (A) Full review, (B) Alert thresholds only, (C) Business section, (D) Layout and readability" - Impact: Determines review scope — default to full review if unspecified --- @@ -63,16 +63,15 @@ Catalog every widget in the dashboard: | Widget Title | Prefix | Type | Group | Has Alert Threshold | Threshold Value | Notes | |-------------|--------|------|-------|--------------------:|----------------|-------| -| ... | I0/P1/D0/— | ... | ... | ... | ... | ... | +| ... | I0/P1/D0/B0/— | ... | ... | ... | ... | ... | Check that every widget title uses the layer-priority prefix system: - `I0-N:` for infrastructure (load balancers, databases, networks) - `P0-N:` for platform (service-specific components from the codebase) -- `D0-N:` for domain (business metrics) +- `D0-N:` for domain (logical domain units in the system — bounded contexts, aggregates, domain components) +- `B0-N:` for business (customer-visible outcomes and business transactions) - The number indicates priority within the layer (`0` = most critical) -**Customer-Facing group and the prefix system**: The Customer-Facing group is a cross-cutting view across layers, not a fourth layer. Widgets inside it retain their source-layer prefix (e.g., `P0: GraphQL Error Rate`, `D0: Purchase Success Rate`, `I0: Healthy Hosts`). The group name itself does not use a layer prefix — it is simply called "Customer-Facing" (or "Triage", "Overview", etc.). Query Value widgets in the Customer-Facing group do not need a prefix since they are big-number status indicators, not timeseries. - Focus on timeseries and query value widgets — these are the primary candidates for alert threshold markers. ### 3. Audit Alert Thresholds @@ -122,33 +121,33 @@ For each widget with a threshold: | p99 latency | ~50ms | 500ms | 10x | auto | TOO FAR — lower to 100-150ms, set Y-max to 175ms | ``` -### 5. Audit Customer-Facing Section +### 5. Audit Business Section -**Principle**: A dedicated "Customer-Facing" group should exist at the top of the dashboard with 5-8 key metrics for immediate outage identification. The specific metrics should reflect the product's business — not just generic traffic and error rates. This group is a cross-cutting view — its timeseries widgets keep their source-layer prefix (`I`, `P`, or `D`), and its query value widgets need no prefix. +**Principle**: A dedicated Business (`B`) group should exist at the top of the dashboard with 5-8 key metrics for immediate outage identification. Business metrics are customer-visible outcomes — not infrastructure or domain internals. The specific metrics should reflect the product's business transactions, not generic traffic and error rates. Check: -- Does a "Customer-Facing" group exist? +- Does a Business group exist (named "Business", "B", or equivalent)? - Is it the first group on the dashboard? -- Does it contain 5-8 metrics covering: traffic volume, API latency, error rates, key business transactions, and database health? -- Do timeseries widgets inside the group carry their source-layer prefix (not a new "CF" or unprefixed title)? +- Do its widgets use the `B0-N:` prefix? +- Does it contain 5-8 metrics covering: customer-visible success rates, key transaction flows, and SLA-impacting latency? - Can someone determine "are customers affected?" within 5 seconds of opening the dashboard? **Findings format**: ```markdown -#### Customer-Facing Section Audit +#### Business Section Audit **Status**: MISSING / INCOMPLETE / OK **Current state**: [Description of what exists] **Recommended metrics** (if missing or incomplete): -1. Total request rate (are we receiving traffic?) -2. Customer-facing error rate (are requests failing?) -3. API p99 latency (are responses slow?) -4. Key transaction success rate (are critical flows working?) -5. Database connection pool usage (is the data layer healthy?) -6. Queue depth or processing lag (is async work backing up?) +1. B0: Key transaction success rate (are critical flows completing?) +2. B0: Customer-facing error rate (are requests failing for customers?) +3. B1: API p99 latency (are responses slow for customers?) +4. B1: Total request rate (are we receiving traffic?) +5. B2: Queue depth or processing lag (is async work backing up?) +6. B2: Key business event throughput (e.g. orders created, payments processed) ``` ### 6. Apply Zero-Knowledge Viewer Test @@ -200,7 +199,7 @@ Compile all findings into a structured report: ## Threshold Proximity Audit [From step 4] -## Customer-Facing Section Audit +## Business Section Audit [From step 5] ## Zero-Knowledge Readability Audit @@ -222,10 +221,10 @@ Compile all findings into a structured report: ## Quality Checklist -- [ ] Every timeseries widget title uses the layer-priority prefix (`I0:`, `P1:`, `D0:`, etc.) — including timeseries inside the Customer-Facing group (exception: query value widgets in Customer-Facing need no prefix) +- [ ] Every widget title uses the layer-priority prefix (`I0:`, `P1:`, `D0:`, `B0:`, etc.) - [ ] Every timeseries widget audited for alert threshold markers - [ ] Threshold proximity checked (no large gaps between normal values and alert lines) -- [ ] Customer-Facing group exists with 5-8 key metrics at the top +- [ ] Business group exists with 5-8 `B`-prefixed metrics at the top - [ ] Zero-knowledge viewer test applied (red indicators visible without context) - [ ] Query Value widgets checked for conditional formatting (green/yellow/red) - [ ] All findings include specific widget names and group references From 4bf60b283c3763c68572bc51ba26f4c9430aa841 Mon Sep 17 00:00:00 2001 From: Yordis Prieto Date: Thu, 2 Apr 2026 19:08:04 -0400 Subject: [PATCH 3/4] fix(trogonstack-datadog): propagate I/P/D/B layer system to design-dashboard skill - Corrects D layer description from "business metrics" to domain units - Adds B layer throughout: SKILL.md, widgets.md layers table, classification guide, and all 4 layout templates in layouts.md - Renames "Customer-Facing" group to "Business" and updates prefixes from mixed I/P/D to B in all layout diagrams - Updates Dashboard Strategy table and Group Structure section Signed-off-by: Yordis Prieto --- .../skills/datadog-design-dashboard/SKILL.md | 14 ++++---- .../references/layouts.md | 34 +++++++++---------- .../references/widgets.md | 23 +++++++------ 3 files changed, 36 insertions(+), 35 deletions(-) diff --git a/plugins/trogonstack-datadog/skills/datadog-design-dashboard/SKILL.md b/plugins/trogonstack-datadog/skills/datadog-design-dashboard/SKILL.md index e3264b6..8ad379a 100644 --- a/plugins/trogonstack-datadog/skills/datadog-design-dashboard/SKILL.md +++ b/plugins/trogonstack-datadog/skills/datadog-design-dashboard/SKILL.md @@ -29,7 +29,7 @@ Before designing, understand what you are building observability for. The metric **If the user points you to a codebase**: Read it. Look at the entry points, the API routes, the database models, the queue consumers, the external service calls. Understanding the code gives you the context to choose metrics that actually matter — not just generic RED/USE signals. -**If the user describes the business**: Use that context to tailor the Customer-Facing section. An e-commerce service cares about checkout success rates. A messaging service cares about delivery latency. A payment service cares about transaction completion. Generic "request rate" and "error rate" are a starting point, but the real value comes from metrics that map to business outcomes. +**If the user describes the business**: Use that context to tailor the Business (`B`) section. An e-commerce service cares about checkout success rates. A messaging service cares about delivery latency. A payment service cares about transaction completion. Generic "request rate" and "error rate" are a starting point, but the real value comes from metrics that map to customer-visible outcomes. **Skip domain discovery if**: You already have deep context about the service from prior conversations or the user has provided detailed specifications. @@ -81,11 +81,11 @@ Using your domain understanding and the chosen framework, design the group struc - **[thresholds.md](references/thresholds.md)** — Alert threshold markers, threshold proximity, Y-axis configuration **Key principles** (not rigid rules — use judgment): -- **Prefix every widget title** with its layer and priority: `I0:` (most critical infra), `P0:` (most critical platform), `D0:` (most critical domain). See [widgets.md](references/widgets.md) for the full prefix system. -- Start with a **Customer-Facing** group (5-8 metrics) so someone with zero service knowledge can tell if customers are affected within 5 seconds. Tailor the metrics to the domain. +- **Prefix every widget title** with its layer and priority: `I0:` (most critical infra), `P0:` (most critical platform), `D0:` (most critical domain), `B0:` (most critical business). See [widgets.md](references/widgets.md) for the full prefix system. +- Start with a **Business** group (5-8 `B`-prefixed metrics) so someone with zero service knowledge can tell if customers are affected within 5 seconds. Tailor the metrics to the domain. - Timeseries widgets should have **alert threshold markers** (red lines) with thresholds close to normal traffic. If a metric doesn't warrant an alert, question whether it belongs — but context-providing metrics can earn their place. - Set **Y-axis max** explicitly near the threshold — don't let auto-scaling compress the normal range. -- Order groups macro-to-micro: customer-facing → overview → domain-specific → infrastructure. +- Order groups macro-to-micro: business → overview → domain-specific → infrastructure. ### 4. Write the output @@ -130,12 +130,12 @@ pup metrics list --filter="trace.http.request.*" - [ ] Dashboard reflects the actual product and business — metrics tailored to the domain - [ ] Dashboard title is concise (no environment, region, or version) - [ ] Template variables defined for env, service, and relevant scopes (default `*`) -- [ ] **Customer-Facing group** with 5-8 metrics tailored to the service's business impact -- [ ] Groups ordered macro-to-micro (customer-facing → overview → details) +- [ ] **Business group** with 5-8 `B`-prefixed metrics tailored to the service's customer-visible outcomes +- [ ] Groups ordered macro-to-micro (business → overview → details) - [ ] **Timeseries widgets have alert threshold markers** (red lines) where the metric is alertable - [ ] **Thresholds close to normal traffic** — no excessive whitespace - [ ] **Zero-knowledge readability** — someone with no service knowledge can spot problems via red indicators -- [ ] **Widget titles prefixed** with layer and priority (`I0:`, `P1:`, `D0:`, etc.) +- [ ] **Widget titles prefixed** with layer and priority (`I0:`, `P1:`, `D0:`, `B0:`, etc.) - [ ] Widget titles use sentence case, don't repeat group name - [ ] Every metric earns its place — if it spikes, someone can act on it diff --git a/plugins/trogonstack-datadog/skills/datadog-design-dashboard/references/layouts.md b/plugins/trogonstack-datadog/skills/datadog-design-dashboard/references/layouts.md index 8a9280e..93c8605 100644 --- a/plugins/trogonstack-datadog/skills/datadog-design-dashboard/references/layouts.md +++ b/plugins/trogonstack-datadog/skills/datadog-design-dashboard/references/layouts.md @@ -29,9 +29,9 @@ Template variables make one dashboard serve many contexts. Define them before la | Approach | Strengths | Weaknesses | |----------|-----------|------------| -| **Per-service** | Focused, fast to scan during incidents. Each team owns their dashboard. Customer-Facing section is specific and actionable. Ops reviews can go service-by-service. | More dashboards to maintain. Cross-service correlation requires switching dashboards. | -| **Consolidated** | Single pane of glass for multiple services. Good for seeing cross-service dependencies. Fewer dashboards to maintain. | Can become overwhelming (100+ metrics). Customer-Facing section becomes diluted. Slower to load and harder to scan during incidents. | -| **Hybrid** | Per-service dashboards for depth + one top-level dashboard with only the Customer-Facing section from each service. Best of both worlds. | Requires maintaining both levels. Customer-Facing metrics duplicated across dashboards. | +| **Per-service** | Focused, fast to scan during incidents. Each team owns their dashboard. Business section is specific and actionable. Ops reviews can go service-by-service. | More dashboards to maintain. Cross-service correlation requires switching dashboards. | +| **Consolidated** | Single pane of glass for multiple services. Good for seeing cross-service dependencies. Fewer dashboards to maintain. | Can become overwhelming (100+ metrics). Business section becomes diluted. Slower to load and harder to scan during incidents. | +| **Hybrid** | Per-service dashboards for depth + one top-level dashboard with only the Business section from each service. Best of both worlds. | Requires maintaining both levels. Business metrics duplicated across dashboards. | --- @@ -41,7 +41,7 @@ Organize widgets into collapsible groups. Groups are the primary navigation mech **Recommended groups** (in order): -1. **Customer-Facing** — 5-8 metrics that answer "are customers affected?" within 5 seconds. Should be the first group. The specific metrics depend on the product. Design so someone with zero service knowledge can spot problems via red indicators. +1. **Business** — 5-8 `B`-prefixed metrics that answer "are customers affected?" within 5 seconds. Should be the first group. The specific metrics depend on the product. Design so someone with zero service knowledge can spot problems via red indicators. 2. **Overview** — Service checks, key health indicators, monitor summaries. 3. **Domain-specific groups** — Organized by the chosen framework (e.g., Rate / Errors / Duration for RED), adapted to the service's actual architecture and concerns. @@ -66,12 +66,12 @@ The most common dashboard type. Monitors a single service's request-level health ┌─────────────────────────────────────────────────────┐ │ Template Variables: env | service | region │ ├─────────────────────────────────────────────────────┤ -│ Group: Customer-Facing │ +│ Group: Business │ │ ┌──────────┬──────────┬──────────┬──────────┐ │ -│ │ P0:Req/s │ P0:Errs │ P0:p99 │ P0:Apdex │ │ +│ │ B0:Req/s │ B0:Errs │ B0:p99 │ B0:Apdex │ │ │ │ (QV+bg) │ (QV+bg) │ (QV+bg) │ (QV+bg) │ │ │ ├──────────────────────┬────────────────────┤ │ -│ │ D0: Key txn success │ I0: DB conn pool │ │ +│ │ B0: Key txn success │ B1: DB conn pool │ │ │ │ (TS + red threshold) │ (TS + red thresh.) │ │ │ └──────────────────────┴────────────────────┘ │ │ 5-8 metrics · zero-knowledge readable │ @@ -112,7 +112,7 @@ The most common dashboard type. Monitors a single service's request-level health └─────────────────────────────────────────────────────┘ ``` -All widget titles use the layer-priority prefix system (`I0:`, `P0:`, `D0:`, etc.) — see [widgets.md](widgets.md) for details. +All widget titles use the layer-priority prefix system (`I0:`, `P0:`, `D0:`, `B0:`, etc.) — see [widgets.md](widgets.md) for details. All timeseries widgets include red alert threshold markers set close to normal traffic. **Widget count**: 20-24 @@ -128,12 +128,12 @@ Monitors host, container, or VM resource health. ┌─────────────────────────────────────────────────────┐ │ Template Variables: env | host | availability_zone │ ├─────────────────────────────────────────────────────┤ -│ Group: Customer-Facing │ +│ Group: Business │ │ ┌──────────┬──────────┬──────────┬──────────┐ │ -│ │P0:Svc Rq │P0:Svc Err│P0:Svc p99│P0:Apdex │ │ +│ │B0:Svc Rq │B0:Svc Err│B0:Svc p99│B0:Apdex │ │ │ │ (QV+bg) │ (QV+bg) │ (QV+bg) │ (QV+bg) │ │ │ ├──────────────────────┬────────────────────┤ │ -│ │ I0: Host avail. │ I0: Network errors │ │ +│ │ B0: Host avail. │ B1: Network errors │ │ │ │ (TS + red threshold) │ (TS + red thresh.) │ │ │ └──────────────────────┴────────────────────┘ │ │ 5-8 metrics · zero-knowledge readable │ @@ -186,12 +186,12 @@ High-level view across multiple services for leadership. ┌─────────────────────────────────────────────────────┐ │ Template Variables: env | team | region │ ├─────────────────────────────────────────────────────┤ -│ Group: Customer-Facing │ +│ Group: Business │ │ ┌──────────┬──────────┬──────────┬──────────┐ │ -│ │P0:Uptime │P0:Cst Err│P0:p99 Lat│P0:Traffic│ │ +│ │B0:Uptime │B0:Cst Err│B0:p99 Lat│B0:Traffic│ │ │ │ (QV+bg) │ (QV+bg) │ (QV+bg) │ (QV+bg) │ │ │ ├──────────────────────┬────────────────────┤ │ -│ │ D0: Revenue txn succ │ D0: Checkout lat │ │ +│ │ B0: Revenue txn succ │ B0: Checkout lat │ │ │ │ (TS + red threshold) │ (TS + red thresh.) │ │ │ └──────────────────────┴────────────────────┘ │ │ 5-8 metrics · zero-knowledge readable │ @@ -242,12 +242,12 @@ Deep-dive dashboard for active incident investigation. ┌─────────────────────────────────────────────────────┐ │ Template Variables: env | service | host | endpoint │ ├─────────────────────────────────────────────────────┤ -│ Group: Customer-Facing │ +│ Group: Business │ │ ┌──────────┬──────────┬──────────┬──────────┐ │ -│ │P0:Cst Err│P0:p99 Lat│P0:Req/s │P0:Apdex │ │ +│ │B0:Cst Err│B0:p99 Lat│B0:Req/s │B0:Apdex │ │ │ │ (QV+bg) │ (QV+bg) │ (QV+bg) │ (QV+bg) │ │ │ ├──────────────────────┬────────────────────┤ │ -│ │ D0: Key txn success │ I0: DB conn pool │ │ +│ │ B0: Key txn success │ B1: DB conn pool │ │ │ │ (TS + red threshold) │ (TS + red thresh.) │ │ │ └──────────────────────┴────────────────────┘ │ │ 5-8 metrics · zero-knowledge readable │ diff --git a/plugins/trogonstack-datadog/skills/datadog-design-dashboard/references/widgets.md b/plugins/trogonstack-datadog/skills/datadog-design-dashboard/references/widgets.md index 61e642f..770a353 100644 --- a/plugins/trogonstack-datadog/skills/datadog-design-dashboard/references/widgets.md +++ b/plugins/trogonstack-datadog/skills/datadog-design-dashboard/references/widgets.md @@ -234,7 +234,8 @@ Every widget title starts with a layer-priority prefix so anyone can immediately |--------|-------|---------------| | `I` | **Infrastructure** | Load balancers, databases, networks, DNS, CDN, storage — shared infrastructure that the service depends on but doesn't own | | `P` | **Platform** | Service-specific platform components from the codebase — gRPC servers, connection pools, cache clients, queue consumers, circuit breakers | -| `D` | **Domain** | Business and domain metrics — checkout success rate, order throughput, payment completion, delivery latency, user sign-ups | +| `D` | **Domain** | Logical domain units in the system — bounded contexts, aggregates, domain components (e.g., order processing pipeline, payment saga, delivery tracking) | +| `B` | **Business** | Customer-visible outcomes and business transactions — checkout success rate, order throughput, payment completion, delivery latency, user sign-ups | ### Priority Numbers @@ -249,13 +250,12 @@ The number after the layer letter indicates priority within that layer. `0` is t ### Examples ```text -Group: "Customer-Facing" - D0: Checkout success rate - D0: Order throughput - I0: Load balancer 5xx - P0: API p99 latency - I1: Database connection pool - P1: gRPC client errors +Group: "Business" + B0: Checkout success rate + B0: Order throughput + B1: API p99 latency + B1: Customer-visible error rate + B2: Failed payment rate Group: "Rate" P0: Requests per second @@ -263,7 +263,7 @@ Group: "Rate" Group: "Errors" P0: Error rate over time - D1: Failed payment rate + D1: Order saga failures P2: Top errors by endpoint Group: "Infrastructure" @@ -279,7 +279,8 @@ When assigning prefixes, use the domain discovery context: - **I (Infrastructure)**: Would this metric exist even if your code didn't? Load balancer, database engine, OS resources, network — things the ops team manages. - **P (Platform)**: Is this about how your code runs? Connection pools your code configures, gRPC channels your code opens, cache hit rates for caches your code uses — the technical platform layer. -- **D (Domain)**: Does this metric map to a business outcome? Checkout completions, delivery SLA, payment success — things a product manager would understand. +- **D (Domain)**: Is this about a logical unit in your domain model? An order processing pipeline, a payment saga, a delivery tracking aggregate — things a domain expert would recognize as a bounded context or aggregate. +- **B (Business)**: Does this metric map to a customer-visible outcome? Checkout completions, delivery SLA, payment success — things a product manager would put on a KPI dashboard. The priority number comes from the ops review order: what do you look at first when paged at 3am? That's `0`. @@ -291,7 +292,7 @@ The priority number comes from the ops review order: what do you look at first w **Widget titles**: Prefix + sentence case, concise, action-oriented. -- Always start with the layer-priority prefix (`I0:`, `P1:`, `D0:`, etc.) +- Always start with the layer-priority prefix (`I0:`, `P1:`, `D0:`, `B0:`, etc.) - Do not repeat the group title after the prefix - Do not repeat the integration name if it is obvious from context - Alias all formulas so legends are readable From 9dd689b29e87c1359c3d57325b967bade4ba66cf Mon Sep 17 00:00:00 2001 From: Yordis Prieto Date: Thu, 2 Apr 2026 19:11:05 -0400 Subject: [PATCH 4/4] fix(trogonstack-datadog): clarify D vs B layer distinction as tech vs business Signed-off-by: Yordis Prieto --- .../skills/datadog-design-dashboard/references/widgets.md | 8 ++++---- .../skills/datadog-review-dashboard/SKILL.md | 4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/plugins/trogonstack-datadog/skills/datadog-design-dashboard/references/widgets.md b/plugins/trogonstack-datadog/skills/datadog-design-dashboard/references/widgets.md index 770a353..9852f6b 100644 --- a/plugins/trogonstack-datadog/skills/datadog-design-dashboard/references/widgets.md +++ b/plugins/trogonstack-datadog/skills/datadog-design-dashboard/references/widgets.md @@ -234,8 +234,8 @@ Every widget title starts with a layer-priority prefix so anyone can immediately |--------|-------|---------------| | `I` | **Infrastructure** | Load balancers, databases, networks, DNS, CDN, storage — shared infrastructure that the service depends on but doesn't own | | `P` | **Platform** | Service-specific platform components from the codebase — gRPC servers, connection pools, cache clients, queue consumers, circuit breakers | -| `D` | **Domain** | Logical domain units in the system — bounded contexts, aggregates, domain components (e.g., order processing pipeline, payment saga, delivery tracking) | -| `B` | **Business** | Customer-visible outcomes and business transactions — checkout success rate, order throughput, payment completion, delivery latency, user sign-ups | +| `D` | **Domain** | Technical health of domain processes — saga failures, aggregate timeouts, domain event lag (tech stuff) | +| `B` | **Business** | Business outcomes — checkout success rate, payment completion, on-time delivery (business stuff) | ### Priority Numbers @@ -279,8 +279,8 @@ When assigning prefixes, use the domain discovery context: - **I (Infrastructure)**: Would this metric exist even if your code didn't? Load balancer, database engine, OS resources, network — things the ops team manages. - **P (Platform)**: Is this about how your code runs? Connection pools your code configures, gRPC channels your code opens, cache hit rates for caches your code uses — the technical platform layer. -- **D (Domain)**: Is this about a logical unit in your domain model? An order processing pipeline, a payment saga, a delivery tracking aggregate — things a domain expert would recognize as a bounded context or aggregate. -- **B (Business)**: Does this metric map to a customer-visible outcome? Checkout completions, delivery SLA, payment success — things a product manager would put on a KPI dashboard. +- **D (Domain)**: Is this technical health of a domain process? Saga step failures, aggregate timeouts, domain event processing lag — tech stuff that a domain engineer cares about. +- **B (Business)**: Is this a business outcome? Payment success rate, checkout completion, on-time delivery — business stuff that a product manager or customer cares about. The priority number comes from the ops review order: what do you look at first when paged at 3am? That's `0`. diff --git a/plugins/trogonstack-datadog/skills/datadog-review-dashboard/SKILL.md b/plugins/trogonstack-datadog/skills/datadog-review-dashboard/SKILL.md index e923d72..195461a 100644 --- a/plugins/trogonstack-datadog/skills/datadog-review-dashboard/SKILL.md +++ b/plugins/trogonstack-datadog/skills/datadog-review-dashboard/SKILL.md @@ -68,8 +68,8 @@ Catalog every widget in the dashboard: Check that every widget title uses the layer-priority prefix system: - `I0-N:` for infrastructure (load balancers, databases, networks) - `P0-N:` for platform (service-specific components from the codebase) -- `D0-N:` for domain (logical domain units in the system — bounded contexts, aggregates, domain components) -- `B0-N:` for business (customer-visible outcomes and business transactions) +- `D0-N:` for domain (technical health of domain processes — tech stuff) +- `B0-N:` for business (business outcomes — business stuff) - The number indicates priority within the layer (`0` = most critical) Focus on timeseries and query value widgets — these are the primary candidates for alert threshold markers.