configure-container
Container infrastructure: GHCR builds, Trivy/Grype scanning, devcontainer. Use when setting up multi-platform GHCR workflows or adding container scanning to CI.
What this skill does
# /configure:container Check and configure comprehensive container infrastructure against project standards with emphasis on **minimal images**, **non-root users**, and **security hardening**. ## When to Use This Skill | Use this skill when... | Use another approach when... | |------------------------|------------------------------| | Auditing container infrastructure compliance (Dockerfile, workflows, scanning) | Writing a Dockerfile from scratch (`/configure:dockerfile`) | | Checking multi-stage builds, non-root users, and security hardening | Configuring Kubernetes deployments (`/configure:skaffold`) | | Setting up container build workflows with GHCR and multi-platform support | Running vulnerability scans on a built image (Trivy CLI directly) | | Verifying `.dockerignore`, OCI labels, and base image versions | Configuring devcontainer features for VS Code | | Adding Trivy/Grype scanning to CI pipelines | Debugging container runtime issues (system-debugging agent) | ## Context - Dockerfiles: !`find . -maxdepth 2 \( -name 'Dockerfile' -o -name 'Dockerfile.*' -o -name '*.Dockerfile' \)` - Docker ignore: !`find . -maxdepth 1 -name '.dockerignore'` - Container workflows: !`find .github/workflows -maxdepth 1 \( -name '*container*' -o -name '*docker*' -o -name '*build*' \)` - Devcontainer: !`find .devcontainer -maxdepth 1 -name 'devcontainer.json'` - Skaffold: !`find . -maxdepth 1 -name 'skaffold.yaml'` - Package files: !`find . -maxdepth 1 \( -name 'package.json' -o -name 'pyproject.toml' -o -name 'Cargo.toml' -o -name 'go.mod' \)` - Project standards: !`find . -maxdepth 1 -name '.project-standards.yaml'` ## Parameters Parse from command arguments: - `--check-only`: Report compliance status without modifications (CI/CD mode) - `--fix`: Apply fixes automatically without prompting - `--component <name>`: Check specific component only (dockerfile, workflow, registry, scanning, devcontainer) ## Security Philosophy **Minimal Attack Surface**: Smaller images = fewer vulnerabilities. Use Alpine (~5MB) for Node.js, slim (~50MB) for Python. **Non-Root by Default**: ALL containers MUST run as non-root users. **Multi-Stage Required**: Separate build and runtime environments. Build tools and dev dependencies should NOT be in production images. ## Execution Execute this container infrastructure compliance check: ### Step 1: Detect container-related files Search for Dockerfile, workflow files, devcontainer config, and `.dockerignore`. Detect the project type (frontend, python, go, rust, infrastructure) from package files. ### Step 2: Look up latest base image versions Use WebSearch or WebFetch to verify current versions before flagging outdated images: 1. **Node.js Alpine images**: Check Docker Hub for latest LTS Alpine tags 2. **Python slim images**: Check Docker Hub for latest slim tags 3. **nginx Alpine**: Check Docker Hub for latest Alpine tags 4. **GitHub Actions**: Check release pages for latest action versions 5. **Trivy**: Check aquasecurity/trivy-action releases ### Step 3: Analyze each component Check each component against standards: **Dockerfile Standards:** | Check | Standard | Severity | |-------|----------|----------| | Exists | Required for containerized projects | FAIL if missing | | Multi-stage | Required (build + runtime stages) | FAIL if missing | | HEALTHCHECK | Required for K8s probes | FAIL if missing | | Non-root user | REQUIRED (not optional) | FAIL if missing | | .dockerignore | Required | WARN if missing | | .dockerignore `Dockerfile*` | Use glob to exclude all Dockerfile variants from context | WARN if only `Dockerfile` | | Base image version | Latest stable (check Docker Hub) | WARN if outdated | | Minimal base | Alpine for Node, slim for Python | WARN if bloated | **Base Image Standards (verify latest before reporting):** | Language | Build Image | Runtime Image | Size Target | |----------|-------------|---------------|-------------| | Node.js | `node:24-alpine` (LTS) | `nginx:1.30-alpine` | < 50MB | | Python | `python:3.14-slim` | `python:3.14-slim` | < 150MB | | Go | `golang:1.26-alpine` | `scratch` or `alpine:3.23` | < 20MB | | Rust | `rust:1.96-alpine` | `alpine:3.23` | < 20MB | **Security Hardening Standards:** | Check | Standard | Severity | |-------|----------|----------| | Non-root USER | Required (create dedicated user) | FAIL if missing | | Read-only FS | `--read-only` or RO annotation | INFO if missing | | No new privileges | `--security-opt=no-new-privileges` | INFO if missing | | Drop capabilities | `--cap-drop=all` + explicit `--cap-add` | INFO if missing | | No secrets in image | No ENV with sensitive data | FAIL if found | **Build Workflow Standards:** | Check | Standard | Severity | |-------|----------|----------| | Workflow exists | container-build.yml or similar | FAIL if missing | | checkout action | v4+ | WARN if older | | build-push-action | v6+ | WARN if older | | Multi-platform | linux/amd64,linux/arm64 | WARN if missing | | Build caching | GHA cache enabled | WARN if missing | | Security scan | Trivy/Grype in workflow | WARN if missing | | `id-token: write` | Required when provenance/SBOM configured | WARN if missing | | Cache scope | Explicit `scope=` for multi-image builds | WARN if missing | | Scanner pinned | Trivy/Grype action pinned by SHA (not `@master`) | WARN if unpinned | **Container Labels Standards (GHCR Integration):** | Check | Standard | Severity | |-------|----------|----------| | `org.opencontainers.image.source` | Required - Links to repository | WARN if missing | | `org.opencontainers.image.description` | Required - Package description | WARN if missing | | `org.opencontainers.image.licenses` | Required - SPDX license | WARN if missing | Run `/configure:dockerfile` for detailed Dockerfile checks if needed. ### Step 4: Generate compliance report Print a formatted compliance report: ``` Container Infrastructure Compliance Report ============================================== Project Type: frontend (detected) Component Status: Dockerfile PASS Build Workflow PASS Registry Config PASS Container Scanning WARN (missing) Devcontainer SKIP (not required) .dockerignore PASS Dockerfile Checks: Multi-stage 2 stages PASS HEALTHCHECK Present PASS Base images node:24, nginx PASS Build Workflow Checks: Workflow container-build.yml PASS checkout v4 PASS build-push-action v6 PASS Multi-platform amd64,arm64 PASS GHA caching Enabled PASS Container Labels Checks: image.source In metadata-action PASS image.description Custom label set PASS image.licenses Not configured WARN Recommendations: - Add org.opencontainers.image.licenses label to workflow - Add Trivy or Grype vulnerability scanning to CI Overall: 2 warnings, 1 info ``` If `--check-only`, stop here. ### Step 5: Apply fixes (if --fix or user confirms) 1. **Missing Dockerfile**: Run `/configure:dockerfile --fix` 2. **Missing build workflow**: Create from template in [REFERENCE.md](REFERENCE.md) 3. **Missing scanning**: Add Trivy scanning job 4. **Missing .dockerignore**: Create standard .dockerignore from [REFERENCE.md](REFERENCE.md) 5. **Outdated actions**: Update version numbers ### Step 6: Update standards tracking Update `.project-standards.yaml`: ```yaml components: container: "2025.1" dockerfile: "2025.1" container-workflow: "2025.1" ``` For detailed templates (Dockerfile, workflow, devcontainer, .dockerignore), see [REFERENCE.md](REFERENCE.md). ## Agentic Optimizations | Context | Command | |---------|---------| | Quick compliance check | `/configure:container --check-only` | | Auto-fix all issues | `/configure:container --fix` | | Dockerfile only | `/configure:container --check-only --component dockerfile` | | Workfl
Related in Cloud & DevOps
appbuilder-action-scaffolder
IncludedCreate, implement, deploy, and debug Adobe Runtime actions with consistent layout, validation, and error handling. Use this skill whenever the user needs to add actions to an App Builder project, understand action structure (params, response format, web/raw actions), configure actions in the manifest, use App Builder SDKs (State, Files, Events, database), deploy and invoke actions via CLI, debug action issues, or implement patterns such as webhook receivers, custom event providers, journaling consumers, large payload redirects, action sequence pipelines, and Asset Compute workers. Also trigger when users mention serverless functions in Adobe context, action logging, IMS authentication for actions, or cron-style scheduled actions.
orchestrating-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. Use this skill when the user needs a multi-step Data Cloud pipeline, cross-phase troubleshooting, or data space and data kit management. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase sf data360 workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching phase-specific skill), the task is STDM/session tracing/parquet telemetry (use observing-agentforce), standard CRM SOQL (use querying-soql), or Apex implementation (use generating-apex).
github-project-automation
IncludedAutomate GitHub repository setup with CI/CD workflows, issue templates, Dependabot, and CodeQL security scanning. Includes 12 production-tested workflows and prevents 18 errors: YAML syntax, action pinning, and configuration. Use when: setting up GitHub Actions CI/CD, creating issue/PR templates, enabling Dependabot or CodeQL scanning, deploying to Cloudflare Workers, implementing matrix testing, or troubleshooting YAML indentation, action version pinning, secrets syntax, runner versions, or CodeQL configuration. Keywords: github actions, github workflow, ci/cd, issue templates, pull request templates, dependabot, codeql, security scanning, yaml syntax, github automation, repository setup, workflow templates, github actions matrix, secrets management, branch protection, codeowners, github projects, continuous integration, continuous deployment, workflow syntax error, action version pinning, runner version, github context, yaml indentation error
sf-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase `sf data360` workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching sf-datacloud-* skill), the task is STDM/session tracing/parquet telemetry (use sf-ai-agentforce-observability), standard CRM SOQL (use sf-soql), or Apex implementation (use sf-apex).
fabric-cli
IncludedUse this skill for Fabric.so CLI workflows with the `fabric` terminal command: diagnose/install/login, search or browse a Fabric library, save notes/links/files, create folders, ask the Fabric AI assistant, manage tasks/workspaces, generate shell completion, check subscription usage, produce JSON output, and use Fabric as persistent agent memory. Do not use for Microsoft Fabric/Azure/Power BI `fab`, Daniel Miessler's Fabric framework, Python Fabric SSH, Fabric.js, or textile/fashion fabric.
lark
IncludedLark/Feishu CLI skills: lark-cli operations for docs, markdown, sheets, base, calendar, im, mail, task, okr, drive, wiki, slides, whiteboard, apps, approval, attendance, contact, vc, minutes, event. Use when the user needs to operate Lark/Feishu resources via lark-cli, send messages, manage documents, spreadsheets, calendars, tasks, OKRs, deploy web pages, or any Feishu/Lark workspace operations.