mirror of
https://github.com/github/awesome-copilot.git
synced 2026-08-10 11:09:56 +00:00
4214189287
While implementing the Agent Plugin v1 spec in https://github.com/stbenjam/skillsaw/pull/483, I used this repository as a canonical real-world source for tests. Along the way its checks surfaced genuine correctness issues worth fixing regardless of tooling: - Internal links that do not resolve (22): wrong relative paths, links whose targets are runtime output paths rather than bundled files (now inline code), a schemeless external URL parsed as a relative path, and links to files that do not exist (removed). - Bundled skill files never referenced from their SKILL.md (14): each is now cited from the section where it is used, so nothing ships unreachable from the skill's instructions. - Unclosed or mis-nested code fences (11): markdown templates embedding code blocks now use four-backtick outer fences so inner fences nest instead of closing the template early and leaking example content as live markdown; also removed stray orphan fences and closed an unterminated block at end of file. - Invisible unicode (1): removed a zero-width space from a code example, a copy-paste artifact invisible to reviewers.
142 lines
4.2 KiB
Markdown
142 lines
4.2 KiB
Markdown
---
|
|
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
|
|
|
|
Use `references/python-edge-module-template.md` to structure implementation proposals and reviews.
|
|
|
|
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.
|