$npx -y skills add github/awesome-copilot --skill azure-smart-city-iot-solution-builderDesign 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.
| 1 | # Azure Smart City IoT Solution Builder |
| 2 | |
| 3 | Use this skill to rebuild and standardize a complete workflow for Azure IoT and Smart City solutions. |
| 4 | |
| 5 | ## When to use it |
| 6 | |
| 7 | Use this skill when the user asks for things like: |
| 8 | |
| 9 | - "I want to build an IoT solution on Azure" |
| 10 | - "Smart City architecture for traffic, lighting, or waste" |
| 11 | - "How do I connect devices, analytics, and alerts?" |
| 12 | - "I need a roadmap and backlog for an urban platform" |
| 13 | |
| 14 | ## Objectives |
| 15 | |
| 16 | - Convert a high-level idea into a deployable architecture. |
| 17 | - Reuse existing Azure-focused skills whenever possible. |
| 18 | - Produce concrete artifacts the team can implement. |
| 19 | |
| 20 | ## Workflow |
| 21 | |
| 22 | ### 0) Mandatory documentation review (before any architecture) |
| 23 | |
| 24 | Before proposing architecture or technology decisions that involve edge computing, review Azure IoT Edge documentation first: |
| 25 | |
| 26 | - https://learn.microsoft.com/azure/iot-edge/ |
| 27 | |
| 28 | Minimum pages to review: |
| 29 | |
| 30 | - What is Azure IoT Edge |
| 31 | - Runtime architecture |
| 32 | - Supported systems |
| 33 | - Version history/release notes |
| 34 | - Relevant Linux/Windows quickstarts for the scenario |
| 35 | |
| 36 | If documentation cannot be consulted, state this explicitly and continue with clearly marked assumptions. |
| 37 | |
| 38 | ### 1) Scope and constraints |
| 39 | |
| 40 | Collect and confirm: |
| 41 | |
| 42 | - City domain: mobility, parking, air quality, water, energy, public safety, waste, etc. |
| 43 | - Scale: number of devices, telemetry frequency, retention, regions. |
| 44 | - Latency and availability objectives. |
| 45 | - Regulatory and privacy constraints. |
| 46 | - Existing systems to integrate (SCADA, GIS, ERP, ticketing, APIs). |
| 47 | |
| 48 | ### 2) Capability map |
| 49 | |
| 50 | Split the platform into layers: |
| 51 | |
| 52 | - Device and edge: onboarding, identity, firmware, OTA, edge processing. |
| 53 | - Ingestion and messaging: command and control, event routing, buffering. |
| 54 | - Data and analytics: hot path vs cold path, dashboards, historical analysis. |
| 55 | - Operations: observability, incident flow, SLOs. |
| 56 | - Governance: RBAC, secrets, policies, network isolation. |
| 57 | |
| 58 | ### 3) Azure service selection (reference) |
| 59 | |
| 60 | - Device connectivity: Azure IoT Hub, Azure IoT Operations, IoT Edge. |
| 61 | - Event streaming: Event Hubs, Service Bus, Event Grid. |
| 62 | - Storage: Blob Storage, Data Lake, Cosmos DB, SQL. |
| 63 | - Analytics: Azure Data Explorer, Stream Analytics, Fabric/Synapse. |
| 64 | - APIs and applications: API Management, App Service, Container Apps, Functions. |
| 65 | - Monitoring: Azure Monitor, Application Insights, Log Analytics. |
| 66 | - Security: Key Vault, Defender for IoT, Private Endpoints, Managed Identity. |
| 67 | |
| 68 | ### 4) Non-functional design |
| 69 | |
| 70 | Define and document: |
| 71 | |
| 72 | - Reliability model (zones/regions, retries, dead-letter handling, replay). |
| 73 | - Security controls (zero trust, encryption, secret rotation, least privilege). |
| 74 | - Cost controls (retention tiers, rightsizing, autoscaling, workload scheduling). |
| 75 | - Data lifecycle (raw, curated, aggregated, archived). |
| 76 | |
| 77 | ### 5) Delivery plan |
| 78 | |
| 79 | Create a phased execution: |
| 80 | |
| 81 | - Phase 1: Pilot district or single use case. |
| 82 | - Phase 2: Multi-domain integration. |
| 83 | - Phase 3: City-scale rollout and optimization. |
| 84 | |
| 85 | For each phase, include: |
| 86 | |
| 87 | - Exit criteria |
| 88 | - Dependencies |
| 89 | - Risks and mitigations |
| 90 | - KPI set |
| 91 | |
| 92 | ## Reuse other skills first |
| 93 | |
| 94 | There are two sources of skills: |
| 95 | |
| 96 | - Runtime-provided skills (external to this repository): only available when the Copilot host environment exposes them. |
| 97 | - Local repository skills (this repository): available as local files under `skills/`. |
| 98 | |
| 99 | ### Runtime-provided Azure skills (optional) |
| 100 | |
| 101 | If they are available in the execution environment, delegate to these specialized skills for deeper guidance: |
| 102 | |
| 103 | - `azure-kubernetes` |
| 104 | - `azure-messaging` |
| 105 | - `azure-observability` |
| 106 | - `azure-storage` |
| 107 | - `azure-rbac` |
| 108 | - `azure-cost` |
| 109 | - `azure-validate` |
| 110 | - `azure-deploy` |
| 111 | |
| 112 | ### Local repository alternatives (use in this repo) |
| 113 | |
| 114 | When runtime skills are not available, prioritize existing local skills in this repository: |
| 115 | |
| 116 | - `azure-architecture-autopilot` for architecture generation and refinement. |
| 117 | - `azure-resource-visualizer` for resource relationship diagrams. |
| 118 | - `azure-role-selector` for role selection guidance. |
| 119 | - `az-cost-optimize` and `azure-pricing` for cost and pricing analysis. |
| 120 | - `azure-deployment-preflight` for pre-deployment checks. |
| 121 | - `appinsights-instrumentation` for telemetry instrumentation patterns. |
| 122 | |
| 123 | If no specialized skill is available, continue with this skill and keep assumptions explicit. |
| 124 | |
| 125 | ## Required output artifacts |
| 126 | |
| 127 | Always provide these outputs: |
| 128 | |
| 129 | 1. Smart City solution summary (scope, assumptions, constraints). |
| 130 | 2. Reference architecture (components and data flow). |
| 131 | 3. Security and governance checklist. |
| 132 | 4. Cost and scaling strategy. |
| 133 | 5. Phased implementation backlog (epics and milestones). |
| 134 | |
| 135 | ## Output template |
| 136 | |
| 137 | Use this response structure: |
| 138 | |
| 139 | 1. Context and objectives |
| 140 | 2. Proposed architecture |
| 141 | 3. Technology decisions and trade-offs |
| 142 | 4. Security, operations, and cost controls |