+- Arduino docs home:
+- Getting started path:
+- Arduino IDE usage:
+- Arduino language reference:
+- Arduino programming reference overview:
+- Arduino memory guide:
+- Arduino debugging fundamentals:
+- Arduino low-power design guide:
+- Arduino communication protocols index:
+- Arduino style guide for libraries:
+
+## Firmware Best Practices
+
+- Keep the `loop()` non-blocking; avoid long `delay()` usage in production logic.
+- Use `millis()`-based scheduling for periodic tasks.
+- Budget SRAM explicitly and avoid dynamic allocation in hot paths.
+- Validate sensor ranges and provide safe defaults for invalid readings.
+- Add startup self-checks and periodic health heartbeat messages.
+- Version the payload schema and firmware version in every telemetry stream.
+- Implement retry with exponential backoff and jitter for network operations.
+- Store credentials outside source code and rotate them according to policy.
+
+## Hardware and Power Best Practices
+
+- Document voltage levels, pin mapping, and current limits per peripheral.
+- Design for brownout and power fluctuation scenarios.
+- Use watchdog and safe recovery behavior where available.
+- Plan low-power modes for battery deployments and validate wake cycles.
+
+## Integration Best Practices for Azure IoT
+
+- Prefer secure transports (MQTT over TLS) and per-device identity.
+- Define idempotent upstream processing for duplicate message scenarios.
+- Include device health metrics (uptime, reset reason, RSSI where applicable).
+- Validate offline buffering bounds to avoid uncontrolled memory growth.
diff --git a/skills/azure-architecture-autopilot/README.md b/skills/azure-architecture-autopilot/README.md
new file mode 100644
index 00000000..20cb000e
--- /dev/null
+++ b/skills/azure-architecture-autopilot/README.md
@@ -0,0 +1,188 @@
+Azure Architecture Autopilot
+
+
+ Design → Diagram → Bicep → Deployment - all from natural language
+
+
+
+ 
+ 
+ 
+ 
+ 
+
+
+
+ Azure Architecture Autopilot designs Azure infrastructure from natural language,
+ generates interactive diagrams, produces modular Bicep templates, and deploys - all through conversation.
+ It also scans existing resources, visualizes them as architecture diagrams, and refines them on the fly.
+
+
+
+
+ 
+
+
+
+ ↑ Auto-generated interactive diagram — drag, zoom, click for details, export to PNG
+
+
+
+ 
+
+ 
+
+
+
+ ↑ Real Azure resources deployed from the generated Bicep templates
+
+
+
+ How It Works •
+ Features •
+ Prerequisites •
+ Usage •
+ Architecture
+
+
+---
+
+## 🔄 How It Works
+
+```
+Path A: "Build me a RAG chatbot on Azure"
+ ↓
+ 🎨 Design → 🔧 Bicep → ✅ Review → 🚀 Deploy
+
+Path B: "Analyze my current Azure resources"
+ ↓
+ 🔍 Scan → 🎨 Modify → 🔧 Bicep → ✅ Review → 🚀 Deploy
+```
+
+| Phase | Role | What Happens |
+|:-----:|------|--------------|
+| **0** | 🔍 Scanner | Scans existing Azure resources via `az` CLI → auto-generates architecture diagram |
+| **1** | 🎨 Advisor | Interactive design through conversation — asks targeted questions with smart defaults |
+| **2** | 🔧 Generator | Produces modular Bicep: `main.bicep` + `modules/*.bicep` + `.bicepparam` |
+| **3** | ✅ Reviewer | Compiles with `az bicep build`, checks security & best practices |
+| **4** | 🚀 Deployer | `validate` → `what-if` → preview diagram → `create` (5-step mandatory sequence) |
+
+---
+
+## ✨ Features
+
+| | Feature | Description |
+|---|---------|-------------|
+| 📦 | **Zero Dependencies** | 605+ Azure icons bundled — no `pip install`, works offline |
+| 🎨 | **Interactive Diagrams** | Drag-and-drop HTML with zoom, click details, PNG export |
+| 🔍 | **Resource Scanning** | Analyze existing Azure infra → auto-generate architecture diagrams |
+| 💬 | **Natural Language** | *"It's slow"*, *"reduce costs"*, *"add security"* → guided resolution |
+| 📊 | **Live Verification** | API versions, SKUs, model availability fetched from MS Docs in real-time |
+| 🔒 | **Secure by Default** | Private Endpoints, RBAC, managed identity — no secrets in files |
+| ⚡ | **Parallel Preload** | Next-phase info loaded while waiting for user input |
+| 🌐 | **Multi-Language** | Auto-detects user language — responds in English, Korean, or any language |
+
+---
+
+## ⚙️ Prerequisites
+
+| Tool | Required | Install |
+|------|:--------:|---------|
+| **GitHub Copilot CLI** | ✅ | [Install guide](https://docs.github.com/copilot/concepts/agents/about-copilot-cli) |
+| **Azure CLI** | ✅ | `winget install Microsoft.AzureCLI` / `brew install azure-cli` |
+| **Python 3.10+** | ✅ | `winget install Python.Python.3.12` / `brew install python` |
+
+> No additional packages required — the diagram engine is bundled in `scripts/`.
+
+### 🤖 Recommended Models
+
+| | Models | Notes |
+|---|--------|-------|
+| 🏆 **Best** | Claude Opus 4.5 / 4.6 | Most reliable for all 5 phases |
+| ✅ **Recommended** | Claude Sonnet 4.5 / 4.6 | Best cost-performance balance |
+| ⚠️ **Minimum** | Claude Sonnet 4, GPT-5.1+ | May skip steps in complex architectures |
+
+---
+
+## 🚀 Usage
+
+### Path A — Build new infrastructure
+
+```
+"Build a RAG chatbot with Foundry and AI Search"
+"Create a data platform with Databricks and ADLS Gen2"
+"Deploy Fabric + ADF pipeline with private endpoints"
+"Set up a microservices architecture with AKS and Cosmos DB"
+```
+
+### Path B — Analyze & modify existing resources
+
+```
+"Analyze my current Azure infrastructure"
+"Scan rg-production and show me the architecture"
+"What resources are in my subscription?"
+```
+
+Then modify through conversation:
+```
+"Add 3 VMs to this architecture"
+"The Foundry endpoint is slow — what can I do?"
+"Reduce costs — downgrade AI Search to Basic"
+"Add private endpoints to all services"
+```
+
+### 📂 Output Structure
+
+```
+/
+├── 00_arch_current.html ← Scanned architecture (Path B)
+├── 01_arch_diagram_draft.html ← Design diagram
+├── 02_arch_diagram_preview.html ← What-if preview
+├── 03_arch_diagram_result.html ← Deployment result
+├── main.bicep ← Orchestration
+├── main.bicepparam ← Parameter values
+└── modules/
+ └── *.bicep ← Per-service modules
+```
+
+---
+
+## 📁 Architecture
+
+```
+SKILL.md ← Lightweight router (~170 lines)
+│
+├── scripts/ ← Embedded diagram engine
+│ ├── generator.py ← Interactive HTML generator
+│ ├── icons.py ← 605+ Azure icons (Base64 SVG)
+│ └── cli.py ← CLI entry point
+│
+└── references/ ← Phase instructions + patterns
+ ├── phase0-scanner.md ← 🔍 Resource scanning
+ ├── phase1-advisor.md ← 🎨 Architecture design
+ ├── bicep-generator.md ← 🔧 Bicep generation
+ ├── bicep-reviewer.md ← ✅ Code review
+ ├── phase4-deployer.md ← 🚀 Deployment pipeline
+ ├── service-gotchas.md ← Required properties & PE mappings
+ ├── azure-common-patterns.md ← Security & naming patterns
+ ├── azure-dynamic-sources.md ← MS Docs URL registry
+ ├── architecture-guidance-sources.md
+ └── ai-data.md ← AI/Data service domain pack
+```
+
+> **Self-contained** — `SKILL.md` is a lightweight router. All phase logic lives in `references/`. The diagram engine is embedded in `scripts/` with no external dependencies.
+
+---
+
+## 📊 Supported Services (70+ types)
+
+All Azure services supported. AI/Data services have optimized templates; others are auto-looked up from MS Docs.
+
+**Key types:** `ai_foundry` · `openai` · `ai_search` · `storage` · `adls` · `keyvault` · `fabric` · `databricks` · `aks` · `vm` · `app_service` · `function_app` · `cosmos_db` · `sql_server` · `postgresql` · `mysql` · `synapse` · `adf` · `apim` · `service_bus` · `logic_apps` · `event_grid` · `event_hub` · `container_apps` · `app_insights` · `log_analytics` · `firewall` · `front_door` · `load_balancer` · `expressroute` · `sentinel` · `redis` · `iot_hub` · `digital_twins` · `signalr` · `acr` · `bastion` · `vpn_gateway` · `data_explorer` · `document_intelligence` ...
+
+
+---
+
+## 📄 License
+
+MIT © [Jeonghoon Lee](https://github.com/whoniiii)
diff --git a/skills/azure-smart-city-iot-solution-builder/SKILL.md b/skills/azure-smart-city-iot-solution-builder/SKILL.md
new file mode 100644
index 00000000..79b20041
--- /dev/null
+++ b/skills/azure-smart-city-iot-solution-builder/SKILL.md
@@ -0,0 +1,156 @@
+---
+name: azure-smart-city-iot-solution-builder
+description: 'Design and plan end-to-end Azure IoT and Smart City solutions: requirements, architecture, security, operations, cost, and a phased delivery plan with concrete implementation artifacts.'
+---
+
+# Azure Smart City IoT Solution Builder
+
+Use this skill to rebuild and standardize a complete workflow for Azure IoT and Smart City solutions.
+
+## When to use it
+
+Use this skill when the user asks for things like:
+
+- "I want to build an IoT solution on Azure"
+- "Smart City architecture for traffic, lighting, or waste"
+- "How do I connect devices, analytics, and alerts?"
+- "I need a roadmap and backlog for an urban platform"
+
+## Objectives
+
+- Convert a high-level idea into a deployable architecture.
+- Reuse existing Azure-focused skills whenever possible.
+- Produce concrete artifacts the team can implement.
+
+## Workflow
+
+### 0) Mandatory documentation review (before any architecture)
+
+Before proposing architecture or technology decisions that involve edge computing, review Azure IoT Edge documentation first:
+
+- https://learn.microsoft.com/azure/iot-edge/
+
+Minimum pages to review:
+
+- What is Azure IoT Edge
+- Runtime architecture
+- Supported systems
+- Version history/release notes
+- Relevant Linux/Windows quickstarts for the scenario
+
+If documentation cannot be consulted, state this explicitly and continue with clearly marked assumptions.
+
+### 1) Scope and constraints
+
+Collect and confirm:
+
+- City domain: mobility, parking, air quality, water, energy, public safety, waste, etc.
+- Scale: number of devices, telemetry frequency, retention, regions.
+- Latency and availability objectives.
+- Regulatory and privacy constraints.
+- Existing systems to integrate (SCADA, GIS, ERP, ticketing, APIs).
+
+### 2) Capability map
+
+Split the platform into layers:
+
+- Device and edge: onboarding, identity, firmware, OTA, edge processing.
+- Ingestion and messaging: command and control, event routing, buffering.
+- Data and analytics: hot path vs cold path, dashboards, historical analysis.
+- Operations: observability, incident flow, SLOs.
+- Governance: RBAC, secrets, policies, network isolation.
+
+### 3) Azure service selection (reference)
+
+- Device connectivity: Azure IoT Hub, Azure IoT Operations, IoT Edge.
+- Event streaming: Event Hubs, Service Bus, Event Grid.
+- Storage: Blob Storage, Data Lake, Cosmos DB, SQL.
+- Analytics: Azure Data Explorer, Stream Analytics, Fabric/Synapse.
+- APIs and applications: API Management, App Service, Container Apps, Functions.
+- Monitoring: Azure Monitor, Application Insights, Log Analytics.
+- Security: Key Vault, Defender for IoT, Private Endpoints, Managed Identity.
+
+### 4) Non-functional design
+
+Define and document:
+
+- Reliability model (zones/regions, retries, dead-letter handling, replay).
+- Security controls (zero trust, encryption, secret rotation, least privilege).
+- Cost controls (retention tiers, rightsizing, autoscaling, workload scheduling).
+- Data lifecycle (raw, curated, aggregated, archived).
+
+### 5) Delivery plan
+
+Create a phased execution:
+
+- Phase 1: Pilot district or single use case.
+- Phase 2: Multi-domain integration.
+- Phase 3: City-scale rollout and optimization.
+
+For each phase, include:
+
+- Exit criteria
+- Dependencies
+- Risks and mitigations
+- KPI set
+
+## Reuse other skills first
+
+There are two sources of skills:
+
+- Runtime-provided skills (external to this repository): only available when the Copilot host environment exposes them.
+- Local repository skills (this repository): available as local files under `skills/`.
+
+### Runtime-provided Azure skills (optional)
+
+If they are available in the execution environment, delegate to these specialized skills for deeper guidance:
+
+- `azure-kubernetes`
+- `azure-messaging`
+- `azure-observability`
+- `azure-storage`
+- `azure-rbac`
+- `azure-cost`
+- `azure-validate`
+- `azure-deploy`
+
+### Local repository alternatives (use in this repo)
+
+When runtime skills are not available, prioritize existing local skills in this repository:
+
+- `azure-architecture-autopilot` for architecture generation and refinement.
+- `azure-resource-visualizer` for resource relationship diagrams.
+- `azure-role-selector` for role selection guidance.
+- `az-cost-optimize` and `azure-pricing` for cost and pricing analysis.
+- `azure-deployment-preflight` for pre-deployment checks.
+- `appinsights-instrumentation` for telemetry instrumentation patterns.
+
+If no specialized skill is available, continue with this skill and keep assumptions explicit.
+
+## Required output artifacts
+
+Always provide these outputs:
+
+1. Smart City solution summary (scope, assumptions, constraints).
+2. Reference architecture (components and data flow).
+3. Security and governance checklist.
+4. Cost and scaling strategy.
+5. Phased implementation backlog (epics and milestones).
+
+## Output template
+
+Use this response structure:
+
+1. Context and objectives
+2. Proposed architecture
+3. Technology decisions and trade-offs
+4. Security, operations, and cost controls
+5. Phased implementation plan
+6. Risks and open questions
+
+## Guidelines
+
+- Do not jump to deployment before validating prerequisites.
+- Do not recommend single-region production for critical city workloads.
+- Do not omit operational ownership (who handles incidents, SLAs, change windows).
+- Clearly separate assumptions from confirmed facts.
diff --git a/skills/azure-smart-city-iot-solution-builder/references/smart-city-solution-template.md b/skills/azure-smart-city-iot-solution-builder/references/smart-city-solution-template.md
new file mode 100644
index 00000000..80126bdf
--- /dev/null
+++ b/skills/azure-smart-city-iot-solution-builder/references/smart-city-solution-template.md
@@ -0,0 +1,73 @@
+# Smart City IoT Solution Template
+
+Use this template to standardize outputs for each new smart city scenario.
+
+## 1. Use case summary
+
+- Domain:
+- Stakeholders:
+- Problem statement:
+- Success metrics:
+
+## 2. Device and data profile
+
+- Device types and count:
+- Telemetry schema:
+- Ingestion rate:
+- Command/control requirements:
+- Retention policy:
+
+## 3. Reference architecture
+
+- Edge and field layer:
+- Ingestion layer:
+- Processing layer:
+- Storage layer:
+- API and integration layer:
+- Monitoring and security layer:
+
+## 4. NFR checklist
+
+- Availability target:
+- Latency target:
+- Security controls:
+- Data privacy constraints:
+- DR strategy:
+- Cost target:
+
+## 5. Phased roadmap
+
+### Phase 1 - Pilot
+
+- Scope:
+- Deliverables:
+- Exit criteria:
+
+### Phase 2 - Scale
+
+- Scope:
+- Deliverables:
+- Exit criteria:
+
+### Phase 3 - Optimize
+
+- Scope:
+- Deliverables:
+- Exit criteria:
+
+## 6. Initial backlog baseline
+
+- Epic: Device onboarding and identity
+- Epic: Telemetry ingestion and routing
+- Epic: Real-time alerting and incident workflow
+- Epic: Historical analytics and reporting
+- Epic: Security and compliance hardening
+- Epic: Governance and cost optimization
+
+## 7. Risks
+
+- Vendor/device interoperability gaps
+- Network reliability in field locations
+- Data quality issues and schema drift
+- Over-retention that increases costs
+- Ambiguity in operational ownership
diff --git a/skills/python-azure-iot-edge-modules/SKILL.md b/skills/python-azure-iot-edge-modules/SKILL.md
new file mode 100644
index 00000000..8282534a
--- /dev/null
+++ b/skills/python-azure-iot-edge-modules/SKILL.md
@@ -0,0 +1,139 @@
+---
+name: python-azure-iot-edge-modules
+description: 'Build and operate Python Azure IoT Edge modules with robust messaging, deployment manifests, observability, and production readiness checks.'
+---
+
+# Python Azure IoT Edge Modules
+
+Use this skill to design, implement, and validate Python-based IoT Edge modules for telemetry processing, local inference, protocol translation, and edge-to-cloud integration.
+
+## When To Use
+
+Use this skill for requests like:
+
+- "quiero crear un modulo Python para IoT Edge"
+- "como despliego modulos edge con manifest"
+- "necesito filtrar/agregar telemetria antes de subirla"
+- "como manejo desconexiones y reintentos en edge"
+
+## Mandatory Docs Review
+
+Before recommending runtime behavior or deployment decisions, review:
+
+- https://learn.microsoft.com/azure/iot-edge/
+- https://learn.microsoft.com/es-es/azure/iot-edge/
+
+Minimum checks:
+
+- Runtime architecture and module lifecycle.
+- Supported host OS and versions.
+- Deployment model and configuration flow.
+- Current release/version guidance.
+
+If documentation cannot be fetched, proceed with explicit assumptions and flag them clearly.
+
+## Python Official References and Best Practices (Required)
+
+Before proposing Python implementation details, consult official Python sources:
+
+- https://www.python.org/
+- https://docs.python.org/3/
+- https://docs.python.org/3/reference/
+- https://docs.python.org/3/library/
+- references/python-official-best-practices.md
+
+Prefer official docs over community snippets unless there is a specific compatibility reason to deviate.
+
+## Goals
+
+- Deliver module architecture and implementation plan that is production-focused.
+- Ensure reliable edge messaging under network variability.
+- Provide deployment, observability, and validation artifacts.
+
+## Module Use Cases
+
+- Protocol adapter (serial/Modbus/OPC-UA to IoT message format).
+- Telemetry enrichment and normalization.
+- Local anomaly detection or inference.
+- Command orchestration and local actuator control.
+
+## Delivery Workflow
+
+### 1) Contract and Interfaces
+
+Define:
+
+- Module inputs and outputs.
+- Message schema and versioning policy.
+- Routes and priorities for normal vs critical telemetry.
+- Desired properties used for dynamic configuration.
+
+### 2) Runtime and Packaging
+
+Specify:
+
+- Python runtime version target.
+- Container image strategy (base image, slim footprint, CVE hygiene).
+- Resource profile (CPU/memory bounds).
+- Startup and health checks.
+
+### 3) Reliability Design
+
+Implement and validate:
+
+- Retries with exponential backoff and jitter.
+- Graceful degradation on upstream failures.
+- Local queueing strategy where needed.
+- Idempotent processing for replayed messages.
+
+### 4) Security Controls
+
+Require:
+
+- No plaintext secrets in code or manifest.
+- Least-privilege module behavior.
+- Secure transport and trusted cert chain handling.
+- Traceability for command handling and state changes.
+
+### 5) Deployment and Operations
+
+Define:
+
+- Environment-specific deployment manifests.
+- Rollout strategy (pilot, staged, broad).
+- Rollback criteria.
+- SLOs and alerting conditions.
+
+## Reuse Other Skills
+
+When relevant, combine with:
+
+- `azure-smart-city-iot-solution-builder` for platform-level architecture.
+- `appinsights-instrumentation` for telemetry instrumentation approaches.
+- `azure-resource-visualizer` for architecture diagrams and dependency mapping.
+
+Also use `references/python-official-best-practices.md` as baseline quality criteria for module design and implementation guidance.
+
+## Required Output
+
+Always provide:
+
+1. Module design brief (purpose, inputs, outputs).
+2. Deployment model (image, manifest, env settings).
+3. Reliability and error-handling strategy.
+4. Security and operations checklist.
+5. Test matrix (functional, chaos, performance, rollback).
+
+## Output Template
+
+1. Context and assumptions
+2. Module architecture
+3. Deployment and configuration
+4. Reliability, security, observability
+5. Validation and rollout plan
+
+## Guardrails
+
+- Do not recommend direct production rollout without pilot stage.
+- Do not embed secrets in Dockerfiles, source, or manifests.
+- Do not omit health probes, restart behavior, and rollback criteria.
diff --git a/skills/python-azure-iot-edge-modules/references/python-edge-module-template.md b/skills/python-azure-iot-edge-modules/references/python-edge-module-template.md
new file mode 100644
index 00000000..8b36630f
--- /dev/null
+++ b/skills/python-azure-iot-edge-modules/references/python-edge-module-template.md
@@ -0,0 +1,63 @@
+# Python IoT Edge Module Template
+
+Use this template to structure implementation proposals and reviews.
+
+## 0) Official Python Baseline
+
+- Official references reviewed from and .
+- Language and stdlib usage validated against and .
+- Best practices reviewed from `references/python-official-best-practices.md`.
+
+## 1) Module Summary
+
+- Module name:
+- Business capability:
+- Inputs:
+- Outputs:
+- Trigger conditions:
+
+## 2) Message Contract
+
+- Schema version:
+- Required fields:
+- Optional fields:
+- Error payload contract:
+
+## 3) Runtime Configuration
+
+- Python version:
+- Base image:
+- Environment variables:
+- Desired properties:
+- Resource limits:
+
+## 4) Resilience
+
+- Retry policy:
+- Backoff policy:
+- Queueing strategy:
+- Idempotency approach:
+- Timeout and circuit-breaker behavior:
+
+## 5) Security
+
+- Secret source (never inline):
+- Identity and permissions:
+- Command authorization model:
+- Audit log requirements:
+
+## 6) Observability
+
+- Health signals:
+- Business metrics:
+- Error metrics:
+- Correlation/trace requirements:
+- Alert thresholds:
+
+## 7) Validation Matrix
+
+- Happy path tests:
+- Malformed payload tests:
+- Network interruption tests:
+- Throughput and latency tests:
+- Rollback validation:
diff --git a/skills/python-azure-iot-edge-modules/references/python-official-best-practices.md b/skills/python-azure-iot-edge-modules/references/python-official-best-practices.md
new file mode 100644
index 00000000..2328e575
--- /dev/null
+++ b/skills/python-azure-iot-edge-modules/references/python-official-best-practices.md
@@ -0,0 +1,48 @@
+# Python Official References and Best Practices
+
+Use these official Python resources before finalizing module architecture or implementation details.
+
+## Official References
+
+- Python home:
+- Python documentation portal:
+- Python tutorial:
+- Python language reference:
+- Python standard library reference:
+- Python HOWTOs:
+- Installing modules:
+- Distributing modules:
+- PEP index:
+- PyPA packaging guide:
+
+## Coding Best Practices
+
+- Target and pin an explicit Python major/minor runtime for each deployment.
+- Prefer explicit, readable code paths over clever compact logic.
+- Use type hints for public interfaces and critical data transformations.
+- Keep module responsibilities focused; separate protocol, business logic, and transport.
+- Validate and sanitize external inputs at boundaries.
+- Use structured exceptions with actionable error messages.
+- Log with enough context for incident triage (correlation id, module id, message id).
+
+## Reliability and Performance Best Practices
+
+- Avoid blocking operations in high-frequency message paths.
+- Enforce timeouts and bounded retries with exponential backoff and jitter.
+- Design idempotent handlers for replay and duplicate deliveries.
+- Use resource limits and monitor memory growth to prevent edge instability.
+- Define graceful shutdown behavior to flush buffered state safely.
+
+## Dependency and Supply Chain Best Practices
+
+- Pin dependencies and document upgrade cadence.
+- Prefer actively maintained libraries with clear release history.
+- Track vulnerabilities and update dependencies regularly.
+- Keep container images minimal and patched.
+
+## Testing Best Practices
+
+- Unit test parsing, validation, and routing logic.
+- Add integration tests for module I/O boundaries.
+- Add chaos tests for network loss, slow upstream, and restart scenarios.
+- Verify rollback behavior and state recovery in deployment tests.