Skill

domain-iot:digital-twin

Guides IoT digital twin design: state/simulation modeling, real-time sync, predictive maintenance, what-if scenarios, 3D visualization, Azure Digital Twins, AWS IoT TwinMaker.

AWS

Azure

infrastructure

ai-ml

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:digital-twin

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

- Designing a digital twin architecture from scratch (shadow vs twin vs simulation)

Supporting Files

references/predictive-maintenance.mdreferences/sync-and-scenarios.mdreferences/twin-modeling.mdreferences/visualization-and-platforms.md

SKILL.md

29 lines · ~548 tokens

Similar 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

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.

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

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.

Digital Twin Patterns

When to use

Designing a digital twin architecture from scratch (shadow vs twin vs simulation)

Modeling twin ontologies with DTDL, RealEstateCore, or custom schemas

Implementing device-to-twin and twin-to-device synchronization pipelines

Building predictive maintenance with RUL models and anomaly detection

Running what-if scenario analysis in a sandboxed twin environment

Selecting Azure Digital Twins, AWS IoT TwinMaker, or open-source alternatives

Core principles

Maturity determines complexity — start with a digital shadow (read-only), graduate to bidirectional twin only when control use cases are proven

Graph topology mirrors physical topology — site → building → floor → room → device; queries follow the physical hierarchy

Eventual consistency is fine for monitoring; not for control — sub-second twin updates matter only in closed-loop control scenarios

Staleness thresholds are a first-class feature — a twin that hasn't updated in 5x its expected interval is broken, not just quiet

Sandbox before touching the physical asset — all what-if scenarios run on a cloned twin state, never against the live twin

Reference Files

references/twin-modeling.md — maturity levels, state-based vs simulation-based twins, DTDL ontology design, example twin state document

references/sync-and-scenarios.md — device-to-twin and twin-to-device sync flows, consistency model, staleness handling, what-if sandbox implementation

references/predictive-maintenance.md — RUL prediction approach, baseline modeling, degradation tracking, ML model selection (Isolation Forest, LSTM, Weibull)

references/visualization-and-platforms.md — 3D visualization options (Three.js, BIM, Unreal), Azure Digital Twins, AWS IoT TwinMaker, Eclipse Ditto, FIWARE

Digital Twin Patterns

When to use

Designing a digital twin architecture from scratch (shadow vs twin vs simulation)
Modeling twin ontologies with DTDL, RealEstateCore, or custom schemas
Implementing device-to-twin and twin-to-device synchronization pipelines
Building predictive maintenance with RUL models and anomaly detection
Running what-if scenario analysis in a sandboxed twin environment
Selecting Azure Digital Twins, AWS IoT TwinMaker, or open-source alternatives

Core principles

Maturity determines complexity — start with a digital shadow (read-only), graduate to bidirectional twin only when control use cases are proven
Graph topology mirrors physical topology — site → building → floor → room → device; queries follow the physical hierarchy
Eventual consistency is fine for monitoring; not for control — sub-second twin updates matter only in closed-loop control scenarios
Staleness thresholds are a first-class feature — a twin that hasn't updated in 5x its expected interval is broken, not just quiet
Sandbox before touching the physical asset — all what-if scenarios run on a cloned twin state, never against the live twin

Reference Files

references/twin-modeling.md — maturity levels, state-based vs simulation-based twins, DTDL ontology design, example twin state document
references/sync-and-scenarios.md — device-to-twin and twin-to-device sync flows, consistency model, staleness handling, what-if sandbox implementation
references/predictive-maintenance.md — RUL prediction approach, baseline modeling, degradation tracking, ML model selection (Isolation Forest, LSTM, Weibull)
references/visualization-and-platforms.md — 3D visualization options (Three.js, BIM, Unreal), Azure Digital Twins, AWS IoT TwinMaker, Eclipse Ditto, FIWARE

domain-iot:digital-twin

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:digital-twin

Popularity

Invocation

Tool Access

Context Preview

Supporting Files

SKILL.md

Digital Twin Patterns

When to use

Core principles

Reference Files

Similar Skills

Help us improve

Digital Twin Patterns

When to use

Core principles

Reference Files