@mmerterden/multi-agent-pipeline 20.2.1 → 20.3.1

package/pipeline/skills/shared/external/docker-expert/SKILL.md

@@ -1,413 +1,169 @@
 ---
 name: docker-expert
-description: "You are an advanced Docker containerization expert with comprehensive, practical knowledge of container optimization, security hardening, multi-stage builds, orchestration patterns, and production deployment strategies based on current industry best practices. Use when writing or reviewing a Dockerfile, compose setup, or container build."
-category: devops
-risk: unknown
-source: community
-date_added: "2026-02-27"
+description: "Dockerfiles and images: multi-stage builds, BuildKit cache and secret mounts, slim or distroless bases, non-root, healthchecks, scanning, multi-arch, Compose for dev. Use when writing, shrinking or hardening a container build."
+metadata:
+  risk: safe
+  source: multi-agent-pipeline
+  date_added: "2026-09-25"
 ---
 
-# Docker Expert
-
-You are an advanced Docker containerization expert with comprehensive, practical knowledge of container optimization, security hardening, multi-stage builds, orchestration patterns, and production deployment strategies based on current industry best practices.
-
-## When invoked:
-
-0. If the issue requires ultra-specific expertise outside Docker, recommend switching and stop:
-   - Kubernetes orchestration, pods, services, ingress → kubernetes-expert (future)
-   - GitHub Actions CI/CD with containers → github-actions-expert
-   - AWS ECS/Fargate or cloud-specific container services → devops-expert
-   - Database containerization with complex persistence → database-expert
-
-   Example to output:
-   "This requires Kubernetes orchestration expertise. Please invoke: 'Use the kubernetes-expert subagent.' Stopping here."
-
-1. Analyze container setup comprehensively:
-   
-   **Use internal tools first (Read, Grep, Glob) for better performance. Shell commands are fallbacks.**
-   
-   ```bash
-   # Docker environment detection
-   docker --version 2>/dev/null || echo "No Docker installed"
-   docker info | grep -E "Server Version|Storage Driver|Container Runtime" 2>/dev/null
-   docker context ls 2>/dev/null | head -3
-   
-   # Project structure analysis
-   find . -name "Dockerfile*" -type f | head -10
-   find . -name "*compose*.yml" -o -name "*compose*.yaml" -type f | head -5
-   find . -name ".dockerignore" -type f | head -3
-   
-   # Container status if running
-   docker ps --format "table {{.Names}}\t{{.Image}}\t{{.Status}}" 2>/dev/null | head -10
-   docker images --format "table {{.Repository}}\t{{.Tag}}\t{{.Size}}" 2>/dev/null | head -10
-   ```
-   
-   **After detection, adapt approach:**
-   - Match existing Dockerfile patterns and base images
-   - Respect multi-stage build conventions
-   - Consider development vs production environments
-   - Account for existing orchestration setup (Compose/Swarm)
-
-2. Identify the specific problem category and complexity level
-
-3. Apply the appropriate solution strategy from my expertise
-
-4. Validate thoroughly:
-   ```bash
-   # Build and security validation
-   docker build --no-cache -t test-build . 2>/dev/null && echo "Build successful"
-   docker history test-build --no-trunc 2>/dev/null | head -5
-   docker scout quickview test-build 2>/dev/null || echo "No Docker Scout"
-   
-   # Runtime validation
-   docker run --rm -d --name validation-test test-build 2>/dev/null
-   docker exec validation-test ps aux 2>/dev/null | head -3
-   docker stop validation-test 2>/dev/null
-   
-   # Compose validation
-   docker-compose config 2>/dev/null && echo "Compose config valid"
-   ```
-
-## Core Expertise Areas
-
-### 1. Dockerfile Optimization & Multi-Stage Builds
-
-**High-priority patterns I address:**
-- **Layer caching optimization**: Separate dependency installation from source code copying
-- **Multi-stage builds**: Minimize production image size while keeping build flexibility
-- **Build context efficiency**: Comprehensive .dockerignore and build context management
-- **Base image selection**: Alpine vs distroless vs scratch image strategies
-
-**Key techniques:**
-```dockerfile
-# Optimized multi-stage pattern
-FROM node:18-alpine AS deps
-WORKDIR /app
-COPY package*.json ./
-RUN npm ci --only=production && npm cache clean --force
+# Docker Images and Compose
 
-FROM node:18-alpine AS build
-WORKDIR /app
-COPY package*.json ./
-RUN npm ci
-COPY . .
-RUN npm run build && npm prune --production
+An image is a deployable artifact. It should be small enough to pull quickly,
+reproducible enough that the same commit gives the same result, and boring
+enough at runtime that nothing in it surprises an operator. This skill is the
+checklist for getting there, ordered by how much each item usually buys.
 
-FROM node:18-alpine AS runtime
-RUN addgroup -g 1001 -S nodejs && adduser -S nextjs -u 1001
-WORKDIR /app
-COPY --from=deps --chown=nextjs:nodejs /app/node_modules ./node_modules
-COPY --from=build --chown=nextjs:nodejs /app/dist ./dist
-COPY --from=build --chown=nextjs:nodejs /app/package*.json ./
-USER nextjs
-EXPOSE 3000
-HEALTHCHECK --interval=30s --timeout=10s --start-period=5s --retries=3 \
-  CMD curl -f http://localhost:3000/health || exit 1
-CMD ["node", "dist/index.js"]
-```
+Pipeline wiring (where the image is built, pushed and promoted) belongs to
+`ci-cd-pipelines`; workflow YAML belongs to `github-actions-templates`.
 
-### 2. Container Security Hardening
+## Review order
 
-**Security focus areas:**
-- **Non-root user configuration**: Proper user creation with specific UID/GID
-- **Secrets management**: Docker secrets, build-time secrets, avoiding env vars
-- **Base image security**: Regular updates, minimal attack surface
-- **Runtime security**: Capability restrictions, resource limits
+1. Does the build context contain only what the build needs?
+2. Is the layer order stable-first, volatile-last, so the cache survives edits?
+3. Does the final stage carry only runtime files?
+4. Does the process run as a non-root user with a read-only-friendly layout?
+5. Are secrets kept out of every layer and of the build history?
+6. Can an orchestrator tell whether the container is healthy and stop it cleanly?
+7. Are base images pinned and scanned?
 
-**Security patterns:**
-```dockerfile
-# Security-hardened container
-FROM node:18-alpine
-RUN addgroup -g 1001 -S appgroup && \
-    adduser -S appuser -u 1001 -G appgroup
-WORKDIR /app
-COPY --chown=appuser:appgroup package*.json ./
-RUN npm ci --only=production
-COPY --chown=appuser:appgroup . .
-USER 1001
-# Drop capabilities, set read-only root filesystem
-```
+## 1. Build context
+
+Everything in the context is sent to the builder and can invalidate `COPY . .`.
+Start `.dockerignore` from a deny list and widen only when a build fails:
 
-### 3. Docker Compose Orchestration
-
-**Orchestration expertise:**
-- **Service dependency management**: Health checks, startup ordering
-- **Network configuration**: Custom networks, service discovery
-- **Environment management**: Dev/staging/prod configurations
-- **Volume strategies**: Named volumes, bind mounts, data persistence
-
-**Production-ready compose pattern:**
-```yaml
-version: '3.8'
-services:
-  app:
-    build:
-      context: .
-      target: production
-    depends_on:
-      db:
-        condition: service_healthy
-    networks:
-      - frontend
-      - backend
-    healthcheck:
-      test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
-      interval: 30s
-      timeout: 10s
-      retries: 3
-      start_period: 40s
-    deploy:
-      resources:
-        limits:
-          cpus: '0.5'
-          memory: 512M
-        reservations:
-          cpus: '0.25'
-          memory: 256M
-
-  db:
-    image: postgres:15-alpine
-    environment:
-      POSTGRES_DB_FILE: /run/secrets/db_name
-      POSTGRES_USER_FILE: /run/secrets/db_user
-      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
-    secrets:
-      - db_name
-      - db_user
-      - db_password
-    volumes:
-      - postgres_data:/var/lib/postgresql/data
-    networks:
-      - backend
-    healthcheck:
-      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER}"]
-      interval: 10s
-      timeout: 5s
-      retries: 5
-
-networks:
-  frontend:
-    driver: bridge
-  backend:
-    driver: bridge
-    internal: true
-
-volumes:
-  postgres_data:
-
-secrets:
-  db_name:
-    external: true
-  db_user:
-    external: true  
-  db_password:
-    external: true
 ```
+.git
+**/node_modules
+**/__pycache__
+**/.venv
+dist
+coverage
+*.log
+.env*
+Dockerfile*
+compose*.yaml
+```
+
+A `.env` file that reaches the context ends up in a layer the moment someone
+writes `COPY . .`. Ignoring it is cheaper than remembering.
 
-### 4. Image Size Optimization
+## 2. Layer order and caching
 
-**Size reduction strategies:**
-- **Distroless images**: Minimal runtime environments
-- **Build artifact optimization**: Remove build tools and cache
-- **Layer consolidation**: Combine RUN commands strategically
-- **Multi-stage artifact copying**: Only copy necessary files
+Copy dependency manifests, install, then copy source. Source changes daily;
+the lockfile changes weekly.
 
-**Optimization techniques:**
 ```dockerfile
-# Minimal production image
-FROM gcr.io/distroless/nodejs18-debian11
-COPY --from=build /app/dist /app
-COPY --from=build /app/node_modules /app/node_modules
+# syntax=docker/dockerfile:1.7
+FROM node:22-bookworm-slim AS deps
 WORKDIR /app
-EXPOSE 3000
-CMD ["index.js"]
+COPY package.json package-lock.json ./
+RUN --mount=type=cache,target=/root/.npm \
+    npm ci --omit=dev
 ```
 
-### 5. Development Workflow Integration
-
-**Development patterns:**
-- **Hot reloading setup**: Volume mounting and file watching
-- **Debug configuration**: Port exposure and debugging tools
-- **Testing integration**: Test-specific containers and environments
-- **Development containers**: Remote development container support via CLI tools
-
-**Development workflow:**
-```yaml
-# Development override
-services:
-  app:
-    build:
-      context: .
-      target: development
-    volumes:
-      - .:/app
-      - /app/node_modules
-      - /app/dist
-    environment:
-      - NODE_ENV=development
-      - DEBUG=app:*
-    ports:
-      - "9229:9229"  # Debug port
-    command: npm run dev
-```
+BuildKit cache mounts keep the package manager cache between builds without
+putting it in the image. Equivalents:
 
-### 6. Performance & Resource Management
-
-**Performance optimization:**
-- **Resource limits**: CPU, memory constraints for stability
-- **Build performance**: Parallel builds, cache utilization
-- **Runtime performance**: Process management, signal handling
-- **Monitoring integration**: Health checks, metrics exposure
-
-**Resource management:**
-```yaml
-services:
-  app:
-    deploy:
-      resources:
-        limits:
-          cpus: '1.0'
-          memory: 1G
-        reservations:
-          cpus: '0.5'
-          memory: 512M
-      restart_policy:
-        condition: on-failure
-        delay: 5s
-        max_attempts: 3
-        window: 120s
-```
+| Tool | Mount target |
+|------|--------------|
+| npm | `/root/.npm` |
+| pnpm | `/root/.local/share/pnpm/store` |
+| pip / uv | `/root/.cache/pip`, `/root/.cache/uv` |
+| Go | `/go/pkg/mod` and `/root/.cache/go-build` |
+| apt | `/var/cache/apt` and `/var/lib/apt` with `sharing=locked` |
 
-## Advanced Problem-Solving Patterns
+For apt, remove the image's `docker-clean` hook or the cache mount stays empty,
+and always pair `update` and `install` in one `RUN`.
 
-### Cross-Platform Builds
-```bash
-# Multi-architecture builds
-docker buildx create --name multiarch-builder --use
-docker buildx build --platform linux/amd64,linux/arm64 \
-  -t myapp:latest --push .
-```
+## 4. Runtime user and filesystem
 
-### Build Cache Optimization
 ```dockerfile
-# Mount build cache for package managers
-FROM node:18-alpine AS deps
+FROM python:3.13-slim
+RUN groupadd --system app && useradd --system --gid app --home /app app
 WORKDIR /app
-COPY package*.json ./
-RUN --mount=type=cache,target=/root/.npm \
-    npm ci --only=production
+COPY --from=build --chown=app:app /app/.venv /app/.venv
+COPY --chown=app:app src/ ./src/
+USER app
+ENV PATH="/app/.venv/bin:$PATH" PYTHONUNBUFFERED=1
+CMD ["python", "-m", "src.products_api"]
 ```
 
-### Secrets Management
+- Numeric `USER 10001` works with Kubernetes `runAsNonRoot` checks, which cannot
+  resolve names.
+- Write only to declared volumes or `/tmp`, so the container can run with
+  `read_only: true`.
+- Listen on a port above 1024; a non-root process cannot bind lower ones
+  without extra capabilities.
+
+## 5. Secrets
+
+Never `ARG` or `ENV` a token: both are visible in `docker history` and in the
+image config. Use a secret mount, which exists only for that `RUN`:
+
 ```dockerfile
-# Build-time secrets (BuildKit)
-FROM alpine
-RUN --mount=type=secret,id=api_key \
-    API_KEY=$(cat /run/secrets/api_key) && \
-    # Use API_KEY for build process
+RUN --mount=type=secret,id=npm_token,env=NPM_TOKEN \
+    npm ci
 ```
 
-### Health Check Strategies
+```bash
+docker buildx build --secret id=npm_token,env=NPM_TOKEN .
+```
+
+For private Git dependencies use `--mount=type=ssh` with `--ssh default`.
+Runtime secrets come from the orchestrator (mounted files or env injected at
+start), never from the image.
+
+## 6. Process behaviour
+
+- Exec form (`CMD ["bin", "arg"]`) so the app is PID 1 and receives `SIGTERM`.
+  Shell form wraps it in `/bin/sh -c`, which does not forward signals.
+- Handle `SIGTERM`: stop accepting work, finish requests already running, exit within
+  the orchestrator's grace period. Add `--init` or `tini` when the app spawns
+  children it does not reap.
+- Log to stdout and stderr; let the platform collect them.
+- `HEALTHCHECK` is honoured by Docker and Compose but ignored by Kubernetes,
+  which uses its own probes. Keep the health endpoint cheap and dependency-free
+  for liveness; check dependencies only in readiness.
+
 ```dockerfile
-# Sophisticated health monitoring
-COPY health-check.sh /usr/local/bin/
-RUN chmod +x /usr/local/bin/health-check.sh
-HEALTHCHECK --interval=30s --timeout=10s --start-period=5s --retries=3 \
-  CMD ["/usr/local/bin/health-check.sh"]
+HEALTHCHECK --interval=15s --timeout=3s --start-period=20s --retries=3 \
+  CMD ["/app/.venv/bin/python", "-c", "import urllib.request,sys; urllib.request.urlopen('http://127.0.0.1:8080/healthz', timeout=2)"]
 ```
 
-## Code Review Checklist
-
-When reviewing Docker configurations, focus on:
-
-### Dockerfile Optimization & Multi-Stage Builds
-- [ ] Dependencies copied before source code for optimal layer caching
-- [ ] Multi-stage builds separate build and runtime environments
-- [ ] Production stage only includes necessary artifacts
-- [ ] Build context optimized with comprehensive .dockerignore
-- [ ] Base image selection appropriate (Alpine vs distroless vs scratch)
-- [ ] RUN commands consolidated to minimize layers where beneficial
-
-### Container Security Hardening
-- [ ] Non-root user created with specific UID/GID (not default)
-- [ ] Container runs as non-root user (USER directive)
-- [ ] Secrets managed properly (not in ENV vars or layers)
-- [ ] Base images kept up-to-date and scanned for vulnerabilities
-- [ ] Minimal attack surface (only necessary packages installed)
-- [ ] Health checks implemented for container monitoring
-
-### Docker Compose & Orchestration
-- [ ] Service dependencies properly defined with health checks
-- [ ] Custom networks configured for service isolation
-- [ ] Environment-specific configurations separated (dev/prod)
-- [ ] Volume strategies appropriate for data persistence needs
-- [ ] Resource limits defined to prevent resource exhaustion
-- [ ] Restart policies configured for production resilience
-
-### Image Size & Performance
-- [ ] Final image size optimized (avoid unnecessary files/tools)
-- [ ] Build cache optimization implemented
-- [ ] Multi-architecture builds considered if needed
-- [ ] Artifact copying selective (only required files)
-- [ ] Package manager cache cleaned in same RUN layer
-
-### Development Workflow Integration
-- [ ] Development targets separate from production
-- [ ] Hot reloading configured properly with volume mounts
-- [ ] Debug ports exposed when needed
-- [ ] Environment variables properly configured for different stages
-- [ ] Testing containers isolated from production builds
-
-### Networking & Service Discovery
-- [ ] Port exposure limited to necessary services
-- [ ] Service naming follows conventions for discovery
-- [ ] Network security implemented (internal networks for backend)
-- [ ] Load balancing considerations addressed
-- [ ] Health check endpoints implemented and tested
-
-## Common Issue Diagnostics
-
-### Build Performance Issues
-**Symptoms**: Slow builds (10+ minutes), frequent cache invalidation
-**Root causes**: Poor layer ordering, large build context, no caching strategy
-**Solutions**: Multi-stage builds, .dockerignore optimization, dependency caching
-
-### Security Vulnerabilities  
-**Symptoms**: Security scan failures, exposed secrets, root execution
-**Root causes**: Outdated base images, hardcoded secrets, default user
-**Solutions**: Regular base updates, secrets management, non-root configuration
-
-### Image Size Problems
-**Symptoms**: Images over 1GB, deployment slowness
-**Root causes**: Unnecessary files, build tools in production, poor base selection
-**Solutions**: Distroless images, multi-stage optimization, artifact selection
-
-### Networking Issues
-**Symptoms**: Service communication failures, DNS resolution errors
-**Root causes**: Missing networks, port conflicts, service naming
-**Solutions**: Custom networks, health checks, proper service discovery
-
-### Development Workflow Problems
-**Symptoms**: Hot reload failures, debugging difficulties, slow iteration
-**Root causes**: Volume mounting issues, port configuration, environment mismatch
-**Solutions**: Development-specific targets, proper volume strategy, debug configuration
-
-## Integration & Handoff Guidelines
-
-**When to recommend other experts:**
-- **Kubernetes orchestration** → kubernetes-expert: Pod management, services, ingress
-- **CI/CD pipeline issues** → github-actions-expert: Build automation, deployment workflows  
-- **Database containerization** → database-expert: Complex persistence, backup strategies
-- **Application-specific optimization** → Language experts: Code-level performance issues
-- **Infrastructure automation** → devops-expert: Terraform, cloud-specific deployments
-
-**Collaboration patterns:**
-- Provide Docker foundation for DevOps deployment automation
-- Create optimized base images for language-specific experts
-- Establish container standards for CI/CD integration
-- Define security baselines for production orchestration
-
-I provide comprehensive Docker containerization expertise with focus on practical optimization, security hardening, and production-ready patterns. My solutions emphasize performance, maintainability, and security best practices for modern container workflows.
-
-## When to Use
-This skill is applicable to execute the workflow or actions described in the overview.
+Distroless images have no `curl`; ship a tiny health binary or rely on the
+orchestrator's probe.
+
+## 7. Pinning, scanning, provenance
+
+- Pin bases by digest in release images (`FROM node:22-bookworm-slim@sha256:...`)
+  and let Renovate or Dependabot bump the digest.
+- Scan in CI and fail on fixable critical findings: `docker scout cves`,
+  `trivy image`, or `grype`.
+- Emit an SBOM and provenance attestation with
+  `docker buildx build --sbom=true --provenance=mode=max`.
+- Add OCI labels (`org.opencontainers.image.source`, `.revision`, `.version`)
+  so a running image leads back to its commit.
+
+## Diagnosing a build
+
+| Symptom | First check |
+|---------|-------------|
+| Every build reinstalls dependencies | a `COPY . .` before the install step, or a missing lockfile copy |
+| Context upload is large | `.dockerignore`; run `docker buildx build --progress=plain` and read the context size |
+| Image is hundreds of MB | `docker history --no-trunc` or `dive` to find the heavy layer |
+| Works locally, fails on arm64 | a prebuilt native binary for one architecture only |
+| Container ignores stop and is killed after 10s | shell-form `CMD`, or no `SIGTERM` handler |
+| `permission denied` after adding `USER` | files copied without `--chown`, or writes outside a writable path |
+
+## Done means
+
+- `docker buildx build` succeeds from a clean cache and from a warm one.
+- Final image runs as non-root, has no compilers or package manager caches.
+- No secret appears in `docker history` or `docker inspect`.
+- Scanner reports no fixable critical vulnerability.
+- The container stops within its grace period on `SIGTERM`.
+
+## References
+
+- `references/patterns.md`: multi-stage Dockerfiles and choosing a runtime base, buildx multi-arch builds, and Compose v2 for local development. Load it when the task reaches those topics.

package/pipeline/skills/shared/external/docker-expert/references/patterns.md

@@ -0,0 +1,98 @@
+# Docker build patterns
+
+Loaded on demand from `../SKILL.md`.
+
+## 3. Multi-stage builds
+
+Build tools, compilers and dev dependencies stay in earlier stages. The last
+stage copies artifacts only.
+
+```dockerfile
+# syntax=docker/dockerfile:1.7
+FROM golang:1.23 AS build
+WORKDIR /src
+COPY go.mod go.sum ./
+RUN --mount=type=cache,target=/go/pkg/mod go mod download
+COPY . .
+RUN --mount=type=cache,target=/go/pkg/mod \
+    --mount=type=cache,target=/root/.cache/go-build \
+    CGO_ENABLED=0 go build -trimpath -ldflags="-s -w" -o /out/orders-api ./cmd/orders-api
+
+FROM gcr.io/distroless/static-debian12:nonroot
+COPY --from=build /out/orders-api /orders-api
+EXPOSE 8080
+ENTRYPOINT ["/orders-api"]
+```
+
+Useful stage tricks:
+
+- A `test` stage that runs the suite, built with `--target test` in CI, keeps
+  test tooling out of the release image.
+- A `dev` stage with hot reload tools, selected in Compose with `target: dev`.
+- `COPY --link` lets BuildKit reuse a layer even when an earlier layer changed.
+
+### Choosing the runtime base
+
+| Base | Size | Shell | Fits |
+|------|------|-------|------|
+| `scratch` | none | no | static binaries that need no CA bundle or tzdata |
+| `distroless/static` / `distroless/base` | very small | no | Go, Rust, JVM (`distroless/java21`) |
+| `*-slim` (Debian) | small | yes | Python, Node, anything needing glibc and debugging |
+| `alpine` | small | yes | when musl is known to be fine for every native dependency |
+
+Alpine's musl changes DNS behaviour and breaks some prebuilt wheels and native
+modules. Pick it on evidence, not by default.
+
+## Multi-architecture builds
+
+```bash
+docker buildx create --use --name multi
+docker buildx build \
+  --platform linux/amd64,linux/arm64 \
+  --cache-from type=registry,ref=registry.example.com/orders-api:buildcache \
+  --cache-to type=registry,ref=registry.example.com/orders-api:buildcache,mode=max \
+  -t registry.example.com/orders-api:1.4.0 --push .
+```
+
+QEMU emulation works but is slow for compiled languages. Prefer cross
+compilation in the build stage using `--platform=$BUILDPLATFORM` plus the
+`TARGETOS` / `TARGETARCH` build args, or native runners per architecture.
+
+## Compose v2 for local development
+
+Use `compose.yaml` and `docker compose` (the v1 `docker-compose` binary and the
+top-level `version:` key are obsolete).
+
+```yaml
+services:
+  api:
+    build: { context: ., target: dev }
+    ports: ["8080:8080"]
+    env_file: .env.local
+    depends_on:
+      db: { condition: service_healthy }
+    develop:
+      watch:
+        - action: sync
+          path: ./src
+          target: /app/src
+        - action: rebuild
+          path: package-lock.json
+  db:
+    image: postgres:17
+    environment:
+      POSTGRES_PASSWORD: devonly
+    volumes: [pgdata:/var/lib/postgresql/data]
+    healthcheck:
+      test: ["CMD-SHELL", "pg_isready -U postgres"]
+      interval: 5s
+      retries: 10
+volumes:
+  pgdata:
+```
+
+- `depends_on` with `service_healthy` replaces sleep-and-retry wrappers.
+- `docker compose watch` syncs files or rebuilds on change.
+- Profiles (`profiles: [tools]`) keep optional services off by default.
+- Compose is for development and small single-host deployments; production
+  orchestration settings (replicas, rollout) belong to the platform.

package/pipeline/skills/shared/external/energykit/SKILL.md

@@ -1,8 +1,9 @@
 ---
 name: energykit
 description: "Query grid electricity forecasts and submit load events using EnergyKit to help users optimize home electricity usage. Use when building smart home apps, EV charger controls, HVAC scheduling, or energy management dashboards that guide users to use power during cleaner or cheaper grid periods."
+metadata:
+  source: "dpearson2699/swift-ios-skills (PolyForm Perimeter 1.0.0)"
 ---
-
 # EnergyKit
 
 Provide grid electricity forecasts to help users choose when to use electricity.