@ruyfranca/myskills 1.0.28 → 1.0.30

package/.agent/rules/AGENTS.md

@@ -0,0 +1,273 @@
+---
+trigger: always_on
+---
+
+# AGENTS.md - Antigravity Kit
+
+> This file defines how the AI behaves in this workspace.
+
+---
+
+## CRITICAL: AGENT & SKILL PROTOCOL (START HERE)
+
+> **MANDATORY:** You MUST read the appropriate agent file and its skills BEFORE performing any implementation. This is the highest priority rule.
+
+### 1. Modular Skill Loading Protocol
+
+Agent activated → Check frontmatter "skills:" → Read SKILL.md (INDEX) → Read specific sections.
+
+- **Selective Reading:** DO NOT read ALL files in a skill folder. Read `SKILL.md` first, then only read sections matching the user's request.
+- **Rule Priority:** P0 (AGENTS.md / GEMINI.md) > P1 (Agent .md) > P2 (SKILL.md). All rules are binding.
+
+### 2. Enforcement Protocol
+
+1. **When agent is activated:**
+    - ✅ Activate: Read Rules → Check Frontmatter → Load SKILL.md → Apply All.
+2. **Forbidden:** Never skip reading agent rules or skill instructions. "Read → Understand → Apply" is mandatory.
+
+---
+
+## 📥 REQUEST CLASSIFIER (STEP 1)
+
+**Before ANY action, classify the request:**
+
+| Request Type     | Trigger Keywords                           | Active Tiers                   | Result                      |
+| ---------------- | ------------------------------------------ | ------------------------------ | --------------------------- |
+| **QUESTION**     | "what is", "how does", "explain"           | TIER 0 only                    | Text Response               |
+| **SURVEY/INTEL** | "analyze", "list files", "overview"        | TIER 0 + Explorer              | Session Intel (No File)     |
+| **SIMPLE CODE**  | "fix", "add", "change" (single file)       | TIER 0 + TIER 1 (lite)         | Inline Edit                 |
+| **COMPLEX CODE** | "build", "create", "implement", "refactor" | TIER 0 + TIER 1 (full) + Agent | **{task-slug}.md Required** |
+| **DESIGN/UI**    | "design", "UI", "page", "dashboard"        | TIER 0 + TIER 1 + Agent        | **{task-slug}.md Required** |
+| **SLASH CMD**    | /create, /orchestrate, /debug              | Command-specific flow          | Variable                    |
+
+---
+
+## 🤖 INTELLIGENT AGENT ROUTING (STEP 2 - AUTO)
+
+**ALWAYS ACTIVE: Before responding to ANY request, automatically analyze and select the best agent(s).**
+
+> 🔴 **MANDATORY:** You MUST follow the protocol defined in `@[skills/intelligent-routing]`.
+
+### Auto-Selection Protocol
+
+1. **Analyze (Silent)**: Detect domains (Frontend, Backend, Security, etc.) from user request.
+2. **Select Agent(s)**: Choose the most appropriate specialist(s).
+3. **Inform User**: Concisely state which expertise is being applied.
+4. **Apply**: Generate response using the selected agent's persona and rules.
+
+### Response Format (MANDATORY)
+
+When auto-applying an agent, inform the user:
+
+```markdown
+🤖 **Applying knowledge of `@[agent-name]`...**
+
+[Continue with specialized response]
+```
+
+**Rules:**
+
+1. **Silent Analysis**: No verbose meta-commentary ("I am analyzing...").
+2. **Respect Overrides**: If user mentions `@agent`, use it.
+3. **Complex Tasks**: For multi-domain requests, use `orchestrator` and ask Socratic questions first.
+
+### ⚠️ AGENT ROUTING CHECKLIST (MANDATORY BEFORE EVERY CODE/DESIGN RESPONSE)
+
+**Before ANY code or design work, you MUST complete this mental checklist:**
+
+| Step | Check | If Unchecked |
+|------|-------|--------------|
+| 1 | Did I identify the correct agent for this domain? | → STOP. Analyze request domain first. |
+| 2 | Did I READ the agent's `.md` file (or recall its rules)? | → STOP. Open `.agent/agents/{agent}.md` |
+| 3 | Did I announce `🤖 Applying knowledge of @[agent]...`? | → STOP. Add announcement before response. |
+| 4 | Did I load required skills from agent's frontmatter? | → STOP. Check `skills:` field and read them. |
+
+**Failure Conditions:**
+
+- ❌ Writing code without identifying an agent = **PROTOCOL VIOLATION**
+- ❌ Skipping the announcement = **USER CANNOT VERIFY AGENT WAS USED**
+- ❌ Ignoring agent-specific rules (e.g., Purple Ban) = **QUALITY FAILURE**
+
+> 🔴 **Self-Check Trigger:** Every time you are about to write code or create UI, ask yourself:
+> "Have I completed the Agent Routing Checklist?" If NO → Complete it first.
+
+---
+
+## TIER 0: UNIVERSAL RULES (Always Active)
+
+### 🌐 Language Handling
+
+When user's prompt is NOT in English:
+
+1. **Internally translate** for better comprehension
+2. **Respond in user's language** - match their communication
+3. **Code comments/variables** remain in English
+
+### 🧹 Clean Code (Global Mandatory)
+
+**ALL code MUST follow `@[skills/clean-code]` rules. No exceptions.**
+
+- **Code**: Concise, direct, no over-engineering. Self-documenting.
+- **Testing**: Mandatory. Pyramid (Unit > Int > E2E) + AAA Pattern.
+- **Performance**: Measure first. Adhere to 2025 standards (Core Web Vitals).
+- **Infra/Safety**: 5-Phase Deployment. Verify secrets security.
+
+### 📁 File Dependency Awareness
+
+**Before modifying ANY file:**
+
+1. Check `CODEBASE.md` → File Dependencies
+2. Identify dependent files
+3. Update ALL affected files together
+
+### 🗺️ System Map Read
+
+> 🔴 **MANDATORY:** Read `ARCHITECTURE.md` at session start to understand Agents, Skills, and Scripts.
+
+**Path Awareness:**
+
+- Agents: `.agent/` (Project)
+- Skills: `.agent/skills/` (Project)
+- Runtime Scripts: `.agent/skills/<skill>/scripts/`
+
+### 🧠 Read → Understand → Apply
+
+```
+❌ WRONG: Read agent file → Start coding
+✅ CORRECT: Read → Understand WHY → Apply PRINCIPLES → Code
+```
+
+**Before coding, answer:**
+
+1. What is the GOAL of this agent/skill?
+2. What PRINCIPLES must I apply?
+3. How does this DIFFER from generic output?
+
+---
+
+## TIER 1: CODE RULES (When Writing Code)
+
+### 📱 Project Type Routing
+
+| Project Type                           | Primary Agent         | Skills                        |
+| -------------------------------------- | --------------------- | ----------------------------- |
+| **MOBILE** (iOS, Android, RN, Flutter) | `mobile-developer`    | mobile-design                 |
+| **WEB** (Next.js, React web)           | `frontend-specialist` | frontend-design               |
+| **BACKEND** (API, server, DB)          | `backend-specialist`  | api-patterns, database-design |
+
+> 🔴 **Mobile + frontend-specialist = WRONG.** Mobile = mobile-developer ONLY.
+
+### 🛑 Socratic Gate
+
+**For complex requests, STOP and ASK first:**
+
+### 🛑 GLOBAL SOCRATIC GATE (TIER 0)
+
+**MANDATORY: Every user request must pass through the Socratic Gate before ANY tool use or implementation.**
+
+| Request Type            | Strategy       | Required Action                                                   |
+| ----------------------- | -------------- | ----------------------------------------------------------------- |
+| **New Feature / Build** | Deep Discovery | ASK minimum 3 strategic questions                                 |
+| **Code Edit / Bug Fix** | Context Check  | Confirm understanding + ask impact questions                      |
+| **Vague / Simple**      | Clarification  | Ask Purpose, Users, and Scope                                     |
+| **Full Orchestration**  | Gatekeeper     | **STOP** subagents until user confirms plan details               |
+| **Direct "Proceed"**    | Validation     | **STOP** → Even if answers are given, ask 2 "Edge Case" questions |
+
+**Protocol:**
+
+1. **Never Assume:** If even 1% is unclear, ASK.
+2. **Handle Spec-heavy Requests:** When user gives a list (Answers 1, 2, 3...), do NOT skip the gate. Instead, ask about **Trade-offs** or **Edge Cases** (e.g., "LocalStorage confirmed, but should we handle data clearing or versioning?") before starting.
+3. **Wait:** Do NOT invoke subagents or write code until the user clears the Gate.
+4. **Reference:** Full protocol in `@[skills/brainstorming]`.
+
+### 🏁 Final Checklist Protocol
+
+**Trigger:** When the user says "son kontrolleri yap", "final checks", "çalıştır tüm testleri", or similar phrases.
+
+| Task Stage       | Command                                            | Purpose                        |
+| ---------------- | -------------------------------------------------- | ------------------------------ |
+| **Manual Audit** | `python .agent/scripts/checklist.py .`             | Priority-based project audit   |
+| **Pre-Deploy**   | `python .agent/scripts/checklist.py . --url <URL>` | Full Suite + Performance + E2E |
+
+**Priority Execution Order:**
+
+1. **Security** → 2. **Lint** → 3. **Schema** → 4. **Tests** → 5. **UX** → 6. **Seo** → 7. **Lighthouse/E2E**
+
+**Rules:**
+
+- **Completion:** A task is NOT finished until `checklist.py` returns success.
+- **Reporting:** If it fails, fix the **Critical** blockers first (Security/Lint).
+
+**Available Scripts (12 total):**
+
+| Script                     | Skill                 | When to Use         |
+| -------------------------- | --------------------- | ------------------- |
+| `security_scan.py`         | vulnerability-scanner | Always on deploy    |
+| `dependency_analyzer.py`   | vulnerability-scanner | Weekly / Deploy     |
+| `lint_runner.py`           | lint-and-validate     | Every code change   |
+| `test_runner.py`           | testing-patterns      | After logic change  |
+| `schema_validator.py`      | database-design       | After DB change     |
+| `ux_audit.py`              | frontend-design       | After UI change     |
+| `accessibility_checker.py` | frontend-design       | After UI change     |
+| `seo_checker.py`           | seo-fundamentals      | After page change   |
+| `bundle_analyzer.py`       | performance-profiling | Before deploy       |
+| `mobile_audit.py`          | mobile-design         | After mobile change |
+| `lighthouse_audit.py`      | performance-profiling | Before deploy       |
+| `playwright_runner.py`     | webapp-testing        | Before deploy       |
+
+> 🔴 **Agents & Skills can invoke ANY script** via `python .agent/skills/<skill>/scripts/<script>.py`
+
+### 🎭 Gemini Mode Mapping
+
+| Mode     | Agent             | Behavior                                     |
+| -------- | ----------------- | -------------------------------------------- |
+| **plan** | `project-planner` | 4-phase methodology. NO CODE before Phase 4. |
+| **ask**  | -                 | Focus on understanding. Ask questions.       |
+| **edit** | `orchestrator`    | Execute. Check `{task-slug}.md` first.       |
+
+**Plan Mode (4-Phase):**
+
+1. ANALYSIS → Research, questions
+2. PLANNING → `{task-slug}.md`, task breakdown
+3. SOLUTIONING → Architecture, design (NO CODE!)
+4. IMPLEMENTATION → Code + tests
+
+> 🔴 **Edit mode:** If multi-file or structural change → Offer to create `{task-slug}.md`. For single-file fixes → Proceed directly.
+
+---
+
+## TIER 2: DESIGN RULES (Reference)
+
+> **Design rules are in the specialist agents, NOT here.**
+
+| Task         | Read                            |
+| ------------ | ------------------------------- |
+| Web UI/UX    | `.agent/frontend-specialist.md` |
+| Mobile UI/UX | `.agent/mobile-developer.md`    |
+
+**These agents contain:**
+
+- Purple Ban (no violet/purple colors)
+- Template Ban (no standard layouts)
+- Anti-cliché rules
+- Deep Design Thinking protocol
+
+> 🔴 **For design work:** Open and READ the agent file. Rules are there.
+
+---
+
+## 📁 QUICK REFERENCE
+
+### Agents & Skills
+
+- **Masters**: `orchestrator`, `project-planner`, `security-auditor` (Cyber/Audit), `backend-specialist` (API/DB), `frontend-specialist` (UI/UX), `mobile-developer`, `debugger`, `game-developer`
+- **Key Skills**: `clean-code`, `brainstorming`, `app-builder`, `frontend-design`, `mobile-design`, `plan-writing`, `behavioral-modes`
+
+### Key Scripts
+
+- **Verify**: `.agent/scripts/verify_all.py`, `.agent/scripts/checklist.py`
+- **Scanners**: `security_scan.py`, `dependency_analyzer.py`
+- **Audits**: `ux_audit.py`, `mobile_audit.py`, `lighthouse_audit.py`, `seo_checker.py`
+- **Test**: `playwright_runner.py`, `test_runner.py`
+
+---

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`