Skill

domain-iot:iot-cloud-integration

Integrates IoT devices with AWS IoT Core, Azure IoT Hub, and Google Cloud IoT. Covers device shadows/twins, rules engines, edge runtimes, data pipelines from ingestion to analytics, and multi-cloud strategies.

AWS

npx claudepluginhub rnavarych/alpha-engineer --plugin domain-iot

Popularity

Parent stars

Parent forks

Invocation

How this skill is triggered — by the user, by Claude, or both

Slash command

/domain-iot:iot-cloud-integration

User invocable

Model invocable

Inline context

Default effort

Tool Access

This skill is limited to the following tools:

ReadGrepGlobBash

Context Preview

The summary Claude sees in its skill listing — used to decide when to auto-load this skill

- Integrating devices with AWS IoT Core, Azure IoT Hub, or GCP after the Cloud IoT Core deprecation

Supporting Files

references/aws-iot-core.mdreferences/azure-iot-hub.mdreferences/gcp-and-pipeline-design.md

SKILL.md

28 lines · ~524 tokens

Similar Skills

domain-iot:edge-computing

Provides IoT edge computing patterns including gateway architecture, edge vs cloud processing, ML inference on edge hardware, K3s/Azure IoT Edge containers, data sync, and offline resilience.

3 files4 tools

domain-iot

1.2k

Guides IoT app development with Rust, covering offline-first design, MQTT communication, power management, and device security constraints.

rust-skills

oci-iot-digital-twin-engineer

Designs and operates OCI IoT digital twin adapters, models, instances, relationships, and domain context. Use for digital twin topology design, lifecycle changes, integration review, and safe model/relationship changes.

4 files3 tools

vanguard-frontier-agentic

Stats

LanguageShell

Parent stars13

Parent forks1

MaintenanceGood

Last CommitMar 3, 2026

Actions

View Source View Plugin View on GitHub View README

Help us improve

Share bugs, ideas, or general feedback.

Stats

Actions

Help us improve

Share bugs, ideas, or general feedback.

IoT Cloud Integration

When to use

Integrating devices with AWS IoT Core, Azure IoT Hub, or GCP after the Cloud IoT Core deprecation

Configuring rules engines to route device messages to downstream services

Designing hot/warm/cold data pipeline architectures for telemetry ingestion

Setting up Device Provisioning Service (DPS) for zero-touch at scale

Evaluating multi-cloud trade-offs or avoiding vendor lock-in

Choosing between Timestream, Azure Data Explorer, BigQuery, and Bigtable for IoT storage

Core principles

Decouple ingestion from processing — message broker or queue between device gateway and any processor; never direct device-to-database writes

Schema validation at the ingestion boundary — malformed payloads caught at the door, not discovered three hops later in a dashboard

Branch early for latency tiers — hot path (real-time alerts), warm path (dashboards), cold path (archive) forked at the rules engine, not bolted on later

Idempotent consumers everywhere — IoT protocols guarantee at-least-once; your processors must handle duplicates gracefully

Open formats in storage — Parquet/Avro in object storage makes the next cloud migration a query problem, not a rewrite

Reference Files

references/aws-iot-core.md — Device Gateway, Message Broker, Device Shadow, Rules Engine SQL, IoT Greengrass edge runtime, AWS data pipeline pattern

references/azure-iot-hub.md — D2C/C2D messaging, Device Twins, DPS allocation policies, IoT Edge modules, message routing config, Azure data pipeline pattern

references/gcp-and-pipeline-design.md — GCP post-deprecation stack (Pub/Sub, Dataflow, BigQuery, Bigtable), generic platform-agnostic pipeline pattern, multi-cloud considerations

IoT Cloud Integration

When to use

Integrating devices with AWS IoT Core, Azure IoT Hub, or GCP after the Cloud IoT Core deprecation
Configuring rules engines to route device messages to downstream services
Designing hot/warm/cold data pipeline architectures for telemetry ingestion
Setting up Device Provisioning Service (DPS) for zero-touch at scale
Evaluating multi-cloud trade-offs or avoiding vendor lock-in
Choosing between Timestream, Azure Data Explorer, BigQuery, and Bigtable for IoT storage

Core principles

Decouple ingestion from processing — message broker or queue between device gateway and any processor; never direct device-to-database writes
Schema validation at the ingestion boundary — malformed payloads caught at the door, not discovered three hops later in a dashboard
Branch early for latency tiers — hot path (real-time alerts), warm path (dashboards), cold path (archive) forked at the rules engine, not bolted on later
Idempotent consumers everywhere — IoT protocols guarantee at-least-once; your processors must handle duplicates gracefully
Open formats in storage — Parquet/Avro in object storage makes the next cloud migration a query problem, not a rewrite

Reference Files

references/aws-iot-core.md — Device Gateway, Message Broker, Device Shadow, Rules Engine SQL, IoT Greengrass edge runtime, AWS data pipeline pattern
references/azure-iot-hub.md — D2C/C2D messaging, Device Twins, DPS allocation policies, IoT Edge modules, message routing config, Azure data pipeline pattern
references/gcp-and-pipeline-design.md — GCP post-deprecation stack (Pub/Sub, Dataflow, BigQuery, Bigtable), generic platform-agnostic pipeline pattern, multi-cloud considerations

domain-iot:iot-cloud-integration

Popularity

Invocation

Tool Access

Context Preview

Supporting Files

SKILL.md

Similar Skills

Help us improve

Help us improve

Find plugins for your project

domain-iot:iot-cloud-integration

Popularity

Invocation

Tool Access

Context Preview

Supporting Files

SKILL.md

IoT Cloud Integration

When to use

Core principles

Reference Files

Similar Skills

Help us improve

IoT Cloud Integration

When to use

Core principles

Reference Files