omgkit 2.15.0 → 2.16.0

package/README.md

@@ -7,7 +7,7 @@
 [![License](https://img.shields.io/badge/license-MIT-blue)](LICENSE)
 
 > **AI Team System for Claude Code**
-> 33 Agents • 111 Commands • 49 Workflows • 128 Skills • 10 Modes • 14 Archetypes
+> 33 Agents • 111 Commands • 49 Workflows • 127 Skills • 10 Modes • 14 Archetypes
 > *"Think Omega. Build Omega. Be Omega."*
 
 OMGKIT transforms Claude Code into an autonomous AI development team with sprint management, specialized agents, and Omega-level thinking for 10x-1000x productivity improvements.
@@ -19,7 +19,7 @@ OMGKIT transforms Claude Code into an autonomous AI development team with sprint
 | **Agents** | 33 | Specialized AI team members |
 | **Commands** | 111 | Slash commands for every task |
 | **Workflows** | 49 | Complete development processes |
-| **Skills** | 128 | Domain expertise modules |
+| **Skills** | 127 | Domain expertise modules |
 | **Modes** | 10 | Behavioral configurations |
 | **Archetypes** | 14 | Project templates for autonomous dev |
 | **Sprint Management** | ✅ | Vision, backlog, team autonomy |
@@ -445,6 +445,42 @@ OMGKIT supports these MCP servers for enhanced capabilities:
 | Filesystem | Secure file operations |
 | Playwright | Browser automation |
 
+## 🏗️ Optimized Alignment Principle (OAP)
+
+OMGKIT uses a **5-level component hierarchy** ensuring consistency and maintainability:
+
+```
+Level 0: MCPs (Foundation)
+    ↓
+Level 1: Commands → use MCPs
+    ↓
+Level 2: Skills → use Commands, MCPs
+    ↓
+Level 3: Agents → use Skills, Commands, MCPs
+    ↓
+Level 4: Workflows → use Agents, Skills, Commands, MCPs
+```
+
+### Five Alignment Rules
+
+1. **Format Compliance** - Components use correct naming patterns
+2. **Existence Validation** - All references must exist
+3. **No Cross-Type Confusion** - Components not confused with other types
+4. **Hierarchical Respect** - Only reference same/lower level components
+5. **Optimization** - Minimal, appropriate, unique references
+
+### Component Formats
+
+| Component | Format | Example |
+|-----------|--------|---------|
+| MCPs | `kebab-case` | `context7` |
+| Commands | `/namespace:name` | `/dev:feature` |
+| Skills | `category/name` | `methodology/writing-plans` |
+| Agents | `kebab-case` | `fullstack-developer` |
+| Workflows | `category/name` | `development/feature` |
+
+All alignment rules are enforced by 400+ automated tests. See [full documentation](https://omgkit.mintlify.app/concepts/alignment-principle).
+
 ## 📄 License
 
 MIT

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "omgkit",
-  "version": "2.15.0",
-  "description": "Omega-Level Development Kit - AI Team System for Claude Code. 33 agents, 111 commands, 128 skills, 49 workflows.",
+  "version": "2.16.0",
+  "description": "Omega-Level Development Kit - AI Team System for Claude Code. 33 agents, 111 commands, 127 skills, 49 workflows.",
   "keywords": [
     "claude-code",
     "ai",

package/plugin/registry.yaml

@@ -1,9 +1,85 @@
 # OMGKIT Component Registry
-# Single Source of Truth for Agents, Skills, Commands, and Workflows
-# Version: 1.0.0
+# Single Source of Truth for Agents, Skills, Commands, Workflows, and MCPs
+# Version: 2.0.0
 # Updated: 2026-01-02
 
-version: "1.0.0"
+version: "2.0.0"
+
+# =============================================================================
+# OPTIMIZED ALIGNMENT PRINCIPLE (OAP)
+# =============================================================================
+# Core architectural rule defining component relationships.
+# See: plugin/stdrules/ALIGNMENT_PRINCIPLE.md for full documentation.
+#
+# Hierarchy (lower levels are used by higher levels):
+#   Level 0: MCPs       → Foundation layer
+#   Level 1: Commands   → Use: MCPs
+#   Level 2: Skills     → Use: Commands, MCPs
+#   Level 3: Agents     → Use: Skills, Commands, MCPs
+#   Level 4: Workflows  → Use: Agents, Skills, Commands, MCPs
+#
+# Rules:
+#   1. Format Compliance  - Use correct format for each component type
+#   2. Existence Validation - All references must point to existing components
+#   3. No Cross-Type Confusion - Don't mix agents/skills/commands
+#   4. Hierarchical Respect - Only reference lower or same level components
+#   5. Optimization - Appropriate, minimal, unique, contextual references
+# =============================================================================
+
+alignment_principle:
+  version: "1.0.0"
+  enforced: true
+  documentation: "plugin/stdrules/ALIGNMENT_PRINCIPLE.md"
+  hierarchy:
+    - level: 0
+      type: mcp
+      format: "mcp-name"
+      location: "plugin/mcp/"
+      uses: []
+    - level: 1
+      type: command
+      format: "/namespace:command-name"
+      location: "plugin/commands/<namespace>/<name>.md"
+      uses: [mcp]
+    - level: 2
+      type: skill
+      format: "category/skill-name"
+      location: "plugin/skills/<category>/<name>/SKILL.md"
+      uses: [command, mcp]
+    - level: 3
+      type: agent
+      format: "kebab-case"
+      location: "plugin/agents/<name>.md"
+      uses: [skill, command, mcp]
+    - level: 4
+      type: workflow
+      format: "category/workflow-name"
+      location: "plugin/workflows/<category>/<name>.md"
+      uses: [agent, skill, command, mcp]
+
+# =============================================================================
+# MCP SERVERS (Model Context Protocol)
+# =============================================================================
+# MCPs provide external capabilities to OMGKIT components.
+# Foundation layer of the alignment hierarchy.
+# =============================================================================
+
+mcp_servers:
+  context7:
+    description: Up-to-date library documentation
+    status: supported
+  sequential-thinking:
+    description: Multi-step reasoning
+    status: supported
+  memory:
+    description: Persistent knowledge graph
+    status: supported
+  filesystem:
+    description: Secure file operations
+    status: supported
+  playwright:
+    description: Browser automation
+    status: supported
 
 # =============================================================================
 # AGENTS

package/plugin/stdrules/ALIGNMENT_PRINCIPLE.md

@@ -0,0 +1,240 @@
+# Optimized Alignment Principle (OAP)
+
+**Version:** 1.0.0
+**Status:** Core Principle
+**Enforcement:** Mandatory (validated by tests)
+
+---
+
+## Overview
+
+The **Optimized Alignment Principle (OAP)** is a core architectural rule that defines how OMGKIT components relate to each other. This principle ensures consistency, maintainability, and scalability across all components.
+
+---
+
+## Component Hierarchy
+
+```
+┌─────────────────────────────────────────────────────────────────────┐
+│                     OPTIMIZED ALIGNMENT HIERARCHY                    │
+├─────────────────────────────────────────────────────────────────────┤
+│                                                                      │
+│  Level 0: MCPs (Model Context Protocol Servers)                      │
+│           └── Foundation layer, used by all other components         │
+│                                                                      │
+│  Level 1: Commands                                                   │
+│           └── Use: zero-to-many MCPs                                 │
+│           └── Format: /namespace:command-name                        │
+│                                                                      │
+│  Level 2: Skills                                                     │
+│           └── Use: zero-to-many Commands, MCPs                       │
+│           └── Format: category/skill-name                            │
+│                                                                      │
+│  Level 3: Agents                                                     │
+│           └── Use: zero-to-many Skills, Commands, MCPs               │
+│           └── Format: kebab-case name                                │
+│                                                                      │
+│  Level 4: Workflows                                                  │
+│           └── Use: zero-to-many Agents, Skills, Commands, MCPs       │
+│           └── Format: category/workflow-name                         │
+│                                                                      │
+└─────────────────────────────────────────────────────────────────────┘
+```
+
+---
+
+## Alignment Rules
+
+### Rule 1: Format Compliance
+
+All component references MUST use the correct format:
+
+| Component | Format | Example |
+|-----------|--------|---------|
+| MCP | `mcp-name` | `context7`, `sequential-thinking` |
+| Command | `/namespace:command-name` | `/dev:feature`, `/omega:10x` |
+| Skill | `category/skill-name` | `methodology/writing-plans` |
+| Agent | `kebab-case` | `fullstack-developer` |
+| Workflow | `category/workflow-name` | `development/feature` |
+
+### Rule 2: Existence Validation
+
+All referenced components MUST exist:
+
+- Skills → Must exist in `/plugin/skills/<category>/<name>/SKILL.md`
+- Commands → Must exist in `/plugin/commands/<namespace>/<name>.md`
+- Agents → Must exist in `/plugin/agents/<name>.md`
+- Workflows → Must exist in `/plugin/workflows/<category>/<name>.md`
+- MCPs → Must be registered in `/plugin/mcp/`
+
+### Rule 3: No Cross-Type Confusion
+
+Components MUST NOT be confused with other types:
+
+- ❌ Agent names in `skills:` field
+- ❌ Skill names in `agents:` field
+- ❌ Commands without proper `/namespace:` prefix
+
+### Rule 4: Hierarchical Respect
+
+Components can only reference components from their level or below:
+
+| Component | Can Reference |
+|-----------|---------------|
+| MCP | (none - foundation layer) |
+| Command | MCPs |
+| Skill | Commands, MCPs |
+| Agent | Skills, Commands, MCPs |
+| Workflow | Agents, Skills, Commands, MCPs |
+
+### Rule 5: Optimization Requirements
+
+References should be:
+
+1. **Appropriate** - Only reference what is needed
+2. **Minimal** - Avoid redundant dependencies
+3. **Unique** - No duplicate references
+4. **Contextual** - Match the component's purpose
+
+---
+
+## Frontmatter Specifications
+
+### Skill Frontmatter
+
+```yaml
+---
+name: skill-name
+description: What the skill does
+category: category-name
+commands:          # Optional: commands this skill uses
+  - /namespace:cmd
+mcps:              # Future: MCPs this skill uses
+  - mcp-name
+---
+```
+
+### Agent Frontmatter
+
+```yaml
+---
+name: agent-name
+description: What the agent does
+tools: Tool1, Tool2
+model: inherit
+skills:            # Skills this agent uses
+  - category/skill-name
+commands:          # Commands this agent can trigger
+  - /namespace:cmd
+mcps:              # Future: MCPs this agent uses
+  - mcp-name
+---
+```
+
+### Workflow Frontmatter
+
+```yaml
+---
+name: workflow-name
+description: What the workflow does
+category: category-name
+agents:            # Agents this workflow orchestrates
+  - agent-name
+skills:            # Skills used across the workflow
+  - category/skill-name
+commands:          # Commands triggered by the workflow
+  - /namespace:cmd
+mcps:              # Future: MCPs used by the workflow
+  - mcp-name
+---
+```
+
+---
+
+## Validation
+
+### Automated Tests
+
+The alignment principle is enforced by automated tests in:
+- `tests/validation/alignment.test.js`
+- `tests/validation/format.test.js`
+- `tests/validation/existence.test.js`
+- `tests/validation/hierarchy.test.js`
+
+### Pre-Publish Check
+
+Before publishing to npm, ALL alignment tests MUST pass:
+
+```bash
+npm test
+```
+
+### CI/CD Integration
+
+GitHub Actions validates alignment on every PR.
+
+---
+
+## Examples
+
+### Correct Alignment
+
+```yaml
+# Agent: fullstack-developer.md
+skills:
+  - methodology/executing-plans      # ✓ Valid skill format
+  - languages/typescript             # ✓ Exists in skills directory
+commands:
+  - /dev:feature                     # ✓ Valid command format
+  - /dev:fix                         # ✓ Exists in commands directory
+```
+
+### Incorrect Alignment
+
+```yaml
+# WRONG - Common mistakes
+skills:
+  - planner                          # ✗ This is an agent name, not skill
+  - writing-plans                    # ✗ Missing category prefix
+  - methodology/nonexistent          # ✗ Skill doesn't exist
+
+commands:
+  - feature                          # ✗ Missing /namespace: prefix
+  - /dev/feature                     # ✗ Wrong separator (/ not :)
+```
+
+---
+
+## Future: MCP Alignment
+
+When MCP support is fully implemented:
+
+1. MCPs will be registered in `/plugin/mcp/`
+2. All components can declare `mcps:` in frontmatter
+3. Tests will validate MCP references exist
+4. Registry will track MCP-component mappings
+
+---
+
+## Enforcement
+
+This principle is:
+
+1. **Documented** - In this file and public docs
+2. **Tested** - 400+ automated tests
+3. **Required** - Must pass before publish
+4. **Versioned** - Changes tracked in changelog
+
+---
+
+## Changelog
+
+### 1.0.0 (2026-01-02)
+- Initial definition of Optimized Alignment Principle
+- Established 5 core alignment rules
+- Created comprehensive test suite
+- Added MCP future support placeholder
+
+---
+
+*Think Omega. Build Omega. Be Omega.* 🔮

package/plugin/workflows/ai-ml/experiment-cycle.md

@@ -5,7 +5,7 @@ triggers:
   - ml:experiment
 agents:
   - ml-engineer
-  - data-scientist
+  - data-engineer
 ---
 
 # Experiment Cycle Workflow

package/plugin/workflows/ai-ml/model-deployment.md

@@ -5,7 +5,7 @@ triggers:
   - ml:deploy
 agents:
   - ml-engineer
-  - site-reliability-engineer
+  - observability-engineer
 ---
 
 # Model Deployment Workflow
@@ -79,7 +79,7 @@ base_images:
 
 ### Step 3.1: Deploy to Staging
 ```yaml
-agent: site-reliability-engineer
+agent: observability-engineer
 action: deploy
 environment: staging
 infrastructure:
@@ -105,7 +105,7 @@ tests:
 
 ### Step 4.1: Canary Deployment
 ```yaml
-agent: site-reliability-engineer
+agent: observability-engineer
 action: deploy
 strategy: canary
 configuration:
@@ -119,7 +119,7 @@ configuration:
 
 ### Step 4.2: Shadow Deployment (Optional)
 ```yaml
-agent: site-reliability-engineer
+agent: observability-engineer
 action: deploy
 strategy: shadow
 configuration:
@@ -131,7 +131,7 @@ configuration:
 
 ### Step 4.3: Full Rollout
 ```yaml
-agent: site-reliability-engineer
+agent: observability-engineer
 action: promote
 after:
   - Canary success
@@ -147,7 +147,7 @@ steps:
 
 ### Step 5.1: Configure Monitoring
 ```yaml
-agent: site-reliability-engineer
+agent: observability-engineer
 action: configure
 monitoring:
   - Prediction latency
@@ -163,7 +163,7 @@ dashboards:
 
 ### Step 5.2: Configure Alerts
 ```yaml
-agent: site-reliability-engineer
+agent: observability-engineer
 action: configure
 alerts:
   - High error rate

package/plugin/workflows/ai-ml/monitoring-setup.md

@@ -5,7 +5,7 @@ triggers:
   - ml:monitoring
 agents:
   - ml-engineer
-  - site-reliability-engineer
+  - observability-engineer
 ---
 
 # ML Monitoring Setup Workflow
@@ -127,7 +127,7 @@ detection:
 
 ### Step 4.1: System Metrics
 ```yaml
-agent: site-reliability-engineer
+agent: observability-engineer
 action: configure
 metrics:
   - Request latency (p50, p95, p99)
@@ -140,7 +140,7 @@ metrics:
 
 ### Step 4.2: SLI/SLO Definition
 ```yaml
-agent: site-reliability-engineer
+agent: observability-engineer
 action: define
 slis:
   - Availability: Successful requests / Total requests
@@ -156,7 +156,7 @@ slos:
 
 ### Step 5.1: Alert Configuration
 ```yaml
-agent: site-reliability-engineer
+agent: observability-engineer
 action: configure
 alert_rules:
   - model_drift_detected:
@@ -175,7 +175,7 @@ alert_rules:
 
 ### Step 5.2: Response Playbooks
 ```yaml
-agent: site-reliability-engineer
+agent: observability-engineer
 action: document
 playbooks:
   - drift_detected:
@@ -196,7 +196,7 @@ playbooks:
 
 ### Step 6.1: Create Dashboards
 ```yaml
-agent: site-reliability-engineer
+agent: observability-engineer
 action: create
 dashboards:
   - model_health:

package/plugin/workflows/event-driven/consumer-groups.md

@@ -5,7 +5,7 @@ triggers:
   - kafka:consumers
 agents:
   - data-engineer
-  - site-reliability-engineer
+  - observability-engineer
 ---
 
 # Consumer Group Management Workflow
@@ -78,7 +78,7 @@ commit_strategy:
 
 ### Step 3.1: Consumer Scaling
 ```yaml
-agent: site-reliability-engineer
+agent: observability-engineer
 action: configure
 scaling:
   min_consumers: 1
@@ -106,7 +106,7 @@ static_membership:
 
 ### Step 4.1: Lag Monitoring
 ```yaml
-agent: site-reliability-engineer
+agent: observability-engineer
 action: configure
 metrics:
   - consumer_lag_per_partition
@@ -121,7 +121,7 @@ tools:
 
 ### Step 4.2: Alerting
 ```yaml
-agent: site-reliability-engineer
+agent: observability-engineer
 action: configure
 alerts:
   - consumer_lag_critical:
@@ -142,7 +142,7 @@ alerts:
 
 ### Step 5.1: Offset Management Operations
 ```yaml
-agent: site-reliability-engineer
+agent: observability-engineer
 action: document
 operations:
   reset_to_earliest:
@@ -158,7 +158,7 @@ operations:
 
 ### Step 5.2: Troubleshooting Runbook
 ```yaml
-agent: site-reliability-engineer
+agent: observability-engineer
 action: document
 scenarios:
   - lag_increasing:

package/plugin/workflows/game-dev/content-pipeline.md

@@ -4,7 +4,7 @@ triggers:
   - manual
   - game:content
 agents:
-  - game-designer
+  - game-systems-designer
   - fullstack-developer
 ---
 
@@ -21,7 +21,7 @@ Create efficient pipeline for game content creation.
 
 ### Step 1.1: Identify Content Types
 ```yaml
-agent: game-designer
+agent: game-systems-designer
 action: catalog
 content_types:
   - 2D_assets: Sprites, UI, textures
@@ -33,7 +33,7 @@ content_types:
 
 ### Step 1.2: Define Pipeline Flow
 ```yaml
-agent: game-designer
+agent: game-systems-designer
 action: design
 flow:
   creation:
@@ -160,7 +160,7 @@ builds:
 
 ### Step 5.1: Data-Driven Content
 ```yaml
-agent: game-designer
+agent: game-systems-designer
 action: design
 systems:
   - JSON/YAML game data
@@ -193,7 +193,7 @@ tools:
 
 ### Step 6.1: Content Guidelines
 ```yaml
-agent: game-designer
+agent: game-systems-designer
 action: document
 guidelines:
   - Art style guide

package/plugin/workflows/game-dev/platform-submission.md

@@ -4,7 +4,7 @@ triggers:
   - manual
   - game:submit
 agents:
-  - game-designer
+  - game-systems-designer
   - fullstack-developer
   - tester
 ---
@@ -22,7 +22,7 @@ Navigate platform certification and store submission.
 
 ### Step 1.1: Platform Requirements Review
 ```yaml
-agent: game-designer
+agent: game-systems-designer
 action: review
 platforms:
   steam:
@@ -54,7 +54,7 @@ platforms:
 
 ### Step 1.2: Content Rating
 ```yaml
-agent: game-designer
+agent: game-systems-designer
 action: submit
 rating_boards:
   - ESRB (North America)
@@ -161,7 +161,7 @@ scope:
 
 ### Step 4.1: Marketing Materials
 ```yaml
-agent: game-designer
+agent: game-systems-designer
 action: prepare
 assets:
   - Store page screenshots (platform sizes)
@@ -174,7 +174,7 @@ assets:
 
 ### Step 4.2: Store Configuration
 ```yaml
-agent: game-designer
+agent: game-systems-designer
 action: configure
 settings:
   - Pricing
@@ -203,7 +203,7 @@ per_platform:
 
 ### Step 5.2: Submit for Review
 ```yaml
-agent: game-designer
+agent: game-systems-designer
 action: submit
 documentation:
   - Build notes
@@ -224,7 +224,7 @@ timeline:
 
 ### Step 6.1: Handle Feedback
 ```yaml
-agent: game-designer
+agent: game-systems-designer
 action: respond
 scenarios:
   approved:
@@ -238,7 +238,7 @@ scenarios:
 
 ### Step 6.2: Launch Preparation
 ```yaml
-agent: game-designer
+agent: game-systems-designer
 action: prepare
 launch_checklist:
   - Press kit ready

package/plugin/workflows/game-dev/playtesting.md

@@ -4,7 +4,7 @@ triggers:
   - manual
   - game:playtest
 agents:
-  - game-designer
+  - game-systems-designer
   - tester
 ---
 
@@ -21,7 +21,7 @@ Conduct effective playtesting to improve game quality.
 
 ### Step 1.1: Define Objectives
 ```yaml
-agent: game-designer
+agent: game-systems-designer
 action: define
 objectives:
   types:
@@ -36,7 +36,7 @@ objectives:
 
 ### Step 1.2: Select Playtesters
 ```yaml
-agent: game-designer
+agent: game-systems-designer
 action: select
 criteria:
   internal:
@@ -82,7 +82,7 @@ tools:
 
 ### Step 2.2: Observation Protocol
 ```yaml
-agent: game-designer
+agent: game-systems-designer
 action: define
 observation:
   - Think-aloud protocol
@@ -94,7 +94,7 @@ observation:
 
 ### Step 2.3: Survey Preparation
 ```yaml
-agent: game-designer
+agent: game-systems-designer
 action: prepare
 surveys:
   pre_play:
@@ -143,7 +143,7 @@ per_session:
 
 ### Step 4.1: Quantitative Analysis
 ```yaml
-agent: game-designer
+agent: game-systems-designer
 action: analyze
 metrics:
   - Completion rates
@@ -159,7 +159,7 @@ visualization:
 
 ### Step 4.2: Qualitative Analysis
 ```yaml
-agent: game-designer
+agent: game-systems-designer
 action: analyze
 methods:
   - Affinity mapping
@@ -171,7 +171,7 @@ methods:
 
 ### Step 4.3: Insight Synthesis
 ```yaml
-agent: game-designer
+agent: game-systems-designer
 action: synthesize
 outputs:
   - Key findings summary
@@ -185,7 +185,7 @@ outputs:
 
 ### Step 5.1: Prioritize Findings
 ```yaml
-agent: game-designer
+agent: game-systems-designer
 action: prioritize
 criteria:
   - Impact on player experience
@@ -201,7 +201,7 @@ categories:
 
 ### Step 5.2: Create Action Items
 ```yaml
-agent: game-designer
+agent: game-systems-designer
 action: plan
 per_finding:
   - Issue description
@@ -213,7 +213,7 @@ per_finding:
 
 ### Step 5.3: Plan Follow-up Testing
 ```yaml
-agent: game-designer
+agent: game-systems-designer
 action: plan
 next_playtest:
   - Verify fixes

package/plugin/workflows/game-dev/prototype-to-production.md

@@ -4,7 +4,7 @@ triggers:
   - manual
   - game:production
 agents:
-  - game-designer
+  - game-systems-designer
   - fullstack-developer
   - tester
 ---
@@ -22,7 +22,7 @@ Convert rapid game prototype into maintainable production code.
 
 ### Step 1.1: Evaluate Prototype
 ```yaml
-agent: game-designer
+agent: game-systems-designer
 action: assess
 evaluation:
   - Core mechanics working
@@ -34,7 +34,7 @@ evaluation:
 
 ### Step 1.2: Define Production Requirements
 ```yaml
-agent: game-designer
+agent: game-systems-designer
 action: define
 requirements:
   - Target frame rate: 60fps
@@ -48,7 +48,7 @@ requirements:
 
 ### Step 2.1: Design Production Architecture
 ```yaml
-agent: game-designer
+agent: game-systems-designer
 action: design
 patterns:
   - Component system (ECS or composition)

package/plugin/workflows/microservices/distributed-tracing.md

@@ -4,7 +4,7 @@ triggers:
   - manual
   - observability:tracing
 agents:
-  - site-reliability-engineer
+  - observability-engineer
   - fullstack-developer
 ---
 
@@ -21,7 +21,7 @@ Set up end-to-end request tracing across services.
 
 ### Step 1.1: Deploy Tracing Backend
 ```yaml
-agent: site-reliability-engineer
+agent: observability-engineer
 action: deploy
 options:
   - Jaeger
@@ -37,7 +37,7 @@ configuration:
 
 ### Step 1.2: Configure Sampling
 ```yaml
-agent: site-reliability-engineer
+agent: observability-engineer
 action: configure
 sampling:
   type: probabilistic  # or rate_limiting, adaptive
@@ -120,7 +120,7 @@ log_correlation:
 
 ### Step 4.2: Metrics Correlation
 ```yaml
-agent: site-reliability-engineer
+agent: observability-engineer
 action: configure
 metrics_correlation:
   - exemplars: trace_id_in_metrics
@@ -131,7 +131,7 @@ metrics_correlation:
 
 ### Step 5.1: Create Dashboards
 ```yaml
-agent: site-reliability-engineer
+agent: observability-engineer
 action: create
 dashboards:
   - service_latency_breakdown
@@ -142,7 +142,7 @@ dashboards:
 
 ### Step 5.2: Configure Alerts
 ```yaml
-agent: site-reliability-engineer
+agent: observability-engineer
 action: configure
 alerts:
   - high_latency_traces

package/plugin/workflows/microservices/service-mesh-setup.md

@@ -5,7 +5,7 @@ triggers:
   - infrastructure:mesh
 agents:
   - platform-engineer
-  - site-reliability-engineer
+  - observability-engineer
 ---
 
 # Service Mesh Setup Workflow
@@ -105,7 +105,7 @@ rules:
 
 ### Step 4.1: Configure Telemetry
 ```yaml
-agent: site-reliability-engineer
+agent: observability-engineer
 action: configure
 integrations:
   - prometheus_metrics
@@ -116,7 +116,7 @@ integrations:
 
 ### Step 4.2: Create Dashboards
 ```yaml
-agent: site-reliability-engineer
+agent: observability-engineer
 action: create
 dashboards:
   - service_mesh_overview
@@ -129,7 +129,7 @@ dashboards:
 
 ### Step 5.1: Verify Mesh Functionality
 ```yaml
-agent: site-reliability-engineer
+agent: observability-engineer
 action: test
 validations:
   - mtls_working