@raishin/vanguard-frontier-agentic 2.8.0 → 2.9.0

package/skills/aws/aws-ec2-compute-operations-steward/references/workflow-and-output.md

@@ -19,7 +19,7 @@ Check these areas before giving a verdict:
    - Required outcome:
    - Explicit non-goals:
 2. **Collect evidence**
-   - Prefer live AWS MCP read-only evidence if available.
+   - Prefer read-only AWS MCP or read-only AWS CLI evidence for current-state claims when available.
    - Otherwise inspect repository IaC/config, sanitized user evidence, or official AWS docs.
    - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
 3. **Stress-test risk**

package/skills/aws/aws-ecs-fargate-platform-operator/SKILL.md

@@ -4,8 +4,8 @@ description: Review Amazon ECS and Fargate platform operations across services,
 allowed-tools: Read Grep Glob
 metadata:
   author: "github: Raishin"
-  version: "0.1.2"
-  updated: "2026-05-05"
+  version: "0.1.4"
+  updated: "2026-06-02"
   category: platform
 ---
 
@@ -26,7 +26,7 @@ Use this skill for:
 
 ## Lean operating rules
 
-- Prefer `AwsDocumentationMcpServer` when available via `uvx awslabs.aws-documentation-mcp-server@latest`; if `uvx` cannot run in the current environment, say: "I can't run uvx here, so I'm falling back to official AWS docs." Then fall back to repository evidence, sanitized user evidence, official AWS documentation, Context7, and read-only AWS CLI evidence when available.
+- Prefer current AWS documentation tools for service behavior. Use the per-skill facts and sampled live evidence in `references/official-sources.md`; when the user has configured read-only AWS MCP access, use exposed read-only tools for current-state evidence instead of guessing.
 - Separate confirmed facts from inference. If state was not queried or shown, say so.
 - Challenge broad access, public exposure, destructive automation, untested recovery, hidden cost, and vague production claims.
 - Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.
@@ -39,6 +39,7 @@ Load these only when needed:
 - [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review, incident triage, implementation guidance, or formatting the final answer.
 - [Safety checklist](references/safety-checklist.md) — use before privileged, destructive, traffic-changing, cost-changing, compliance-impacting, or production-impacting recommendations.
 - [Official sources](references/official-sources.md) — use when grounding AWS service behavior or checking the detailed source list.
+- [ECS Fargate Service Safety Guide](references/ecs-fargate-service-safety.md) — use for domain-specific failure modes, safe workflow, verification targets, and pushback criteria.
 
 ## Response minimum
 

package/skills/aws/aws-ecs-fargate-platform-operator/metadata.json

@@ -14,14 +14,14 @@
   "summary": "Review Amazon ECS and Fargate services across task roles, execution roles, deployment circuit breakers, blue/green, load balancing, autoscaling, logging, networking, and rollback.",
   "source_type": "original",
   "official_docs": [
-    "https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-failure-detection.html",
-    "https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-circuit-breaker.html",
-    "https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-type-blue-green.html",
-    "https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security-iam-roles.html"
+    "https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html",
+    "https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_execution_IAM_role.html",
+    "https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-deployment.html",
+    "https://docs.aws.amazon.com/AmazonECS/latest/developerguide/troubleshooting.html"
   ],
   "security_notes": "Do not approve ECS/Fargate production changes without task-role separation, deployment rollback behavior, health check evidence, logs, secrets posture, and load balancer/target group validation.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-ecs-fargate-platform-operator",
   "author": "github: Raishin",
-  "version": "0.1.2"
+  "version": "0.1.4"
 }

package/skills/aws/aws-ecs-fargate-platform-operator/references/ecs-fargate-service-safety.md

@@ -0,0 +1,59 @@
+# ECS Fargate Service Safety Guide
+
+Use this reference for Amazon ECS/Fargate platform reviews covering services, task definitions, task role vs execution role, capacity providers, load balancers, deployment circuit breakers, blue/green, autoscaling, health checks, logs, secrets, networking, and rollback.
+
+## What people get wrong
+
+The lazy story is:
+
+> ECS service stable means the platform is healthy.
+
+Wrong. Stable desired count can hide overprivileged task roles, broken health checks, missing circuit breakers, wrong image tags, secret exposure, capacity-provider drift, and weak rollback.
+
+Common bad assumptions:
+
+- Task role and execution role can share permissions.
+- Latest task definition revision is safe.
+- Fargate removes capacity and networking concerns.
+- ALB health checks prove application correctness.
+- Circuit breaker is enough without alarms and rollback validation.
+- Secrets in task definition references are safe without IAM/KMS review.
+
+## ECS/Fargate failure modes
+
+- Execution role cannot pull images, publish logs, or fetch secrets; task role has broad app permissions.
+- Task definition changes CPU/memory, ports, env vars, logging, secrets, or image tag unexpectedly.
+- Deployment min/max healthy percent, circuit breaker, or CodeDeploy blue/green settings cause outage or no rollback.
+- Target group health check path/port/grace period hides app startup failure.
+- Subnet/security group/assignPublicIp/service discovery settings expose or isolate tasks incorrectly.
+- Autoscaling follows CPU while bottleneck is queue depth, latency, memory, or downstream throttling.
+
+## Minimum safe workflow
+
+1. Identify cluster, service, launch type, deployment controller, task definition family, target groups, and capacity provider strategy.
+2. Review task definition diffs: image digest/tag, CPU/memory, ports, env/secrets, logs, roles, health checks, and platform version.
+3. Separate execution role from task role and verify least privilege for ECR, CloudWatch Logs, Secrets Manager, SSM, KMS, and app APIs.
+4. Check deployment safety: circuit breaker, alarms, desired count, min/max healthy percent, blue/green hooks, and rollback revision.
+5. Review networking and exposure: subnets, security groups, public IPs, load balancer, service discovery, and VPC endpoints.
+6. Validate observability: service events, stopped task reasons, target health, logs, metrics, and deployment state changes.
+7. Require approval before update-service, force-new-deployment, task definition registration, or scaling changes.
+
+## Verification targets
+
+- ECS service definition, deployments, events, desired/running/pending counts, deployment controller, and circuit breaker
+- task definition image digest, CPU/memory, roles, secrets, logging, health checks, ports, volumes, and platform version
+- task execution role and task role IAM/KMS/Secrets Manager/ECR/CloudWatch Logs permissions
+- ALB/NLB target groups, health check path/port/grace, listener rules, and target health
+- capacity providers, Fargate/Fargate Spot mix, autoscaling policies, CloudWatch alarms, and queue/business metrics
+- CodeDeploy AppSpec, lifecycle hooks, alarms, rollback config, and previous task definition target
+
+## When to push back
+
+Push back if the user asks to:
+
+- force new deployment without root-cause evidence
+- widen task or execution role blindly
+- deploy mutable image tags without digest/provenance
+- disable health checks or circuit breakers to reach steady state
+- scale desired count to hide crash loops
+- treat service stable as proof of security or readiness

package/skills/aws/aws-ecs-fargate-platform-operator/references/official-sources.md

@@ -5,11 +5,25 @@ Use this reference only when you need source grounding for AWS service behavior
 ## AWS documentation
 
 Use these as starting points, not as proof of the user's live AWS state:
-- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-failure-detection.html
-- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-circuit-breaker.html
-- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-type-blue-green.html
-- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security-iam-roles.html
+- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html
+- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_execution_IAM_role.html
+- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-deployment.html
+- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/troubleshooting.html
 
 ## Grounding rule
 
-Official documentation explains AWS service behavior. It does not prove the user's current account, Region, quota, resource configuration, IAM boundary, pricing, or operational state. Prefer live AWS MCP/CLI evidence or sanitized user-provided evidence for current-state claims.
+Official documentation explains AWS service behavior. It does not prove the user's current account, Region, quota, resource configuration, IAM boundary, pricing, entitlement, or operational state. Prefer read-only AWS MCP or CLI evidence, repository evidence, or sanitized user-provided evidence for current-state claims.
+
+## Current MCP/documentation refresh (2026-06-02)
+
+Service facts from official docs:
+- Fargate for ECS provides serverless container management with task definitions, platform versions, capacity providers, service load balancing, and usage metrics.
+- The ECS task execution role lets the ECS agent perform AWS API calls such as pulling ECR images, retrieving Secrets Manager or Systems Manager values, and accessing configured storage; it is distinct from the application task role.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported Amazon ECS and AWS Fargate as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Sampled APIs `ECS+DescribeServices` and `ECS+DescribeTasks` were reported `isAvailableIn` in those regions.
+
+Review implications:
+- Require evidence for task role vs execution role separation, image-pull path, secrets access, network mode/security groups, load balancer health, deployment controller, circuit breaker/rollback, logs, and autoscaling.
+- Fargate availability does not prove platform-version compatibility, quota, subnet capacity, or service health in the user's account.

package/skills/aws/aws-ecs-fargate-platform-operator/references/safety-checklist.md

@@ -5,10 +5,10 @@ Use this reference before privileged, destructive, traffic-changing, cost-changi
 ## Non-negotiables
 
 - Never ask users to paste secrets, access keys, session tokens, private keys, customer identifiers, or sensitive account data into chat.
-- Prefer official AWS MCP tools when exposed by the active runtime. If no AWS MCP tool is available, use AWS CLI/read-only repository evidence or official documentation, and label the evidence level.
+- Use read-only AWS MCP or read-only AWS CLI evidence for live state when available; otherwise use repository evidence, sanitized user evidence, or official documentation and label the evidence level.
 - Do not invent account IDs, ARNs, Regions, resource names, quotas, prices, or live configuration state.
 - Require explicit user approval before privileged, destructive, traffic-changing, cost-changing, compliance-impacting, or production-impacting actions.
-- Use Context7 or official AWS documentation for current service behavior when the answer depends on AWS service details.
+- Use current official AWS documentation for service behavior when the answer depends on AWS service details.
 - Keep remediation least-privilege, reversible, and scoped to the requested workload or account boundary.
 
 ## Stress checks

package/skills/aws/aws-ecs-fargate-platform-operator/references/workflow-and-output.md

@@ -19,7 +19,7 @@ Check these areas before giving a verdict:
    - Required outcome:
    - Explicit non-goals:
 2. **Collect evidence**
-   - Prefer live AWS MCP read-only evidence if available.
+   - Prefer read-only AWS MCP or read-only AWS CLI evidence for current-state claims when available.
    - Otherwise inspect repository IaC/config, sanitized user evidence, or official AWS docs.
    - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
 3. **Stress-test risk**

package/skills/aws/aws-ecs-service-remediation-operator/SKILL.md

@@ -4,8 +4,8 @@ description: Correct AWS ECS and Fargate service definitions, task definition co
 allowed-tools: Read Edit Write MultiEdit Grep Glob
 metadata:
   author: "github: Raishin"
-  version: "0.1.0"
-  updated: "2026-05-05"
+  version: "0.1.2"
+  updated: "2026-06-02"
   category: platform
 ---
 
@@ -25,7 +25,7 @@ Use this skill for:
 
 ## Lean operating rules
 
-- Prefer `AwsDocumentationMcpServer` when available via `uvx awslabs.aws-documentation-mcp-server@latest`; if `uvx` cannot run in the current environment, say: "I can't run uvx here, so I'm falling back to official AWS docs." Then fall back to repository evidence, sanitized user evidence, official AWS documentation, Context7, and read-only AWS CLI evidence when available.
+- Prefer current AWS documentation tools for service behavior. Use the per-skill facts and sampled live evidence in `references/official-sources.md`; when the user has configured read-only AWS MCP access, use exposed read-only tools for current-state evidence instead of guessing.
 - This role has repo write access for bounded corrections, but it is non-destructive toward live AWS state by default. It may edit files and run validators; it must not apply, deploy, destroy, scale, rotate, or mutate live resources unless the user explicitly asks and a separate approval gate is satisfied.
 - Separate confirmed facts from inference. If state was not queried or shown, say so.
 - Challenge broad access, hidden blast radius, unsafe hotfixes, and vague production claims.
@@ -39,6 +39,7 @@ Load these only when needed:
 - [Workflow and output contract](references/workflow-and-output.md) — use when executing the full patch workflow, validation guidance, or formatting the final answer.
 - [Safety checklist](references/safety-checklist.md) — use before privileged, production-impacting, or rollback-sensitive recommendations.
 - [Official sources](references/official-sources.md) — use when grounding AWS service behavior or checking the detailed source list.
+- [ECS Remediation Playbook](references/ecs-remediation-playbook.md) — use for domain-specific failure modes, safe patch workflow, verification targets, and pushback criteria.
 
 ## Response minimum
 

package/skills/aws/aws-ecs-service-remediation-operator/metadata.json

@@ -14,13 +14,14 @@
   "summary": "Correct ECS/Fargate service definitions, task settings, deployment parameters, and environment configuration in-repo with bounded write access and no live service mutation by default.",
   "source_type": "original",
   "official_docs": [
-    "https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html",
-    "https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html",
-    "https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-type-ecs.html"
+    "https://docs.aws.amazon.com/AmazonECS/latest/developerguide/troubleshooting.html",
+    "https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-deployment.html",
+    "https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_execution_IAM_role.html",
+    "https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html"
   ],
   "security_notes": "Repo write access only. Do not force new deployments, scale services, or alter live task state from this role by default. Surface rollout and rollback implications explicitly.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-ecs-service-remediation-operator",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.2"
 }

package/skills/aws/aws-ecs-service-remediation-operator/references/ecs-remediation-playbook.md

@@ -0,0 +1,59 @@
+# ECS Remediation Playbook
+
+Use this reference when correcting ECS/Fargate task definitions, services, deployment parameters, load balancer health checks, secrets, logging, capacity providers, or CodeDeploy blue/green wiring in repository files.
+
+## What people get wrong
+
+The lazy story is:
+
+> ECS service is unhealthy, so tweak desired count or task definition and redeploy.
+
+Wrong. ECS failures often come from task role/execution role confusion, image pull, secrets, target health, capacity provider, deployment controller, or container health checks.
+
+Common bad assumptions:
+
+- Task role and execution role are interchangeable.
+- Increasing desired count fixes failing tasks.
+- Health check grace period can hide root cause.
+- Latest task definition revision is automatically safe.
+- Container logs are enough without service events and target health.
+- A repo service definition fix authorizes forcing a new deployment.
+
+## Failure-mode map
+
+- **Image pull:** ECR permissions, VPC endpoints, registry creds, platform architecture.
+- **Startup:** env var/secrets, command/entrypoint, health check, dependency readiness.
+- **Networking:** subnet, security group, assignPublicIp, target group, service discovery.
+- **IAM:** task role for app calls, execution role for pull/log/secrets.
+- **Capacity:** Fargate quota, capacity provider weights/base, CPU/memory mismatch.
+- **Deployment:** circuit breaker, min/max healthy percent, CodeDeploy task sets, alarms.
+
+## Minimum safe workflow
+
+1. Identify service, cluster, launch type, deployment controller, and task definition family.
+2. Correlate service events, stopped-task reasons, target health, and logs before patching.
+3. Patch only the repo field tied to the evidence.
+4. Preserve rollback task definition or previous service config.
+5. Validate IaC/task-definition schema and project tests.
+6. State whether force-new-deployment/register-task-definition/update-service is still required and approval-gated.
+
+## Verification targets
+
+- task definition: image, CPU/memory, roles, secrets, logs, health checks, ports
+- service definition: desired count, deployment config, circuit breaker, capacity providers, subnets/security groups
+- load balancer target group health and health check path/port
+- CodeDeploy AppSpec and task set config for blue/green
+- CloudWatch logs and ECS service events/stopped-task reasons
+- validation commands for CloudFormation/CDK/Terraform/task definition JSON
+
+## When to push back
+
+Push back if the user asks to:
+
+- force a new deployment without root-cause evidence
+- disable health checks or circuit breaker to get green status
+- swap task/execution role permissions blindly
+- increase desired count to mask crash loops
+- remove secrets/logging to simplify a task definition
+- deploy latest task revision without rollback target
+

package/skills/aws/aws-ecs-service-remediation-operator/references/official-sources.md

@@ -1,5 +1,29 @@
 # Official sources
 
-- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html
-- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html
-- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-type-ecs.html
+Use this reference only when you need source grounding for AWS service behavior or the detailed source list.
+
+## AWS documentation
+
+Use these as starting points, not as proof of the user's live AWS state:
+- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/troubleshooting.html
+- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-deployment.html
+- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_execution_IAM_role.html
+- https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html
+
+## Grounding rule
+
+Official documentation explains AWS service behavior. It does not prove the user's current account, Region, quota, resource configuration, IAM boundary, pricing, entitlement, or operational state. Prefer read-only AWS MCP or CLI evidence, repository evidence, or sanitized user-provided evidence for current-state claims.
+
+## Current MCP/documentation refresh (2026-06-02)
+
+Service facts from official docs:
+- ECS troubleshooting guidance covers task, service, agent, Docker, EBS, Service Connect, Fargate, and throttling errors as distinct failure classes.
+- ECS service deployments track lifecycle states, circuit breaker failures, CloudWatch alarms, rollbacks, and service history for recent deployments.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported Amazon ECS, AWS Fargate, and AWS CodeDeploy as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Sampled APIs `ECS+DescribeServices`, `ECS+DescribeTasks`, and `CodeDeploy+GetDeployment` were reported `isAvailableIn` in those regions.
+
+Review implications:
+- Repo-side fixes must identify the failing service/task-definition field, expected deployment behavior, validation command, and rollback diff; they must not force live service updates by default.
+- Do not infer root cause from one ECS error string; correlate service events, stopped-task reasons, target health, deployment controller, task/execution roles, image pull, secrets, and logs.

package/skills/aws/aws-eks-platform-operator/SKILL.md

@@ -4,8 +4,8 @@ description: Review Amazon EKS Kubernetes platform operations across cluster acc
 allowed-tools: Read Grep Glob
 metadata:
   author: "github: Raishin"
-  version: "0.1.2"
-  updated: "2026-05-05"
+  version: "0.1.4"
+  updated: "2026-06-02"
   category: platform
 ---
 
@@ -26,7 +26,7 @@ Use this skill for:
 
 ## Lean operating rules
 
-- Prefer `AwsDocumentationMcpServer` when available via `uvx awslabs.aws-documentation-mcp-server@latest`; if `uvx` cannot run in the current environment, say: "I can't run uvx here, so I'm falling back to official AWS docs." Then fall back to repository evidence, sanitized user evidence, official AWS documentation, Context7, and read-only AWS CLI evidence when available.
+- Prefer current AWS documentation tools for service behavior. Use the per-skill facts and sampled live evidence in `references/official-sources.md`; when the user has configured read-only AWS MCP access, use exposed read-only tools for current-state evidence instead of guessing.
 - Separate confirmed facts from inference. If state was not queried or shown, say so.
 - Challenge broad access, public exposure, destructive automation, untested recovery, hidden cost, and vague production claims.
 - Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.
@@ -39,6 +39,7 @@ Load these only when needed:
 - [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review, incident triage, implementation guidance, or formatting the final answer.
 - [Safety checklist](references/safety-checklist.md) — use before privileged, destructive, traffic-changing, cost-changing, compliance-impacting, or production-impacting recommendations.
 - [Official sources](references/official-sources.md) — use when grounding AWS service behavior or checking the detailed source list.
+- [EKS Platform Operations Guide](references/eks-platform-operations.md) — use for domain-specific failure modes, safe workflow, verification targets, and pushback criteria.
 
 ## Response minimum
 

package/skills/aws/aws-eks-platform-operator/metadata.json

@@ -14,14 +14,14 @@
   "summary": "Review Amazon EKS platform operations across cluster identity, access entries, node strategy, networking, autoscaling, upgrades, reliability, security, observability, and cost.",
   "source_type": "original",
   "official_docs": [
-    "https://docs.aws.amazon.com/eks/latest/best-practices/introduction.html",
-    "https://docs.aws.amazon.com/eks/latest/best-practices/security.html",
-    "https://docs.aws.amazon.com/eks/latest/best-practices/reliability.html",
+    "https://docs.aws.amazon.com/eks/latest/userguide/creating-access-entries.html",
+    "https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html",
+    "https://docs.aws.amazon.com/eks/latest/userguide/eks-add-ons.html",
     "https://docs.aws.amazon.com/eks/latest/userguide/security-iam.html"
   ],
   "security_notes": "Do not call an EKS cluster production-ready without explicit identity, network isolation, upgrade, node disruption, image/runtime security, and observability evidence.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-eks-platform-operator",
   "author": "github: Raishin",
-  "version": "0.1.2"
+  "version": "0.1.4"
 }

package/skills/aws/aws-eks-platform-operator/references/eks-platform-operations.md

@@ -0,0 +1,59 @@
+# EKS Platform Operations Guide
+
+Use this reference for Amazon EKS platform operations across cluster access, Kubernetes RBAC, IRSA, EKS Pod Identity, node groups, Karpenter, VPC CNI, add-ons, upgrades, observability, autoscaling, ingress, and multi-tenant workload safety.
+
+## What people get wrong
+
+The lazy story is:
+
+> EKS is Kubernetes, so standard cluster checks are enough.
+
+Wrong. EKS failures sit at the AWS/Kubernetes seam: IAM-to-RBAC mapping, pod identity, CNI IP exhaustion, security group boundaries, add-on drift, node lifecycle, and control-plane version skew.
+
+Common bad assumptions:
+
+- Cluster admin in Kubernetes is the same as AWS account admin.
+- IRSA or Pod Identity automatically enforces least privilege.
+- Managed node groups remove node lifecycle risk.
+- Karpenter fixes capacity without disruption risk.
+- VPC CNI networking behaves like overlay networking.
+- Add-on upgrades are low risk if the cluster version is supported.
+
+## EKS failure modes
+
+- Access entries, aws-auth, IAM roles, and Kubernetes RBAC create hidden privilege paths.
+- Service accounts share broad roles or trust policies across namespaces.
+- Pods cannot schedule due to IP exhaustion, security groups for pods, taints, topology spread, or PDB constraints.
+- Karpenter/node group changes drain critical workloads without disruption budget evidence.
+- CNI/CoreDNS/kube-proxy/add-on drift breaks networking or DNS.
+- Cluster upgrade ignores API deprecations, webhook compatibility, managed add-ons, and workload tests.
+
+## Minimum safe workflow
+
+1. Identify cluster version, endpoint exposure, accounts/Regions, node strategy, add-ons, and tenant model.
+2. Review access control: IAM principals, access entries/aws-auth, Kubernetes RBAC, IRSA/Pod Identity, and break-glass.
+3. Check workload safety: namespaces, network policies, pod security, secrets, image provenance, and resource limits.
+4. Check capacity and networking: node groups, Karpenter, VPC CNI IPs, subnets, security groups, load balancers, and ingress.
+5. Check operations: upgrades, PDBs, autoscaling, observability, backups, runbooks, and incident history.
+6. Recommend staged, reversible changes with drain/rollback plans.
+7. Never mutate cluster access, node groups, add-ons, or workloads without explicit approval.
+
+## Verification targets
+
+- EKS cluster version, endpoint access, access entries/aws-auth, IAM roles, Kubernetes RBAC, and audit logs
+- IRSA/Pod Identity service account mappings, trust policies, namespace scoping, and token audience boundaries
+- managed node groups, self-managed nodes, Karpenter NodePools/NodeClasses, AMIs, labels, taints, and disruption settings
+- VPC CNI config, subnet IP capacity, security groups for pods, network policies, ingress/load balancer controller, and DNS/CoreDNS health
+- add-on versions, upgrade insights, deprecated APIs, PDBs, HPA/KEDA/Cluster Autoscaler, metrics/logs/traces, and backup/restore evidence
+- workload readiness, rollout strategy, image scanning, secrets handling, and incident/change timeline
+
+## When to push back
+
+Push back if the user asks to:
+
+- grant cluster-admin broadly to unblock access
+- upgrade EKS without deprecated API and add-on compatibility checks
+- change Karpenter/node disruption settings without PDB and workload impact review
+- ignore VPC CNI IP capacity or subnet constraints
+- treat IRSA/Pod Identity as least privilege without policy review
+- mutate production cluster state from advisory evidence alone

package/skills/aws/aws-eks-platform-operator/references/official-sources.md

@@ -5,11 +5,25 @@ Use this reference only when you need source grounding for AWS service behavior
 ## AWS documentation
 
 Use these as starting points, not as proof of the user's live AWS state:
-- https://docs.aws.amazon.com/eks/latest/best-practices/introduction.html
-- https://docs.aws.amazon.com/eks/latest/best-practices/security.html
-- https://docs.aws.amazon.com/eks/latest/best-practices/reliability.html
+- https://docs.aws.amazon.com/eks/latest/userguide/creating-access-entries.html
+- https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html
+- https://docs.aws.amazon.com/eks/latest/userguide/eks-add-ons.html
 - https://docs.aws.amazon.com/eks/latest/userguide/security-iam.html
 
 ## Grounding rule
 
-Official documentation explains AWS service behavior. It does not prove the user's current account, Region, quota, resource configuration, IAM boundary, pricing, or operational state. Prefer live AWS MCP/CLI evidence or sanitized user-provided evidence for current-state claims.
+Official documentation explains AWS service behavior. It does not prove the user's current account, Region, quota, resource configuration, IAM boundary, pricing, entitlement, or operational state. Prefer read-only AWS MCP or CLI evidence, repository evidence, or sanitized user-provided evidence for current-state claims.
+
+## Current MCP/documentation refresh (2026-06-02)
+
+Service facts from official docs:
+- EKS access entries associate IAM principal ARNs with Kubernetes access, Kubernetes groups, and EKS access policies; they are a control point for cluster access review.
+- EKS cluster upgrade best-practice guidance is relevant to platform operations because control plane, node, add-on, and workload compatibility can break independently.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported Amazon EKS as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Sampled APIs `EKS+DescribeCluster` and `EKS+ListAddons` were reported `isAvailableIn` in those regions.
+
+Review implications:
+- Do not approve EKS posture without evidence for cluster version, add-ons, node groups/Fargate profiles, access entries/RBAC, IRSA or pod identity, network policy, logging, and upgrade/rollback plan.
+- Regional service availability does not prove account quota, cluster health, add-on compatibility, or Kubernetes object state.

package/skills/aws/aws-eks-platform-operator/references/safety-checklist.md

@@ -5,10 +5,10 @@ Use this reference before privileged, destructive, traffic-changing, cost-changi
 ## Non-negotiables
 
 - Never ask users to paste secrets, access keys, session tokens, private keys, customer identifiers, or sensitive account data into chat.
-- Prefer official AWS MCP tools when exposed by the active runtime. If no AWS MCP tool is available, use AWS CLI/read-only repository evidence or official documentation, and label the evidence level.
+- Use read-only AWS MCP or read-only AWS CLI evidence for live state when available; otherwise use repository evidence, sanitized user evidence, or official documentation and label the evidence level.
 - Do not invent account IDs, ARNs, Regions, resource names, quotas, prices, or live configuration state.
 - Require explicit user approval before privileged, destructive, traffic-changing, cost-changing, or production-impacting actions.
-- Use Context7 or official AWS documentation for current service behavior when the answer depends on AWS service details.
+- Use current official AWS documentation for service behavior when the answer depends on AWS service details.
 - Keep remediation least-privilege, reversible, and scoped to the requested workload or account boundary.
 
 ## Stress checks

package/skills/aws/aws-eks-platform-operator/references/workflow-and-output.md

@@ -19,7 +19,7 @@ Check these areas before giving a verdict:
    - Required outcome:
    - Explicit non-goals:
 2. **Collect evidence**
-   - Prefer live AWS MCP read-only evidence if available.
+   - Prefer read-only AWS MCP or read-only AWS CLI evidence for current-state claims when available.
    - Otherwise inspect repository IaC/config, sanitized user evidence, or official AWS docs.
    - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
 3. **Stress-test risk**

package/skills/aws/aws-event-driven-architecture-review/SKILL.md

@@ -4,8 +4,8 @@ description: Review AWS event-driven system design across EventBridge, event bus
 allowed-tools: Read Grep Glob
 metadata:
   author: "github: Raishin"
-  version: "0.1.2"
-  updated: "2026-05-05"
+  version: "0.1.4"
+  updated: "2026-06-02"
   category: platform
 ---
 
@@ -26,7 +26,7 @@ Use this skill for:
 
 ## Lean operating rules
 
-- Prefer `AwsDocumentationMcpServer` when available via `uvx awslabs.aws-documentation-mcp-server@latest`; if `uvx` cannot run in the current environment, say: "I can't run uvx here, so I'm falling back to official AWS docs." Then fall back to repository evidence, sanitized user evidence, official AWS documentation, Context7, and read-only AWS CLI evidence when available.
+- Prefer current AWS documentation tools for service behavior. Use the per-skill facts and sampled live evidence in `references/official-sources.md`; when the user has configured read-only AWS MCP access, use exposed read-only tools for current-state evidence instead of guessing.
 - Separate confirmed facts from inference. If state was not queried or shown, say so.
 - Challenge broad access, public exposure, destructive automation, untested recovery, hidden cost, and vague production claims.
 - Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.
@@ -39,6 +39,7 @@ Load these only when needed:
 - [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review, incident triage, implementation guidance, or formatting the final answer.
 - [Safety checklist](references/safety-checklist.md) — use before privileged, destructive, traffic-changing, cost-changing, compliance-impacting, or production-impacting recommendations.
 - [Official sources](references/official-sources.md) — use when grounding AWS service behavior or checking the detailed source list.
+- [Event Delivery Failure Modes Guide](references/event-delivery-failure-modes.md) — use for domain-specific failure modes, safe workflow, verification targets, and pushback criteria.
 
 ## Response minimum
 

package/skills/aws/aws-event-driven-architecture-review/metadata.json

@@ -14,14 +14,14 @@
   "summary": "Review AWS EventBridge, SQS, SNS, Step Functions, Pipes, event schemas, retries, DLQs, idempotency, cross-account routing, monitoring, and event-loop risk.",
   "source_type": "original",
   "official_docs": [
-    "https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html",
-    "https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-patterns-best-practices.html",
-    "https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-rules-best-practices.html",
-    "https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-monitoring-events-best-practices.html"
+    "https://docs.aws.amazon.com/decision-guides/latest/sns-or-sqs-or-eventbridge/sns-or-sqs-or-eventbridge.html",
+    "https://docs.aws.amazon.com/lambda/latest/dg/concepts-event-driven-architectures.html",
+    "https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-rules.html",
+    "https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html"
   ],
   "security_notes": "Do not accept event-driven designs without precise patterns, DLQs/retry semantics, idempotent consumers, monitoring, cross-account policy review, and loop/cost controls.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-event-driven-architecture-review",
   "author": "github: Raishin",
-  "version": "0.1.2"
+  "version": "0.1.4"
 }

package/skills/aws/aws-event-driven-architecture-review/references/event-delivery-failure-modes.md

@@ -0,0 +1,59 @@
+# Event Delivery Failure Modes Guide
+
+Use this reference for AWS event-driven architecture reviews involving EventBridge, SQS, SNS, Step Functions, Pipes, event schemas, filtering, cross-account routing, retries, DLQs, archive/replay, idempotency, and event-loop risk.
+
+## What people get wrong
+
+The lazy story is:
+
+> Async decoupling makes the system more reliable.
+
+Wrong. Async systems move failure into queues, retries, duplicates, ordering gaps, poison messages, and invisible backlog. Decoupling without contracts and observability is just delayed failure.
+
+Common bad assumptions:
+
+- EventBridge patterns are precise by default.
+- DLQs prove no event is lost.
+- SNS, SQS, and EventBridge are interchangeable.
+- Replay is safe without idempotent consumers.
+- Step Functions state machines automatically document business correctness.
+- Cross-account event buses are safe if the policy allows the account.
+
+## Event-driven failure modes
+
+- Broad event patterns create fanout storms, loops, or unintended consumers.
+- Consumer retries amplify downstream throttling or duplicate side effects.
+- SQS visibility timeout, max receive count, FIFO ordering, or deduplication is misaligned with handlers.
+- SNS filtering drops events silently from business perspective.
+- EventBridge archive/replay reprocesses stale events into non-idempotent workflows.
+- Pipes/enrichment target roles allow unintended read/write access.
+
+## Minimum safe workflow
+
+1. Map producers, buses/topics/queues/state machines, consumers, schemas, ownership, and account boundaries.
+2. Define delivery guarantees: ordering, duplication, latency, retention, replay, and poison-message handling.
+3. Review filtering and routing precision for EventBridge rules, SNS filters, Pipes, and cross-account bus policies.
+4. Verify retry, DLQ, redrive, archive, replay, timeout, and idempotency behavior for every consumer.
+5. Check observability: backlog, age, failures, throttles, retries, DLQ depth, business counters, and trace correlation.
+6. Compare service choice: SNS, SQS, EventBridge, Step Functions, or Pipes based on coupling and failure semantics.
+7. Require approval before live replay, redrive, rule broadening, or policy mutation.
+
+## Verification targets
+
+- EventBridge event buses, rules, patterns, targets, DLQs, archives, replays, global endpoints, and bus policies
+- SQS queue type, visibility timeout, retention, redrive policy, DLQ, FIFO/dedup, and ApproximateAgeOfOldestMessage
+- SNS topic policy, subscription filters, delivery status, DLQ, encryption, and cross-account subscribers
+- Step Functions retries, catches, timeouts, compensation paths, execution history, and idempotency keys
+- EventBridge Pipes source/filter/enrichment/target roles and failure destinations
+- schema registry/contracts, producer ownership, consumer ownership, and version compatibility
+
+## When to push back
+
+Push back if the user asks to:
+
+- replay or redrive events without idempotency and blast-radius proof
+- broaden EventBridge rules to catch unknown events
+- ignore DLQ growth because primary flow is healthy
+- use async messaging to hide slow or unreliable dependencies
+- grant cross-account bus access without source and detail-type constraints
+- choose SNS/SQS/EventBridge without stating delivery semantics