@ngxtm/devkit 3.6.1 → 3.8.0

package/merged-commands/multi-agent-patterns.md

@@ -0,0 +1,262 @@
+---
+name: multi-agent-patterns
+description: "Master orchestrator, peer-to-peer, and hierarchical multi-agent architectures"
+source: "https://github.com/muratcankoylan/Agent-Skills-for-Context-Engineering/tree/main/skills/multi-agent-patterns"
+risk: safe
+---
+
+## When to Use This Skill
+
+Master orchestrator, peer-to-peer, and hierarchical multi-agent architectures
+
+Use this skill when working with master orchestrator, peer-to-peer, and hierarchical multi-agent architectures.
+# Multi-Agent Architecture Patterns
+
+Multi-agent architectures distribute work across multiple language model instances, each with its own context window. When designed well, this distribution enables capabilities beyond single-agent limits. When designed poorly, it introduces coordination overhead that negates benefits. The critical insight is that sub-agents exist primarily to isolate context, not to anthropomorphize role division.
+
+## When to Activate
+
+Activate this skill when:
+- Single-agent context limits constrain task complexity
+- Tasks decompose naturally into parallel subtasks
+- Different subtasks require different tool sets or system prompts
+- Building systems that must handle multiple domains simultaneously
+- Scaling agent capabilities beyond single-context limits
+- Designing production agent systems with multiple specialized components
+
+## Core Concepts
+
+Multi-agent systems address single-agent context limitations through distribution. Three dominant patterns exist: supervisor/orchestrator for centralized control, peer-to-peer/swarm for flexible handoffs, and hierarchical for layered abstraction. The critical design principle is context isolation—sub-agents exist primarily to partition context rather than to simulate organizational roles.
+
+Effective multi-agent systems require explicit coordination protocols, consensus mechanisms that avoid sycophancy, and careful attention to failure modes including bottlenecks, divergence, and error propagation.
+
+## Detailed Topics
+
+### Why Multi-Agent Architectures
+
+**The Context Bottleneck**
+Single agents face inherent ceilings in reasoning capability, context management, and tool coordination. As tasks grow more complex, context windows fill with accumulated history, retrieved documents, and tool outputs. Performance degrades according to predictable patterns: the lost-in-middle effect, attention scarcity, and context poisoning.
+
+Multi-agent architectures address these limitations by partitioning work across multiple context windows. Each agent operates in a clean context focused on its subtask. Results aggregate at a coordination layer without any single context bearing the full burden.
+
+**The Token Economics Reality**
+Multi-agent systems consume significantly more tokens than single-agent approaches. Production data shows:
+
+| Architecture | Token Multiplier | Use Case |
+|--------------|------------------|----------|
+| Single agent chat | 1× baseline | Simple queries |
+| Single agent with tools | ~4× baseline | Tool-using tasks |
+| Multi-agent system | ~15× baseline | Complex research/coordination |
+
+Research on the BrowseComp evaluation found that three factors explain 95% of performance variance: token usage (80% of variance), number of tool calls, and model choice. This validates the multi-agent approach of distributing work across agents with separate context windows to add capacity for parallel reasoning.
+
+Critically, upgrading to better models often provides larger performance gains than doubling token budgets. Claude Sonnet 4.5 showed larger gains than doubling tokens on earlier Sonnet versions. GPT-5.2's thinking mode similarly outperforms raw token increases. This suggests model selection and multi-agent architecture are complementary strategies.
+
+**The Parallelization Argument**
+Many tasks contain parallelizable subtasks that a single agent must execute sequentially. A research task might require searching multiple independent sources, analyzing different documents, or comparing competing approaches. A single agent processes these sequentially, accumulating context with each step.
+
+Multi-agent architectures assign each subtask to a dedicated agent with a fresh context. All agents work simultaneously, then return results to a coordinator. The total real-world time approaches the duration of the longest subtask rather than the sum of all subtasks.
+
+**The Specialization Argument**
+Different tasks benefit from different agent configurations: different system prompts, different tool sets, different context structures. A general-purpose agent must carry all possible configurations in context. Specialized agents carry only what they need.
+
+Multi-agent architectures enable specialization without combinatorial explosion. The coordinator routes to specialized agents; each agent operates with lean context optimized for its domain.
+
+### Architectural Patterns
+
+**Pattern 1: Supervisor/Orchestrator**
+The supervisor pattern places a central agent in control, delegating to specialists and synthesizing results. The supervisor maintains global state and trajectory, decomposes user objectives into subtasks, and routes to appropriate workers.
+
+```
+User Query -> Supervisor -> [Specialist, Specialist, Specialist] -> Aggregation -> Final Output
+```
+
+When to use: Complex tasks with clear decomposition, tasks requiring coordination across domains, tasks where human oversight is important.
+
+Advantages: Strict control over workflow, easier to implement human-in-the-loop interventions, ensures adherence to predefined plans.
+
+Disadvantages: Supervisor context becomes bottleneck, supervisor failures cascade to all workers, "telephone game" problem where supervisors paraphrase sub-agent responses incorrectly.
+
+**The Telephone Game Problem and Solution**
+LangGraph benchmarks found supervisor architectures initially performed 50% worse than optimized versions due to the "telephone game" problem where supervisors paraphrase sub-agent responses incorrectly, losing fidelity.
+
+The fix: implement a `forward_message` tool allowing sub-agents to pass responses directly to users:
+
+```python
+def forward_message(message: str, to_user: bool = True):
+    """
+    Forward sub-agent response directly to user without supervisor synthesis.
+    
+    Use when:
+    - Sub-agent response is final and complete
+    - Supervisor synthesis would lose important details
+    - Response format must be preserved exactly
+    """
+    if to_user:
+        return {"type": "direct_response", "content": message}
+    return {"type": "supervisor_input", "content": message}
+```
+
+With this pattern, swarm architectures slightly outperform supervisors because sub-agents respond directly to users, eliminating translation errors.
+
+Implementation note: Implement direct pass-through mechanisms allowing sub-agents to pass responses directly to users rather than through supervisor synthesis when appropriate.
+
+**Pattern 2: Peer-to-Peer/Swarm**
+The peer-to-peer pattern removes central control, allowing agents to communicate directly based on predefined protocols. Any agent can transfer control to any other through explicit handoff mechanisms.
+
+```python
+def transfer_to_agent_b():
+    return agent_b  # Handoff via function return
+
+agent_a = Agent(
+    name="Agent A",
+    functions=[transfer_to_agent_b]
+)
+```
+
+When to use: Tasks requiring flexible exploration, tasks where rigid planning is counterproductive, tasks with emergent requirements that defy upfront decomposition.
+
+Advantages: No single point of failure, scales effectively for breadth-first exploration, enables emergent problem-solving behaviors.
+
+Disadvantages: Coordination complexity increases with agent count, risk of divergence without central state keeper, requires robust convergence constraints.
+
+Implementation note: Define explicit handoff protocols with state passing. Ensure agents can communicate their context needs to receiving agents.
+
+**Pattern 3: Hierarchical**
+Hierarchical structures organize agents into layers of abstraction: strategic, planning, and execution layers. Strategy layer agents define goals and constraints; planning layer agents break goals into actionable plans; execution layer agents perform atomic tasks.
+
+```
+Strategy Layer (Goal Definition) -> Planning Layer (Task Decomposition) -> Execution Layer (Atomic Tasks)
+```
+
+When to use: Large-scale projects with clear hierarchical structure, enterprise workflows with management layers, tasks requiring both high-level planning and detailed execution.
+
+Advantages: Mirrors organizational structures, clear separation of concerns, enables different context structures at different levels.
+
+Disadvantages: Coordination overhead between layers, potential for misalignment between strategy and execution, complex error propagation.
+
+### Context Isolation as Design Principle
+
+The primary purpose of multi-agent architectures is context isolation. Each sub-agent operates in a clean context window focused on its subtask without carrying accumulated context from other subtasks.
+
+**Isolation Mechanisms**
+Full context delegation: For complex tasks where the sub-agent needs complete understanding, the planner shares its entire context. The sub-agent has its own tools and instructions but receives full context for its decisions.
+
+Instruction passing: For simple, well-defined subtasks, the planner creates instructions via function call. The sub-agent receives only the instructions needed for its specific task.
+
+File system memory: For complex tasks requiring shared state, agents read and write to persistent storage. The file system serves as the coordination mechanism, avoiding context bloat from shared state passing.
+
+**Isolation Trade-offs**
+Full context delegation provides maximum capability but defeats the purpose of sub-agents. Instruction passing maintains isolation but limits sub-agent flexibility. File system memory enables shared state without context passing but introduces latency and consistency challenges.
+
+The right choice depends on task complexity, coordination needs, and acceptable latency.
+
+### Consensus and Coordination
+
+**The Voting Problem**
+Simple majority voting treats hallucinations from weak models as equal to reasoning from strong models. Without intervention, multi-agent discussions devolve into consensus on false premises due to inherent bias toward agreement.
+
+**Weighted Voting**
+Weight agent votes by confidence or expertise. Agents with higher confidence or domain expertise carry more weight in final decisions.
+
+**Debate Protocols**
+Debate protocols require agents to critique each other's outputs over multiple rounds. Adversarial critique often yields higher accuracy on complex reasoning than collaborative consensus.
+
+**Trigger-Based Intervention**
+Monitor multi-agent interactions for specific behavioral markers. Stall triggers activate when discussions make no progress. Sycophancy triggers detect when agents mimic each other's answers without unique reasoning.
+
+### Framework Considerations
+
+Different frameworks implement these patterns with different philosophies. LangGraph uses graph-based state machines with explicit nodes and edges. AutoGen uses conversational/event-driven patterns with GroupChat. CrewAI uses role-based process flows with hierarchical crew structures.
+
+## Practical Guidance
+
+### Failure Modes and Mitigations
+
+**Failure: Supervisor Bottleneck**
+The supervisor accumulates context from all workers, becoming susceptible to saturation and degradation.
+
+Mitigation: Implement output schema constraints so workers return only distilled summaries. Use checkpointing to persist supervisor state without carrying full history.
+
+**Failure: Coordination Overhead**
+Agent communication consumes tokens and introduces latency. Complex coordination can negate parallelization benefits.
+
+Mitigation: Minimize communication through clear handoff protocols. Batch results where possible. Use asynchronous communication patterns.
+
+**Failure: Divergence**
+Agents pursuing different goals without central coordination can drift from intended objectives.
+
+Mitigation: Define clear objective boundaries for each agent. Implement convergence checks that verify progress toward shared goals. Use time-to-live limits on agent execution.
+
+**Failure: Error Propagation**
+Errors in one agent's output propagate to downstream agents that consume that output.
+
+Mitigation: Validate agent outputs before passing to consumers. Implement retry logic with circuit breakers. Use idempotent operations where possible.
+
+## Examples
+
+**Example 1: Research Team Architecture**
+```text
+Supervisor
+├── Researcher (web search, document retrieval)
+├── Analyzer (data analysis, statistics)
+├── Fact-checker (verification, validation)
+└── Writer (report generation, formatting)
+```
+
+**Example 2: Handoff Protocol**
+```python
+def handle_customer_request(request):
+    if request.type == "billing":
+        return transfer_to(billing_agent)
+    elif request.type == "technical":
+        return transfer_to(technical_agent)
+    elif request.type == "sales":
+        return transfer_to(sales_agent)
+    else:
+        return handle_general(request)
+```
+
+## Guidelines
+
+1. Design for context isolation as the primary benefit of multi-agent systems
+2. Choose architecture pattern based on coordination needs, not organizational metaphor
+3. Implement explicit handoff protocols with state passing
+4. Use weighted voting or debate protocols for consensus
+5. Monitor for supervisor bottlenecks and implement checkpointing
+6. Validate outputs before passing between agents
+7. Set time-to-live limits to prevent infinite loops
+8. Test failure scenarios explicitly
+
+## Integration
+
+This skill builds on context-fundamentals and context-degradation. It connects to:
+
+- memory-systems - Shared state management across agents
+- tool-design - Tool specialization per agent
+- context-optimization - Context partitioning strategies
+
+## References
+
+Internal reference:
+- [Frameworks Reference](./references/frameworks.md) - Detailed framework implementation patterns
+
+Related skills in this collection:
+- context-fundamentals - Context basics
+- memory-systems - Cross-agent memory
+- context-optimization - Partitioning strategies
+
+External resources:
+- [LangGraph Documentation](https://langchain-ai.github.io/langgraph/) - Multi-agent patterns and state management
+- [AutoGen Framework](https://microsoft.github.io/autogen/) - GroupChat and conversational patterns
+- [CrewAI Documentation](https://docs.crewai.com/) - Hierarchical agent processes
+- [Research on Multi-Agent Coordination](https://arxiv.org/abs/2308.00352) - Survey of multi-agent systems
+
+---
+
+## Skill Metadata
+
+**Created**: 2025-12-20
+**Last Updated**: 2025-12-20
+**Author**: Agent Skills for Context Engineering Contributors
+**Version**: 1.0.0

package/merged-commands/multi-cloud-architecture.md

@@ -0,0 +1,189 @@
+---
+name: multi-cloud-architecture
+description: Design multi-cloud architectures using a decision framework to select and integrate services across AWS, Azure, and GCP. Use when building multi-cloud systems, avoiding vendor lock-in, or leveraging best-of-breed services from multiple providers.
+---
+
+# Multi-Cloud Architecture
+
+Decision framework and patterns for architecting applications across AWS, Azure, and GCP.
+
+## Do not use this skill when
+
+- The task is unrelated to multi-cloud architecture
+- You need a different domain or tool outside this scope
+
+## Instructions
+
+- Clarify goals, constraints, and required inputs.
+- Apply relevant best practices and validate outcomes.
+- Provide actionable steps and verification.
+- If detailed examples are required, open `resources/implementation-playbook.md`.
+
+## Purpose
+
+Design cloud-agnostic architectures and make informed decisions about service selection across cloud providers.
+
+## Use this skill when
+
+- Design multi-cloud strategies
+- Migrate between cloud providers
+- Select cloud services for specific workloads
+- Implement cloud-agnostic architectures
+- Optimize costs across providers
+
+## Cloud Service Comparison
+
+### Compute Services
+
+| AWS | Azure | GCP | Use Case |
+|-----|-------|-----|----------|
+| EC2 | Virtual Machines | Compute Engine | IaaS VMs |
+| ECS | Container Instances | Cloud Run | Containers |
+| EKS | AKS | GKE | Kubernetes |
+| Lambda | Functions | Cloud Functions | Serverless |
+| Fargate | Container Apps | Cloud Run | Managed containers |
+
+### Storage Services
+
+| AWS | Azure | GCP | Use Case |
+|-----|-------|-----|----------|
+| S3 | Blob Storage | Cloud Storage | Object storage |
+| EBS | Managed Disks | Persistent Disk | Block storage |
+| EFS | Azure Files | Filestore | File storage |
+| Glacier | Archive Storage | Archive Storage | Cold storage |
+
+### Database Services
+
+| AWS | Azure | GCP | Use Case |
+|-----|-------|-----|----------|
+| RDS | SQL Database | Cloud SQL | Managed SQL |
+| DynamoDB | Cosmos DB | Firestore | NoSQL |
+| Aurora | PostgreSQL/MySQL | Cloud Spanner | Distributed SQL |
+| ElastiCache | Cache for Redis | Memorystore | Caching |
+
+**Reference:** See `references/service-comparison.md` for complete comparison
+
+## Multi-Cloud Patterns
+
+### Pattern 1: Single Provider with DR
+
+- Primary workload in one cloud
+- Disaster recovery in another
+- Database replication across clouds
+- Automated failover
+
+### Pattern 2: Best-of-Breed
+
+- Use best service from each provider
+- AI/ML on GCP
+- Enterprise apps on Azure
+- General compute on AWS
+
+### Pattern 3: Geographic Distribution
+
+- Serve users from nearest cloud region
+- Data sovereignty compliance
+- Global load balancing
+- Regional failover
+
+### Pattern 4: Cloud-Agnostic Abstraction
+
+- Kubernetes for compute
+- PostgreSQL for database
+- S3-compatible storage (MinIO)
+- Open source tools
+
+## Cloud-Agnostic Architecture
+
+### Use Cloud-Native Alternatives
+
+- **Compute:** Kubernetes (EKS/AKS/GKE)
+- **Database:** PostgreSQL/MySQL (RDS/SQL Database/Cloud SQL)
+- **Message Queue:** Apache Kafka (MSK/Event Hubs/Confluent)
+- **Cache:** Redis (ElastiCache/Azure Cache/Memorystore)
+- **Object Storage:** S3-compatible API
+- **Monitoring:** Prometheus/Grafana
+- **Service Mesh:** Istio/Linkerd
+
+### Abstraction Layers
+
+```
+Application Layer
+    ↓
+Infrastructure Abstraction (Terraform)
+    ↓
+Cloud Provider APIs
+    ↓
+AWS / Azure / GCP
+```
+
+## Cost Comparison
+
+### Compute Pricing Factors
+
+- **AWS:** On-demand, Reserved, Spot, Savings Plans
+- **Azure:** Pay-as-you-go, Reserved, Spot
+- **GCP:** On-demand, Committed use, Preemptible
+
+### Cost Optimization Strategies
+
+1. Use reserved/committed capacity (30-70% savings)
+2. Leverage spot/preemptible instances
+3. Right-size resources
+4. Use serverless for variable workloads
+5. Optimize data transfer costs
+6. Implement lifecycle policies
+7. Use cost allocation tags
+8. Monitor with cloud cost tools
+
+**Reference:** See `references/multi-cloud-patterns.md`
+
+## Migration Strategy
+
+### Phase 1: Assessment
+- Inventory current infrastructure
+- Identify dependencies
+- Assess cloud compatibility
+- Estimate costs
+
+### Phase 2: Pilot
+- Select pilot workload
+- Implement in target cloud
+- Test thoroughly
+- Document learnings
+
+### Phase 3: Migration
+- Migrate workloads incrementally
+- Maintain dual-run period
+- Monitor performance
+- Validate functionality
+
+### Phase 4: Optimization
+- Right-size resources
+- Implement cloud-native services
+- Optimize costs
+- Enhance security
+
+## Best Practices
+
+1. **Use infrastructure as code** (Terraform/OpenTofu)
+2. **Implement CI/CD pipelines** for deployments
+3. **Design for failure** across clouds
+4. **Use managed services** when possible
+5. **Implement comprehensive monitoring**
+6. **Automate cost optimization**
+7. **Follow security best practices**
+8. **Document cloud-specific configurations**
+9. **Test disaster recovery** procedures
+10. **Train teams** on multiple clouds
+
+## Reference Files
+
+- `references/service-comparison.md` - Complete service comparison
+- `references/multi-cloud-patterns.md` - Architecture patterns
+
+## Related Skills
+
+- `terraform-module-library` - For IaC implementation
+- `cost-optimization` - For cost management
+- `hybrid-cloud-networking` - For connectivity

package/merged-commands/multi-platform-apps-multi-platform.md

@@ -0,0 +1,203 @@
+---
+name: multi-platform-apps-multi-platform
+description: "Build and deploy the same feature consistently across web, mobile, and desktop platforms using API-first architecture and parallel implementation strategies."
+---
+
+# Multi-Platform Feature Development Workflow
+
+Build and deploy the same feature consistently across web, mobile, and desktop platforms using API-first architecture and parallel implementation strategies.
+
+[Extended thinking: This workflow orchestrates multiple specialized agents to ensure feature parity across platforms while maintaining platform-specific optimizations. The coordination strategy emphasizes shared contracts and parallel development with regular synchronization points. By establishing API contracts and data models upfront, teams can work independently while ensuring consistency. The workflow benefits include faster time-to-market, reduced integration issues, and maintainable cross-platform codebases.]
+
+## Use this skill when
+
+- Working on multi-platform feature development workflow tasks or workflows
+- Needing guidance, best practices, or checklists for multi-platform feature development workflow
+
+## Do not use this skill when
+
+- The task is unrelated to multi-platform feature development workflow
+- You need a different domain or tool outside this scope
+
+## Instructions
+
+- Clarify goals, constraints, and required inputs.
+- Apply relevant best practices and validate outcomes.
+- Provide actionable steps and verification.
+- If detailed examples are required, open `resources/implementation-playbook.md`.
+
+## Phase 1: Architecture and API Design (Sequential)
+
+### 1. Define Feature Requirements and API Contracts
+- Use Task tool with subagent_type="backend-architect"
+- Prompt: "Design the API contract for feature: $ARGUMENTS. Create OpenAPI 3.1 specification with:
+  - RESTful endpoints with proper HTTP methods and status codes
+  - GraphQL schema if applicable for complex data queries
+  - WebSocket events for real-time features
+  - Request/response schemas with validation rules
+  - Authentication and authorization requirements
+  - Rate limiting and caching strategies
+  - Error response formats and codes
+  Define shared data models that all platforms will consume."
+- Expected output: Complete API specification, data models, and integration guidelines
+
+### 2. Design System and UI/UX Consistency
+- Use Task tool with subagent_type="ui-ux-designer"
+- Prompt: "Create cross-platform design system for feature using API spec: [previous output]. Include:
+  - Component specifications for each platform (Material Design, iOS HIG, Fluent)
+  - Responsive layouts for web (mobile-first approach)
+  - Native patterns for iOS (SwiftUI) and Android (Material You)
+  - Desktop-specific considerations (keyboard shortcuts, window management)
+  - Accessibility requirements (WCAG 2.2 Level AA)
+  - Dark/light theme specifications
+  - Animation and transition guidelines"
+- Context from previous: API endpoints, data structures, authentication flows
+- Expected output: Design system documentation, component library specs, platform guidelines
+
+### 3. Shared Business Logic Architecture
+- Use Task tool with subagent_type="comprehensive-review::architect-review"
+- Prompt: "Design shared business logic architecture for cross-platform feature. Define:
+  - Core domain models and entities (platform-agnostic)
+  - Business rules and validation logic
+  - State management patterns (MVI/Redux/BLoC)
+  - Caching and offline strategies
+  - Error handling and retry policies
+  - Platform-specific adapter patterns
+  Consider Kotlin Multiplatform for mobile or TypeScript for web/desktop sharing."
+- Context from previous: API contracts, data models, UI requirements
+- Expected output: Shared code architecture, platform abstraction layers, implementation guide
+
+## Phase 2: Parallel Platform Implementation
+
+### 4a. Web Implementation (React/Next.js)
+- Use Task tool with subagent_type="frontend-developer"
+- Prompt: "Implement web version of feature using:
+  - React 18+ with Next.js 14+ App Router
+  - TypeScript for type safety
+  - TanStack Query for API integration: [API spec]
+  - Zustand/Redux Toolkit for state management
+  - Tailwind CSS with design system: [design specs]
+  - Progressive Web App capabilities
+  - SSR/SSG optimization where appropriate
+  - Web vitals optimization (LCP < 2.5s, FID < 100ms)
+  Follow shared business logic: [architecture doc]"
+- Context from previous: API contracts, design system, shared logic patterns
+- Expected output: Complete web implementation with tests
+
+### 4b. iOS Implementation (SwiftUI)
+- Use Task tool with subagent_type="ios-developer"
+- Prompt: "Implement iOS version using:
+  - SwiftUI with iOS 17+ features
+  - Swift 5.9+ with async/await
+  - URLSession with Combine for API: [API spec]
+  - Core Data/SwiftData for persistence
+  - Design system compliance: [iOS HIG specs]
+  - Widget extensions if applicable
+  - Platform-specific features (Face ID, Haptics, Live Activities)
+  - Testable MVVM architecture
+  Follow shared patterns: [architecture doc]"
+- Context from previous: API contracts, iOS design guidelines, shared models
+- Expected output: Native iOS implementation with unit/UI tests
+
+### 4c. Android Implementation (Kotlin/Compose)
+- Use Task tool with subagent_type="mobile-developer"
+- Prompt: "Implement Android version using:
+  - Jetpack Compose with Material 3
+  - Kotlin coroutines and Flow
+  - Retrofit/Ktor for API: [API spec]
+  - Room database for local storage
+  - Hilt for dependency injection
+  - Material You dynamic theming: [design specs]
+  - Platform features (biometric auth, widgets)
+  - Clean architecture with MVI pattern
+  Follow shared logic: [architecture doc]"
+- Context from previous: API contracts, Material Design specs, shared patterns
+- Expected output: Native Android implementation with tests
+
+### 4d. Desktop Implementation (Optional - Electron/Tauri)
+- Use Task tool with subagent_type="frontend-mobile-development::frontend-developer"
+- Prompt: "Implement desktop version using Tauri 2.0 or Electron with:
+  - Shared web codebase where possible
+  - Native OS integration (system tray, notifications)
+  - File system access if needed
+  - Auto-updater functionality
+  - Code signing and notarization setup
+  - Keyboard shortcuts and menu bar
+  - Multi-window support if applicable
+  Reuse web components: [web implementation]"
+- Context from previous: Web implementation, desktop-specific requirements
+- Expected output: Desktop application with platform packages
+
+## Phase 3: Integration and Validation
+
+### 5. API Documentation and Testing
+- Use Task tool with subagent_type="documentation-generation::api-documenter"
+- Prompt: "Create comprehensive API documentation including:
+  - Interactive OpenAPI/Swagger documentation
+  - Platform-specific integration guides
+  - SDK examples for each platform
+  - Authentication flow diagrams
+  - Rate limiting and quota information
+  - Postman/Insomnia collections
+  - WebSocket connection examples
+  - Error handling best practices
+  - API versioning strategy
+  Test all endpoints with platform implementations."
+- Context from previous: Implemented platforms, API usage patterns
+- Expected output: Complete API documentation portal, test results
+
+### 6. Cross-Platform Testing and Feature Parity
+- Use Task tool with subagent_type="unit-testing::test-automator"
+- Prompt: "Validate feature parity across all platforms:
+  - Functional testing matrix (features work identically)
+  - UI consistency verification (follows design system)
+  - Performance benchmarks per platform
+  - Accessibility testing (platform-specific tools)
+  - Network resilience testing (offline, slow connections)
+  - Data synchronization validation
+  - Platform-specific edge cases
+  - End-to-end user journey tests
+  Create test report with any platform discrepancies."
+- Context from previous: All platform implementations, API documentation
+- Expected output: Test report, parity matrix, performance metrics
+
+### 7. Platform-Specific Optimizations
+- Use Task tool with subagent_type="application-performance::performance-engineer"
+- Prompt: "Optimize each platform implementation:
+  - Web: Bundle size, lazy loading, CDN setup, SEO
+  - iOS: App size, launch time, memory usage, battery
+  - Android: APK size, startup time, frame rate, battery
+  - Desktop: Binary size, resource usage, startup time
+  - API: Response time, caching, compression
+  Maintain feature parity while leveraging platform strengths.
+  Document optimization techniques and trade-offs."
+- Context from previous: Test results, performance metrics
+- Expected output: Optimized implementations, performance improvements
+
+## Configuration Options
+
+- **--platforms**: Specify target platforms (web,ios,android,desktop)
+- **--api-first**: Generate API before UI implementation (default: true)
+- **--shared-code**: Use Kotlin Multiplatform or similar (default: evaluate)
+- **--design-system**: Use existing or create new (default: create)
+- **--testing-strategy**: Unit, integration, e2e (default: all)
+
+## Success Criteria
+
+- API contract defined and validated before implementation
+- All platforms achieve feature parity with <5% variance
+- Performance metrics meet platform-specific standards
+- Accessibility standards met (WCAG 2.2 AA minimum)
+- Cross-platform testing shows consistent behavior
+- Documentation complete for all platforms
+- Code reuse >40% between platforms where applicable
+- User experience optimized for each platform's conventions
+
+## Platform-Specific Considerations
+
+**Web**: PWA capabilities, SEO optimization, browser compatibility
+**iOS**: App Store guidelines, TestFlight distribution, iOS-specific features
+**Android**: Play Store requirements, Android App Bundles, device fragmentation
+**Desktop**: Code signing, auto-updates, OS-specific installers
+
+Initial feature specification: $ARGUMENTS