Agent Skills are a lightweight, open format for extending AI agent capabilities with specialized knowledge and workflows.
At its core, a skill is a folder containing a SKILL.md file. This file includes metadata (name and description, at minimum) and instructions that tell an agent how to perform a specific task. Skills can also bundle scripts, templates, and reference materials.
my-skill/
├── SKILL.md # Required: instructions + metadata
├── scripts/ # Optional: executable code
├── references/ # Optional: documentation
└── assets/ # Optional: templates, resources
This section is auto-generated by
misc/update-skills-references.sh. Do not edit manually.
Advisory guidance for Amazon EKS architecture and configuration decisions — compute strategy, networking, security, reliability, cost, autoscaling, observability, multi-tenancy, and upgrade planning. Also answers Terraform configuration questions about terraform-aws-modules/terraform-aws-eks. Use for any EKS planning or architectural judgment call, even when phrased casually. Do NOT use for generating documents or code (eks-design, eks-build), scoring or auditing a live cluster (eks-operation-review, eks-upgrade-check), discovering what is running (eks-recon), MCP tooling setup (eks-mcp-server), building developer platforms and IDPs (eks-platform-engineering), GenAI/LLM workload decisions — GPU vs Trainium/Inferentia, vLLM/Ray serving, distributed training, ML storage (eks-genai), or compliance-regime hardening and audit prep — HIPAA/PCI/FedRAMP, CIS benchmarks, GuardDuty, image signing (eks-security) or EXECUTING an x86→arm64/Graviton migration — scan, cutover, multi-arch builds (use graviton-migration).
References (loaded on demand):
| Reference | Description |
|---|---|
| argocd-patterns.md | Argocd patterns |
| autoscaling.md | Autoscaling |
| cluster-upgrades.md | Cluster upgrades |
| container-registry.md | Container registry |
| cost-optimization.md | Cost optimization |
| eks-auto-mode.md | Eks auto mode |
| karpenter.md | Karpenter |
| networking-ingress-dns.md | Networking ingress dns |
| networking.md | Networking |
| observability.md | Observability |
| reliability-advanced.md | Reliability advanced |
| reliability-core.md | Reliability core |
| scalability.md | Scalability |
| security-runtime-network.md | Security runtime network |
| security-supply-chain.md | Security supply chain |
| security.md | Security |
| terraform-examples.md | Terraform examples |
Use when building EKS clusters. Generates complete, production-ready Terraform projects with optional ArgoCD GitOps integration. Handles environment-specific constraints: air-gapped/VPC-endpoint-only networks, enterprise proxies, private container registries, compliance requirements. Supports 3 patterns: full Terraform, ArgoCD+Terraform, ArgoCD+ACK/KRO. Includes validated modules, two-phase webhook ordering, IRSA/Pod Identity, and 29+ addon configurations. Ask interactive questions or accept requirements YAML. Also use when (1) generating EKS Terraform code from scratch, (2) creating GitOps-managed EKS addons with ArgoCD, (3) scaffolding EKS projects with compliance constraints, (4) implementing two-phase webhook ordering for EKS addons, (5) configuring IRSA or Pod Identity for EKS workloads, (6) generating ArgoCD ApplicationSets for EKS addon management, or (7) comparing deployment patterns for implementation decisions. Skip for Amazon ECS (use ecs-build).
References (loaded on demand):
| Reference | Description |
|---|---|
| addon-catalog.md | Addon catalog |
| baseline-defaults.md | Baseline defaults |
| checkov-config.md | Checkov config |
| customization-guide.md | Customization guide |
| lessons-learned.md | Lessons learned |
| pattern-guide.md | Pattern guide |
| version-matrix.md | Version matrix |
Scripts:
| Script | Description |
|---|---|
| validate_project.sh | Validate_project |
Run a live EKS cluster cost efficiency assessment — analyze spending across 6 dimensions (compute efficiency, Spot/Graviton adoption, networking, storage, observability, idle resources), calculate a weighted 0-100 Cost Score, and generate a prioritized report with dollar-quantified findings and ready-to-apply remediation snippets. Use this skill when someone asks "how much am I wasting on EKS?", "run a cost audit on my cluster", "what's my biggest cost driver?", "analyze my cluster's cost efficiency", or needs dollar-denominated findings for a FinOps review — even if they don't say "cost intelligence" or "score". Combines live Cost Explorer data, CloudWatch utilization metrics, and Kubernetes resource analysis. Falls back to AWS CLI and kubectl when the EKS MCP server is unavailable. Distinct from eks-best-practices (static advisory guidance), eks-operation-review (operational health), and eks-recon (cluster discovery). Distinct from graviton-migration, which EXECUTES the x86→arm64 move, not scoring savings.
References (loaded on demand):
| Reference | Description |
|---|---|
| compute-efficiency.md | Compute efficiency |
| cost-data-collection.md | Cost data collection |
| cost-estimation-fallback.md | Cost estimation fallback |
| fargate-costs.md | Fargate costs |
| findings-format.md | Findings format |
| idle-resources.md | Idle resources |
| networking-costs.md | Networking costs |
| observability-costs.md | Observability costs |
| report-generation.md | Report generation |
| spot-graviton-adoption.md | Spot graviton adoption |
| storage-costs.md | Storage costs |
| waste-calculation.md | Waste calculation |
Tools:
| File | Description |
|---|---|
| report_to_html.py | Report_to_html |
Use when designing EKS architecture. Generates design documents with Mermaid diagrams, ADRs, security architecture, and validation reports. Translates requirements into tailored EKS designs guided by Well-Architected best practices. Covers cluster architecture, compute, networking, security, addons, observability, cost, and upgrade strategy. Also use when reviewing or validating existing EKS architectures, planning networking or security, evaluating deployment models, or generating architecture diagrams. Skip for short advisory recommendations without a formal document (eks-best-practices), Internal Developer Platforms or progressive delivery (eks-platform-engineering), and GenAI/LLM workload design — GPU vs Neuron, vLLM/Ray serving, distributed training (eks-genai).
References (loaded on demand):
| Reference | Description |
|---|---|
| architecture-validation.md | Architecture validation |
| output-structure.md | Output structure |
Use whenever someone is building, training, fine-tuning, or serving a generative AI / LLM workload on Amazon EKS — phrased as "GPU vs Trainium/Inferentia", "vLLM on EKS", "Ray Serve / KubeRay", "distributed training on EKS", "FSx for Lustre for ML", "Karpenter for GPU", "EFA / NCCL multi-node", "DCGM / Neuron Monitor", "LiteLLM / AI gateway", "RAG on EKS", "agentic AI on EKS", or "self-host Llama / Mistral / Qwen". Walks the opinionated 6-layer stack (compute → cluster/scheduler → frameworks → storage → observability → AI gateway), the GPU-vs-Neuron decision, the JARK + vLLM + LiteLLM canonical reference, KV-cache tiering, cost levers (Neuron, Spot, Capacity Blocks), and a non-negotiable security baseline. Trigger even if "GenAI" is never said — any GPU/Neuron, inference-serving, or distributed-training decision on EKS qualifies. Skip for SageMaker-only or Bedrock-only (no self-hosting) asks, and for generic cluster design/build with no AI/ML workload (use eks-design / eks-build).
References (loaded on demand):
| Reference | Description |
|---|---|
| agentic-and-rag.md | Agentic and rag |
| ai-gateway.md | Ai gateway |
| cluster-and-scheduling.md | Cluster and scheduling |
| compute-hardware.md | Compute hardware |
| distributed-training.md | Distributed training |
| inference-serving.md | Inference serving |
| kv-cache-and-cost.md | Kv cache and cost |
| observability.md | Observability |
| reference-implementations.md | Reference implementations |
| security-and-compliance.md | Security and compliance |
| storage.md | Storage |
| use-cases.md | Use cases |
Assess a live EKS cluster's NGINX/Ingress estate and plan migration to Gateway API, the AWS Load Balancer Controller (ALB Ingress), or AWS Transform (ATX). Discovers ingress controllers and routes, scores migration difficulty 0–100 with a separate re-architecture gate, and generates per-cluster reports plus ready-to-apply manifests. Use when someone asks "how hard is it to move off nginx ingress?", "assess my ingress migration", "migrate nginx to ALB or Gateway API", "ingress migration audit", or "nginx ingress retirement plan". Not for upgrade readiness (eks-upgrade-check), operational audits (eks-operation-review), general cluster discovery (eks-recon), or general ingress configuration advice (eks-best-practices).
References (loaded on demand):
| Reference | Description |
|---|---|
| alb-migration.md | Alb migration |
| atx-guide.md | Atx guide |
| dns-certificates.md | Dns certificates |
| gateway-api.md | Gateway api |
| ingress-discovery.md | Ingress discovery |
| ingress-resources.md | Ingress resources |
| migration-plan.md | Migration plan |
| migration-risk.md | Migration risk |
| report-generation.md | Report generation |
| traffic-routing.md | Traffic routing |
Tools:
| File | Description |
|---|---|
| report_to_html.py | Report_to_html |
Install, configure, and troubleshoot the EKS MCP Server connection in your AI assistant (Claude Code, Cursor, Kiro). Use ONLY for MCP server setup problems — config file location (.mcp.json), IAM permissions for eks-mcp actions, uvx installation, choosing AWS-hosted vs self-hosted mode, or debugging why MCP tools fail to appear after config. Also activate if user mentions "eks mcp", "mcp server", "mcp.json", or "mcp tools not showing". Do NOT use for actual cluster operations once MCP is working — those go to eks-recon (discovery), eks-operation-review (audits), or eks-upgrade-check (upgrades). For setting up the Arm migration MCP server used for arm64 readiness scanning, use graviton-migration, not this skill.
References (loaded on demand):
| Reference | Description |
|---|---|
| aws-hosted-setup.md | Aws hosted setup |
| self-hosted-setup.md | Self hosted setup |
Run a structured EKS operational excellence assessment against a live cluster. Covers 10 areas — networking, autoscaling, observability, access & identity, add-ons, workload config, deployments, cluster lifecycle, IaC, operational processes — and produces a GREEN/AMBER/RED rated report with prioritized recommendations. Activate for any request to audit, review, health-check, or score an EKS cluster's operational posture, including section-scoped reviews of individual areas. Not for upgrade readiness, cluster discovery, or architectural design advice.
References (loaded on demand):
| Reference | Description |
|---|---|
| access-identity.md | Access identity |
| addon-management.md | Addon management |
| autoscaling.md | Autoscaling |
| cluster-lifecycle.md | Cluster lifecycle |
| deployment-practices.md | Deployment practices |
| infrastructure-as-code.md | Infrastructure as code |
| networking.md | Networking |
| observability.md | Observability |
| operational-processes.md | Operational processes |
| report-generation.md | Report generation |
| workload-configuration.md | Workload configuration |
Tools:
| File | Description |
|---|---|
| report_to_html.py | Report_to_html |
Use whenever someone is designing or building an Internal Developer Platform (IDP) or doing platform engineering on Amazon EKS — phrased as "build a developer platform", "self-service for developers", "golden paths", "IDP", or "set up Backstage / ArgoCD / Kargo". Covers the opinionated platform stack — developer portal (Backstage), GitOps delivery (ArgoCD, Argo Workflows), progressive delivery (Argo Rollouts) and multi-stage promotion (Kargo), infrastructure abstraction (ACK, kro), the developer-facing app abstraction (Backstage templates + kro, or KubeVela/OAM), self-service provisioning, hub-and-spoke topology with the GitOps Bridge, identity/SSO (Keycloak, Pod Identity), measuring success (DORA, Apache DevLake), GenAI-assisted platform engineering (Kiro), and golden paths for AI/ML and data. Trigger even if "platform engineering" is never said. Skip for single-cluster EKS architecture or cost/ops tuning with no platform angle (use eks-best-practices); for standalone Terraform use terraform-skill.
References (loaded on demand):
| Reference | Description |
|---|---|
| aiml-data-platform.md | Aiml data platform |
| application-model-oam.md | Application model oam |
| developer-portal-backstage.md | Developer portal backstage |
| genai-platform-engineering.md | Genai platform engineering |
| gitops-delivery.md | Gitops delivery |
| golden-paths.md | Golden paths |
| identity-and-tenancy.md | Identity and tenancy |
| idp-architecture.md | Idp architecture |
| infrastructure-abstraction.md | Infrastructure abstraction |
| measuring-success.md | Measuring success |
| progressive-delivery.md | Progressive delivery |
EKS cluster reconnaissance and environment discovery — reports the raw FACTS of a cluster and its environment. Detects compute (Karpenter, MNG, Auto Mode, Fargate, nodes/AMI), networking (VPC/CNI, subnets, load balancers, DNS), security facts (auth mode, IRSA/Pod Identity, RBAC, encryption), add-ons/Helm, observability, workloads (Deployments, StatefulSets, PDBs, HPAs), storage (CSI, StorageClasses, PVs, backup tooling), IaC (Terraform, CDK, eksctl), CI/CD (Actions, ArgoCD, Flux), and cluster insights. Use to discover or document the current state of an EKS cluster — 'what am I running', 'tell me about my setup', 'what version am I on', inventory before an upgrade/migration/design. Reports facts only; it does not score, rate, plan, or recommend, and overlapping facts with other skills is fine. Route elsewhere for a JUDGMENT or ARTIFACT: readiness scoring/deprecated-API checks (eks-upgrade-check), GREEN/AMBER/RED audits (eks-operation-review), design docs/diagrams (eks-design).
References (loaded on demand):
| Reference | Description |
|---|---|
| addons.md | Addons |
| cicd.md | Cicd |
| cluster-basics.md | Cluster basics |
| cluster-insights.md | Cluster insights |
| compute.md | Compute |
| iac.md | Iac |
| networking.md | Networking |
| observability.md | Observability |
| security.md | Security |
| storage.md | Storage |
| workloads.md | Workloads |
Agents:
| File | Description |
|---|---|
| addons-recon.md | Addons recon |
| cicd-recon.md | Cicd recon |
| cluster-insights-recon.md | Cluster insights recon |
| compute-recon.md | Compute recon |
| iac-recon.md | Iac recon |
| networking-recon.md | Networking recon |
| observability-recon.md | Observability recon |
| security-recon.md | Security recon |
| storage-recon.md | Storage recon |
| workloads-recon.md | Workloads recon |
Use whenever someone needs security or compliance guidance for Amazon EKS — phrased as "CIS Benchmark for EKS", "HIPAA / PCI-DSS / FedRAMP / SOC 2 / GDPR on EKS", "harden my EKS cluster", "Bottlerocket vs AL2023 vs RHEL/Ubuntu AMI", "EKS Pod Identity vs IRSA", "Access Entries vs aws-auth", "GuardDuty for EKS", "Pod Security Admission / Kyverno / OPA", "NetworkPolicy / Security Groups for Pods", "ECR scanning / image signing (Cosign / Notation)", "EKS audit logging", "etcd / secrets encryption", or regulated-workload / audit-prep guidance. Walks the discovery-driven 7-layer security stack (OS/AMI → identity → workload → image → runtime → audit → compliance accelerators), the compliance-regime scope view, the AWS-canonical baseline, and a 30/60/90 hardening roadmap. Trigger even if "compliance" is never said — any EKS hardening, audit-prep, or regulated-workload decision qualifies. Skip for non-EKS (ECS/ROSA), account-level security with no EKS angle, or GenAI-workload security (use eks-genai).
References (loaded on demand):
| Reference | Description |
|---|---|
| audit-logging.md | Audit logging |
| auto-mode-security.md | Auto mode security |
| compliance-accelerators.md | Compliance accelerators |
| compliance-regimes.md | Compliance regimes |
| encryption-and-secrets.md | Encryption and secrets |
| engagement-and-response.md | Engagement and response |
| identity-and-access.md | Identity and access |
| image-supply-chain.md | Image supply chain |
| incident-response-and-forensics.md | Incident response and forensics |
| multi-tenancy.md | Multi tenancy |
| os-ami-hardening.md | Os ami hardening |
| runtime-security.md | Runtime security |
| workload-security.md | Workload security |
Assess EKS cluster upgrade readiness — run automated checks across 8 areas (version, breaking changes, deprecated APIs, add-on compatibility, node readiness, workload risks, AWS Insights, upgrade plan), calculate a 0-100 readiness score with a hard-blocker override, and generate a markdown/HTML report with prioritized remediation. Use this skill whenever someone asks "can I upgrade my cluster?", "is my cluster ready for 1.32?", "are we good to go to 1.33?", "what is blocking my upgrade?", or "should we move to the next version?" — even if they do not say "readiness" or "score". Falls back to AWS CLI and kubectl when the EKS MCP server is unavailable.
References (loaded on demand):
| Reference | Description |
|---|---|
| addon-compatibility.md | Addon compatibility |
| breaking-changes.md | Breaking changes |
| deprecated-apis.md | Deprecated apis |
| node-readiness.md | Node readiness |
| report-generation.md | Report generation |
| upgrade-insights.md | Upgrade insights |
| version-validation.md | Version validation |
| workload-risks.md | Workload risks |
Data:
| File | Description |
|---|---|
| oss_addon_registry.json | Oss_addon_registry |
Tools:
| File | Description |
|---|---|
| md_to_html.py | Md_to_html |
Use when choosing and architecting an Amazon ECS deployment model for a NEW workload — Fargate vs ECS on EC2 vs Managed Instances vs Express Mode vs ECS Anywhere/External — plus capacity-provider strategy, task sizing, awsvpc/ENI density, networking, service parameters, and launch-type or topology migration (EC2 launch type to capacity providers/Managed Instances; Service Discovery to Service Connect). Also the shared ECS best-practices corpus. Triggers include "which ECS launch type", "Fargate or EC2", "should I use Managed Instances", "migrate off EC2 launch type", "App Mesh to Service Connect", "migrate off App Runner". Skip for existing-app replatform (ecs-modernize); auditing a live estate (ecs-operation-review); cost/TCO (ecs-cost-intelligence); inventory (ecs-recon); security (ecs-security); deployment/CICD (ecs-devops); observability (ecs-observability); GPU/ML design AND GPU launch-type choice (ecs-genai); Kubernetes/EKS (eks-design); Terraform generation of a settled design (use ecs-build).
References (loaded on demand):
| Reference | Description |
|---|---|
| architecture-design.md | Architecture design |
| best-practices-corpus.md | Best practices corpus |
| capacity-and-scaling.md | Capacity and scaling |
| launch-type-migration.md | Launch type migration |
| model-selection-framework.md | Model selection framework |
| networking-and-eni-density.md | Networking and eni density |
Use when building Amazon ECS infrastructure with Terraform, generating apply-ready code for ECS clusters, services, and task definitions across three capacity models — Fargate (FARGATE_SPOT as capacity provider), EC2 Auto Scaling group providers, and ECS Managed Instances. Covers rolling/blue-green/linear/canary deployment config, Express services, Service Connect, private/VPC-endpoint-only networking, secrets, and Graviton. Also use when (1) wiring a Managed Instances capacity provider and its infrastructure IAM role, (2) mixing FARGATE and FARGATE_SPOT in a strategy, (3) rendering the Terraform deployment configuration for a blue/green, linear, or canary strategy, (4) generating VPC endpoints for private or air-gapped ECS, (5) configuring Application Auto Scaling, or (6) rendering the migration of a service from launch type to capacity providers. Skip for EKS/Kubernetes builds (use eks-build), design and launch-type selection (use ecs-architect), CI/CD pipelines and release strategy (use ecs-devops).
References (loaded on demand):
| Reference | Description |
|---|---|
| autoscaling.md | Autoscaling |
| baseline-defaults.md | Baseline defaults |
| capacity-provider-guide.md | Capacity provider guide |
| networking-security.md | Networking security |
| service-and-deployment.md | Service and deployment |
| task-definition-guide.md | Task definition guide |
| version-matrix.md | Version matrix |
Scripts:
| Script | Description |
|---|---|
| validate_project.sh | Validate_project |
Use when someone is deploying, releasing, or shipping software to Amazon ECS — phrased as "blue/green deployment on ECS", "canary deployment for my ECS service", "set up CI/CD for ECS", "GitHub Actions deploy to Fargate", "my ECS deployment is stuck", "ECS deployment circuit breaker", "ECS task sets", or "migrate off CodeDeploy blue/green". Covers strategy selection (rolling/blue-green/linear/canary), lifecycle hooks, circuit-breaker and alarm rollback, and pipelines (CodePipeline, GitHub Actions, ECR scanning) — scoped per launch type (EC2, Fargate, Managed Instances, ECS Anywhere). Trigger even if "deployment strategy" is never said — any release-safety, traffic-shifting, rollback, or pipeline decision for an ECS service qualifies. Skip for EKS/Kubernetes (use eks-* skills) and greenfield ECS architecture with no release angle (use ecs-architect for design and ecs-build for Terraform generation incl. deployment config blocks). For ECS monitoring stacks use ecs-observability; for GPU/ML on ECS use ecs-genai.
References (loaded on demand):
| Reference | Description |
|---|---|
| cicd-pipelines.md | Cicd pipelines |
| controllers-and-migration.md | Controllers and migration |
| deployment-strategies.md | Deployment strategies |
| failure-detection-and-rollback.md | Failure detection and rollback |
Use whenever someone runs a GPU / ML / GenAI / LLM workload on Amazon ECS: GPU on ECS, ECS GPU-optimized AMI, g4dn/g5/g6/p4/p5 on ECS, which ECS launch type for GPU, Inferentia/Trainium/Neuron on ECS, distributed training, model inference or vLLM/Triton/TGI/Ray on ECS, Capacity Blocks, GPU sharing, ASG per GPU type. Covers GPU on ECS-on-EC2 and ECS Managed Instances (GPU AMIs, NVIDIA runtime, instance families); mixed-instance ASGs supported but constrained (no weighting; managed scaling protects on the smallest type); Capacity Blocks; inference/serving; Neuron; distributed ML; GPU observability; a GPU/ML security slice (PCI/HIPAA). AWS Fargate has NO GPU: use ECS-on-EC2, Managed Instances, ECS Anywhere, or keep Fargate and call Bedrock. Trigger even if GenAI is unsaid. Use eks-genai for Kubernetes/EKS; SageMaker for fully-managed ML; Bedrock for managed foundation models; ecs-architect for non-accelerator ECS design; ecs-build to render the settled design as Terraform; ecs-security for deep compliance.
References (loaded on demand):
| Reference | Description |
|---|---|
| capacity-and-scaling.md | Capacity and scaling |
| compute-hardware.md | Compute hardware |
| distributed-training.md | Distributed training |
| inference-serving.md | Inference serving |
| neuron-on-ecs.md | Neuron on ecs |
| observability.md | Observability |
| security-and-compliance.md | Security and compliance |
| service-boundaries.md | Service boundaries |
| storage.md | Storage |
| use-cases.md | Use cases |
Advise on Amazon ECS observability architecture — select the logs/metrics/traces stack (CloudWatch, Container Insights, X-Ray, ADOT/OpenTelemetry, Managed Prometheus/Grafana, FireLens to third-party) by compliance needs, existing tooling, scale, budget, and launch types (EC2, Fargate, Managed Instances, ECS Anywhere). Use for "how should we monitor our ECS services", "Container Insights or Prometheus for ECS", "are we losing ECS container logs", "set up tracing on Fargate", "ECS logging best practices", "Datadog vs CloudWatch for ECS", "GPU metrics for ECS tasks", or "plan live-debug access to an ECS task". Any ECS logging, metrics, tracing, or alerting design question qualifies even if "observability" is never said. Skip for EKS/Kubernetes (eks-* skills), deployment mechanics/CI-CD/deploy-failure diagnosis (ecs-devops; deploy-failure alerting stays here), security posture beyond observability audit logging (ecs-security), live-estate audits (ecs-operation-review), and FinOps audits of observability spend.
References (loaded on demand):
| Reference | Description |
|---|---|
| launch-type-matrix.md | Launch type matrix |
| log-delivery.md | Log delivery |
| metrics-stacks.md | Metrics stacks |
| native-visibility-and-exec.md | Native visibility and exec |
| tracing-and-signals.md | Tracing and signals |
Run a structured Amazon ECS operational-excellence assessment against a live estate (Fargate/EC2/Managed Instances/ECS Anywhere) and score it GREEN/AMBER/RED. Skip for EKS/Kubernetes (use eks-operation-review). Covers 8 domains — clusters & capacity, networking, task definitions, services & deployment safety (circuit breaker, blue/green, canary), service health & autoscaling (grace period, draining, AZ rebalancing), observability, security posture, and operational processes — producing a rated report with prioritized actions. Activate for "audit my ECS estate", "ECS health check", "score my ECS posture", "review my ECS services", "GREEN/AMBER/RED my ECS clusters", including single-domain reviews. For Day-0 design use ecs-architect; for security hardening use ecs-security; for cost/TCO use ecs-cost-intelligence; for observability design use ecs-observability; for CI/CD engineering use ecs-devops; for replatform/refactor use ecs-modernize; for read-only inventory use ecs-recon (siblings once available).
References (loaded on demand):
| Reference | Description |
|---|---|
| cluster-capacity.md | Cluster capacity |
| networking.md | Networking |
| observability.md | Observability |
| operational-processes.md | Operational processes |
| report-generation.md | Report generation |
| scoring-rubric.md | Scoring rubric |
| security-posture.md | Security posture |
| service-health-scaling.md | Service health scaling |
| services-deployment.md | Services deployment |
| task-definitions.md | Task definitions |
Tools:
| File | Description |
|---|---|
| report_to_html.py | Report_to_html |
ECS environment reconnaissance and discovery. Detects compute and capacity providers, task definitions, deployment configuration, auto scaling, networking, security posture, observability, and IaC/CI-CD tooling. Use when someone asks about their ECS environment, wants to describe a cluster, inspect a service, or document task definitions — even without naming the skill. Applies to Amazon ECS, not Amazon EKS (use eks-recon). Discovers current state only — does not score, audit, or design. Skip for operational audits and GREEN/AMBER/RED scoring (ecs-operation-review), deployment-model design, launch-type selection, and ECS best practices (ecs-architect), deployment strategy design and CI/CD engineering (ecs-devops), GPU/ML workloads (ecs-genai), security and compliance (ecs-security), cost/TCO (ecs-cost-intelligence, once available), observability design (ecs-observability), and replatform/migration (ecs-modernize, once available).
References (loaded on demand):
| Reference | Description |
|---|---|
| autoscaling.md | Autoscaling |
| cicd.md | Cicd |
| compute.md | Compute |
| deployment.md | Deployment |
| iac.md | Iac |
| networking.md | Networking |
| observability.md | Observability |
| overview.md | Overview |
| security.md | Security |
| task-definitions.md | Task definitions |
Security and compliance guidance for Amazon ECS — "ECS was unable to assume the role", task role vs execution role, iam:PassRole, confused-deputy aws:SourceArn trust, Fargate vs EC2 shared responsibility, injecting Secrets Manager/SSM secrets (trailing-colon JSON-key gotcha), readonlyRootFilesystem / non-root / drop capabilities, ECS Exec governance, security-group-per-task, VPC endpoint policies, GuardDuty ECS Runtime Monitoring, ECR Inspector scanning, image signing, Fargate FIPS, or PCI/HIPAA/FedRAMP. Walks a discovery-driven 7-layer stack plus the AWS-canonical baseline and a 30/60/90 roadmap. Trigger even if "compliance" is never said — any ECS hardening, task-trust fix, or secrets-injection qualifies. Skip for EKS/Kubernetes (eks-security), GenAI/GPU security (ecs-genai), App Runner/Lambda, auditing a live estate's operational posture (ecs-operation-review — "audit my ECS security posture" matches both), or account-level security with no ECS angle.
References (loaded on demand):
| Reference | Description |
|---|---|
| audit-logging.md | Audit logging |
| compliance-accelerators.md | Compliance accelerators |
| compliance-regimes.md | Compliance regimes |
| encryption-and-secrets.md | Encryption and secrets |
| engagement-and-response.md | Engagement and response |
| identity-and-access.md | Identity and access |
| image-supply-chain.md | Image supply chain |
| incident-response-and-forensics.md | Incident response and forensics |
| network-isolation.md | Network isolation |
| runtime-security.md | Runtime security |
| shared-responsibility.md | Shared responsibility |
| task-container-hardening.md | Task container hardening |
Execute a workload migration from x86 (amd64) to AWS Graviton (arm64) — set up the Arm migration MCP server for code, dependency, and container arm64-readiness scanning, then run the migration — pre-migration scanning, Karpenter arm64 node cutover, and multi-arch CI pipelines. Use when someone says "migrate to Graviton", "move my workloads to arm64", "is my app arm64-ready", "graviton migration", "port this service to Graviton", "scan my code for arm64 blockers", "set up multi-arch container builds", or "cut my nodes over to arm64". This skill owns migration EXECUTION (readiness scanning, NodePool cutover, multi-arch builds). Do NOT use for scoring Graviton cost savings, quantifying Spot/Graviton adoption, or "how much would Graviton save me?" (use eks-cost-intelligence); for advisory "should I use Graviton?" architecture guidance (use eks-best-practices); or for general, non-Graviton MCP server setup like the EKS MCP server (use eks-mcp-server).
References (loaded on demand):
| Reference | Description |
|---|---|
| agent-scope-boundaries.md | Agent scope boundaries |
| dependency-knowledge.md | Dependency knowledge |
| karpenter-migration.md | Karpenter migration |
| multi-arch-pipelines.md | Multi arch pipelines |
| perf-validation.md | Perf validation |
| scanner-workflow.md | Scanner workflow |
Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.
References (loaded on demand):
| Reference | Description |
|---|---|
| schemas.md | Schemas |
Scripts:
| Script | Description |
|---|---|
| init.py | init |
| aggregate_benchmark.py | Aggregate_benchmark |
| generate_report.py | Generate_report |
| improve_description.py | Improve_description |
| package_skill.py | Package_skill |
| quick_validate.py | Quick_validate |
| run_eval.py | Run_eval |
| run_loop.py | Run_loop |
| utils.py | Utils |
Assets:
| Asset | Description |
|---|---|
| eval_review.html | Eval_review |
Agents:
| File | Description |
|---|---|
| analyzer.md | Analyzer |
| comparator.md | Comparator |
| grader.md | Grader |
Eval viewer:
| File | Description |
|---|---|
| generate_review.py | Generate_review |
| viewer.html | Viewer |
Author a new steering workflow for any AWS service and pair it with a matching slash-command shim. Use when the user asks to create a steering workflow, add a workflow to apex, standardize steering, write a new workflow for EKS / RDS / Lambda / IAM / any AWS service, or build a phased playbook that plugs into a service hub. Covers the convention (frontmatter, header block, required sections), tool routing (knowledge vs. live MCP vs. setup-bridge), and the lint pass before handoff.
References (loaded on demand):
| Reference | Description |
|---|---|
| anti-patterns.md | Anti patterns |
| convention.md | Convention |
| tool-routing.md | Tool routing |
Scripts:
| Script | Description |
|---|---|
| quick_validate.py | Quick_validate |
Assets:
| Asset | Description |
|---|---|
| command-shim-skeleton.md | Command shim skeleton |
| workflow-skeleton.md | Workflow skeleton |
Use when writing, reviewing, or debugging Terraform/OpenTofu modules, tests, CI, scans, or state ops - diagnoses failure mode (identity churn, secrets, blast radius, CI drift, state corruption) with version-aware guards.
References (loaded on demand):
| Reference | Description |
|---|---|
| ci-cd-workflows.md | Ci cd workflows |
| code-intelligence-lsp.md | Code intelligence lsp |
| code-patterns.md | Code patterns |
| module-patterns.md | Module patterns |
| quick-reference.md | Quick reference |
| security-compliance.md | Security compliance |
| state-management.md | State management |
| testing-frameworks.md | Testing frameworks |
Audit and update every documentation surface in the APEX repo against the current state of skills, steering workflows, README marker tables, and the Docusaurus site under misc/website/. After any change to a skill (rename, retire, add, edit description), walk the repo, re-run script-managed surfaces if their --check fails, and reason through every tracked prose *.md to catch references that need updating. Use after adding/removing/renaming a skill, after editing SKILL.md frontmatter, after editing README marker blocks, or before publishing a docs change. Also use when the user says "update docs", "sync docs", "check docs", "run update-docs", or mentions that documentation might be stale.
Skills use progressive disclosure to manage context efficiently:
-
Discovery: At startup, agents load only the name and description of each available skill, just enough to know when it might be relevant.
-
Activation: When a task matches a skill's description, the agent reads the full
SKILL.mdinstructions into context. -
Execution: The agent follows the instructions, optionally loading referenced files or executing bundled code as needed.
This approach keeps agents fast while giving them access to more context on demand.
Every skill starts with a SKILL.md file containing YAML frontmatter and Markdown instructions:
---
name: pdf-processing
description: Extract PDF text, fill forms, merge files. Use when handling PDFs.
---
# PDF Processing
## When to use this skill
Use this skill when the user needs to work with PDF files...
## How to extract text
1. Use pdfplumber for text extraction...
## How to fill forms
...The following frontmatter is required at the top of SKILL.md:
name: A short identifierdescription: When to use this skill
The Markdown body contains the actual instructions and has no specific restrictions on structure or content.
This simple format has some key advantages:
- Self-documenting: A skill author or user can read a
SKILL.mdand understand what it does, making skills easy to audit and improve. - Extensible: Skills can range in complexity from just text instructions to executable code, assets, and templates.
- Portable: Skills are just files, so they're easy to edit, version, and share.
- View the specification to understand the full format.
- Add skills support to your agent to build a compatible client.
- See example skills on GitHub.
- Read authoring best practices for writing effective skills.
- Use the reference library to validate skills and generate prompt XML.
Every team-owned skill has a matching evaluation entry under misc/evals/ — a triggering.json for trigger-accuracy tests and an evals.json for end-to-end task-usefulness tests, both runnable via the tooling in skills/skill-creator/. Vendored skills (skill-creator, terraform-skill) are excluded since they're maintained upstream. See misc/evals/README.md for the capability catalogue and how to run each eval type.