[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M70N6VNEY4FGSVHPAFT2VBEP":3,"skill-same:01M70N6VNEY4FGSVHPAFT2VBEP":115},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":31,"publishedAt":52,"linkOnly":53,"markdownContent":54,"markdownBody":55,"frontMatter":56,"refName":57,"commitSha":58,"skillDirectory":59,"forksCount":60,"repositoryHtmlUrl":61,"repositoryHomepageUrl":62,"ownerHtmlUrl":63,"ownerBlogUrl":64,"ownerDescription":65,"updatedAt":66,"install":67,"resources":80},"01M70N6VNEY4FGSVHPAFT2VBEP","iot-system-architect",null,"Expert IoT system architecture covering distributed systems, event-driven design, edge computing, and microservices patterns. Use when designing multi-device systems, planning communication architecture, implementing event-driven patterns, scaling IoT deployments, or documenting architecture decisions for distributed IoT systems.","shengdabai\u002FTony-Claude-Code-Skills","shengdabai","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F116417419?v=4","01M70F6D2WY5PQV5A92BKYJQEW","Tony Sheng","01M70F6D3GAAAYZ5H4CC1G8VXM",3,"MIT","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Frghamilton3-dotfiles\u002Fdot_claude\u002Fskills\u002Fiot-system-architect\u002Fiot-system-architect\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51],"iot system architect","iot","architect","system","System Architect","deployments","when","for","implementing","event","scaling","edge computing","patterns","expert","design","use","edge","communication","planning","architecture","2026-11-10 10:12:30",false,"---\nname: iot-system-architect\ndescription: Expert IoT system architecture covering distributed systems, event-driven design, edge computing, and microservices patterns. Use when designing multi-device systems, planning communication architecture, implementing event-driven patterns, scaling IoT deployments, or documenting architecture decisions for distributed IoT systems.\n---\n\n# IoT System Architect\n\n## Overview\n\nThis skill provides comprehensive guidance for designing and implementing scalable, resilient distributed IoT systems. Apply this skill when architecting multi-device systems, designing communication patterns, implementing event-driven architectures, or making critical architecture decisions for IoT deployments.\n\nThe skill encompasses distributed systems principles, communication architecture, microservices patterns, state management, scalability strategies, and design patterns specifically tailored for IoT environments.\n\n## When to Use This Skill\n\nInvoke this skill when:\n\n- **Designing a new IoT system** from scratch\n- **Planning communication architecture** between multiple devices\n- **Implementing event-driven patterns** with MQTT or similar protocols\n- **Scaling existing IoT deployments** beyond initial MVP\n- **Documenting architecture decisions** for IoT systems\n- **Resolving architectural challenges** in distributed device networks\n- **Evaluating trade-offs** between different architecture approaches\n- **Designing for offline-first** or eventually consistent systems\n- **Planning state synchronization** across distributed devices\n- **Implementing microservices** for IoT backend systems\n\n## Core Architecture Capabilities\n\n### 1. Distributed Systems Design\n\nApply distributed systems principles to create resilient, scalable IoT architectures.\n\n**Key Concepts:**\n- Event-driven architecture with publish-subscribe messaging\n- Edge computing vs cloud processing trade-offs\n- Data consistency models (strong, eventual, causal)\n- CAP theorem implications for IoT systems\n- Offline-first design patterns\n\n**When to Apply:**\n- Designing systems with multiple autonomous devices\n- Planning data flow and processing locations\n- Determining consistency requirements\n- Handling network partitions and failures\n\n**Reference Material:**\nFor detailed patterns and implementation strategies, read:\n```\nreferences\u002Farchitecture-patterns.md\n```\n\nThis reference contains:\n- Event-driven architecture with MQTT pub\u002Fsub\n- Edge vs cloud processing decision frameworks\n- Data consistency in distributed environments\n- CAP theorem trade-offs for IoT\n- Eventually consistent data models\n- Offline-first design patterns\n\n**Example Application:**\n\nWhen designing a timer system with multiple displays that need to stay synchronized:\n\n1. **Determine consistency requirements**: Do all displays need to show exactly the same time instantly (strong consistency) or is eventual consistency acceptable?\n\n2. **Choose processing location**: Should timer logic run on each device (edge) or centrally (cloud\u002Fhub)?\n\n3. **Design for partitions**: What happens when devices lose network connectivity?\n\n4. **Implement offline-first**: Each device maintains local state and syncs when possible\n\nFor the Argus timer system, review the specific implementation:\n```\nreferences\u002Fargus-system.md\n```\n\n### 2. Communication Architecture\n\nDesign robust, efficient communication patterns for device coordination.\n\n**Key Patterns:**\n- Hub-and-spoke topology (centralized broker)\n- Mesh networking (peer-to-peer)\n- Message broker design and configuration\n- Topic naming conventions and hierarchy\n- Quality of Service (QoS) strategies\n- Message payload optimization\n\n**When to Apply:**\n- Choosing communication topology for device network\n- Designing MQTT topic structure\n- Selecting appropriate QoS levels\n- Optimizing message payloads for bandwidth\n- Configuring message broker (Mosquitto, RabbitMQ)\n\n**Topic Structure Best Practices:**\n\nDesign hierarchical topic structures:\n```\n{system}\u002F{location}\u002F{device-type}\u002F{device-id}\u002F{data-type}\n\nExamples:\nargus\u002Fdesk\u002Ftimer\u002Fdevice01\u002Fstate\nargus\u002Fdesk\u002Ftimer\u002Fdevice01\u002Fcommand\nargus\u002Fwrist\u002Fdisplay\u002Fdevice02\u002Ftelemetry\n```\n\nUse wildcards for flexible subscriptions:\n```\nargus\u002F+\u002Ftimer\u002F+\u002Fstate      # All timer states\nargus\u002Fdesk\u002F#               # All desk devices\n+\u002F+\u002F+\u002F+\u002Ftelemetry         # All telemetry\n```\n\n**QoS Selection Guidelines:**\n- QoS 0: High-frequency sensor data, non-critical telemetry\n- QoS 1: Important events, commands, state updates\n- QoS 2: Financial transactions, critical commands\n\nFor comprehensive communication patterns, read:\n```\nreferences\u002Farchitecture-patterns.md\n  - Hub-and-Spoke Topology\n  - Message Broker Design\n  - Topic Naming Conventions\n  - QoS Strategy\n  - Payload Optimization\n```\n\n### 3. Microservices Patterns\n\nApply microservices architecture to IoT backend systems for modularity and scalability.\n\n**Decomposition Strategies:**\n- Service boundaries by device type\n- Service boundaries by business capability\n- Domain-Driven Design (bounded contexts)\n\n**Key Patterns:**\n- API design for device coordination\n- Service discovery mechanisms\n- Inter-service communication (sync vs async)\n- Failure isolation and resilience\n- Container orchestration with Docker\n\n**When to Apply:**\n- Breaking down monolithic IoT backend\n- Scaling specific system components independently\n- Isolating failures to prevent cascading issues\n- Supporting multiple development teams\n- Enabling technology diversity\n\n**Example Decomposition for Argus System:**\n```\nmqtt-broker\u002F           - Mosquitto MQTT broker\ndevice-service\u002F        - Device registration and discovery\ntimer-service\u002F         - Timer logic and state management\nnotification-service\u002F  - Notification delivery\nai-service\u002F            - ML inference (Jetson Nano)\ntelemetry-service\u002F     - Metrics collection and storage\n```\n\n**Implementation Guidance:**\n\nFor detailed microservices patterns and scalability strategies, read:\n```\nreferences\u002Fmicroservices-scalability.md\n```\n\nThis reference covers:\n- Service boundary definition\n- API design patterns (REST, GraphQL, gRPC)\n- Service discovery mechanisms\n- Communication patterns (sync\u002Fasync)\n- Resilience patterns (circuit breaker, bulkhead)\n- Container orchestration\n- Scalability considerations\n- Database sharding\n- Caching strategies\n- Connection pooling\n\n### 4. State Management\n\nImplement robust state synchronization across distributed devices.\n\n**Patterns:**\n- Device state synchronization\n- State machine design for device modes\n- Conflict-Free Replicated Data Types (CRDTs)\n- Event sourcing\n- State recovery after connection loss\n- Idempotent operations\n\n**When to Apply:**\n- Synchronizing state across multiple devices\n- Handling concurrent state updates\n- Recovering from network partitions\n- Implementing device operating modes\n- Ensuring eventual consistency\n\n**State Machine Example (Timer Modes):**\n\nDefine clear state transitions:\n```\nStates: Idle → Working → Break → LongBreak\nEvents: start(), pause(), resume(), complete()\n\nTransitions:\n  Idle + start() → Working\n  Working + complete() → Break\n  Break + complete() → Working (or LongBreak after N cycles)\n```\n\n**Conflict Resolution:**\n\nWhen devices update state concurrently:\n1. Use vector clocks to detect concurrent updates\n2. Apply Last-Write-Wins (LWW) for simple fields\n3. Implement custom merge functions for complex state\n4. Use timestamps as tiebreaker\n\nFor implementation patterns, reference:\n```\nreferences\u002Farchitecture-patterns.md\n  - Eventually Consistent Data Models\n  - Offline-First Design Patterns\n\nreferences\u002Fargus-system.md\n  - State Synchronization Strategy\n  - Conflict Resolution\n```\n\n### 5. Design Patterns for IoT\n\nApply proven design patterns to IoT system implementation.\n\n**Core Patterns:**\n\n**Observer Pattern** - MQTT subscriptions for state changes\n```python\n# Devices publish state changes\n# Services observe via MQTT subscriptions\ntopic: \"device\u002F{id}\u002Fstate\"\nsubscribers: notification-service, telemetry-service, ui-dashboard\n```\n\n**State Pattern** - Device operating modes\n```python\n# Timer device with work\u002Fbreak\u002Fidle states\n# Each state encapsulates mode-specific behavior\nclass WorkState, BreakState, IdleState\n```\n\n**Strategy Pattern** - Different timer modes (Pomodoro, custom, countdown)\n```python\n# Interchangeable algorithms for timer duration calculation\nclass PomodoroStrategy, CustomStrategy, CountdownStrategy\n```\n\n**Factory Pattern** - Device-specific MQTT handlers\n```python\n# Create appropriate handler based on device type\nHandlerFactory.create_handler('timer') → TimerHandler\nHandlerFactory.create_handler('display') → DisplayHandler\n```\n\n**Singleton Pattern** - MQTT broker connection\n```python\n# Single shared connection to MQTT broker\nMQTTConnectionManager.get_instance()\n```\n\n**Publish-Subscribe Pattern** - Core MQTT communication\n```python\n# One-to-many event distribution\nPublisher → MQTT Broker → Multiple Subscribers\n```\n\nFor detailed implementations and examples, read:\n```\nreferences\u002Fdesign-patterns.md\n```\n\nThis reference includes complete code examples for:\n- Observer, State, Strategy, Factory, Singleton patterns\n- Publish-Subscribe, Command, Adapter patterns\n- Proxy and Template Method patterns\n- IoT-specific implementations and use cases\n\n### 6. Scalability Planning\n\nDesign systems that scale from MVP to production loads.\n\n**Scaling Dimensions:**\n- Horizontal vs vertical scaling\n- Load balancing strategies\n- Database sharding for device data\n- Caching strategies (Redis)\n- Message queue sizing\n- Connection pooling\n\n**When to Apply:**\n- Planning for growth beyond initial deployment\n- Optimizing system performance under load\n- Identifying bottlenecks\n- Designing for multi-tenant scenarios\n- Supporting increasing device counts\n\n**Scaling Strategy Template:**\n\n1. **Current Scale (MVP)**: Define baseline (devices, users, messages\u002Fsec)\n2. **Near-Term Scale**: Plan for 10x growth\n3. **Future Scale**: Envision 100x growth\n4. **Bottlenecks**: Identify potential scaling limitations\n5. **Mitigation**: Plan scaling approach for each bottleneck\n\n**Example for Argus System:**\n```\nCurrent: 3 devices, 1 user, single location\nNear-Term: 10 devices, 2 users, multiple rooms\nFuture: 50 devices, 10 users, multiple locations\n\nScaling Strategy:\n- MQTT Broker: Vertical scaling, then clustering\n- Timer Service: Horizontal scaling (stateless)\n- Database: Vertical + read replicas\n- Cache: Redis for shared state\n```\n\nFor comprehensive scalability patterns, read:\n```\nreferences\u002Fmicroservices-scalability.md\n  - Horizontal vs Vertical Scaling\n  - Load Balancing Strategies\n  - Database Sharding\n  - Caching Strategies\n  - Message Queue Sizing\n  - Connection Pooling\n```\n\n### 7. Architecture Decision Records (ADRs)\n\nDocument significant architecture decisions with rationale and trade-offs.\n\n**When to Create ADRs:**\n- Choosing communication protocol (MQTT vs WebSocket vs HTTP)\n- Selecting database technology\n- Deciding on consistency model\n- Adopting new technology or framework\n- Making trade-offs with significant implications\n\n**ADR Structure:**\n1. **Context**: What forces drive this decision?\n2. **Decision**: What are we doing?\n3. **Rationale**: Why is this the right choice?\n4. **Alternatives**: What else was considered?\n5. **Consequences**: What are the trade-offs?\n6. **Implementation Impact**: How does this affect the system?\n\n**Using the ADR Template:**\n\nCopy the ADR template to document decisions:\n```\nassets\u002Fadr-template.md\n```\n\nThe template includes:\n- Complete structure with all required sections\n- Example filled-out ADR (MQTT for Device Communication)\n- Guidance for each section\n- Success metrics and follow-up actions\n\n**Best Practices:**\n- Create ADRs early in the decision process\n- Include multiple alternatives with honest trade-offs\n- Be specific about consequences (positive and negative)\n- Define measurable success metrics\n- Update ADRs as decisions evolve (revision history)\n\n### 8. Architecture Visualization\n\nCreate clear diagrams to communicate system design.\n\n**Diagram Types:**\n\n**System Context Diagram** - High-level view of system and external actors\n**Container Diagram** - System components and their interactions\n**Sequence Diagram** - Message flow for specific scenarios\n**State Diagram** - Device state machines\n**Deployment Diagram** - Physical infrastructure layout\n\n**Using Diagram Templates:**\n\nPlantUML templates are provided for C4 model diagrams:\n```\nassets\u002Fc4-diagram-template.puml\n```\n\nTemplates include:\n- Container diagram (system components)\n- Sequence diagram (message flow)\n- Deployment diagram (infrastructure)\n- State machine diagram (device states)\n- Component diagram (internal structure)\n\n**Generating Diagrams:**\n\nUse PlantUML to render diagrams:\n```bash\n# Install PlantUML\napt install plantuml\n\n# Generate diagram\nplantuml diagram.puml\n```\n\nOnline rendering available at: https:\u002F\u002Fwww.plantuml.com\u002Fplantuml\u002F\n\n**Customization:**\n- Update component names and relationships\n- Adjust styles and colors for device types\n- Add notes for important details\n- Use tags for visual grouping\n\n## Architecture Workflow\n\n### 1. Requirements Analysis\n\nIdentify system requirements and constraints:\n- Functional requirements (what must the system do?)\n- Non-functional requirements (performance, reliability, security)\n- Technical constraints (hardware, connectivity, power)\n- Business constraints (budget, timeline, resources)\n\n### 2. Architecture Design\n\nApply capabilities from this skill:\n\n1. **Choose topology**: Hub-and-spoke, mesh, or hybrid\n2. **Design communication**: Protocol, topic structure, QoS\n3. **Plan state management**: Consistency model, synchronization\n4. **Apply patterns**: Identify relevant design patterns\n5. **Plan for scale**: Anticipate growth and bottlenecks\n6. **Design for failure**: Offline operation, recovery strategies\n\n### 3. Documentation\n\nCreate architecture documentation:\n\n1. **System diagrams**: Use C4 model templates\n2. **ADRs**: Document key decisions\n3. **Communication specs**: Topic structure, message formats\n4. **State machines**: Define device operating modes\n5. **API documentation**: REST\u002FMQTT interface specs\n\n### 4. Implementation\n\nImplement architecture with best practices:\n\n1. **Start with communication**: MQTT broker and topic structure\n2. **Implement state management**: Local state + synchronization\n3. **Add resilience**: Offline-first, retry logic, circuit breakers\n4. **Instrument for observability**: Logging, metrics, monitoring\n5. **Test edge cases**: Network failures, concurrent updates, scale\n\n### 5. Iteration and Evolution\n\nContinuously improve architecture:\n\n1. **Monitor performance**: Latency, throughput, resource usage\n2. **Validate decisions**: Review ADRs against actual metrics\n3. **Identify bottlenecks**: Profile and optimize\n4. **Plan evolution**: Create ADRs for significant changes\n5. **Refactor incrementally**: Avoid big-bang rewrites\n\n## Argus System as Reference Implementation\n\nThe Argus productivity tracking system serves as a concrete reference implementation demonstrating these architecture principles in practice.\n\n**System Overview:**\n- Multiple devices (Presto, T-Embed, Stream Deck, Android)\n- Hub-and-spoke topology with Jetson Nano as central hub\n- MQTT-based event-driven architecture\n- Offline-first design with eventual consistency\n- Microservices backend on Jetson Nano\n\n**Key Architectural Decisions:**\n- MQTT for device communication (low latency, pub\u002Fsub)\n- Eventually consistent state (AP in CAP theorem)\n- Edge processing for real-time responses\n- Hub for coordination and intelligence\n\n**Learning from Argus:**\n\nStudy the complete system architecture:\n```\nreferences\u002Fargus-system.md\n```\n\nThis reference provides:\n- Complete system architecture diagram\n- Component details for each device\n- Communication patterns and topic structure\n- State synchronization strategy\n- Failure modes and recovery\n- Performance characteristics\n- Security considerations\n- Scalability path from MVP to production\n\nUse Argus as a template for similar distributed IoT systems.\n\n## Resources\n\n### references\u002F\n\nIn-depth documentation loaded into context as needed:\n\n- **architecture-patterns.md**: Distributed systems patterns, communication architecture, consistency models, offline-first design\n- **microservices-scalability.md**: Microservices decomposition, API design, resilience patterns, scaling strategies\n- **design-patterns.md**: Implementation patterns with code examples (Observer, State, Strategy, Factory, Singleton, Pub\u002FSub)\n- **argus-system.md**: Complete reference implementation with architecture diagrams, communication patterns, and implementation details\n\n### assets\u002F\n\nTemplates for architecture documentation and visualization:\n\n- **adr-template.md**: Architecture Decision Record template with complete example (MQTT decision)\n- **c4-diagram-template.puml**: PlantUML templates for system diagrams (container, sequence, deployment, state, component)\n\n## Architecture Principles\n\nFollow these principles when designing IoT systems:\n\n1. **Loose Coupling**: Devices and services operate independently through well-defined interfaces\n2. **High Cohesion**: Related functionality grouped together in components or services\n3. **Fail-Safe**: Graceful degradation when components fail or network partitions occur\n4. **Observability**: Comprehensive logging, metrics, and monitoring for debugging and optimization\n5. **Maintainability**: Clear module boundaries, documentation, and testability\n6. **Performance**: Meet real-time constraints with appropriate processing location and communication patterns\n7. **Security**: Defense in depth with authentication, authorization, and encryption where appropriate\n\n## Getting Started\n\nTo apply this skill to a new project:\n\n1. **Define requirements**: Identify functional and non-functional requirements\n2. **Study Argus**: Review the reference implementation for patterns\n3. **Choose topology**: Select appropriate communication architecture\n4. **Design communication**: Create MQTT topic structure and message formats\n5. **Plan state management**: Define consistency model and synchronization approach\n6. **Create ADRs**: Document key architecture decisions\n7. **Generate diagrams**: Use C4 templates to visualize architecture\n8. **Implement incrementally**: Start with core communication, add features iteratively\n9. **Monitor and evolve**: Instrument system, gather metrics, refine architecture\n\nFor any architecture questions or trade-offs, consult the relevant reference documentation and apply the patterns and principles outlined in this skill.\n","# IoT System Architect\n\n## Overview\n\nThis skill provides comprehensive guidance for designing and implementing scalable, resilient distributed IoT systems. Apply this skill when architecting multi-device systems, designing communication patterns, implementing event-driven architectures, or making critical architecture decisions for IoT deployments.\n\nThe skill encompasses distributed systems principles, communication architecture, microservices patterns, state management, scalability strategies, and design patterns specifically tailored for IoT environments.\n\n## When to Use This Skill\n\nInvoke this skill when:\n\n- **Designing a new IoT system** from scratch\n- **Planning communication architecture** between multiple devices\n- **Implementing event-driven patterns** with MQTT or similar protocols\n- **Scaling existing IoT deployments** beyond initial MVP\n- **Documenting architecture decisions** for IoT systems\n- **Resolving architectural challenges** in distributed device networks\n- **Evaluating trade-offs** between different architecture approaches\n- **Designing for offline-first** or eventually consistent systems\n- **Planning state synchronization** across distributed devices\n- **Implementing microservices** for IoT backend systems\n\n## Core Architecture Capabilities\n\n### 1. Distributed Systems Design\n\nApply distributed systems principles to create resilient, scalable IoT architectures.\n\n**Key Concepts:**\n- Event-driven architecture with publish-subscribe messaging\n- Edge computing vs cloud processing trade-offs\n- Data consistency models (strong, eventual, causal)\n- CAP theorem implications for IoT systems\n- Offline-first design patterns\n\n**When to Apply:**\n- Designing systems with multiple autonomous devices\n- Planning data flow and processing locations\n- Determining consistency requirements\n- Handling network partitions and failures\n\n**Reference Material:**\nFor detailed patterns and implementation strategies, read:\n```\nreferences\u002Farchitecture-patterns.md\n```\n\nThis reference contains:\n- Event-driven architecture with MQTT pub\u002Fsub\n- Edge vs cloud processing decision frameworks\n- Data consistency in distributed environments\n- CAP theorem trade-offs for IoT\n- Eventually consistent data models\n- Offline-first design patterns\n\n**Example Application:**\n\nWhen designing a timer system with multiple displays that need to stay synchronized:\n\n1. **Determine consistency requirements**: Do all displays need to show exactly the same time instantly (strong consistency) or is eventual consistency acceptable?\n\n2. **Choose processing location**: Should timer logic run on each device (edge) or centrally (cloud\u002Fhub)?\n\n3. **Design for partitions**: What happens when devices lose network connectivity?\n\n4. **Implement offline-first**: Each device maintains local state and syncs when possible\n\nFor the Argus timer system, review the specific implementation:\n```\nreferences\u002Fargus-system.md\n```\n\n### 2. Communication Architecture\n\nDesign robust, efficient communication patterns for device coordination.\n\n**Key Patterns:**\n- Hub-and-spoke topology (centralized broker)\n- Mesh networking (peer-to-peer)\n- Message broker design and configuration\n- Topic naming conventions and hierarchy\n- Quality of Service (QoS) strategies\n- Message payload optimization\n\n**When to Apply:**\n- Choosing communication topology for device network\n- Designing MQTT topic structure\n- Selecting appropriate QoS levels\n- Optimizing message payloads for bandwidth\n- Configuring message broker (Mosquitto, RabbitMQ)\n\n**Topic Structure Best Practices:**\n\nDesign hierarchical topic structures:\n```\n{system}\u002F{location}\u002F{device-type}\u002F{device-id}\u002F{data-type}\n\nExamples:\nargus\u002Fdesk\u002Ftimer\u002Fdevice01\u002Fstate\nargus\u002Fdesk\u002Ftimer\u002Fdevice01\u002Fcommand\nargus\u002Fwrist\u002Fdisplay\u002Fdevice02\u002Ftelemetry\n```\n\nUse wildcards for flexible subscriptions:\n```\nargus\u002F+\u002Ftimer\u002F+\u002Fstate      # All timer states\nargus\u002Fdesk\u002F#               # All desk devices\n+\u002F+\u002F+\u002F+\u002Ftelemetry         # All telemetry\n```\n\n**QoS Selection Guidelines:**\n- QoS 0: High-frequency sensor data, non-critical telemetry\n- QoS 1: Important events, commands, state updates\n- QoS 2: Financial transactions, critical commands\n\nFor comprehensive communication patterns, read:\n```\nreferences\u002Farchitecture-patterns.md\n  - Hub-and-Spoke Topology\n  - Message Broker Design\n  - Topic Naming Conventions\n  - QoS Strategy\n  - Payload Optimization\n```\n\n### 3. Microservices Patterns\n\nApply microservices architecture to IoT backend systems for modularity and scalability.\n\n**Decomposition Strategies:**\n- Service boundaries by device type\n- Service boundaries by business capability\n- Domain-Driven Design (bounded contexts)\n\n**Key Patterns:**\n- API design for device coordination\n- Service discovery mechanisms\n- Inter-service communication (sync vs async)\n- Failure isolation and resilience\n- Container orchestration with Docker\n\n**When to Apply:**\n- Breaking down monolithic IoT backend\n- Scaling specific system components independently\n- Isolating failures to prevent cascading issues\n- Supporting multiple development teams\n- Enabling technology diversity\n\n**Example Decomposition for Argus System:**\n```\nmqtt-broker\u002F           - Mosquitto MQTT broker\ndevice-service\u002F        - Device registration and discovery\ntimer-service\u002F         - Timer logic and state management\nnotification-service\u002F  - Notification delivery\nai-service\u002F            - ML inference (Jetson Nano)\ntelemetry-service\u002F     - Metrics collection and storage\n```\n\n**Implementation Guidance:**\n\nFor detailed microservices patterns and scalability strategies, read:\n```\nreferences\u002Fmicroservices-scalability.md\n```\n\nThis reference covers:\n- Service boundary definition\n- API design patterns (REST, GraphQL, gRPC)\n- Service discovery mechanisms\n- Communication patterns (sync\u002Fasync)\n- Resilience patterns (circuit breaker, bulkhead)\n- Container orchestration\n- Scalability considerations\n- Database sharding\n- Caching strategies\n- Connection pooling\n\n### 4. State Management\n\nImplement robust state synchronization across distributed devices.\n\n**Patterns:**\n- Device state synchronization\n- State machine design for device modes\n- Conflict-Free Replicated Data Types (CRDTs)\n- Event sourcing\n- State recovery after connection loss\n- Idempotent operations\n\n**When to Apply:**\n- Synchronizing state across multiple devices\n- Handling concurrent state updates\n- Recovering from network partitions\n- Implementing device operating modes\n- Ensuring eventual consistency\n\n**State Machine Example (Timer Modes):**\n\nDefine clear state transitions:\n```\nStates: Idle → Working → Break → LongBreak\nEvents: start(), pause(), resume(), complete()\n\nTransitions:\n  Idle + start() → Working\n  Working + complete() → Break\n  Break + complete() → Working (or LongBreak after N cycles)\n```\n\n**Conflict Resolution:**\n\nWhen devices update state concurrently:\n1. Use vector clocks to detect concurrent updates\n2. Apply Last-Write-Wins (LWW) for simple fields\n3. Implement custom merge functions for complex state\n4. Use timestamps as tiebreaker\n\nFor implementation patterns, reference:\n```\nreferences\u002Farchitecture-patterns.md\n  - Eventually Consistent Data Models\n  - Offline-First Design Patterns\n\nreferences\u002Fargus-system.md\n  - State Synchronization Strategy\n  - Conflict Resolution\n```\n\n### 5. Design Patterns for IoT\n\nApply proven design patterns to IoT system implementation.\n\n**Core Patterns:**\n\n**Observer Pattern** - MQTT subscriptions for state changes\n```python\n# Devices publish state changes\n# Services observe via MQTT subscriptions\ntopic: \"device\u002F{id}\u002Fstate\"\nsubscribers: notification-service, telemetry-service, ui-dashboard\n```\n\n**State Pattern** - Device operating modes\n```python\n# Timer device with work\u002Fbreak\u002Fidle states\n# Each state encapsulates mode-specific behavior\nclass WorkState, BreakState, IdleState\n```\n\n**Strategy Pattern** - Different timer modes (Pomodoro, custom, countdown)\n```python\n# Interchangeable algorithms for timer duration calculation\nclass PomodoroStrategy, CustomStrategy, CountdownStrategy\n```\n\n**Factory Pattern** - Device-specific MQTT handlers\n```python\n# Create appropriate handler based on device type\nHandlerFactory.create_handler('timer') → TimerHandler\nHandlerFactory.create_handler('display') → DisplayHandler\n```\n\n**Singleton Pattern** - MQTT broker connection\n```python\n# Single shared connection to MQTT broker\nMQTTConnectionManager.get_instance()\n```\n\n**Publish-Subscribe Pattern** - Core MQTT communication\n```python\n# One-to-many event distribution\nPublisher → MQTT Broker → Multiple Subscribers\n```\n\nFor detailed implementations and examples, read:\n```\nreferences\u002Fdesign-patterns.md\n```\n\nThis reference includes complete code examples for:\n- Observer, State, Strategy, Factory, Singleton patterns\n- Publish-Subscribe, Command, Adapter patterns\n- Proxy and Template Method patterns\n- IoT-specific implementations and use cases\n\n### 6. Scalability Planning\n\nDesign systems that scale from MVP to production loads.\n\n**Scaling Dimensions:**\n- Horizontal vs vertical scaling\n- Load balancing strategies\n- Database sharding for device data\n- Caching strategies (Redis)\n- Message queue sizing\n- Connection pooling\n\n**When to Apply:**\n- Planning for growth beyond initial deployment\n- Optimizing system performance under load\n- Identifying bottlenecks\n- Designing for multi-tenant scenarios\n- Supporting increasing device counts\n\n**Scaling Strategy Template:**\n\n1. **Current Scale (MVP)**: Define baseline (devices, users, messages\u002Fsec)\n2. **Near-Term Scale**: Plan for 10x growth\n3. **Future Scale**: Envision 100x growth\n4. **Bottlenecks**: Identify potential scaling limitations\n5. **Mitigation**: Plan scaling approach for each bottleneck\n\n**Example for Argus System:**\n```\nCurrent: 3 devices, 1 user, single location\nNear-Term: 10 devices, 2 users, multiple rooms\nFuture: 50 devices, 10 users, multiple locations\n\nScaling Strategy:\n- MQTT Broker: Vertical scaling, then clustering\n- Timer Service: Horizontal scaling (stateless)\n- Database: Vertical + read replicas\n- Cache: Redis for shared state\n```\n\nFor comprehensive scalability patterns, read:\n```\nreferences\u002Fmicroservices-scalability.md\n  - Horizontal vs Vertical Scaling\n  - Load Balancing Strategies\n  - Database Sharding\n  - Caching Strategies\n  - Message Queue Sizing\n  - Connection Pooling\n```\n\n### 7. Architecture Decision Records (ADRs)\n\nDocument significant architecture decisions with rationale and trade-offs.\n\n**When to Create ADRs:**\n- Choosing communication protocol (MQTT vs WebSocket vs HTTP)\n- Selecting database technology\n- Deciding on consistency model\n- Adopting new technology or framework\n- Making trade-offs with significant implications\n\n**ADR Structure:**\n1. **Context**: What forces drive this decision?\n2. **Decision**: What are we doing?\n3. **Rationale**: Why is this the right choice?\n4. **Alternatives**: What else was considered?\n5. **Consequences**: What are the trade-offs?\n6. **Implementation Impact**: How does this affect the system?\n\n**Using the ADR Template:**\n\nCopy the ADR template to document decisions:\n```\nassets\u002Fadr-template.md\n```\n\nThe template includes:\n- Complete structure with all required sections\n- Example filled-out ADR (MQTT for Device Communication)\n- Guidance for each section\n- Success metrics and follow-up actions\n\n**Best Practices:**\n- Create ADRs early in the decision process\n- Include multiple alternatives with honest trade-offs\n- Be specific about consequences (positive and negative)\n- Define measurable success metrics\n- Update ADRs as decisions evolve (revision history)\n\n### 8. Architecture Visualization\n\nCreate clear diagrams to communicate system design.\n\n**Diagram Types:**\n\n**System Context Diagram** - High-level view of system and external actors\n**Container Diagram** - System components and their interactions\n**Sequence Diagram** - Message flow for specific scenarios\n**State Diagram** - Device state machines\n**Deployment Diagram** - Physical infrastructure layout\n\n**Using Diagram Templates:**\n\nPlantUML templates are provided for C4 model diagrams:\n```\nassets\u002Fc4-diagram-template.puml\n```\n\nTemplates include:\n- Container diagram (system components)\n- Sequence diagram (message flow)\n- Deployment diagram (infrastructure)\n- State machine diagram (device states)\n- Component diagram (internal structure)\n\n**Generating Diagrams:**\n\nUse PlantUML to render diagrams:\n```bash\n# Install PlantUML\napt install plantuml\n\n# Generate diagram\nplantuml diagram.puml\n```\n\nOnline rendering available at: https:\u002F\u002Fwww.plantuml.com\u002Fplantuml\u002F\n\n**Customization:**\n- Update component names and relationships\n- Adjust styles and colors for device types\n- Add notes for important details\n- Use tags for visual grouping\n\n## Architecture Workflow\n\n### 1. Requirements Analysis\n\nIdentify system requirements and constraints:\n- Functional requirements (what must the system do?)\n- Non-functional requirements (performance, reliability, security)\n- Technical constraints (hardware, connectivity, power)\n- Business constraints (budget, timeline, resources)\n\n### 2. Architecture Design\n\nApply capabilities from this skill:\n\n1. **Choose topology**: Hub-and-spoke, mesh, or hybrid\n2. **Design communication**: Protocol, topic structure, QoS\n3. **Plan state management**: Consistency model, synchronization\n4. **Apply patterns**: Identify relevant design patterns\n5. **Plan for scale**: Anticipate growth and bottlenecks\n6. **Design for failure**: Offline operation, recovery strategies\n\n### 3. Documentation\n\nCreate architecture documentation:\n\n1. **System diagrams**: Use C4 model templates\n2. **ADRs**: Document key decisions\n3. **Communication specs**: Topic structure, message formats\n4. **State machines**: Define device operating modes\n5. **API documentation**: REST\u002FMQTT interface specs\n\n### 4. Implementation\n\nImplement architecture with best practices:\n\n1. **Start with communication**: MQTT broker and topic structure\n2. **Implement state management**: Local state + synchronization\n3. **Add resilience**: Offline-first, retry logic, circuit breakers\n4. **Instrument for observability**: Logging, metrics, monitoring\n5. **Test edge cases**: Network failures, concurrent updates, scale\n\n### 5. Iteration and Evolution\n\nContinuously improve architecture:\n\n1. **Monitor performance**: Latency, throughput, resource usage\n2. **Validate decisions**: Review ADRs against actual metrics\n3. **Identify bottlenecks**: Profile and optimize\n4. **Plan evolution**: Create ADRs for significant changes\n5. **Refactor incrementally**: Avoid big-bang rewrites\n\n## Argus System as Reference Implementation\n\nThe Argus productivity tracking system serves as a concrete reference implementation demonstrating these architecture principles in practice.\n\n**System Overview:**\n- Multiple devices (Presto, T-Embed, Stream Deck, Android)\n- Hub-and-spoke topology with Jetson Nano as central hub\n- MQTT-based event-driven architecture\n- Offline-first design with eventual consistency\n- Microservices backend on Jetson Nano\n\n**Key Architectural Decisions:**\n- MQTT for device communication (low latency, pub\u002Fsub)\n- Eventually consistent state (AP in CAP theorem)\n- Edge processing for real-time responses\n- Hub for coordination and intelligence\n\n**Learning from Argus:**\n\nStudy the complete system architecture:\n```\nreferences\u002Fargus-system.md\n```\n\nThis reference provides:\n- Complete system architecture diagram\n- Component details for each device\n- Communication patterns and topic structure\n- State synchronization strategy\n- Failure modes and recovery\n- Performance characteristics\n- Security considerations\n- Scalability path from MVP to production\n\nUse Argus as a template for similar distributed IoT systems.\n\n## Resources\n\n### references\u002F\n\nIn-depth documentation loaded into context as needed:\n\n- **architecture-patterns.md**: Distributed systems patterns, communication architecture, consistency models, offline-first design\n- **microservices-scalability.md**: Microservices decomposition, API design, resilience patterns, scaling strategies\n- **design-patterns.md**: Implementation patterns with code examples (Observer, State, Strategy, Factory, Singleton, Pub\u002FSub)\n- **argus-system.md**: Complete reference implementation with architecture diagrams, communication patterns, and implementation details\n\n### assets\u002F\n\nTemplates for architecture documentation and visualization:\n\n- **adr-template.md**: Architecture Decision Record template with complete example (MQTT decision)\n- **c4-diagram-template.puml**: PlantUML templates for system diagrams (container, sequence, deployment, state, component)\n\n## Architecture Principles\n\nFollow these principles when designing IoT systems:\n\n1. **Loose Coupling**: Devices and services operate independently through well-defined interfaces\n2. **High Cohesion**: Related functionality grouped together in components or services\n3. **Fail-Safe**: Graceful degradation when components fail or network partitions occur\n4. **Observability**: Comprehensive logging, metrics, and monitoring for debugging and optimization\n5. **Maintainability**: Clear module boundaries, documentation, and testability\n6. **Performance**: Meet real-time constraints with appropriate processing location and communication patterns\n7. **Security**: Defense in depth with authentication, authorization, and encryption where appropriate\n\n## Getting Started\n\nTo apply this skill to a new project:\n\n1. **Define requirements**: Identify functional and non-functional requirements\n2. **Study Argus**: Review the reference implementation for patterns\n3. **Choose topology**: Select appropriate communication architecture\n4. **Design communication**: Create MQTT topic structure and message formats\n5. **Plan state management**: Define consistency model and synchronization approach\n6. **Create ADRs**: Document key architecture decisions\n7. **Generate diagrams**: Use C4 templates to visualize architecture\n8. **Implement incrementally**: Start with core communication, add features iteratively\n9. **Monitor and evolve**: Instrument system, gather metrics, refine architecture\n\nFor any architecture questions or trade-offs, consult the relevant reference documentation and apply the patterns and principles outlined in this skill.\n",{"name":5,"description":7},"main","7850740bd837adb32f0a109ab2af82482196c6f2","skills\u002Frghamilton3-dotfiles\u002Fdot_claude\u002Fskills\u002Fiot-system-architect\u002Fiot-system-architect",1,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills","https:\u002F\u002Fzturnsgo.com","https:\u002F\u002Fgithub.com\u002Fshengdabai","https:\u002F\u002Fzturnsgo.com\u002F","AI × education creator — producer, not consumer. Taught 6,000+ learners; shipping learning tools & daily essays with Claude Code, practicing @xiaolai's way 🥋","2026-11-01 21:28:23",{"source":8,"skillName":5,"commands":68,"prompt":78,"zipAvailable":79},[69,72,75],{"tool":70,"command":71},"npx","npx skills add shengdabai\u002FTony-Claude-Code-Skills --skill iot-system-architect",{"tool":73,"command":74},"bunx","bunx skills add shengdabai\u002FTony-Claude-Code-Skills --skill iot-system-architect",{"tool":76,"command":77},"pnpm","pnpm dlx skills add shengdabai\u002FTony-Claude-Code-Skills --skill iot-system-architect","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Frghamilton3-dotfiles\u002Fdot_claude\u002Fskills\u002Fiot-system-architect\u002Fiot-system-architect\u002FSKILL.md",true,[81,87,91,97,101,105,109],{"path":82,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":85,"sourceHtmlUrl":86},"assets\u002Fadr-template.md","ASSET","资产文件",10104,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Frghamilton3-dotfiles\u002Fdot_claude\u002Fskills\u002Fiot-system-architect\u002Fiot-system-architect\u002Fassets\u002Fadr-template.md",{"path":88,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":89,"sourceHtmlUrl":90},"assets\u002Fc4-diagram-template.puml",8570,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Frghamilton3-dotfiles\u002Fdot_claude\u002Fskills\u002Fiot-system-architect\u002Fiot-system-architect\u002Fassets\u002Fc4-diagram-template.puml",{"path":92,"resourceType":93,"resourceTypeDesc":94,"sizeBytes":95,"sourceHtmlUrl":96},"references\u002Farchitecture-patterns.md","REFERENCE","参考文档",11757,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Frghamilton3-dotfiles\u002Fdot_claude\u002Fskills\u002Fiot-system-architect\u002Fiot-system-architect\u002Freferences\u002Farchitecture-patterns.md",{"path":98,"resourceType":93,"resourceTypeDesc":94,"sizeBytes":99,"sourceHtmlUrl":100},"references\u002Fargus-system.md",12793,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Frghamilton3-dotfiles\u002Fdot_claude\u002Fskills\u002Fiot-system-architect\u002Fiot-system-architect\u002Freferences\u002Fargus-system.md",{"path":102,"resourceType":93,"resourceTypeDesc":94,"sizeBytes":103,"sourceHtmlUrl":104},"references\u002Fdesign-patterns.md",19469,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Frghamilton3-dotfiles\u002Fdot_claude\u002Fskills\u002Fiot-system-architect\u002Fiot-system-architect\u002Freferences\u002Fdesign-patterns.md",{"path":106,"resourceType":93,"resourceTypeDesc":94,"sizeBytes":107,"sourceHtmlUrl":108},"references\u002Fmicroservices-scalability.md",14695,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Frghamilton3-dotfiles\u002Fdot_claude\u002Fskills\u002Fiot-system-architect\u002Fiot-system-architect\u002Freferences\u002Fmicroservices-scalability.md",{"path":110,"resourceType":111,"resourceTypeDesc":112,"sizeBytes":113,"sourceHtmlUrl":114},"scripts\u002F.keep","SCRIPT","脚本",0,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Frghamilton3-dotfiles\u002Fdot_claude\u002Fskills\u002Fiot-system-architect\u002Fiot-system-architect\u002Fscripts\u002F.keep",[116,133,162,187,209,229],{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":125,"publishedAt":52},"01M70P17DAD4C1C47NPH6A96EM","xiaolai-methodology","以李笑来(Li Xiaolai)的思考方式、方法论与表达风格,为用户做全方位 1-on-1 教练指导,覆盖创业、赚钱、投资、学习、自学、读书写作、用 AI、以及人生心态与自我管理。当用户提到 \"李笑来\"、\"笑来\"、\"笑来老师\"、\"扮演李笑来\"、\"找笑来聊聊\"、\"笑来怎么看\"、\"xiaolai\"、\"把时间当作朋友\"、\"通往财富自由之路\"、\"定投改变命运\"、\"韭菜的自我修养\"、\"自学是门手艺\"、\"让时间陪你慢慢变富\"、\"七年就是一辈子\"、\"元认知\"、\"活在未来\"、\"复利\u002F长期主义\"、\"践行\"、\"痴迷改进\"、\"个人商业模式\u002F出售时间\"、\"睡后收入\"、\"定投\"、\"财富自由\"、\"操作系统升级\"、\"最少必要知识\"、\"北极星提示词\"、\"用 AI 该怎么学\u002F思考\" 等任一触发词,或当用户带着关于创业\u002F赚钱\u002F投资\u002F学习\u002F职业\u002F重大人生决策的困惑、希望被人用笑来式的「逻辑 + 大白话 + 类比 + 重新定义 + 践行导向」来点醒和指导时,自动进入李笑来教练模式。","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fxiaolai-methodology\u002FSKILL.md",[122],{"categoryNo":123,"categoryName":124,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",[126,127,128,129,130,131,132],"methodology","xiaolai","xiaolai methodology","朋友","投资","writing","收入",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":143,"publishedAt":52},"01M70P13NB9YP7ACJR1S861CDS","zread","Produce and consume a wiki-style knowledge base for a code repository via the `zread` CLI and its on-disk output under `.\u002F.zread\u002Fwiki\u002F`. Use this skill whenever the user wants to understand, onboard onto, explore, summarize, map, or get an overview of an unfamiliar codebase; asks for architecture docs, a project wiki, a repo walkthrough, module\u002Fpackage explanations, or \"what does this repo do\"; wants to generate, regenerate, resume, browse, or serve code documentation locally; or mentions zread \u002F zread.ai directly. Also use it proactively before diving into a large unknown repo — if `.\u002F.zread\u002Fwiki\u002Fcurrent` exists, read the generated pages instead of crawling source file-by-file; if it doesn't, consider offering to run `zread generate`. The trigger is the intent (understand a codebase through generated docs), not the literal word \"zread\".","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fzread\u002FSKILL.md",[139,140],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":141,"categoryName":142,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000030","开发工程师",[135,144,145,146,147,148,149,150,151,152,153,154,155,156,157,158,51,159,160,161],"knowledge","wiki","explore","walkthrough","project","get","knowledge base","run","generate","intent","cli","map","documentation","project wiki","disk","code","unknown","generated",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":172,"publishedAt":52},"01M70P10S4SWMZQ8BJAFBFDRW3","youtube","Launch the YouTube Creator Agent to auto-generate videos.\nUse when: user types \u002Fyoutube, wants to create YouTube videos,\ngenerate video content, or upload to YouTube.\nKeywords: youtube, video, 视频, 创作视频, 发布视频","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fyoutube\u002FSKILL.md",[168,169],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":170,"categoryName":171,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000036","内容创作者",[164,173,174,175,176,177,178,179,152,180,181,182,38,47,183,184,185,186],"user","content","视频","creator","generate video","videos","launch","video content","create","upload","auto","types","Video","创作",{"skillNo":188,"name":189,"nameZh":6,"description":190,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":191,"categories":192,"keywords":194,"publishedAt":52},"01M70P0YE95D8BACZCGV8BK90K","youtube-script-sync","Sync, update, or optimize Tony's GetNote knowledge base `Youtube视频逐字稿` by turning each parent recording or first-person idea note into an idempotent child note containing a directly recordable YouTube long-video or Shorts script. Use when the user says “更新\u002F同步\u002F优化 Youtube视频逐字稿知识库”, or says “更新\u002F同步\u002F优化该知识库” while this knowledge base is the active context.","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fyoutube-script-sync\u002FSKILL.md",[193],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[195,196,164,197,198,185,199,200,201,202,203,204,205,206,150,207,38,47,144,208],"sync","script","youtube script sync","recording","shorts","first","base","person","update","active","child","optimize","idempotent","long",{"skillNo":210,"name":211,"nameZh":6,"description":212,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":213,"categories":214,"keywords":219,"publishedAt":52},"01M70P0WMV5XT0EEC0N445PW07","writing-skills","How to write SKILL.md files that trigger reliably and teach effectively. Use when creating, improving, or reviewing Claude Code skills.","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fxiaolai\u002Fnlpm\u002Fskills\u002Fnlpm\u002Fwriting-skills\u002FSKILL.md",[215,216,217,218],{"categoryNo":123,"categoryName":124,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":141,"categoryName":142,"taxonomyType":29,"taxonomyTypeDesc":30},{"categoryNo":170,"categoryName":171,"taxonomyType":29,"taxonomyTypeDesc":30},[220,131,221,222,223,224,159,38,47,225,226,227,228],"writing skills","how","teach","write skill","write","claude code skills","files","how to","trigger",{"skillNo":230,"name":231,"nameZh":6,"description":232,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":233,"categories":234,"keywords":237,"publishedAt":52},"01M70P0SJFR4YVJQBGMHKGSKXT","writing-rules","How to write .claude\u002Frules\u002F files that Claude actually follows. Use when creating, improving, or reviewing project rules.","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fxiaolai\u002Fnlpm\u002Fskills\u002Fnlpm\u002Fwriting-rules\u002FSKILL.md",[235,236],{"categoryNo":123,"categoryName":124,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":170,"categoryName":171,"taxonomyType":29,"taxonomyTypeDesc":30},[238,131,239,148,240,226,38,221,224,47,227],"Rules","writing rules","project rules"]