mirror of
https://github.com/github/awesome-copilot.git
synced 2026-05-03 13:45:55 +00:00
feat(skills): add IoT edge skills and align agent/instruction docs (#1431)
* feat(skills): add IoT edge skills and align agent/instruction docs * fix(ci): handle fork permission errors in plugin structure check * fix(ci): allow intentional Spanish vocabulary in codespell * docs(skills): translate IoT edge skill content to English * fix(ci): pass codespell and README validation * chore: regenerate skills index after merge
This commit is contained in:
Sertxito
GitHub
156
skills/azure-smart-city-iot-solution-builder/SKILL.md
Normal file
156
skills/azure-smart-city-iot-solution-builder/SKILL.md
Normal file
@@ -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.
|
||||
@@ -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
|
||||
Reference in New Issue
Block a user