@ruyfranca/myskills 1.0.27 → 1.0.29

package/.agent/skills/cqrs-implementation/SKILL.md

@@ -0,0 +1,107 @@
+---
+name: cqrs-implementation
+description: "Implement Command Query Responsibility Segregation for scalable architectures. Use when separating read and write models, optimizing query performance, or building event-sourced systems."
+risk: unknown
+source: community
+date_added: "2026-02-27"
+---
+
+# CQRS Implementation
+
+Comprehensive guide to implementing CQRS (Command Query Responsibility Segregation) patterns.
+
+## Use this skill when
+
+- Separating read and write concerns
+- Scaling reads independently from writes
+- Building event-sourced systems
+- Optimizing complex query scenarios
+- Different read/write data models are needed
+- High-performance reporting is required
+
+## Do not use this skill when
+
+- The domain is simple and CRUD is sufficient
+- You cannot operate separate read/write models
+- Strong immediate consistency is required everywhere
+
+## Instructions
+
+- Identify read/write workloads and consistency needs.
+- Define command and query models with clear boundaries.
+- Implement read model projections and synchronization.
+- Validate performance, recovery, and failure modes.
+
+## Core Concepts
+
+### Commands (Write Side)
+
+```typescript
+// Command — intent to change state
+interface SubmitOrderCommand {
+  orderId: string;
+  items: OrderItem[];
+  customerId: string;
+}
+
+// Command Handler
+class SubmitOrderHandler {
+  async handle(cmd: SubmitOrderCommand): Promise<void> {
+    const order = await this.orderRepo.findById(cmd.orderId);
+    order.submit(cmd.items);
+    await this.orderRepo.save(order);
+    await this.eventBus.publish(order.domainEvents);
+  }
+}
+```
+
+### Queries (Read Side)
+
+```typescript
+// Read model — optimized for queries
+interface OrderSummaryView {
+  orderId: string;
+  customerName: string;
+  totalAmount: number;
+  status: string;
+  createdAt: Date;
+}
+
+// Query Handler
+class GetOrderSummaryHandler {
+  async handle(orderId: string): Promise<OrderSummaryView> {
+    return this.readDb.query(
+      'SELECT * FROM order_summaries WHERE order_id = $1',
+      [orderId]
+    );
+  }
+}
+```
+
+### Projection Building
+
+```typescript
+// Project events to read model
+class OrderProjection {
+  async on(event: OrderSubmitted): Promise<void> {
+    await this.readDb.upsert('order_summaries', {
+      order_id: event.orderId,
+      status: 'submitted',
+      submitted_at: event.occurredAt,
+    });
+  }
+}
+```
+
+## Synchronization Strategies
+
+| Strategy | Consistency | Complexity |
+|----------|-------------|------------|
+| Synchronous | Strong | High |
+| Async via events | Eventual | Medium |
+| Change Data Capture | Near-real-time | Medium |
+| Scheduled rebuild | Eventual | Low |
+
+## Related Skills
+
+Works well with: `event-sourcing-architect`, `ddd-tactical-patterns`

package/.agent/skills/ddd-strategic-design/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: ddd-strategic-design
+description: "Design DDD strategic artifacts including subdomains, bounded contexts, and ubiquitous language for complex business domains."
+risk: safe
+source: self
+tags: "[ddd, strategic-design, bounded-context, ubiquitous-language]"
+date_added: "2026-02-27"
+---
+
+# DDD Strategic Design
+
+## Use this skill when
+
+- Defining core, supporting, and generic subdomains.
+- Splitting a monolith or service landscape by domain boundaries.
+- Aligning teams and ownership with bounded contexts.
+- Building a shared ubiquitous language with domain experts.
+
+## Do not use this skill when
+
+- The domain model is stable and already well bounded.
+- You need tactical code patterns only.
+- The task is purely infrastructure or UI oriented.
+
+## Instructions
+
+1. Extract domain capabilities and classify subdomains.
+2. Define bounded contexts around consistency and ownership.
+3. Establish a ubiquitous language glossary and anti-terms.
+4. Capture context boundaries in ADRs before implementation.
+
+## Required artifacts
+
+- Subdomain classification table
+- Bounded context catalog
+- Glossary with canonical terms
+- Boundary decisions with rationale
+
+## Subdomain Classification
+
+| Type | Description | Example |
+|------|-------------|---------|
+| **Core** | Competitive advantage, high complexity | Order management |
+| **Supporting** | Needed but not differentiating | Notifications |
+| **Generic** | Commodity, buy or use SaaS | Authentication |
+
+## Bounded Context Patterns
+
+### Context Map Relationships
+
+| Pattern | When to Use |
+|---------|------------|
+| **Partnership** | Teams must cooperate closely |
+| **Shared Kernel** | Small shared model owned jointly |
+| **Customer-Supplier** | One team depends on the other |
+| **Anti-Corruption Layer** | Protect from legacy/external models |
+| **Published Language** | Well-documented integration protocol |
+
+## Examples
+
+```text
+Use @ddd-strategic-design to map our commerce domain into bounded contexts,
+classify subdomains, and propose team ownership.
+```
+
+## Limitations
+
+- This skill does not produce executable code.
+- It cannot infer business truth without stakeholder input.
+- It should be followed by tactical design before implementation.

package/.agent/skills/ddd-tactical-patterns/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: ddd-tactical-patterns
+description: "Apply DDD tactical patterns in code using entities, value objects, aggregates, repositories, and domain events with explicit invariants."
+risk: safe
+source: self
+tags: "[ddd, tactical, aggregates, value-objects, domain-events]"
+date_added: "2026-02-27"
+---
+
+# DDD Tactical Patterns
+
+## Use this skill when
+
+- Translating domain rules into code structures.
+- Designing aggregate boundaries and invariants.
+- Refactoring an anemic model into behavior-rich domain objects.
+- Defining repository contracts and domain event boundaries.
+
+## Do not use this skill when
+
+- You are still defining strategic boundaries.
+- The task is only API documentation or UI layout.
+- Full DDD complexity is not justified.
+
+## Instructions
+
+1. Identify invariants first and design aggregates around them.
+2. Model immutable value objects for validated concepts.
+3. Keep domain behavior in domain objects, not controllers.
+4. Emit domain events for meaningful state transitions.
+5. Keep repositories at aggregate root boundaries.
+
+## Core Building Blocks
+
+| Building Block | Description | Key Rule |
+|----------------|-------------|----------|
+| **Entity** | Has identity, mutable | ID never changes |
+| **Value Object** | No identity, immutable | Equality by value |
+| **Aggregate** | Transaction boundary | Only root is public |
+| **Repository** | Collection abstraction | One per aggregate root |
+| **Domain Event** | Fact that happened | Immutable, past tense name |
+| **Domain Service** | Stateless behavior | For cross-aggregate logic |
+
+## Example
+
+```typescript
+class Order {
+  private status: "draft" | "submitted" = "draft";
+
+  submit(itemsCount: number): void {
+    if (itemsCount === 0) throw new Error("Order cannot be submitted empty");
+    if (this.status !== "draft") throw new Error("Order already submitted");
+    this.status = "submitted";
+    this.addEvent(new OrderSubmitted(this.id));
+  }
+}
+```
+
+## Aggregate Design Rules
+
+- Keep aggregates small — focus on invariants
+- Reference other aggregates by ID only
+- Design for eventual consistency between aggregates
+- One transaction = one aggregate
+
+## Limitations
+
+- This skill does not define deployment architecture.
+- It does not choose databases or transport protocols.
+- It should be paired with testing patterns for invariant coverage.

package/.agent/skills/elixir-pro/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: elixir-pro
+description: Write idiomatic Elixir code with OTP patterns, supervision trees, and Phoenix LiveView. Masters concurrency, fault tolerance, and distributed systems.
+risk: unknown
+source: community
+date_added: "2026-02-27"
+---
+
+# Elixir Pro
+
+You are an Elixir expert specializing in concurrent, fault-tolerant, and distributed systems.
+
+## Use this skill when
+
+- Building concurrent, fault-tolerant Elixir applications
+- Working with OTP patterns (GenServer, Supervisor, Application)
+- Developing Phoenix applications and LiveView real-time features
+- Designing distributed systems with Elixir
+
+## Do not use this skill when
+
+- The task is unrelated to Elixir/OTP/Phoenix
+- You need a different language or runtime
+
+## Focus Areas
+
+- OTP patterns (GenServer, Supervisor, Application)
+- Phoenix framework and LiveView real-time features
+- Ecto for database interactions and changesets
+- Pattern matching and guard clauses
+- Concurrent programming with processes and Tasks
+- Distributed systems with nodes and clustering
+- Performance optimization on the BEAM VM
+
+## Core Patterns
+
+```elixir
+# GenServer example
+defmodule MyWorker do
+  use GenServer
+
+  def start_link(opts), do: GenServer.start_link(__MODULE__, opts, name: __MODULE__)
+  def init(state), do: {:ok, state}
+
+  def handle_call(:get_state, _from, state) do
+    {:reply, state, state}
+  end
+
+  def handle_cast({:update, new_val}, state) do
+    {:noreply, Map.put(state, :value, new_val)}
+  end
+end
+
+# Supervision tree
+defmodule MyApp.Supervisor do
+  use Supervisor
+
+  def start_link(opts), do: Supervisor.start_link(__MODULE__, opts, name: __MODULE__)
+
+  def init(_opts) do
+    children = [
+      MyWorker,
+      {Task.Supervisor, name: MyApp.TaskSupervisor}
+    ]
+    Supervisor.init(children, strategy: :one_for_one)
+  end
+end
+```
+
+## Approach
+
+1. Embrace "let it crash" philosophy with proper supervision
+2. Use pattern matching over conditional logic
+3. Design with processes for isolation and concurrency
+4. Leverage immutability for predictable state
+5. Test with ExUnit, focusing on property-based testing
+6. Profile with :observer and :recon for bottlenecks
+
+## Output
+
+- Idiomatic Elixir following community style guide
+- OTP applications with proper supervision trees
+- Phoenix apps with contexts and clean boundaries
+- ExUnit tests with doctests and async where possible
+- Dialyzer specs for type safety
+- Performance benchmarks with Benchee
+- Telemetry instrumentation for observability
+
+Follow Elixir conventions. Design for fault tolerance and horizontal scaling.

package/.agent/skills/event-sourcing-architect/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: event-sourcing-architect
+description: "Expert in event sourcing, CQRS, and event-driven architecture patterns. Masters event store design, projection building, saga orchestration, and eventual consistency patterns."
+risk: unknown
+source: community
+date_added: "2026-02-27"
+---
+
+# Event Sourcing Architect
+
+Expert in event sourcing, CQRS, and event-driven architecture patterns. Masters event store design, projection building, saga orchestration, and eventual consistency patterns. Use PROACTIVELY for event-sourced systems, audit trail requirements, or complex domain modeling with temporal queries.
+
+## Capabilities
+
+- Event store design and implementation
+- CQRS (Command Query Responsibility Segregation) patterns
+- Projection building and read model optimization
+- Saga and process manager orchestration
+- Event versioning and schema evolution
+- Snapshotting strategies for performance
+- Eventual consistency handling
+
+## Use this skill when
+
+- Building systems requiring complete audit trails
+- Implementing complex business workflows with compensating actions
+- Designing systems needing temporal queries ("what was state at time X")
+- Separating read and write models for performance
+- Building event-driven microservices architectures
+- Implementing undo/redo or time-travel debugging
+
+## Do not use this skill when
+
+- The domain is simple and CRUD is sufficient
+- You cannot support event store operations or projections
+- Strong immediate consistency is required everywhere
+
+## Instructions
+
+1. Identify aggregate boundaries and event streams
+2. Design events as immutable facts
+3. Implement command handlers and event application
+4. Build projections for query requirements
+5. Design saga/process managers for cross-aggregate workflows
+6. Implement snapshotting for long-lived aggregates
+7. Set up event versioning strategy
+
+## Safety
+
+- Never mutate or delete committed events in production.
+- Rebuild projections in staging before running in production.
+
+## Best Practices
+
+- Events are facts - never delete or modify them
+- Keep events small and focused
+- Version events from day one
+- Design for eventual consistency
+- Use correlation IDs for tracing
+- Implement idempotent event handlers
+- Plan for projection rebuilding
+- Use durable execution for process managers and sagas
+
+## Related Skills
+
+Works well with: `cqrs-implementation`, `ddd-tactical-patterns`, `saga-orchestration`

package/.agent/skills/golang-pro/SKILL.md

@@ -0,0 +1,121 @@
+---
+name: golang-pro
+description: Master Go 1.21+ with modern patterns, advanced concurrency, performance optimization, and production-ready microservices.
+risk: unknown
+source: community
+date_added: "2026-02-27"
+---
+
+# Go Pro
+
+You are a Go expert specializing in modern Go 1.21+ development with advanced concurrency patterns, performance optimization, and production-ready system design.
+
+## Use this skill when
+
+- Building Go services, CLIs, or microservices
+- Designing concurrency patterns and performance optimizations
+- Reviewing Go architecture and production readiness
+
+## Do not use this skill when
+
+- You need another language or runtime
+- You only need basic Go syntax explanations
+- You cannot change Go tooling or build configuration
+
+## Instructions
+
+1. Confirm Go version, tooling, and runtime constraints.
+2. Choose concurrency and architecture patterns.
+3. Implement with testing and profiling.
+4. Optimize for latency, memory, and reliability.
+
+## Key Capabilities
+
+### Concurrency & Parallelism
+
+```go
+// Worker pool pattern
+func workerPool(ctx context.Context, jobs <-chan Job, numWorkers int) <-chan Result {
+    results := make(chan Result, numWorkers)
+    var wg sync.WaitGroup
+    
+    for i := 0; i < numWorkers; i++ {
+        wg.Add(1)
+        go func() {
+            defer wg.Done()
+            for job := range jobs {
+                select {
+                case results <- processJob(ctx, job):
+                case <-ctx.Done():
+                    return
+                }
+            }
+        }()
+    }
+    
+    go func() {
+        wg.Wait()
+        close(results)
+    }()
+    
+    return results
+}
+```
+
+### Error Handling
+
+```go
+// Wrap errors with context
+if err := store.Save(user); err != nil {
+    return fmt.Errorf("saving user %s: %w", user.ID, err)
+}
+
+// Sentinel errors
+var ErrNotFound = errors.New("not found")
+
+// Check wrapped errors
+if errors.Is(err, ErrNotFound) {
+    // handle not found
+}
+```
+
+### Testing
+
+```go
+func TestCalculate(t *testing.T) {
+    cases := []struct {
+        name  string
+        input int
+        want  int
+    }{
+        {"positive", 5, 25},
+        {"zero", 0, 0},
+        {"negative", -3, 9},
+    }
+    
+    for _, tc := range cases {
+        t.Run(tc.name, func(t *testing.T) {
+            got := Calculate(tc.input)
+            if got != tc.want {
+                t.Errorf("Calculate(%d) = %d, want %d", tc.input, got, tc.want)
+            }
+        })
+    }
+}
+```
+
+## Modern Go Features (1.21+)
+
+- Structured logging with `slog` (built-in)
+- Improved type inference for generics
+- `slices` and `maps` packages for common operations
+- `min`, `max`, `clear` built-in functions
+- `errors.Join` for combining errors
+
+## Best Practices
+
+- Prefer composition over inheritance (embed interfaces)
+- Accept interfaces, return structs
+- Use context for cancellation and deadlines
+- Profile before optimizing (pprof)
+- Use `golangci-lint` with strict config in CI

package/.agent/skills/kotlin-coroutines-expert/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: kotlin-coroutines-expert
+description: "Expert patterns for Kotlin Coroutines and Flow, covering structured concurrency, error handling, and testing."
+risk: safe
+source: community
+date_added: "2026-02-27"
+---
+
+# Kotlin Coroutines Expert
+
+## Overview
+
+A guide to mastering asynchronous programming with Kotlin Coroutines. Covers advanced topics like structured concurrency, `Flow` transformations, exception handling, and testing strategies.
+
+## When to Use This Skill
+
+- Use when implementing asynchronous operations in Kotlin.
+- Use when designing reactive data streams with `Flow`.
+- Use when debugging coroutine cancellations or exceptions.
+- Use when writing unit tests for suspending functions or Flows.
+
+## Step-by-Step Guide
+
+### 1. Structured Concurrency
+
+Always launch coroutines within a defined `CoroutineScope`. Use `coroutineScope` or `supervisorScope` to group concurrent tasks.
+
+```kotlin
+suspend fun loadDashboardData(): DashboardData = coroutineScope {
+    val userDeferred = async { userRepo.getUser() }
+    val settingsDeferred = async { settingsRepo.getSettings() }
+    
+    DashboardData(
+        user = userDeferred.await(),
+        settings = settingsDeferred.await()
+    )
+}
+```
+
+### 2. Exception Handling
+
+Use `CoroutineExceptionHandler` for top-level scopes, but rely on `try-catch` within suspending functions for granular control.
+
+```kotlin
+val handler = CoroutineExceptionHandler { _, exception ->
+    println("Caught $exception")
+}
+
+viewModelScope.launch(handler) {
+    try {
+        riskyOperation()
+    } catch (e: IOException) {
+        // Handle network error specifically
+    }
+}
+```
+
+### 3. Reactive Streams with Flow
+
+Use `StateFlow` for state that needs to be retained, and `SharedFlow` for events.
+
+```kotlin
+// Cold Flow (Lazy)
+val searchResults: Flow<List<Item>> = searchQuery
+    .debounce(300)
+    .flatMapLatest { query -> searchRepo.search(query) }
+    .flowOn(Dispatchers.IO)
+
+// Hot Flow (State)
+val uiState: StateFlow<UiState> = _uiState.asStateFlow()
+```
+
+### 4. Parallel Execution with Error Handling
+
+```kotlin
+suspend fun fetchDataWithErrorHandling() = supervisorScope {
+    val task1 = async { 
+        try { api.fetchA() } catch (e: Exception) { null } 
+    }
+    val task2 = async { api.fetchB() }
+    
+    // If task2 fails, task1 is NOT cancelled because of supervisorScope
+    val result1 = task1.await()
+    val result2 = task2.await() // May throw
+}
+```
+
+## Best Practices
+
+- ✅ **Do:** Use `Dispatchers.IO` for blocking I/O operations.
+- ✅ **Do:** Cancel scopes when they are no longer needed (e.g., `ViewModel.onCleared`).
+- ✅ **Do:** Use `TestScope` and `runTest` for unit testing coroutines.
+- ❌ **Don't:** Use `GlobalScope`. It breaks structured concurrency and can lead to leaks.
+- ❌ **Don't:** Catch `CancellationException` unless you rethrow it.
+
+## Troubleshooting
+
+**Problem:** Coroutine test hangs or fails unpredictably.
+**Solution:** Ensure you are using `runTest` and injecting `TestDispatcher` into your classes so you can control virtual time.