musubi-sdd 5.1.0 → 5.6.1

package/src/templates/agents/claude-code/skills/site-reliability-engineer/slo-sli-guide.md

@@ -9,21 +9,25 @@ Guide for implementing Service Level Objectives (SLOs) and Service Level Indicat
 ## Key Concepts
 
 ### SLI (Service Level Indicator)
+
 A quantitative measure of service behavior.
 
 **Example**: 99.5% of requests return successfully in under 200ms.
 
 ### SLO (Service Level Objective)
+
 A target value for an SLI.
 
 **Example**: 99.9% availability over 30 days.
 
 ### SLA (Service Level Agreement)
+
 A contract with consequences for missing SLOs.
 
 **Example**: If uptime < 99.9%, customer gets 10% credit.
 
 ### Error Budget
+
 The acceptable amount of downtime/errors.
 
 **Example**: 99.9% availability = 43 minutes downtime/month budget.
@@ -33,32 +37,37 @@ The acceptable amount of downtime/errors.
 ## Common SLIs
 
 ### 1. Availability
+
 ```
 Availability = (Successful Requests / Total Requests) × 100
 ```
 
 ### 2. Latency
+
 ```
 Latency SLI = Requests < Threshold / Total Requests
 ```
 
 | Percentile | Typical Target |
-|------------|----------------|
-| p50 | < 100ms |
-| p95 | < 250ms |
-| p99 | < 500ms |
+| ---------- | -------------- |
+| p50        | < 100ms        |
+| p95        | < 250ms        |
+| p99        | < 500ms        |
 
 ### 3. Throughput
+
 ```
 Throughput = Requests per Second (RPS)
 ```
 
 ### 4. Error Rate
+
 ```
 Error Rate = (Failed Requests / Total Requests) × 100
 ```
 
 ### 5. Saturation
+
 ```
 CPU Utilization, Memory Usage, Queue Depth
 ```
@@ -70,12 +79,12 @@ CPU Utilization, Memory Usage, Queue Depth
 ### Step 1: Identify Critical User Journeys
 
 ```markdown
-| Journey | Description | Importance |
-|---------|-------------|------------|
-| Login | User authentication | Critical |
-| Checkout | Payment processing | Critical |
-| Search | Product search | High |
-| Browse | Catalog browsing | Medium |
+| Journey  | Description         | Importance |
+| -------- | ------------------- | ---------- |
+| Login    | User authentication | Critical   |
+| Checkout | Payment processing  | Critical   |
+| Search   | Product search      | High       |
+| Browse   | Catalog browsing    | Medium     |
 ```
 
 ### Step 2: Define SLIs for Each Journey
@@ -85,16 +94,16 @@ journeys:
   login:
     slis:
       - type: availability
-        measure: "% of successful logins"
+        measure: '% of successful logins'
       - type: latency
-        measure: "p99 login time"
-      
+        measure: 'p99 login time'
+
   checkout:
     slis:
       - type: availability
-        measure: "% of successful checkouts"
+        measure: '% of successful checkouts'
       - type: latency
-        measure: "p95 checkout time"
+        measure: 'p95 checkout time'
 ```
 
 ### Step 3: Set SLO Targets
@@ -104,11 +113,11 @@ slos:
   login-availability:
     target: 99.9%
     window: 30 days
-    
+
   login-latency-p99:
     target: 500ms
     window: 30 days
-    
+
   checkout-availability:
     target: 99.95%
     window: 30 days
@@ -118,29 +127,32 @@ slos:
 
 ## SLO Document Template
 
-```markdown
+````markdown
 # SLO Document: [Service Name]
 
 ## Service Overview
+
 [Brief description of the service]
 
 ## SLO Summary
 
-| SLO | Target | Window | Priority |
-|-----|--------|--------|----------|
-| Availability | 99.9% | 30 days | P0 |
-| Latency (p99) | < 200ms | 30 days | P1 |
-| Error Rate | < 0.1% | 30 days | P1 |
+| SLO           | Target  | Window  | Priority |
+| ------------- | ------- | ------- | -------- |
+| Availability  | 99.9%   | 30 days | P0       |
+| Latency (p99) | < 200ms | 30 days | P1       |
+| Error Rate    | < 0.1%  | 30 days | P1       |
 
 ## Detailed SLOs
 
 ### Availability
+
 - **SLI**: Percentage of successful HTTP responses (2xx, 3xx)
 - **Target**: 99.9%
 - **Window**: Rolling 30 days
 - **Error Budget**: 43.2 minutes/month
 
 ### Latency
+
 - **SLI**: p99 latency of all API requests
 - **Target**: < 200ms
 - **Window**: Rolling 30 days
@@ -148,35 +160,40 @@ slos:
 ## Measurement
 
 ### Data Sources
+
 - Prometheus metrics
 - Application logs
 - Synthetic monitoring
 
 ### Queries
+
 ```promql
 # Availability
-sum(rate(http_requests_total{status=~"2..|3.."}[5m])) 
-/ 
+sum(rate(http_requests_total{status=~"2..|3.."}[5m]))
+/
 sum(rate(http_requests_total[5m]))
 
 # Latency p99
-histogram_quantile(0.99, 
+histogram_quantile(0.99,
   sum(rate(http_request_duration_seconds_bucket[5m])) by (le)
 )
 ```
+````
 
 ## Alerting
 
-| Alert | Condition | Severity |
-|-------|-----------|----------|
-| Burn Rate High | 2% budget burned in 1h | Critical |
-| Burn Rate Warning | 5% budget burned in 6h | Warning |
+| Alert             | Condition              | Severity |
+| ----------------- | ---------------------- | -------- |
+| Burn Rate High    | 2% budget burned in 1h | Critical |
+| Burn Rate Warning | 5% budget burned in 6h | Warning  |
 
 ## Escalation
+
 - **P0**: Page on-call immediately
 - **P1**: Alert on-call, respond within 1h
 - **P2**: Next business day
-```
+
+````
 
 ---
 
@@ -200,7 +217,7 @@ histogram_quantile(0.99,
 - All hands on reliability
 - Only critical fixes deployed
 - Requires director approval to deploy
-```
+````
 
 ---
 
@@ -210,13 +227,13 @@ histogram_quantile(0.99,
 
 ```promql
 # 5-minute availability
-sum(rate(http_requests_total{status=~"2..|3.."}[5m])) 
-/ 
+sum(rate(http_requests_total{status=~"2..|3.."}[5m]))
+/
 sum(rate(http_requests_total[5m]))
 
 # 30-day availability
-sum(increase(http_requests_total{status=~"2..|3.."}[30d])) 
-/ 
+sum(increase(http_requests_total{status=~"2..|3.."}[30d]))
+/
 sum(increase(http_requests_total[30d]))
 ```
 
@@ -224,13 +241,13 @@ sum(increase(http_requests_total[30d]))
 
 ```promql
 # p99 latency
-histogram_quantile(0.99, 
+histogram_quantile(0.99,
   sum(rate(http_request_duration_seconds_bucket[5m])) by (le)
 )
 
 # Percentage of requests under 200ms
-sum(rate(http_request_duration_seconds_bucket{le="0.2"}[5m])) 
-/ 
+sum(rate(http_request_duration_seconds_bucket{le="0.2"}[5m]))
+/
 sum(rate(http_request_duration_seconds_count[5m]))
 ```
 
@@ -240,11 +257,11 @@ sum(rate(http_request_duration_seconds_count[5m]))
 # Error budget remaining (as percentage)
 1 - (
   (1 - (
-    sum(increase(http_requests_total{status=~"2..|3.."}[30d])) 
-    / 
+    sum(increase(http_requests_total{status=~"2..|3.."}[30d]))
+    /
     sum(increase(http_requests_total[30d]))
-  )) 
-  / 
+  ))
+  /
   (1 - 0.999)  # SLO target
 )
 ```
@@ -257,9 +274,9 @@ sum(rate(http_request_duration_seconds_count[5m]))
 # Grafana dashboard panels
 
 panels:
-  - title: "Current Availability"
+  - title: 'Current Availability'
     type: stat
-    query: "availability_sli"
+    query: 'availability_sli'
     thresholds:
       - value: 0.999
         color: green
@@ -268,18 +285,18 @@ panels:
       - value: 0
         color: red
 
-  - title: "Error Budget Remaining"
+  - title: 'Error Budget Remaining'
     type: gauge
-    query: "error_budget_remaining"
+    query: 'error_budget_remaining'
     max: 100
-    
-  - title: "Latency p99"
+
+  - title: 'Latency p99'
     type: timeseries
-    query: "latency_p99"
-    
-  - title: "Error Budget Burn Rate"
+    query: 'latency_p99'
+
+  - title: 'Error Budget Burn Rate'
     type: timeseries
-    query: "burn_rate_1h"
+    query: 'burn_rate_1h'
 ```
 
 ---
@@ -287,16 +304,19 @@ panels:
 ## SLO Review Checklist
 
 ### Weekly
+
 - [ ] Check error budget status
 - [ ] Review any SLO breaches
 - [ ] Assess burn rate trends
 
 ### Monthly
+
 - [ ] SLO performance report
 - [ ] Error budget consumption analysis
 - [ ] Review and adjust targets if needed
 
 ### Quarterly
+
 - [ ] Comprehensive SLO review
 - [ ] Update user journey mapping
 - [ ] Refine SLI definitions

package/src/templates/agents/claude-code/skills/software-developer/solid-principles.md

@@ -11,27 +11,30 @@ SOLID is an acronym for five design principles that make software designs more u
 > **A class should have only one reason to change.**
 
 ### Definition
+
 A class should have only one job or responsibility. If a class has multiple responsibilities, changes to one responsibility may affect the other.
 
 ### Bad Example ❌
+
 ```typescript
 class UserService {
   createUser(data: UserData): User {
     // Create user
     const user = this.repository.create(data);
-    
+
     // Send welcome email (second responsibility!)
     this.emailService.send(user.email, 'Welcome!');
-    
+
     // Log activity (third responsibility!)
     this.logger.log(`User created: ${user.id}`);
-    
+
     return user;
   }
 }
 ```
 
 ### Good Example ✅
+
 ```typescript
 class UserService {
   createUser(data: UserData): User {
@@ -48,6 +51,7 @@ class UserEventHandler {
 ```
 
 ### Checklist
+
 - [ ] Does the class have only one reason to change?
 - [ ] Can you describe the class responsibility in one sentence without "and"?
 - [ ] Are all methods related to the same responsibility?
@@ -59,9 +63,11 @@ class UserEventHandler {
 > **Software entities should be open for extension but closed for modification.**
 
 ### Definition
+
 You should be able to extend a class's behavior without modifying its existing code.
 
 ### Bad Example ❌
+
 ```typescript
 class PaymentProcessor {
   processPayment(type: string, amount: number): void {
@@ -77,6 +83,7 @@ class PaymentProcessor {
 ```
 
 ### Good Example ✅
+
 ```typescript
 interface PaymentMethod {
   process(amount: number): PaymentResult;
@@ -108,6 +115,7 @@ class PaymentProcessor {
 ```
 
 ### Checklist
+
 - [ ] Can new features be added without modifying existing code?
 - [ ] Are extension points (interfaces, abstract classes) defined?
 - [ ] Does adding a new case require only adding new code?
@@ -119,21 +127,26 @@ class PaymentProcessor {
 > **Subtypes must be substitutable for their base types.**
 
 ### Definition
+
 Objects of a superclass should be replaceable with objects of its subclasses without affecting program correctness.
 
 ### Bad Example ❌
+
 ```typescript
 class Rectangle {
-  constructor(public width: number, public height: number) {}
-  
+  constructor(
+    public width: number,
+    public height: number
+  ) {}
+
   setWidth(width: number): void {
     this.width = width;
   }
-  
+
   setHeight(height: number): void {
     this.height = height;
   }
-  
+
   area(): number {
     return this.width * this.height;
   }
@@ -144,7 +157,7 @@ class Square extends Rectangle {
     this.width = width;
     this.height = width; // Violates LSP!
   }
-  
+
   setHeight(height: number): void {
     this.width = height;
     this.height = height; // Violates LSP!
@@ -160,14 +173,18 @@ function testRectangle(rect: Rectangle): void {
 ```
 
 ### Good Example ✅
+
 ```typescript
 interface Shape {
   area(): number;
 }
 
 class Rectangle implements Shape {
-  constructor(public width: number, public height: number) {}
-  
+  constructor(
+    public width: number,
+    public height: number
+  ) {}
+
   area(): number {
     return this.width * this.height;
   }
@@ -175,7 +192,7 @@ class Rectangle implements Shape {
 
 class Square implements Shape {
   constructor(public side: number) {}
-  
+
   area(): number {
     return this.side * this.side;
   }
@@ -183,6 +200,7 @@ class Square implements Shape {
 ```
 
 ### Checklist
+
 - [ ] Can subclass be used anywhere parent is expected?
 - [ ] Do subclasses honor the parent's contract?
 - [ ] Are there any overridden methods that change expected behavior?
@@ -194,9 +212,11 @@ class Square implements Shape {
 > **Clients should not be forced to depend on interfaces they do not use.**
 
 ### Definition
+
 Many specific interfaces are better than one general-purpose interface. Don't force classes to implement methods they don't need.
 
 ### Bad Example ❌
+
 ```typescript
 interface Worker {
   work(): void;
@@ -205,19 +225,32 @@ interface Worker {
 }
 
 class HumanWorker implements Worker {
-  work(): void { /* ... */ }
-  eat(): void { /* ... */ }
-  sleep(): void { /* ... */ }
+  work(): void {
+    /* ... */
+  }
+  eat(): void {
+    /* ... */
+  }
+  sleep(): void {
+    /* ... */
+  }
 }
 
 class RobotWorker implements Worker {
-  work(): void { /* ... */ }
-  eat(): void { throw new Error('Robots don\'t eat!'); } // Forced to implement!
-  sleep(): void { throw new Error('Robots don\'t sleep!'); } // Forced to implement!
+  work(): void {
+    /* ... */
+  }
+  eat(): void {
+    throw new Error("Robots don't eat!");
+  } // Forced to implement!
+  sleep(): void {
+    throw new Error("Robots don't sleep!");
+  } // Forced to implement!
 }
 ```
 
 ### Good Example ✅
+
 ```typescript
 interface Workable {
   work(): void;
@@ -232,18 +265,27 @@ interface Sleepable {
 }
 
 class HumanWorker implements Workable, Eatable, Sleepable {
-  work(): void { /* ... */ }
-  eat(): void { /* ... */ }
-  sleep(): void { /* ... */ }
+  work(): void {
+    /* ... */
+  }
+  eat(): void {
+    /* ... */
+  }
+  sleep(): void {
+    /* ... */
+  }
 }
 
 class RobotWorker implements Workable {
-  work(): void { /* ... */ }
+  work(): void {
+    /* ... */
+  }
   // No need to implement eat or sleep!
 }
 ```
 
 ### Checklist
+
 - [ ] Are interfaces focused and cohesive?
 - [ ] Do implementing classes use all interface methods?
 - [ ] Can large interfaces be split into smaller ones?
@@ -255,9 +297,11 @@ class RobotWorker implements Workable {
 > **High-level modules should not depend on low-level modules. Both should depend on abstractions.**
 
 ### Definition
+
 Depend on abstractions (interfaces), not concrete implementations. This allows for flexibility and easier testing.
 
 ### Bad Example ❌
+
 ```typescript
 class MySQLDatabase {
   query(sql: string): any[] {
@@ -267,7 +311,7 @@ class MySQLDatabase {
 
 class UserRepository {
   private database = new MySQLDatabase(); // Tight coupling!
-  
+
   findById(id: string): User {
     return this.database.query(`SELECT * FROM users WHERE id = '${id}'`);
   }
@@ -275,6 +319,7 @@ class UserRepository {
 ```
 
 ### Good Example ✅
+
 ```typescript
 interface Database {
   query(sql: string): any[];
@@ -294,7 +339,7 @@ class PostgreSQLDatabase implements Database {
 
 class UserRepository {
   constructor(private database: Database) {} // Injected!
-  
+
   findById(id: string): User {
     return this.database.query(`SELECT * FROM users WHERE id = '${id}'`);
   }
@@ -309,6 +354,7 @@ const repository = new UserRepository(new MockDatabase());
 ```
 
 ### Checklist
+
 - [ ] Do high-level modules depend on abstractions?
 - [ ] Are dependencies injected rather than created internally?
 - [ ] Can implementations be swapped without code changes?
@@ -317,13 +363,13 @@ const repository = new UserRepository(new MockDatabase());
 
 ## SOLID Summary Table
 
-| Principle | Acronym | Key Idea |
-|-----------|---------|----------|
-| Single Responsibility | S | One class, one job |
-| Open/Closed | O | Extend, don't modify |
-| Liskov Substitution | L | Subtypes are replaceable |
-| Interface Segregation | I | Small, focused interfaces |
-| Dependency Inversion | D | Depend on abstractions |
+| Principle             | Acronym | Key Idea                  |
+| --------------------- | ------- | ------------------------- |
+| Single Responsibility | S       | One class, one job        |
+| Open/Closed           | O       | Extend, don't modify      |
+| Liskov Substitution   | L       | Subtypes are replaceable  |
+| Interface Segregation | I       | Small, focused interfaces |
+| Dependency Inversion  | D       | Depend on abstractions    |
 
 ---
 
@@ -331,13 +377,13 @@ const repository = new UserRepository(new MockDatabase());
 
 ### Constitutional Alignment
 
-| Principle | Constitutional Article |
-|-----------|----------------------|
-| SRP | Article VII: Simplicity Gate |
-| OCP | Article I: Library-First (extensible libraries) |
-| LSP | Article III: Test-First (substitutable mocks) |
-| ISP | Article VIII: Anti-Abstraction (focused interfaces) |
-| DIP | Article IX: Integration-First (testable dependencies) |
+| Principle | Constitutional Article                                |
+| --------- | ----------------------------------------------------- |
+| SRP       | Article VII: Simplicity Gate                          |
+| OCP       | Article I: Library-First (extensible libraries)       |
+| LSP       | Article III: Test-First (substitutable mocks)         |
+| ISP       | Article VIII: Anti-Abstraction (focused interfaces)   |
+| DIP       | Article IX: Integration-First (testable dependencies) |
 
 ### When to Apply