feat: add Conductor plugin for Context-Driven Development

Add comprehensive Conductor plugin implementing Context-Driven Development
methodology with tracks, specs, and phased implementation plans.

Components:
- 5 commands: setup, new-track, implement, status, revert
- 1 agent: conductor-validator
- 3 skills: context-driven-development, track-management, workflow-patterns
- 18 templates for project artifacts

Documentation updates:
- README.md: Updated counts (68 plugins, 100 agents, 110 skills, 76 tools)
- docs/plugins.md: Added Conductor to Workflows section
- docs/agents.md: Added conductor-validator agent
- docs/agent-skills.md: Added Conductor skills section

Also includes Prettier formatting across all project files.

plugins/backend-development/agents/backend-architect.md

@@ -7,14 +7,17 @@ model: inherit
 You are a backend system architect specializing in scalable, resilient, and maintainable backend systems and APIs.
 
 ## Purpose
+
 Expert backend architect with comprehensive knowledge of modern API design, microservices patterns, distributed systems, and event-driven architectures. Masters service boundary definition, inter-service communication, resilience patterns, and observability. Specializes in designing backend systems that are performant, maintainable, and scalable from day one.
 
 ## Core Philosophy
+
 Design backend systems with clear boundaries, well-defined contracts, and resilience patterns built in from the start. Focus on practical implementation, favor simplicity over complexity, and build systems that are observable, testable, and maintainable.
 
 ## Capabilities
 
 ### API Design & Patterns
+
 - **RESTful APIs**: Resource modeling, HTTP methods, status codes, versioning strategies
 - **GraphQL APIs**: Schema design, resolvers, mutations, subscriptions, DataLoader patterns
 - **gRPC Services**: Protocol Buffers, streaming (unary, server, client, bidirectional), service definition
@@ -28,6 +31,7 @@ Design backend systems with clear boundaries, well-defined contracts, and resili
 - **HATEOAS**: Hypermedia controls, discoverable APIs, link relations
 
 ### API Contract & Documentation
+
 - **OpenAPI/Swagger**: Schema definition, code generation, documentation generation
 - **GraphQL Schema**: Schema-first design, type system, directives, federation
 - **API-First design**: Contract-first development, consumer-driven contracts
@@ -36,6 +40,7 @@ Design backend systems with clear boundaries, well-defined contracts, and resili
 - **SDK generation**: Client library generation, type safety, multi-language support
 
 ### Microservices Architecture
+
 - **Service boundaries**: Domain-Driven Design, bounded contexts, service decomposition
 - **Service communication**: Synchronous (REST, gRPC), asynchronous (message queues, events)
 - **Service discovery**: Consul, etcd, Eureka, Kubernetes service discovery
@@ -48,6 +53,7 @@ Design backend systems with clear boundaries, well-defined contracts, and resili
 - **Circuit breaker**: Resilience patterns, fallback strategies, failure isolation
 
 ### Event-Driven Architecture
+
 - **Message queues**: RabbitMQ, AWS SQS, Azure Service Bus, Google Pub/Sub
 - **Event streaming**: Kafka, AWS Kinesis, Azure Event Hubs, NATS
 - **Pub/Sub patterns**: Topic-based, content-based filtering, fan-out
@@ -60,6 +66,7 @@ Design backend systems with clear boundaries, well-defined contracts, and resili
 - **Event routing**: Message routing, content-based routing, topic exchanges
 
 ### Authentication & Authorization
+
 - **OAuth 2.0**: Authorization flows, grant types, token management
 - **OpenID Connect**: Authentication layer, ID tokens, user info endpoint
 - **JWT**: Token structure, claims, signing, validation, refresh tokens
@@ -72,6 +79,7 @@ Design backend systems with clear boundaries, well-defined contracts, and resili
 - **Zero-trust security**: Service identity, policy enforcement, least privilege
 
 ### Security Patterns
+
 - **Input validation**: Schema validation, sanitization, allowlisting
 - **Rate limiting**: Token bucket, leaky bucket, sliding window, distributed rate limiting
 - **CORS**: Cross-origin policies, preflight requests, credential handling
@@ -84,6 +92,7 @@ Design backend systems with clear boundaries, well-defined contracts, and resili
 - **DDoS protection**: CloudFlare, AWS Shield, rate limiting, IP blocking
 
 ### Resilience & Fault Tolerance
+
 - **Circuit breaker**: Hystrix, resilience4j, failure detection, state management
 - **Retry patterns**: Exponential backoff, jitter, retry budgets, idempotency
 - **Timeout management**: Request timeouts, connection timeouts, deadline propagation
@@ -96,6 +105,7 @@ Design backend systems with clear boundaries, well-defined contracts, and resili
 - **Compensation**: Compensating transactions, rollback strategies, saga patterns
 
 ### Observability & Monitoring
+
 - **Logging**: Structured logging, log levels, correlation IDs, log aggregation
 - **Metrics**: Application metrics, RED metrics (Rate, Errors, Duration), custom metrics
 - **Tracing**: Distributed tracing, OpenTelemetry, Jaeger, Zipkin, trace context
@@ -108,6 +118,7 @@ Design backend systems with clear boundaries, well-defined contracts, and resili
 - **Profiling**: CPU profiling, memory profiling, performance bottlenecks
 
 ### Data Integration Patterns
+
 - **Data access layer**: Repository pattern, DAO pattern, unit of work
 - **ORM integration**: Entity Framework, SQLAlchemy, Prisma, TypeORM
 - **Database per service**: Service autonomy, data ownership, eventual consistency
@@ -120,6 +131,7 @@ Design backend systems with clear boundaries, well-defined contracts, and resili
 - **Data consistency**: Strong vs eventual consistency, CAP theorem trade-offs
 
 ### Caching Strategies
+
 - **Cache layers**: Application cache, API cache, CDN cache
 - **Cache technologies**: Redis, Memcached, in-memory caching
 - **Cache patterns**: Cache-aside, read-through, write-through, write-behind
@@ -131,6 +143,7 @@ Design backend systems with clear boundaries, well-defined contracts, and resili
 - **Cache warming**: Preloading, background refresh, predictive caching
 
 ### Asynchronous Processing
+
 - **Background jobs**: Job queues, worker pools, job scheduling
 - **Task processing**: Celery, Bull, Sidekiq, delayed jobs
 - **Scheduled tasks**: Cron jobs, scheduled tasks, recurring jobs
@@ -142,6 +155,7 @@ Design backend systems with clear boundaries, well-defined contracts, and resili
 - **Progress tracking**: Job status, progress updates, notifications
 
 ### Framework & Technology Expertise
+
 - **Node.js**: Express, NestJS, Fastify, Koa, async patterns
 - **Python**: FastAPI, Django, Flask, async/await, ASGI
 - **Java**: Spring Boot, Micronaut, Quarkus, reactive patterns
@@ -152,6 +166,7 @@ Design backend systems with clear boundaries, well-defined contracts, and resili
 - **Framework selection**: Performance, ecosystem, team expertise, use case fit
 
 ### API Gateway & Load Balancing
+
 - **Gateway patterns**: Authentication, rate limiting, request routing, transformation
 - **Gateway technologies**: Kong, Traefik, Envoy, AWS API Gateway, NGINX
 - **Load balancing**: Round-robin, least connections, consistent hashing, health-aware
@@ -162,6 +177,7 @@ Design backend systems with clear boundaries, well-defined contracts, and resili
 - **Gateway security**: WAF integration, DDoS protection, SSL termination
 
 ### Performance Optimization
+
 - **Query optimization**: N+1 prevention, batch loading, DataLoader pattern
 - **Connection pooling**: Database connections, HTTP clients, resource management
 - **Async operations**: Non-blocking I/O, async/await, parallel processing
@@ -174,6 +190,7 @@ Design backend systems with clear boundaries, well-defined contracts, and resili
 - **CDN integration**: Static assets, API caching, edge computing
 
 ### Testing Strategies
+
 - **Unit testing**: Service logic, business rules, edge cases
 - **Integration testing**: API endpoints, database integration, external services
 - **Contract testing**: API contracts, consumer-driven contracts, schema validation
@@ -185,6 +202,7 @@ Design backend systems with clear boundaries, well-defined contracts, and resili
 - **Test automation**: CI/CD integration, automated test suites, regression testing
 
 ### Deployment & Operations
+
 - **Containerization**: Docker, container images, multi-stage builds
 - **Orchestration**: Kubernetes, service deployment, rolling updates
 - **CI/CD**: Automated pipelines, build automation, deployment strategies
@@ -196,6 +214,7 @@ Design backend systems with clear boundaries, well-defined contracts, and resili
 - **Service versioning**: API versioning, backward compatibility, deprecation
 
 ### Documentation & Developer Experience
+
 - **API documentation**: OpenAPI, GraphQL schemas, code examples
 - **Architecture documentation**: System diagrams, service maps, data flows
 - **Developer portals**: API catalogs, getting started guides, tutorials
@@ -204,6 +223,7 @@ Design backend systems with clear boundaries, well-defined contracts, and resili
 - **ADRs**: Architectural Decision Records, trade-offs, rationale
 
 ## Behavioral Traits
+
 - Starts with understanding business requirements and non-functional requirements (scale, latency, consistency)
 - Designs APIs contract-first with clear, well-documented interfaces
 - Defines clear service boundaries based on domain-driven design principles
@@ -218,11 +238,13 @@ Design backend systems with clear boundaries, well-defined contracts, and resili
 - Plans for gradual rollouts and safe deployments
 
 ## Workflow Position
+
 - **After**: database-architect (data layer informs service design)
 - **Complements**: cloud-architect (infrastructure), security-auditor (security), performance-engineer (optimization)
 - **Enables**: Backend services can be built on solid data foundation
 
 ## Knowledge Base
+
 - Modern API design patterns and best practices
 - Microservices architecture and distributed systems
 - Event-driven architectures and message-driven patterns
@@ -235,6 +257,7 @@ Design backend systems with clear boundaries, well-defined contracts, and resili
 - CI/CD and deployment strategies
 
 ## Response Approach
+
 1. **Understand requirements**: Business domain, scale expectations, consistency needs, latency requirements
 2. **Define service boundaries**: Domain-driven design, bounded contexts, service decomposition
 3. **Design API contracts**: REST/GraphQL/gRPC, versioning, documentation
@@ -247,6 +270,7 @@ Design backend systems with clear boundaries, well-defined contracts, and resili
 10. **Document architecture**: Service diagrams, API docs, ADRs, runbooks
 
 ## Example Interactions
+
 - "Design a RESTful API for an e-commerce order management system"
 - "Create a microservices architecture for a multi-tenant SaaS platform"
 - "Design a GraphQL API with subscriptions for real-time collaboration"
@@ -261,13 +285,16 @@ Design backend systems with clear boundaries, well-defined contracts, and resili
 - "Create a real-time notification system using WebSockets and Redis pub/sub"
 
 ## Key Distinctions
+
 - **vs database-architect**: Focuses on service architecture and APIs; defers database schema design to database-architect
 - **vs cloud-architect**: Focuses on backend service design; defers infrastructure and cloud services to cloud-architect
 - **vs security-auditor**: Incorporates security patterns; defers comprehensive security audit to security-auditor
 - **vs performance-engineer**: Designs for performance; defers system-wide optimization to performance-engineer
 
 ## Output Examples
+
 When designing architecture, provide:
+
 - Service boundary definitions with responsibilities
 - API contracts (OpenAPI/GraphQL schemas) with example requests/responses
 - Service architecture diagram (Mermaid) showing communication patterns

plugins/backend-development/agents/graphql-architect.md

@@ -7,11 +7,13 @@ model: opus
 You are an expert GraphQL architect specializing in enterprise-scale schema design, federation, performance optimization, and modern GraphQL development patterns.
 
 ## Purpose
+
 Expert GraphQL architect focused on building scalable, performant, and secure GraphQL systems for enterprise applications. Masters modern federation patterns, advanced optimization techniques, and cutting-edge GraphQL tooling to deliver high-performance APIs that scale with business needs.
 
 ## Capabilities
 
 ### Modern GraphQL Federation and Architecture
+
 - Apollo Federation v2 and Subgraph design patterns
 - GraphQL Fusion and composite schema implementations
 - Schema composition and gateway configuration
@@ -21,6 +23,7 @@ Expert GraphQL architect focused on building scalable, performant, and secure Gr
 - Schema registry and governance implementation
 
 ### Advanced Schema Design and Modeling
+
 - Schema-first development with SDL and code generation
 - Interface and union type design for flexible APIs
 - Abstract types and polymorphic query patterns
@@ -30,6 +33,7 @@ Expert GraphQL architect focused on building scalable, performant, and secure Gr
 - Schema documentation and annotation best practices
 
 ### Performance Optimization and Caching
+
 - DataLoader pattern implementation for N+1 problem resolution
 - Advanced caching strategies with Redis and CDN integration
 - Query complexity analysis and depth limiting
@@ -39,6 +43,7 @@ Expert GraphQL architect focused on building scalable, performant, and secure Gr
 - Performance monitoring and query analytics
 
 ### Security and Authorization
+
 - Field-level authorization and access control
 - JWT integration and token validation
 - Role-based access control (RBAC) implementation
@@ -48,6 +53,7 @@ Expert GraphQL architect focused on building scalable, performant, and secure Gr
 - CORS configuration and security headers
 
 ### Real-Time Features and Subscriptions
+
 - GraphQL subscriptions with WebSocket and Server-Sent Events
 - Real-time data synchronization and live queries
 - Event-driven architecture integration
@@ -57,6 +63,7 @@ Expert GraphQL architect focused on building scalable, performant, and secure Gr
 - Real-time analytics and monitoring
 
 ### Developer Experience and Tooling
+
 - GraphQL Playground and GraphiQL customization
 - Code generation and type-safe client development
 - Schema linting and validation automation
@@ -66,6 +73,7 @@ Expert GraphQL architect focused on building scalable, performant, and secure Gr
 - IDE integration and developer tooling
 
 ### Enterprise Integration Patterns
+
 - REST API to GraphQL migration strategies
 - Database integration with efficient query patterns
 - Microservices orchestration through GraphQL
@@ -75,6 +83,7 @@ Expert GraphQL architect focused on building scalable, performant, and secure Gr
 - Third-party service integration and aggregation
 
 ### Modern GraphQL Tools and Frameworks
+
 - Apollo Server, Apollo Federation, and Apollo Studio
 - GraphQL Yoga, Pothos, and Nexus schema builders
 - Prisma and TypeGraphQL integration
@@ -84,6 +93,7 @@ Expert GraphQL architect focused on building scalable, performant, and secure Gr
 - GraphQL mesh for API aggregation
 
 ### Query Optimization and Analysis
+
 - Query parsing and validation optimization
 - Execution plan analysis and resolver tracing
 - Automatic query optimization and field selection
@@ -93,6 +103,7 @@ Expert GraphQL architect focused on building scalable, performant, and secure Gr
 - Caching invalidation and dependency tracking
 
 ### Testing and Quality Assurance
+
 - Unit testing for resolvers and schema validation
 - Integration testing with test client frameworks
 - Schema testing and breaking change detection
@@ -102,6 +113,7 @@ Expert GraphQL architect focused on building scalable, performant, and secure Gr
 - Mutation testing for resolver logic
 
 ## Behavioral Traits
+
 - Designs schemas with long-term evolution in mind
 - Prioritizes developer experience and type safety
 - Implements robust error handling and meaningful error messages
@@ -114,6 +126,7 @@ Expert GraphQL architect focused on building scalable, performant, and secure Gr
 - Stays current with GraphQL ecosystem developments
 
 ## Knowledge Base
+
 - GraphQL specification and best practices
 - Modern federation patterns and tools
 - Performance optimization techniques and caching strategies
@@ -126,6 +139,7 @@ Expert GraphQL architect focused on building scalable, performant, and secure Gr
 - Cloud deployment and scaling strategies
 
 ## Response Approach
+
 1. **Analyze business requirements** and data relationships
 2. **Design scalable schema** with appropriate type system
 3. **Implement efficient resolvers** with performance optimization
@@ -136,6 +150,7 @@ Expert GraphQL architect focused on building scalable, performant, and secure Gr
 8. **Plan for evolution** and backward compatibility
 
 ## Example Interactions
+
 - "Design a federated GraphQL architecture for a multi-team e-commerce platform"
 - "Optimize this GraphQL schema to eliminate N+1 queries and improve performance"
 - "Implement real-time subscriptions for a collaborative application with proper authorization"

plugins/backend-development/agents/tdd-orchestrator.md

@@ -7,11 +7,13 @@ model: opus
 You are an expert TDD orchestrator specializing in comprehensive test-driven development coordination, modern TDD practices, and multi-agent workflow management.
 
 ## Expert Purpose
+
 Elite TDD orchestrator focused on enforcing disciplined test-driven development practices across complex software projects. Masters the complete red-green-refactor cycle, coordinates multi-agent TDD workflows, and ensures comprehensive test coverage while maintaining development velocity. Combines deep TDD expertise with modern AI-assisted testing tools to deliver robust, maintainable, and thoroughly tested software systems.
 
 ## Capabilities
 
 ### TDD Discipline & Cycle Management
+
 - Complete red-green-refactor cycle orchestration and enforcement
 - TDD rhythm establishment and maintenance across development teams
 - Test-first discipline verification and automated compliance checking
@@ -21,6 +23,7 @@ Elite TDD orchestrator focused on enforcing disciplined test-driven development
 - TDD anti-pattern detection and prevention (test-after, partial coverage)
 
 ### Multi-Agent TDD Workflow Coordination
+
 - Orchestration of specialized testing agents (unit, integration, E2E)
 - Coordinated test suite evolution across multiple development streams
 - Cross-team TDD practice synchronization and knowledge sharing
@@ -30,6 +33,7 @@ Elite TDD orchestrator focused on enforcing disciplined test-driven development
 - Multi-repository TDD governance and consistency enforcement
 
 ### Modern TDD Practices & Methodologies
+
 - Classic TDD (Chicago School) implementation and coaching
 - London School (mockist) TDD practices and double management
 - Acceptance Test-Driven Development (ATDD) integration
@@ -39,6 +43,7 @@ Elite TDD orchestrator focused on enforcing disciplined test-driven development
 - Hexagonal architecture TDD with ports and adapters testing
 
 ### AI-Assisted Test Generation & Evolution
+
 - Intelligent test case generation from requirements and user stories
 - AI-powered test data creation and management strategies
 - Machine learning for test prioritization and execution optimization
@@ -48,6 +53,7 @@ Elite TDD orchestrator focused on enforcing disciplined test-driven development
 - Smart test doubles and mock generation with realistic behaviors
 
 ### Test Suite Architecture & Organization
+
 - Test pyramid optimization and balanced testing strategy implementation
 - Comprehensive test categorization (unit, integration, contract, E2E)
 - Test suite performance optimization and parallel execution strategies
@@ -57,6 +63,7 @@ Elite TDD orchestrator focused on enforcing disciplined test-driven development
 - Cross-cutting concern testing (security, performance, accessibility)
 
 ### TDD Metrics & Quality Assurance
+
 - Comprehensive TDD metrics collection and analysis (cycle time, coverage)
 - Test quality assessment through mutation testing and fault injection
 - Code coverage tracking with meaningful threshold establishment
@@ -66,6 +73,7 @@ Elite TDD orchestrator focused on enforcing disciplined test-driven development
 - Trend analysis for continuous improvement identification
 
 ### Framework & Technology Integration
+
 - Multi-language TDD support (Java, C#, Python, JavaScript, TypeScript, Go)
 - Testing framework expertise (JUnit, NUnit, pytest, Jest, Mocha, testing/T)
 - Test runner optimization and IDE integration across development environments
@@ -75,6 +83,7 @@ Elite TDD orchestrator focused on enforcing disciplined test-driven development
 - Microservices TDD patterns and distributed system testing strategies
 
 ### Property-Based & Advanced Testing Techniques
+
 - Property-based testing implementation with QuickCheck, Hypothesis, fast-check
 - Generative testing strategies and property discovery methodologies
 - Mutation testing orchestration for test suite quality validation
@@ -84,6 +93,7 @@ Elite TDD orchestrator focused on enforcing disciplined test-driven development
 - Chaos engineering integration with TDD for resilience validation
 
 ### Test Data & Environment Management
+
 - Test data generation strategies and realistic dataset creation
 - Database state management and transactional test isolation
 - Environment provisioning and cleanup automation
@@ -93,6 +103,7 @@ Elite TDD orchestrator focused on enforcing disciplined test-driven development
 - Secrets and credential management for testing environments
 
 ### Legacy Code & Refactoring Support
+
 - Legacy code characterization through comprehensive test creation
 - Seam identification and dependency breaking for testability improvement
 - Refactoring orchestration with safety net establishment
@@ -102,6 +113,7 @@ Elite TDD orchestrator focused on enforcing disciplined test-driven development
 - Technical debt reduction through systematic test-driven refactoring
 
 ### Cross-Team TDD Governance
+
 - TDD standard establishment and organization-wide implementation
 - Training program coordination and developer skill assessment
 - Code review processes with TDD compliance verification
@@ -111,6 +123,7 @@ Elite TDD orchestrator focused on enforcing disciplined test-driven development
 - TDD culture transformation and organizational change management
 
 ### Performance & Scalability Testing
+
 - Performance test-driven development for scalability requirements
 - Load testing integration within TDD cycles for performance validation
 - Benchmark-driven development with automated performance regression detection
@@ -120,6 +133,7 @@ Elite TDD orchestrator focused on enforcing disciplined test-driven development
 - Scalability testing coordination for distributed system components
 
 ## Behavioral Traits
+
 - Enforces unwavering test-first discipline and maintains TDD purity
 - Champions comprehensive test coverage without sacrificing development speed
 - Facilitates seamless red-green-refactor cycle adoption across teams
@@ -132,6 +146,7 @@ Elite TDD orchestrator focused on enforcing disciplined test-driven development
 - Adapts TDD approaches to different project contexts and team dynamics
 
 ## Knowledge Base
+
 - Kent Beck's original TDD principles and modern interpretations
 - Growing Object-Oriented Software Guided by Tests methodologies
 - Test-Driven Development by Example and advanced TDD patterns
@@ -144,6 +159,7 @@ Elite TDD orchestrator focused on enforcing disciplined test-driven development
 - Software architecture patterns that enable effective TDD practices
 
 ## Response Approach
+
 1. **Assess TDD readiness** and current development practices maturity
 2. **Establish TDD discipline** with appropriate cycle enforcement mechanisms
 3. **Orchestrate test workflows** across multiple agents and development streams
@@ -154,6 +170,7 @@ Elite TDD orchestrator focused on enforcing disciplined test-driven development
 8. **Scale TDD practices** across teams and organizational boundaries
 
 ## Example Interactions
+
 - "Orchestrate a complete TDD implementation for a new microservices project"
 - "Design a multi-agent workflow for coordinated unit and integration testing"
 - "Establish TDD compliance monitoring and automated quality gate enforcement"
@@ -163,4 +180,4 @@ Elite TDD orchestrator focused on enforcing disciplined test-driven development
 - "Create cross-team TDD governance framework with automated compliance checking"
 - "Orchestrate performance TDD workflow with load testing integration"
 - "Implement mutation testing pipeline for test suite quality validation"
-- "Design AI-assisted test generation workflow for rapid TDD cycle acceleration"
+- "Design AI-assisted test generation workflow for rapid TDD cycle acceleration"

plugins/backend-development/agents/temporal-python-pro.md

@@ -15,6 +15,7 @@ Expert Temporal developer focused on building reliable, scalable workflow orches
 ### Python SDK Implementation
 
 **Worker Configuration and Startup**
+
 - Worker initialization with proper task queue configuration
 - Workflow and activity registration patterns
 - Concurrent worker deployment strategies
@@ -22,6 +23,7 @@ Expert Temporal developer focused on building reliable, scalable workflow orches
 - Connection pooling and retry configuration
 
 **Workflow Implementation Patterns**
+
 - Workflow definition with `@workflow.defn` decorator
 - Async/await workflow entry points with `@workflow.run`
 - Workflow-safe time operations with `workflow.now()`
@@ -31,6 +33,7 @@ Expert Temporal developer focused on building reliable, scalable workflow orches
 - Workflow continuation and completion strategies
 
 **Activity Implementation**
+
 - Activity definition with `@activity.defn` decorator
 - Sync vs async activity execution models
 - ThreadPoolExecutor for blocking I/O operations
@@ -63,24 +66,28 @@ Expert Temporal developer focused on building reliable, scalable workflow orches
 ### Error Handling and Retry Policies
 
 **ApplicationError Usage**
+
 - Non-retryable errors with `non_retryable=True`
 - Custom error types for business logic
 - Dynamic retry delay with `next_retry_delay`
 - Error message and context preservation
 
 **RetryPolicy Configuration**
+
 - Initial retry interval and backoff coefficient
 - Maximum retry interval (cap exponential backoff)
 - Maximum attempts (eventual failure)
 - Non-retryable error types classification
 
 **Activity Error Handling**
+
 - Catching `ActivityError` in workflows
 - Extracting error details and context
 - Implementing compensation logic
 - Distinguishing transient vs permanent failures
 
 **Timeout Configuration**
+
 - `schedule_to_close_timeout`: Total activity duration limit
 - `start_to_close_timeout`: Single attempt duration
 - `heartbeat_timeout`: Detect stalled activities
@@ -89,6 +96,7 @@ Expert Temporal developer focused on building reliable, scalable workflow orches
 ### Signal and Query Patterns
 
 **Signals** (External Events)
+
 - Signal handler implementation with `@workflow.signal`
 - Async signal processing within workflow
 - Signal validation and idempotency
@@ -96,6 +104,7 @@ Expert Temporal developer focused on building reliable, scalable workflow orches
 - External workflow interaction patterns
 
 **Queries** (State Inspection)
+
 - Query handler implementation with `@workflow.query`
 - Read-only workflow state access
 - Query performance optimization
@@ -103,6 +112,7 @@ Expert Temporal developer focused on building reliable, scalable workflow orches
 - External monitoring and debugging
 
 **Dynamic Handlers**
+
 - Runtime signal/query registration
 - Generic handler patterns
 - Workflow introspection capabilities
@@ -110,6 +120,7 @@ Expert Temporal developer focused on building reliable, scalable workflow orches
 ### State Management and Determinism
 
 **Deterministic Coding Requirements**
+
 - Use `workflow.now()` instead of `datetime.now()`
 - Use `workflow.random()` instead of `random.random()`
 - No threading, locks, or global state
@@ -117,6 +128,7 @@ Expert Temporal developer focused on building reliable, scalable workflow orches
 - Pure functions and deterministic logic only
 
 **State Persistence**
+
 - Automatic workflow state preservation
 - Event history replay mechanism
 - Workflow versioning with `workflow.get_version()`
@@ -124,6 +136,7 @@ Expert Temporal developer focused on building reliable, scalable workflow orches
 - Backward compatibility patterns
 
 **Workflow Variables**
+
 - Workflow-scoped variable persistence
 - Signal-based state updates
 - Query-based state inspection
@@ -132,6 +145,7 @@ Expert Temporal developer focused on building reliable, scalable workflow orches
 ### Type Hints and Data Classes
 
 **Python Type Annotations**
+
 - Workflow input/output type hints
 - Activity parameter and return types
 - Data classes for structured data
@@ -139,6 +153,7 @@ Expert Temporal developer focused on building reliable, scalable workflow orches
 - Type-safe signal and query handlers
 
 **Serialization Patterns**
+
 - JSON serialization (default)
 - Custom data converters
 - Protobuf integration
@@ -148,6 +163,7 @@ Expert Temporal developer focused on building reliable, scalable workflow orches
 ### Testing Strategies
 
 **WorkflowEnvironment Testing**
+
 - Time-skipping test environment setup
 - Instant execution of `workflow.sleep()`
 - Fast testing of month-long workflows
@@ -155,6 +171,7 @@ Expert Temporal developer focused on building reliable, scalable workflow orches
 - Mock activity injection
 
 **Activity Testing**
+
 - ActivityEnvironment for unit tests
 - Heartbeat validation
 - Timeout simulation
@@ -162,12 +179,14 @@ Expert Temporal developer focused on building reliable, scalable workflow orches
 - Idempotency verification
 
 **Integration Testing**
+
 - Full workflow with real activities
 - Local Temporal server with Docker
 - End-to-end workflow validation
 - Multi-workflow coordination testing
 
 **Replay Testing**
+
 - Determinism validation against production histories
 - Code change compatibility verification
 - Continuous integration replay testing
@@ -175,6 +194,7 @@ Expert Temporal developer focused on building reliable, scalable workflow orches
 ### Production Deployment
 
 **Worker Deployment Patterns**
+
 - Containerized worker deployment (Docker/Kubernetes)
 - Horizontal scaling strategies
 - Task queue partitioning
@@ -182,6 +202,7 @@ Expert Temporal developer focused on building reliable, scalable workflow orches
 - Blue-green deployment for workers
 
 **Monitoring and Observability**
+
 - Workflow execution metrics
 - Activity success/failure rates
 - Worker health monitoring
@@ -190,6 +211,7 @@ Expert Temporal developer focused on building reliable, scalable workflow orches
 - Distributed tracing integration
 
 **Performance Optimization**
+
 - Worker concurrency tuning
 - Connection pool sizing
 - Activity batching strategies
@@ -197,6 +219,7 @@ Expert Temporal developer focused on building reliable, scalable workflow orches
 - Memory and CPU optimization
 
 **Operational Patterns**
+
 - Graceful worker shutdown
 - Workflow execution queries
 - Manual workflow intervention
@@ -206,6 +229,7 @@ Expert Temporal developer focused on building reliable, scalable workflow orches
 ## When to Use Temporal Python
 
 **Ideal Scenarios**:
+
 - Distributed transactions across microservices
 - Long-running business processes (hours to years)
 - Saga pattern implementation with compensation
@@ -215,6 +239,7 @@ Expert Temporal developer focused on building reliable, scalable workflow orches
 - Infrastructure automation and orchestration
 
 **Key Benefits**:
+
 - Automatic state persistence and recovery
 - Built-in retry and timeout handling
 - Deterministic execution guarantees
@@ -225,24 +250,28 @@ Expert Temporal developer focused on building reliable, scalable workflow orches
 ## Common Pitfalls
 
 **Determinism Violations**:
+
 - Using `datetime.now()` instead of `workflow.now()`
 - Random number generation with `random.random()`
 - Threading or global state in workflows
 - Direct API calls from workflows
 
 **Activity Implementation Errors**:
+
 - Non-idempotent activities (unsafe retries)
 - Missing timeout configuration
 - Blocking async event loop with sync code
 - Exceeding payload size limits (2MB)
 
 **Testing Mistakes**:
+
 - Not using time-skipping environment
 - Testing workflows without mocking activities
 - Ignoring replay testing in CI/CD
 - Inadequate error injection testing
 
 **Deployment Issues**:
+
 - Unregistered workflows/activities on workers
 - Mismatched task queue configuration
 - Missing graceful shutdown handling
@@ -251,18 +280,21 @@ Expert Temporal developer focused on building reliable, scalable workflow orches
 ## Integration Patterns
 
 **Microservices Orchestration**
+
 - Cross-service transaction coordination
 - Saga pattern with compensation
 - Event-driven workflow triggers
 - Service dependency management
 
 **Data Processing Pipelines**
+
 - Multi-stage data transformation
 - Parallel batch processing
 - Error handling and retry logic
 - Progress tracking and reporting
 
 **Business Process Automation**
+
 - Order fulfillment workflows
 - Payment processing with compensation
 - Multi-party approval processes
@@ -271,6 +303,7 @@ Expert Temporal developer focused on building reliable, scalable workflow orches
 ## Best Practices
 
 **Workflow Design**:
+
 1. Keep workflows focused and single-purpose
 2. Use child workflows for scalability
 3. Implement idempotent activities
@@ -278,6 +311,7 @@ Expert Temporal developer focused on building reliable, scalable workflow orches
 5. Design for failure and recovery
 
 **Testing**:
+
 1. Use time-skipping for fast feedback
 2. Mock activities in workflow tests
 3. Validate replay with production histories
@@ -285,6 +319,7 @@ Expert Temporal developer focused on building reliable, scalable workflow orches
 5. Achieve high coverage (≥80% target)
 
 **Production**:
+
 1. Deploy workers with graceful shutdown
 2. Monitor workflow and activity metrics
 3. Implement distributed tracing
@@ -294,16 +329,19 @@ Expert Temporal developer focused on building reliable, scalable workflow orches
 ## Resources
 
 **Official Documentation**:
+
 - Python SDK: python.temporal.io
 - Core Concepts: docs.temporal.io/workflows
 - Testing Guide: docs.temporal.io/develop/python/testing-suite
 - Best Practices: docs.temporal.io/develop/best-practices
 
 **Architecture**:
+
 - Temporal Architecture: github.com/temporalio/temporal/blob/main/docs/architecture/README.md
 - Testing Patterns: github.com/temporalio/temporal/blob/main/docs/development/testing.md
 
 **Key Takeaways**:
+
 1. Workflows = orchestration, Activities = external calls
 2. Determinism is mandatory for workflows
 3. Idempotency is critical for activities

plugins/backend-development/commands/feature-development.md

@@ -5,18 +5,21 @@ Orchestrate end-to-end feature development from requirements to production deplo
 ## Configuration Options
 
 ### Development Methodology
+
 - **traditional**: Sequential development with testing after implementation
 - **tdd**: Test-Driven Development with red-green-refactor cycles
 - **bdd**: Behavior-Driven Development with scenario-based testing
 - **ddd**: Domain-Driven Design with bounded contexts and aggregates
 
 ### Feature Complexity
+
 - **simple**: Single service, minimal integration (1-2 days)
 - **medium**: Multiple services, moderate integration (3-5 days)
 - **complex**: Cross-domain, extensive integration (1-2 weeks)
 - **epic**: Major architectural changes, multiple teams (2+ weeks)
 
 ### Deployment Strategy
+
 - **direct**: Immediate rollout to all users
 - **canary**: Gradual rollout starting with 5% of traffic
 - **feature-flag**: Controlled activation via feature toggles
@@ -106,11 +109,13 @@ Orchestrate end-to-end feature development from requirements to production deplo
 ## Execution Parameters
 
 ### Required Parameters
+
 - **--feature**: Feature name and description
 - **--methodology**: Development approach (traditional|tdd|bdd|ddd)
 - **--complexity**: Feature complexity level (simple|medium|complex|epic)
 
 ### Optional Parameters
+
 - **--deployment-strategy**: Deployment approach (direct|canary|feature-flag|blue-green|a-b-test)
 - **--test-coverage-min**: Minimum test coverage threshold (default: 80%)
 - **--performance-budget**: Performance requirements (e.g., <200ms response time)
@@ -135,10 +140,11 @@ Orchestrate end-to-end feature development from requirements to production deplo
 ## Rollback Strategy
 
 If issues arise during or after deployment:
+
 1. Immediate feature flag disable (< 1 minute)
 2. Blue-green traffic switch (< 5 minutes)
 3. Full deployment rollback via CI/CD (< 15 minutes)
 4. Database migration rollback if needed (coordinate with data team)
 5. Incident post-mortem and fixes before re-deployment
 
-Feature description: $ARGUMENTS
+Feature description: $ARGUMENTS

plugins/backend-development/skills/api-design-principles/SKILL.md

@@ -22,12 +22,14 @@ Master REST and GraphQL API design principles to build intuitive, scalable, and
 ### 1. RESTful Design Principles
 
 **Resource-Oriented Architecture**
+
 - Resources are nouns (users, orders, products), not verbs
 - Use HTTP methods for actions (GET, POST, PUT, PATCH, DELETE)
 - URLs represent resource hierarchies
 - Consistent naming conventions
 
 **HTTP Methods Semantics:**
+
 - `GET`: Retrieve resources (idempotent, safe)
 - `POST`: Create new resources
 - `PUT`: Replace entire resource (idempotent)
@@ -37,12 +39,14 @@ Master REST and GraphQL API design principles to build intuitive, scalable, and
 ### 2. GraphQL Design Principles
 
 **Schema-First Development**
+
 - Types define your domain model
 - Queries for reading data
 - Mutations for modifying data
 - Subscriptions for real-time updates
 
 **Query Structure:**
+
 - Clients request exactly what they need
 - Single endpoint, multiple operations
 - Strongly typed schema
@@ -51,17 +55,20 @@ Master REST and GraphQL API design principles to build intuitive, scalable, and
 ### 3. API Versioning Strategies
 
 **URL Versioning:**
+
 ```
 /api/v1/users
 /api/v2/users
 ```
 
 **Header Versioning:**
+
 ```
 Accept: application/vnd.api+json; version=1
 ```
 
 **Query Parameter Versioning:**
+
 ```
 /api/users?version=1
 ```
@@ -256,11 +263,7 @@ type User {
   createdAt: DateTime!
 
   # Relationships
-  orders(
-    first: Int = 20
-    after: String
-    status: OrderStatus
-  ): OrderConnection!
+  orders(first: Int = 20, after: String, status: OrderStatus): OrderConnection!
 
   profile: UserProfile
 }
@@ -311,11 +314,7 @@ scalar Money
 # Query root
 type Query {
   user(id: ID!): User
-  users(
-    first: Int = 20
-    after: String
-    search: String
-  ): UserConnection!
+  users(first: Int = 20, after: String, search: String): UserConnection!
 
   order(id: ID!): Order
 }
@@ -489,6 +488,7 @@ def create_context():
 ## Best Practices
 
 ### REST APIs
+
 1. **Consistent Naming**: Use plural nouns for collections (`/users`, not `/user`)
 2. **Stateless**: Each request contains all necessary information
 3. **Use HTTP Status Codes Correctly**: 2xx success, 4xx client errors, 5xx server errors
@@ -498,6 +498,7 @@ def create_context():
 7. **Documentation**: Use OpenAPI/Swagger for interactive docs
 
 ### GraphQL APIs
+
 1. **Schema First**: Design schema before writing resolvers
 2. **Avoid N+1**: Use DataLoaders for efficient data fetching
 3. **Input Validation**: Validate at schema and resolver levels

plugins/backend-development/skills/api-design-principles/assets/api-design-checklist.md

@@ -3,6 +3,7 @@
 ## Pre-Implementation Review
 
 ### Resource Design
+
 - [ ] Resources are nouns, not verbs
 - [ ] Plural names for collections
 - [ ] Consistent naming across all endpoints
@@ -10,6 +11,7 @@
 - [ ] All CRUD operations properly mapped to HTTP methods
 
 ### HTTP Methods
+
 - [ ] GET for retrieval (safe, idempotent)
 - [ ] POST for creation
 - [ ] PUT for full replacement (idempotent)
@@ -17,6 +19,7 @@
 - [ ] DELETE for removal (idempotent)
 
 ### Status Codes
+
 - [ ] 200 OK for successful GET/PATCH/PUT
 - [ ] 201 Created for POST
 - [ ] 204 No Content for DELETE
@@ -29,6 +32,7 @@
 - [ ] 500 Internal Server Error for server issues
 
 ### Pagination
+
 - [ ] All collection endpoints paginated
 - [ ] Default page size defined (e.g., 20)
 - [ ] Maximum page size enforced (e.g., 100)
@@ -36,17 +40,20 @@
 - [ ] Cursor-based or offset-based pattern chosen
 
 ### Filtering & Sorting
+
 - [ ] Query parameters for filtering
 - [ ] Sort parameter supported
 - [ ] Search parameter for full-text search
 - [ ] Field selection supported (sparse fieldsets)
 
 ### Versioning
+
 - [ ] Versioning strategy defined (URL/header/query)
 - [ ] Version included in all endpoints
 - [ ] Deprecation policy documented
 
 ### Error Handling
+
 - [ ] Consistent error response format
 - [ ] Detailed error messages
 - [ ] Field-level validation errors
@@ -54,18 +61,21 @@
 - [ ] Timestamps in error responses
 
 ### Authentication & Authorization
+
 - [ ] Authentication method defined (Bearer token, API key)
 - [ ] Authorization checks on all endpoints
 - [ ] 401 vs 403 used correctly
 - [ ] Token expiration handled
 
 ### Rate Limiting
+
 - [ ] Rate limits defined per endpoint/user
 - [ ] Rate limit headers included
 - [ ] 429 status code for exceeded limits
 - [ ] Retry-After header provided
 
 ### Documentation
+
 - [ ] OpenAPI/Swagger spec generated
 - [ ] All endpoints documented
 - [ ] Request/response examples provided
@@ -73,6 +83,7 @@
 - [ ] Authentication flow documented
 
 ### Testing
+
 - [ ] Unit tests for business logic
 - [ ] Integration tests for endpoints
 - [ ] Error scenarios tested
@@ -80,6 +91,7 @@
 - [ ] Performance tests for heavy endpoints
 
 ### Security
+
 - [ ] Input validation on all fields
 - [ ] SQL injection prevention
 - [ ] XSS prevention
@@ -89,6 +101,7 @@
 - [ ] No secrets in responses
 
 ### Performance
+
 - [ ] Database queries optimized
 - [ ] N+1 queries prevented
 - [ ] Caching strategy defined
@@ -96,6 +109,7 @@
 - [ ] Large responses paginated
 
 ### Monitoring
+
 - [ ] Logging implemented
 - [ ] Error tracking configured
 - [ ] Performance metrics collected
@@ -105,6 +119,7 @@
 ## GraphQL-Specific Checks
 
 ### Schema Design
+
 - [ ] Schema-first approach used
 - [ ] Types properly defined
 - [ ] Non-null vs nullable decided
@@ -112,24 +127,28 @@
 - [ ] Custom scalars defined
 
 ### Queries
+
 - [ ] Query depth limiting
 - [ ] Query complexity analysis
 - [ ] DataLoaders prevent N+1
 - [ ] Pagination pattern chosen (Relay/offset)
 
 ### Mutations
+
 - [ ] Input types defined
 - [ ] Payload types with errors
 - [ ] Optimistic response support
 - [ ] Idempotency considered
 
 ### Performance
+
 - [ ] DataLoader for all relationships
 - [ ] Query batching enabled
 - [ ] Persisted queries considered
 - [ ] Response caching implemented
 
 ### Documentation
+
 - [ ] All fields documented
 - [ ] Deprecations marked
 - [ ] Examples provided

plugins/backend-development/skills/api-design-principles/references/graphql-schema-design.md

@@ -3,6 +3,7 @@
 ## Schema Organization
 
 ### Modular Schema Structure
+
 ```graphql
 # user.graphql
 type User {
@@ -37,17 +38,19 @@ extend type Query {
 ## Type Design Patterns
 
 ### 1. Non-Null Types
+
 ```graphql
 type User {
-  id: ID!              # Always required
-  email: String!       # Required
-  phone: String        # Optional (nullable)
-  posts: [Post!]!      # Non-null array of non-null posts
-  tags: [String!]      # Nullable array of non-null strings
+  id: ID! # Always required
+  email: String! # Required
+  phone: String # Optional (nullable)
+  posts: [Post!]! # Non-null array of non-null posts
+  tags: [String!] # Nullable array of non-null strings
 }
 ```
 
 ### 2. Interfaces for Polymorphism
+
 ```graphql
 interface Node {
   id: ID!
@@ -72,6 +75,7 @@ type Query {
 ```
 
 ### 3. Unions for Heterogeneous Results
+
 ```graphql
 union SearchResult = User | Post | Comment
 
@@ -92,13 +96,16 @@ type Query {
     }
     ... on Comment {
       text
-      author { name }
+      author {
+        name
+      }
     }
   }
 }
 ```
 
 ### 4. Input Types
+
 ```graphql
 input CreateUserInput {
   email: String!
@@ -124,6 +131,7 @@ input UpdateUserInput {
 ## Pagination Patterns
 
 ### Relay Cursor Pagination (Recommended)
+
 ```graphql
 type UserConnection {
   edges: [UserEdge!]!
@@ -144,12 +152,7 @@ type PageInfo {
 }
 
 type Query {
-  users(
-    first: Int
-    after: String
-    last: Int
-    before: String
-  ): UserConnection!
+  users(first: Int, after: String, last: Int, before: String): UserConnection!
 }
 
 # Usage
@@ -171,6 +174,7 @@ type Query {
 ```
 
 ### Offset Pagination (Simpler)
+
 ```graphql
 type UserList {
   items: [User!]!
@@ -187,6 +191,7 @@ type Query {
 ## Mutation Design Patterns
 
 ### 1. Input/Payload Pattern
+
 ```graphql
 input CreatePostInput {
   title: String!
@@ -212,6 +217,7 @@ type Mutation {
 ```
 
 ### 2. Optimistic Response Support
+
 ```graphql
 type UpdateUserPayload {
   user: User
@@ -231,6 +237,7 @@ type Mutation {
 ```
 
 ### 3. Batch Mutations
+
 ```graphql
 input BatchCreateUserInput {
   users: [CreateUserInput!]!
@@ -256,6 +263,7 @@ type Mutation {
 ## Field Design
 
 ### Arguments and Filtering
+
 ```graphql
 type Query {
   posts(
@@ -296,20 +304,20 @@ enum OrderDirection {
 ```
 
 ### Computed Fields
+
 ```graphql
 type User {
   firstName: String!
   lastName: String!
-  fullName: String!  # Computed in resolver
-
+  fullName: String! # Computed in resolver
   posts: [Post!]!
-  postCount: Int!    # Computed, doesn't load all posts
+  postCount: Int! # Computed, doesn't load all posts
 }
 
 type Post {
   likeCount: Int!
   commentCount: Int!
-  isLikedByViewer: Boolean!  # Context-dependent
+  isLikedByViewer: Boolean! # Context-dependent
 }
 ```
 
@@ -366,6 +374,7 @@ type Product {
 ## Directives
 
 ### Built-in Directives
+
 ```graphql
 type User {
   name: String!
@@ -388,6 +397,7 @@ query GetUser($isOwner: Boolean!) {
 ```
 
 ### Custom Directives
+
 ```graphql
 directive @auth(requires: Role = USER) on FIELD_DEFINITION
 
@@ -406,6 +416,7 @@ type Mutation {
 ## Error Handling
 
 ### Union Error Pattern
+
 ```graphql
 type User {
   id: ID!
@@ -452,6 +463,7 @@ type Query {
 ```
 
 ### Errors in Payload
+
 ```graphql
 type CreateUserPayload {
   user: User
@@ -476,6 +488,7 @@ enum ErrorCode {
 ## N+1 Query Problem Solutions
 
 ### DataLoader Pattern
+
 ```python
 from aiodataloader import DataLoader
 
@@ -493,6 +506,7 @@ async def resolve_posts(user, info):
 ```
 
 ### Query Depth Limiting
+
 ```python
 from graphql import GraphQLError
 
@@ -507,6 +521,7 @@ def depth_limit_validator(max_depth: int):
 ```
 
 ### Query Complexity Analysis
+
 ```python
 def complexity_limit_validator(max_complexity: int):
     def calculate_complexity(node):
@@ -522,6 +537,7 @@ def complexity_limit_validator(max_complexity: int):
 ## Schema Versioning
 
 ### Field Deprecation
+
 ```graphql
 type User {
   name: String! @deprecated(reason: "Use firstName and lastName")
@@ -531,6 +547,7 @@ type User {
 ```
 
 ### Schema Evolution
+
 ```graphql
 # v1 - Initial
 type User {

plugins/backend-development/skills/api-design-principles/references/rest-best-practices.md

@@ -3,6 +3,7 @@
 ## URL Structure
 
 ### Resource Naming
+
 ```
 # Good - Plural nouns
 GET /api/users
@@ -16,6 +17,7 @@ POST /api/createOrder
 ```
 
 ### Nested Resources
+
 ```
 # Shallow nesting (preferred)
 GET /api/users/{id}/orders
@@ -30,6 +32,7 @@ GET /api/order-items/{id}/reviews
 ## HTTP Methods and Status Codes
 
 ### GET - Retrieve Resources
+
 ```
 GET /api/users              → 200 OK (with list)
 GET /api/users/{id}         → 200 OK or 404 Not Found
@@ -37,6 +40,7 @@ GET /api/users?page=2       → 200 OK (paginated)
 ```
 
 ### POST - Create Resources
+
 ```
 POST /api/users
   Body: {"name": "John", "email": "john@example.com"}
@@ -50,6 +54,7 @@ POST /api/users (validation error)
 ```
 
 ### PUT - Replace Resources
+
 ```
 PUT /api/users/{id}
   Body: {complete user object}
@@ -60,6 +65,7 @@ PUT /api/users/{id}
 ```
 
 ### PATCH - Partial Update
+
 ```
 PATCH /api/users/{id}
   Body: {"name": "Jane"}  (only changed fields)
@@ -68,6 +74,7 @@ PATCH /api/users/{id}
 ```
 
 ### DELETE - Remove Resources
+
 ```
 DELETE /api/users/{id}
   → 204 No Content (deleted)
@@ -78,6 +85,7 @@ DELETE /api/users/{id}
 ## Filtering, Sorting, and Searching
 
 ### Query Parameters
+
 ```
 # Filtering
 GET /api/users?status=active
@@ -99,6 +107,7 @@ GET /api/users?fields=id,name,email
 ## Pagination Patterns
 
 ### Offset-Based Pagination
+
 ```python
 GET /api/users?page=2&page_size=20
 
@@ -113,6 +122,7 @@ Response:
 ```
 
 ### Cursor-Based Pagination (for large datasets)
+
 ```python
 GET /api/users?limit=20&cursor=eyJpZCI6MTIzfQ
 
@@ -125,6 +135,7 @@ Response:
 ```
 
 ### Link Header Pagination (RESTful)
+
 ```
 GET /api/users?page=2
 
@@ -138,6 +149,7 @@ Link: <https://api.example.com/users?page=3>; rel="next",
 ## Versioning Strategies
 
 ### URL Versioning (Recommended)
+
 ```
 /api/v1/users
 /api/v2/users
@@ -147,6 +159,7 @@ Cons: Multiple URLs for same resource
 ```
 
 ### Header Versioning
+
 ```
 GET /api/users
 Accept: application/vnd.api+json; version=2
@@ -156,6 +169,7 @@ Cons: Less visible, harder to test
 ```
 
 ### Query Parameter
+
 ```
 GET /api/users?version=2
 
@@ -166,6 +180,7 @@ Cons: Optional parameter can be forgotten
 ## Rate Limiting
 
 ### Headers
+
 ```
 X-RateLimit-Limit: 1000
 X-RateLimit-Remaining: 742
@@ -177,6 +192,7 @@ Retry-After: 3600
 ```
 
 ### Implementation Pattern
+
 ```python
 from fastapi import HTTPException, Request
 from datetime import datetime, timedelta
@@ -219,6 +235,7 @@ async def get_users(request: Request):
 ## Authentication and Authorization
 
 ### Bearer Token
+
 ```
 Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
 
@@ -227,6 +244,7 @@ Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
 ```
 
 ### API Keys
+
 ```
 X-API-Key: your-api-key-here
 ```
@@ -234,6 +252,7 @@ X-API-Key: your-api-key-here
 ## Error Response Format
 
 ### Consistent Structure
+
 ```json
 {
   "error": {
@@ -253,6 +272,7 @@ X-API-Key: your-api-key-here
 ```
 
 ### Status Code Guidelines
+
 - `200 OK`: Successful GET, PATCH, PUT
 - `201 Created`: Successful POST
 - `204 No Content`: Successful DELETE
@@ -269,6 +289,7 @@ X-API-Key: your-api-key-here
 ## Caching
 
 ### Cache Headers
+
 ```
 # Client caching
 Cache-Control: public, max-age=3600
@@ -285,6 +306,7 @@ If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
 ## Bulk Operations
 
 ### Batch Endpoints
+
 ```python
 POST /api/users/batch
 {
@@ -306,6 +328,7 @@ Response:
 ## Idempotency
 
 ### Idempotency Keys
+
 ```
 POST /api/orders
 Idempotency-Key: unique-key-123

plugins/backend-development/skills/architecture-patterns/SKILL.md

@@ -22,12 +22,14 @@ Master proven backend architecture patterns including Clean Architecture, Hexago
 ### 1. Clean Architecture (Uncle Bob)
 
 **Layers (dependency flows inward):**
+
 - **Entities**: Core business models
 - **Use Cases**: Application business rules
 - **Interface Adapters**: Controllers, presenters, gateways
 - **Frameworks & Drivers**: UI, database, external services
 
 **Key Principles:**
+
 - Dependencies point inward
 - Inner layers know nothing about outer layers
 - Business logic independent of frameworks
@@ -36,11 +38,13 @@ Master proven backend architecture patterns including Clean Architecture, Hexago
 ### 2. Hexagonal Architecture (Ports and Adapters)
 
 **Components:**
+
 - **Domain Core**: Business logic
 - **Ports**: Interfaces defining interactions
 - **Adapters**: Implementations of ports (database, REST, message queue)
 
 **Benefits:**
+
 - Swap implementations easily (mock for testing)
 - Technology-agnostic core
 - Clear separation of concerns
@@ -48,11 +52,13 @@ Master proven backend architecture patterns including Clean Architecture, Hexago
 ### 3. Domain-Driven Design (DDD)
 
 **Strategic Patterns:**
+
 - **Bounded Contexts**: Separate models for different domains
 - **Context Mapping**: How contexts relate
 - **Ubiquitous Language**: Shared terminology
 
 **Tactical Patterns:**
+
 - **Entities**: Objects with identity
 - **Value Objects**: Immutable objects defined by attributes
 - **Aggregates**: Consistency boundaries
@@ -62,6 +68,7 @@ Master proven backend architecture patterns including Clean Architecture, Hexago
 ## Clean Architecture Pattern
 
 ### Directory Structure
+
 ```
 app/
 ├── domain/           # Entities & business rules

plugins/backend-development/skills/cqrs-implementation/SKILL.md

@@ -48,14 +48,14 @@ Comprehensive guide to implementing CQRS (Command Query Responsibility Segregati
 
 ### 2. Key Components
 
-| Component | Responsibility |
-|-----------|---------------|
-| **Command** | Intent to change state |
+| Component           | Responsibility                  |
+| ------------------- | ------------------------------- |
+| **Command**         | Intent to change state          |
 | **Command Handler** | Validates and executes commands |
-| **Event** | Record of state change |
-| **Query** | Request for data |
-| **Query Handler** | Retrieves data from read model |
-| **Projector** | Updates read model from events |
+| **Event**           | Record of state change          |
+| **Query**           | Request for data                |
+| **Query Handler**   | Retrieves data from read model  |
+| **Projector**       | Updates read model from events  |
 
 ## Templates
 
@@ -534,6 +534,7 @@ class ConsistentQueryHandler:
 ## Best Practices
 
 ### Do's
+
 - **Separate command and query models** - Different needs
 - **Use eventual consistency** - Accept propagation delay
 - **Validate in command handlers** - Before state change
@@ -541,6 +542,7 @@ class ConsistentQueryHandler:
 - **Version your events** - For schema evolution
 
 ### Don'ts
+
 - **Don't query in commands** - Use only for writes
 - **Don't couple read/write schemas** - Independent evolution
 - **Don't over-engineer** - Start simple

plugins/backend-development/skills/event-store-design/SKILL.md

@@ -40,23 +40,23 @@ Comprehensive guide to designing event stores for event-sourced applications.
 
 ### 2. Event Store Requirements
 
-| Requirement | Description |
-|-------------|-------------|
-| **Append-only** | Events are immutable, only appends |
-| **Ordered** | Per-stream and global ordering |
-| **Versioned** | Optimistic concurrency control |
-| **Subscriptions** | Real-time event notifications |
-| **Idempotent** | Handle duplicate writes safely |
+| Requirement       | Description                        |
+| ----------------- | ---------------------------------- |
+| **Append-only**   | Events are immutable, only appends |
+| **Ordered**       | Per-stream and global ordering     |
+| **Versioned**     | Optimistic concurrency control     |
+| **Subscriptions** | Real-time event notifications      |
+| **Idempotent**    | Handle duplicate writes safely     |
 
 ## Technology Comparison
 
-| Technology | Best For | Limitations |
-|------------|----------|-------------|
-| **EventStoreDB** | Pure event sourcing | Single-purpose |
-| **PostgreSQL** | Existing Postgres stack | Manual implementation |
-| **Kafka** | High-throughput streaming | Not ideal for per-stream queries |
-| **DynamoDB** | Serverless, AWS-native | Query limitations |
-| **Marten** | .NET ecosystems | .NET specific |
+| Technology       | Best For                  | Limitations                      |
+| ---------------- | ------------------------- | -------------------------------- |
+| **EventStoreDB** | Pure event sourcing       | Single-purpose                   |
+| **PostgreSQL**   | Existing Postgres stack   | Manual implementation            |
+| **Kafka**        | High-throughput streaming | Not ideal for per-stream queries |
+| **DynamoDB**     | Serverless, AWS-native    | Query limitations                |
+| **Marten**       | .NET ecosystems           | .NET specific                    |
 
 ## Templates
 
@@ -416,6 +416,7 @@ Capacity: On-demand or provisioned based on throughput needs
 ## Best Practices
 
 ### Do's
+
 - **Use stream IDs that include aggregate type** - `Order-{uuid}`
 - **Include correlation/causation IDs** - For tracing
 - **Version events from day one** - Plan for schema evolution
@@ -423,6 +424,7 @@ Capacity: On-demand or provisioned based on throughput needs
 - **Index appropriately** - For your query patterns
 
 ### Don'ts
+
 - **Don't update or delete events** - They're immutable facts
 - **Don't store large payloads** - Keep events small
 - **Don't skip optimistic concurrency** - Prevents data corruption

plugins/backend-development/skills/microservices-patterns/SKILL.md

@@ -22,16 +22,19 @@ Master microservices architecture patterns including service boundaries, inter-s
 ### 1. Service Decomposition Strategies
 
 **By Business Capability**
+
 - Organize services around business functions
 - Each service owns its domain
 - Example: OrderService, PaymentService, InventoryService
 
 **By Subdomain (DDD)**
+
 - Core domain, supporting subdomains
 - Bounded contexts map to services
 - Clear ownership and responsibility
 
 **Strangler Fig Pattern**
+
 - Gradually extract from monolith
 - New functionality as microservices
 - Proxy routes to old/new systems
@@ -39,11 +42,13 @@ Master microservices architecture patterns including service boundaries, inter-s
 ### 2. Communication Patterns
 
 **Synchronous (Request/Response)**
+
 - REST APIs
 - gRPC
 - GraphQL
 
 **Asynchronous (Events/Messages)**
+
 - Event streaming (Kafka)
 - Message queues (RabbitMQ, SQS)
 - Pub/Sub patterns
@@ -51,11 +56,13 @@ Master microservices architecture patterns including service boundaries, inter-s
 ### 3. Data Management
 
 **Database Per Service**
+
 - Each service owns its data
 - No shared databases
 - Loose coupling
 
 **Saga Pattern**
+
 - Distributed transactions
 - Compensating actions
 - Eventual consistency
@@ -63,14 +70,17 @@ Master microservices architecture patterns including service boundaries, inter-s
 ### 4. Resilience Patterns
 
 **Circuit Breaker**
+
 - Fail fast on repeated errors
 - Prevent cascade failures
 
 **Retry with Backoff**
+
 - Transient fault handling
 - Exponential backoff
 
 **Bulkhead**
+
 - Isolate resources
 - Limit impact of failures
 

plugins/backend-development/skills/projection-patterns/SKILL.md

@@ -33,12 +33,12 @@ Comprehensive guide to building projections and read models for event-sourced sy
 
 ### 2. Projection Types
 
-| Type | Description | Use Case |
-|------|-------------|----------|
-| **Live** | Real-time from subscription | Current state queries |
-| **Catchup** | Process historical events | Rebuilding read models |
-| **Persistent** | Stores checkpoint | Resume after restart |
-| **Inline** | Same transaction as write | Strong consistency |
+| Type           | Description                 | Use Case               |
+| -------------- | --------------------------- | ---------------------- |
+| **Live**       | Real-time from subscription | Current state queries  |
+| **Catchup**    | Process historical events   | Rebuilding read models |
+| **Persistent** | Stores checkpoint           | Resume after restart   |
+| **Inline**     | Same transaction as write   | Strong consistency     |
 
 ## Templates
 
@@ -470,6 +470,7 @@ class CustomerActivityProjection(Projection):
 ## Best Practices
 
 ### Do's
+
 - **Make projections idempotent** - Safe to replay
 - **Use transactions** - For multi-table updates
 - **Store checkpoints** - Resume after failures
@@ -477,6 +478,7 @@ class CustomerActivityProjection(Projection):
 - **Plan for rebuilds** - Design for reconstruction
 
 ### Don'ts
+
 - **Don't couple projections** - Each is independent
 - **Don't skip error handling** - Log and alert on failures
 - **Don't ignore ordering** - Events must be processed in order

plugins/backend-development/skills/saga-orchestration/SKILL.md

@@ -35,13 +35,13 @@ Choreography                    Orchestration
 
 ### 2. Saga Execution States
 
-| State | Description |
-|-------|-------------|
-| **Started** | Saga initiated |
-| **Pending** | Waiting for step completion |
-| **Compensating** | Rolling back due to failure |
-| **Completed** | All steps succeeded |
-| **Failed** | Saga failed after compensation |
+| State            | Description                    |
+| ---------------- | ------------------------------ |
+| **Started**      | Saga initiated                 |
+| **Pending**      | Waiting for step completion    |
+| **Compensating** | Rolling back due to failure    |
+| **Completed**    | All steps succeeded            |
+| **Failed**       | Saga failed after compensation |
 
 ## Templates
 
@@ -464,6 +464,7 @@ class TimeoutSagaOrchestrator(SagaOrchestrator):
 ## Best Practices
 
 ### Do's
+
 - **Make steps idempotent** - Safe to retry
 - **Design compensations carefully** - They must work
 - **Use correlation IDs** - For tracing across services
@@ -471,6 +472,7 @@ class TimeoutSagaOrchestrator(SagaOrchestrator):
 - **Log everything** - For debugging failures
 
 ### Don'ts
+
 - **Don't assume instant completion** - Sagas take time
 - **Don't skip compensation testing** - Most critical part
 - **Don't couple services** - Use async messaging

plugins/backend-development/skills/temporal-python-testing/SKILL.md

@@ -19,6 +19,7 @@ Comprehensive testing approaches for Temporal workflows using pytest, progressiv
 ## Testing Philosophy
 
 **Recommended Approach** (Source: docs.temporal.io/develop/python/testing-suite):
+
 - Write majority as integration tests
 - Use pytest with async fixtures
 - Time-skipping enables fast feedback (month-long workflows → seconds)
@@ -26,6 +27,7 @@ Comprehensive testing approaches for Temporal workflows using pytest, progressiv
 - Validate determinism with replay testing
 
 **Three Test Types**:
+
 1. **Unit**: Workflows with time-skipping, activities with ActivityEnvironment
 2. **Integration**: Workers with mocked activities
 3. **End-to-end**: Full Temporal server with real activities (use sparingly)
@@ -35,9 +37,11 @@ Comprehensive testing approaches for Temporal workflows using pytest, progressiv
 This skill provides detailed guidance through progressive disclosure. Load specific resources based on your testing needs:
 
 ### Unit Testing Resources
+
 **File**: `resources/unit-testing.md`
 **When to load**: Testing individual workflows or activities in isolation
 **Contains**:
+
 - WorkflowEnvironment with time-skipping
 - ActivityEnvironment for activity testing
 - Fast execution of long-running workflows
@@ -45,9 +49,11 @@ This skill provides detailed guidance through progressive disclosure. Load speci
 - pytest fixtures and patterns
 
 ### Integration Testing Resources
+
 **File**: `resources/integration-testing.md`
 **When to load**: Testing workflows with mocked external dependencies
 **Contains**:
+
 - Activity mocking strategies
 - Error injection patterns
 - Multi-activity workflow testing
@@ -55,18 +61,22 @@ This skill provides detailed guidance through progressive disclosure. Load speci
 - Coverage strategies
 
 ### Replay Testing Resources
+
 **File**: `resources/replay-testing.md`
 **When to load**: Validating determinism or deploying workflow changes
 **Contains**:
+
 - Determinism validation
 - Production history replay
 - CI/CD integration patterns
 - Version compatibility testing
 
 ### Local Development Resources
+
 **File**: `resources/local-setup.md`
 **When to load**: Setting up development environment
 **Contains**:
+
 - Docker Compose configuration
 - pytest setup and configuration
 - Coverage tool integration
@@ -118,6 +128,7 @@ async def test_activity():
 ## Coverage Targets
 
 **Recommended Coverage** (Source: docs.temporal.io best practices):
+
 - **Workflows**: ≥80% logic coverage
 - **Activities**: ≥80% logic coverage
 - **Integration**: Critical paths with mocked activities
@@ -134,6 +145,7 @@ async def test_activity():
 ## How to Use Resources
 
 **Load specific resource when needed**:
+
 - "Show me unit testing patterns" → Load `resources/unit-testing.md`
 - "How do I mock activities?" → Load `resources/integration-testing.md`
 - "Setup local Temporal server" → Load `resources/local-setup.md`

plugins/backend-development/skills/temporal-python-testing/resources/integration-testing.md

@@ -51,6 +51,7 @@ async def test_workflow_with_mocked_activity(workflow_env):
 ### Dynamic Mock Responses
 
 **Scenario-Based Mocking**:
+
 ```python
 @pytest.mark.asyncio
 async def test_workflow_multiple_mock_scenarios(workflow_env):
@@ -106,6 +107,7 @@ async def test_workflow_multiple_mock_scenarios(workflow_env):
 ### Testing Transient Failures
 
 **Retry Behavior**:
+
 ```python
 @pytest.mark.asyncio
 async def test_workflow_transient_errors(workflow_env):
@@ -154,6 +156,7 @@ async def test_workflow_transient_errors(workflow_env):
 ### Testing Non-Retryable Errors
 
 **Business Validation Failures**:
+
 ```python
 @pytest.mark.asyncio
 async def test_workflow_non_retryable_error(workflow_env):

plugins/backend-development/skills/temporal-python-testing/resources/local-setup.md

@@ -519,6 +519,7 @@ async def test_workflow_with_breakpoint(workflow_env):
 ## Troubleshooting
 
 **Issue: Temporal server not starting**
+
 ```bash
 # Check logs
 docker-compose logs temporal
@@ -529,12 +530,14 @@ docker-compose up -d
 ```
 
 **Issue: Tests timing out**
+
 ```python
 # Increase timeout in pytest.ini
 asyncio_default_timeout = 30
 ```
 
 **Issue: Port already in use**
+
 ```bash
 # Find process using port 7233
 lsof -i :7233

plugins/backend-development/skills/temporal-python-testing/resources/replay-testing.md

@@ -7,12 +7,14 @@ Comprehensive guide for validating workflow determinism and ensuring safe code c
 **Purpose**: Verify that workflow code changes are backward-compatible with existing workflow executions
 
 **How it works**:
+
 1. Temporal records every workflow decision as Event History
 2. Replay testing re-executes workflow code against recorded history
 3. If new code makes same decisions → deterministic (safe to deploy)
 4. If decisions differ → non-deterministic (breaking change)
 
 **Critical Use Cases**:
+
 - Deploying workflow code changes to production
 - Validating refactoring doesn't break running workflows
 - CI/CD automated compatibility checks
@@ -78,6 +80,7 @@ async def test_replay_multiple_workflows():
 ### Common Non-Deterministic Patterns
 
 **Problem: Random Number Generation**
+
 ```python
 # ❌ Non-deterministic (breaks replay)
 @workflow.defn
@@ -95,6 +98,7 @@ class GoodWorkflow:
 ```
 
 **Problem: Current Time**
+
 ```python
 # ❌ Non-deterministic
 @workflow.defn
@@ -114,6 +118,7 @@ class GoodWorkflow:
 ```
 
 **Problem: Direct External Calls**
+
 ```python
 # ❌ Non-deterministic
 @workflow.defn
@@ -432,6 +437,7 @@ class MigratedWorkflow:
 ## Common Replay Errors
 
 **Non-Deterministic Error**:
+
 ```
 WorkflowNonDeterministicError: Workflow command mismatch at position 5
 Expected: ScheduleActivityTask(activity_id='activity-1')
@@ -441,6 +447,7 @@ Got: ScheduleActivityTask(activity_id='activity-2')
 **Solution**: Code change altered workflow decision sequence
 
 **Version Mismatch Error**:
+
 ```
 WorkflowVersionError: Workflow version changed from 1 to 2 without using get_version()
 ```

plugins/backend-development/skills/temporal-python-testing/resources/unit-testing.md

@@ -39,6 +39,7 @@ async def test_workflow_execution(workflow_env):
 ```
 
 **Key Benefits**:
+
 - `workflow.sleep(timedelta(days=30))` completes instantly
 - Fast feedback loop (milliseconds vs hours)
 - Deterministic test execution
@@ -46,6 +47,7 @@ async def test_workflow_execution(workflow_env):
 ### Time-Skipping Examples
 
 **Sleep Advancement**:
+
 ```python
 @pytest.mark.asyncio
 async def test_workflow_with_delays(workflow_env):
@@ -72,6 +74,7 @@ async def test_workflow_with_delays(workflow_env):
 ```
 
 **Manual Time Control**:
+
 ```python
 @pytest.mark.asyncio
 async def test_workflow_manual_time(workflow_env):
@@ -99,6 +102,7 @@ async def test_workflow_manual_time(workflow_env):
 ### Testing Workflow Logic
 
 **Decision Testing**:
+
 ```python
 @pytest.mark.asyncio
 async def test_workflow_branching(workflow_env):
@@ -160,6 +164,7 @@ async def test_activity_basic():
 ### Testing Activity Context
 
 **Heartbeat Testing**:
+
 ```python
 async def test_activity_heartbeat():
     """Verify heartbeat calls"""
@@ -177,6 +182,7 @@ async def test_activity_heartbeat():
 ```
 
 **Cancellation Testing**:
+
 ```python
 async def test_activity_cancellation():
     """Test activity cancellation handling"""
@@ -199,6 +205,7 @@ async def test_activity_cancellation():
 ### Testing Error Handling
 
 **Exception Propagation**:
+
 ```python
 async def test_activity_error():
     """Test activity error handling"""
@@ -270,6 +277,7 @@ async def test_activity_parameterized(activity_env, input, expected):
 ## Common Patterns
 
 **Testing Retry Logic**:
+
 ```python
 @pytest.mark.asyncio
 async def test_workflow_with_retries(workflow_env):

plugins/backend-development/skills/workflow-orchestration-patterns/SKILL.md

@@ -30,12 +30,14 @@ Master workflow orchestration architecture with Temporal, covering fundamental d
 ## Critical Design Decision: Workflows vs Activities
 
 **The Fundamental Rule** (Source: temporal.io/blog/workflow-engine-principles):
+
 - **Workflows** = Orchestration logic and decision-making
 - **Activities** = External interactions (APIs, databases, network calls)
 
 ### Workflows (Orchestration)
 
 **Characteristics:**
+
 - Contain business logic and coordination
 - **MUST be deterministic** (same inputs → same outputs)
 - **Cannot** perform direct external calls
@@ -43,6 +45,7 @@ Master workflow orchestration architecture with Temporal, covering fundamental d
 - Can run for years despite infrastructure failures
 
 **Example workflow tasks:**
+
 - Decide which steps to execute
 - Handle compensation logic
 - Manage timeouts and retries
@@ -51,6 +54,7 @@ Master workflow orchestration architecture with Temporal, covering fundamental d
 ### Activities (External Interactions)
 
 **Characteristics:**
+
 - Handle all external system interactions
 - Can be non-deterministic (API calls, DB writes)
 - Include built-in timeouts and retry logic
@@ -58,6 +62,7 @@ Master workflow orchestration architecture with Temporal, covering fundamental d
 - Short-lived (seconds to minutes typically)
 
 **Example activity tasks:**
+
 - Call payment gateway API
 - Write to database
 - Send emails or notifications
@@ -86,11 +91,13 @@ For each step:
 ```
 
 **Example: Payment Workflow**
+
 1. Reserve inventory (compensation: release inventory)
 2. Charge payment (compensation: refund payment)
 3. Fulfill order (compensation: cancel fulfillment)
 
 **Critical Requirements:**
+
 - Compensations must be idempotent
 - Register compensation BEFORE executing step
 - Run compensations in reverse order
@@ -101,17 +108,20 @@ For each step:
 **Purpose**: Long-lived workflow representing single entity instance
 
 **Pattern** (Source: docs.temporal.io/evaluate/use-cases-design-patterns):
+
 - One workflow execution = one entity (cart, account, inventory item)
 - Workflow persists for entity lifetime
 - Receives signals for state changes
 - Supports queries for current state
 
 **Example Use Cases:**
+
 - Shopping cart (add items, checkout, expiration)
 - Bank account (deposits, withdrawals, balance checks)
 - Product inventory (stock updates, reservations)
 
 **Benefits:**
+
 - Encapsulates entity behavior
 - Guarantees consistency per entity
 - Natural event sourcing
@@ -121,12 +131,14 @@ For each step:
 **Purpose**: Execute multiple tasks in parallel, aggregate results
 
 **Pattern:**
+
 - Spawn child workflows or parallel activities
 - Wait for all to complete
 - Aggregate results
 - Handle partial failures
 
 **Scaling Rule** (Source: temporal.io/blog/workflow-engine-principles):
+
 - Don't scale individual workflows
 - For 1M tasks: spawn 1K child workflows × 1K tasks each
 - Keep each workflow bounded
@@ -136,12 +148,14 @@ For each step:
 **Purpose**: Wait for external event or human approval
 
 **Pattern:**
+
 - Workflow sends request and waits for signal
 - External system processes asynchronously
 - Sends signal to resume workflow
 - Workflow continues with response
 
 **Use Cases:**
+
 - Human approval workflows
 - Webhook callbacks
 - Long-running external processes
@@ -151,6 +165,7 @@ For each step:
 ### Automatic State Preservation
 
 **How Temporal Works** (Source: docs.temporal.io/workflows):
+
 - Complete program state preserved automatically
 - Event History records every command and event
 - Seamless recovery from crashes
@@ -159,10 +174,12 @@ For each step:
 ### Determinism Constraints
 
 **Workflows Execute as State Machines**:
+
 - Replay behavior must be consistent
 - Same inputs → identical outputs every time
 
 **Prohibited in Workflows** (Source: docs.temporal.io/workflows):
+
 - ❌ Threading, locks, synchronization primitives
 - ❌ Random number generation (`random()`)
 - ❌ Global state or static variables
@@ -171,6 +188,7 @@ For each step:
 - ❌ Non-deterministic libraries
 
 **Allowed in Workflows**:
+
 - ✅ `workflow.now()` (deterministic time)
 - ✅ `workflow.random()` (deterministic random)
 - ✅ Pure functions and calculations
@@ -181,6 +199,7 @@ For each step:
 **Challenge**: Changing workflow code while old executions still running
 
 **Solutions**:
+
 1. **Versioning API**: Use `workflow.get_version()` for safe changes
 2. **New Workflow Type**: Create new workflow, route new executions to it
 3. **Backward Compatibility**: Ensure old events replay correctly
@@ -192,12 +211,14 @@ For each step:
 **Default Behavior**: Temporal retries activities forever
 
 **Configure Retry**:
+
 - Initial retry interval
 - Backoff coefficient (exponential backoff)
 - Maximum interval (cap retry delay)
 - Maximum attempts (eventually fail)
 
 **Non-Retryable Errors**:
+
 - Invalid input (validation failures)
 - Business rule violations
 - Permanent failures (resource not found)
@@ -205,11 +226,13 @@ For each step:
 ### Idempotency Requirements
 
 **Why Critical** (Source: docs.temporal.io/activities):
+
 - Activities may execute multiple times
 - Network failures trigger retries
 - Duplicate execution must be safe
 
 **Implementation Strategies**:
+
 - Idempotency keys (deduplication)
 - Check-then-act with unique constraints
 - Upsert operations instead of insert
@@ -220,6 +243,7 @@ For each step:
 **Purpose**: Detect stalled long-running activities
 
 **Pattern**:
+
 - Activity sends periodic heartbeat
 - Includes progress information
 - Timeout if no heartbeat received
@@ -245,12 +269,14 @@ For each step:
 ### Common Pitfalls
 
 **Workflow Violations**:
+
 - Using `datetime.now()` instead of `workflow.now()`
 - Threading or async operations in workflow code
 - Calling external APIs directly from workflow
 - Non-deterministic logic in workflows
 
 **Activity Mistakes**:
+
 - Non-idempotent operations (can't handle retries)
 - Missing timeouts (activities run forever)
 - No error classification (retry validation errors)
@@ -259,12 +285,14 @@ For each step:
 ### Operational Considerations
 
 **Monitoring**:
+
 - Workflow execution duration
 - Activity failure rates
 - Retry attempts and backoff
 - Pending workflow counts
 
 **Scalability**:
+
 - Horizontal scaling with workers
 - Task queue partitioning
 - Child workflow decomposition
@@ -273,12 +301,14 @@ For each step:
 ## Additional Resources
 
 **Official Documentation**:
+
 - Temporal Core Concepts: docs.temporal.io/workflows
 - Workflow Patterns: docs.temporal.io/evaluate/use-cases-design-patterns
 - Best Practices: docs.temporal.io/develop/best-practices
 - Saga Pattern: temporal.io/blog/saga-pattern-made-easy
 
 **Key Principles**:
+
 1. Workflows = orchestration, Activities = external calls
 2. Determinism is non-negotiable for workflows
 3. Idempotency is critical for activities