@raishin/vanguard-frontier-agentic 2.7.1 → 2.9.0

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

package/skills/aws/aws-event-driven-architecture-review/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/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
 
 ## 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:
+- AWS decision guidance differentiates SNS, SQS, and EventBridge by messaging pattern and integration need; choosing one is an architecture decision, not a default.
+- Lambda event-driven architecture guidance calls out benefits, trade-offs, and anti-patterns; asynchronous flows need explicit retry, idempotency, and failure handling design.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported Amazon EventBridge and AWS Lambda as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Sampled APIs `EventBridge+ListRules`, `SQS+GetQueueAttributes`, `SNS+GetTopicAttributes`, `Lambda+GetFunction`, and `SFN+DescribeStateMachine` were reported `isAvailableIn` in those regions.
+
+Review implications:
+- Require event contract, producer/consumer ownership, retry/DLQ policy, ordering/deduplication needs, idempotency, schema/versioning, observability, and replay strategy.
+- Service/API availability does not prove that a specific event bus, queue, topic, rule, Lambda, or state machine is configured correctly.

package/skills/aws/aws-event-driven-architecture-review/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-event-driven-architecture-review/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-generative-ai-developer/SKILL.md

@@ -4,8 +4,8 @@ description: Build Amazon Bedrock and serverless generative AI applications usin
 allowed-tools: Read Edit Write MultiEdit Grep Glob Bash
 metadata:
   author: "github: Raishin"
-  version: "0.1.0"
-  updated: "2026-05-05"
+  version: "0.1.4"
+  updated: "2026-06-02"
   category: ai
 ---
 
@@ -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.
 - Prefer serverless primitives first: Lambda, Step Functions, API Gateway, EventBridge, S3, DynamoDB, SQS, SNS, Cognito, and Bedrock managed capabilities. Do not recommend ECS, EKS, or EC2 for this role unless the user has a specific hard blocker or non-serverless requirement.
 - Separate confirmed facts from inference. If state was not queried or shown, say so.
 - Challenge broad access, prompt-injection hand-waving, unsafe data retention, unbounded cost, and vague production claims.
@@ -40,6 +40,7 @@ Load these only when needed:
 - [Workflow and output contract](references/workflow-and-output.md) — use when executing the full design review, implementation guidance, or formatting the final answer.
 - [Safety checklist](references/safety-checklist.md) — use before privileged, destructive, 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.
+- [Bedrock Serverless GenAI Guide](references/bedrock-serverless-genai.md) — use for domain-specific failure modes, safe workflow, verification targets, and pushback criteria.
 
 ## Response minimum
 

package/skills/aws/aws-generative-ai-developer/metadata.json

@@ -15,17 +15,13 @@
   "source_type": "original",
   "official_docs": [
     "https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html",
-    "https://docs.aws.amazon.com/bedrock/latest/userguide/security-overview.html",
-    "https://docs.aws.amazon.com/bedrock/latest/userguide/security-best-practice-agents.html",
-    "https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-injection.html",
-    "https://docs.aws.amazon.com/bedrock/latest/userguide/bedrock-example-cross-serverless-prompt-chaining-section.html",
-    "https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html",
-    "https://docs.aws.amazon.com/lambda/latest/dg/with-step-functions.html",
-    "https://docs.aws.amazon.com/apigateway/latest/developerguide/security-best-practices.html"
+    "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html",
+    "https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html",
+    "https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/GenAI-observability.html"
   ],
   "security_notes": "Prefer serverless managed services for this role unless a concrete blocker is provided. Do not approve broad model access, unsafe prompt/tool flows, weak auth, uncontrolled retention, or missing observability and cost controls.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-generative-ai-developer",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.4"
 }

package/skills/aws/aws-generative-ai-developer/references/bedrock-serverless-genai.md

@@ -0,0 +1,61 @@
+# Bedrock Serverless GenAI Guide
+
+Use this reference for Amazon Bedrock serverless applications, RAG flows, prompt orchestration, Guardrails, Lambda/API Gateway/Step Functions integrations, and production-readiness gaps.
+
+## What people get wrong
+
+The lazy story is:
+
+> Bedrock is managed, so the app is safe if IAM is scoped and the model works.
+
+Wrong. Managed inference does not solve prompt injection, data boundary, retrieval leakage, token cost, evaluation, observability, or fallback design.
+
+Common bad assumptions:
+
+- Guardrails replace application authorization and data filtering.
+- A model invocation test proves production behavior.
+- RAG quality is a vector database problem only.
+- Prompt/version changes do not need release control.
+- Cross-Region inference profiles are just a performance feature, not a residency and cost decision.
+- CloudWatch GenAI observability exists for the app unless explicitly enabled and scoped.
+
+## GenAI-specific failure modes
+
+- User prompt or retrieved context overrides system intent or tool boundaries.
+- Knowledge base retrieves unauthorized, stale, or ungrounded content.
+- Lambda/API Gateway timeout, payload, streaming, or concurrency limits are ignored.
+- Token usage, retries, and long context windows create unbounded cost.
+- Logs capture prompts, documents, PII, secrets, or customer data without retention controls.
+- Model, Region, guardrail, prompt, or embedding changes are not versioned or evaluated.
+- Fallback path silently downgrades quality, safety, or data residency.
+
+## Minimum safe workflow
+
+1. Identify the use case, data classification, user roles, model/Region, latency target, and cost boundary.
+2. Choose the simplest serverless shape: API Gateway or AppSync, Lambda, Step Functions for orchestration, EventBridge/SQS for async, S3/DynamoDB for state, and Bedrock managed capabilities.
+3. Define prompt, guardrail, retrieval, tool, and output contracts before implementation.
+4. Add explicit evaluation criteria: golden prompts, refusal cases, retrieval-grounding checks, latency, token budget, and safety regressions.
+5. Design observability with redaction: token counts, latency, model errors, guardrail interventions, retrieval IDs, and user-impact metrics.
+6. Require IAM/KMS/network/data-retention boundaries for prompts, documents, embeddings, logs, and outputs.
+7. Keep deploy, model access changes, guardrail publishing, and data-source ingestion approval-gated.
+
+## Verification targets
+
+- Bedrock model, Region, inference profile, guardrail, prompt/version, and invocation path
+- Knowledge Base data source, chunking, metadata filters, embedding model, sync status, and authorization boundary
+- Lambda/API Gateway/Step Functions timeout, payload, streaming, concurrency, retry, and error handling
+- IAM permissions for `bedrock:*` actions narrowed by model/resource where practical
+- KMS, S3, DynamoDB, CloudWatch Logs retention, VPC/private connectivity, and data residency settings
+- eval set, expected outputs, refusal cases, retrieval citations, and regression threshold
+- cost controls: token budget, max output tokens, retry limits, quotas, and alerting
+
+## When to push back
+
+Push back if the user asks to:
+
+- ship a GenAI app without prompt/retrieval safety evals
+- treat Guardrails as a complete security boundary
+- log raw prompts or retrieved documents broadly
+- use broad Bedrock/IAM permissions for convenience
+- ignore token/cost limits during retries or long conversations
+- claim model availability proves app readiness

package/skills/aws/aws-generative-ai-developer/references/official-sources.md

@@ -1,33 +1,28 @@
 # Official sources
 
-Use this reference when grounding current AWS generative AI developer guidance.
-
-## Amazon Bedrock
-
-- What is Amazon Bedrock
-  https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html
-- Amazon Bedrock security overview
-  https://docs.aws.amazon.com/bedrock/latest/userguide/security-overview.html
-- Security best practices for Amazon Bedrock Agents
-  https://docs.aws.amazon.com/bedrock/latest/userguide/security-best-practice-agents.html
-- Prompt injection
-  https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-injection.html
-- Serverless prompt chaining example
-  https://docs.aws.amazon.com/bedrock/latest/userguide/bedrock-example-cross-serverless-prompt-chaining-section.html
-
-## AWS serverless foundations
-
-- AWS Lambda best practices
-  https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html
-- AWS Lambda with Step Functions
-  https://docs.aws.amazon.com/lambda/latest/dg/with-step-functions.html
-- AWS Lambda observability
-  https://docs.aws.amazon.com/lambda/latest/operatorguide/monitoring-observability.html
-- Amazon API Gateway security best practices
-  https://docs.aws.amazon.com/apigateway/latest/developerguide/security-best-practices.html
-- Event-driven architecture on AWS
-  https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/event-driven-architecture.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/bedrock/latest/userguide/what-is-bedrock.html
+- https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html
+- https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html
+- https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/GenAI-observability.html
 
 ## Grounding rule
 
-Docs explain service behavior. They do not prove the user's deployed stack, quotas, IAM boundaries, model access, runtime latency, or cost profile.
+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:
+- Amazon Bedrock provides managed access to foundation models and related application features; model availability, feature maturity, and regional coverage can vary.
+- CloudWatch generative AI observability can trace prompts, track token latency, and monitor AgentCore agents, but observability must be enabled and scoped to the application.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported Amazon Bedrock as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+
+Review implications:
+- Require model/region selection, guardrails, prompt/version management, RAG source boundaries, IAM/KMS controls, logging, cost/token limits, evaluation criteria, and rollback/fallback behavior.
+- Do not infer deployed agent/model safety from Bedrock service availability; inspect app configuration, prompts, tools, data sources, and telemetry.

package/skills/aws/aws-iac-change-safety-review/SKILL.md

@@ -4,8 +4,8 @@ description: Review AWS infrastructure-as-code changes across CDK, CloudFormatio
 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: delivery
 ---
 
@@ -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.
+- [IaC Change Risk Review Guide](references/iac-change-risk-review.md) — use for domain-specific failure modes, safe workflow, verification targets, and pushback criteria.
 
 ## Response minimum
 

package/skills/aws/aws-iac-change-safety-review/metadata.json

@@ -14,14 +14,14 @@
   "summary": "Review AWS CDK, CloudFormation, SAM, Terraform, and mixed IaC changes for replacement, deletion, drift, IAM, network, data-loss, rollback, and deployment safety risks.",
   "source_type": "original",
   "official_docs": [
-    "https://docs.aws.amazon.com/cdk/v2/guide/best-practices.html",
-    "https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/best-practices.html",
     "https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/drift-aware-change-sets.html",
-    "https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html"
+    "https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/event-detail-stack-drift-detection-change.html",
+    "https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/best-practices.html",
+    "https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-policy.html"
   ],
   "security_notes": "Never approve an AWS IaC deployment from source diff alone when production state, generated artifacts, change sets, drift, replacements, destructive changes, or rollback are unresolved.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-iac-change-safety-review",
   "author": "github: Raishin",
-  "version": "0.1.2"
+  "version": "0.1.4"
 }

package/skills/aws/aws-iac-change-safety-review/references/iac-change-risk-review.md

@@ -0,0 +1,59 @@
+# IaC Change Risk Review Guide
+
+Use this reference when reviewing CloudFormation, CDK, SAM, Terraform, Serverless Framework, change sets, drift, stack policies, StackSets, and production deployment preflights.
+
+## What people get wrong
+
+The lazy story is:
+
+> The plan/change set is the source of truth, so read it and decide.
+
+Wrong. Plans and change sets are necessary but not sufficient. They can miss live drift, parameter context, provider behavior, replacement side effects, data retention, and organizational guardrails.
+
+Common bad assumptions:
+
+- `No changes` means no operational risk.
+- Replacement is acceptable if CloudFormation can perform it.
+- Terraform destroy/create is safe when names stay similar.
+- Drift is separate from the proposed change.
+- Stack policies and rollback triggers are optional.
+- IAM diffs can be reviewed by action count alone.
+
+## IaC-review failure modes
+
+- Resource replacement deletes state, changes DNS, rotates identity, or breaks consumers.
+- IAM, KMS, security group, route, bucket, or trust-policy changes widen blast radius.
+- Parameter/default changes alter multiple environments unexpectedly.
+- StackSets or modules propagate a risky pattern across accounts/Regions.
+- Drift means the apply will not behave like the repo diff.
+- Rollback would fail because stateful resources, migrations, or retained resources are not handled.
+
+## Minimum safe workflow
+
+1. Identify IaC tool, target environment, account/Region scope, and deployment mechanism.
+2. Review repo diff plus generated template/plan/change set, not only source files.
+3. Classify each material change as add, modify, replace, delete, permission widen, exposure, stateful, or rollback-sensitive.
+4. Check drift, parameters, stack policies, rollback triggers, and cross-stack/module dependencies where applicable.
+5. Require validation evidence: lint, synth, plan/change set, policy checks, and test outputs.
+6. Return go/no-go with blockers, risky resources, mitigation, owner, and rollback evidence.
+7. Keep deployment/apply/destroy outside this review unless a separate guarded approval path is invoked.
+
+## Verification targets
+
+- CloudFormation/SAM template diff, change set replacement/delete details, drift detection, stack policy, rollback trigger, and events
+- CDK synth/diff output, bootstrap environment, asset changes, and security approval prompts
+- Terraform fmt/validate/plan, provider lockfile, state backend, targeted apply risk, and destroy/replacement markers
+- IAM/KMS/security group/network/storage/database diffs and policy validation output
+- StackSets, modules, nested stacks, parameters, exports/imports, and environment overlays
+- rollback plan: previous template, state backup, retained resources, migration reversal, and data restore point
+
+## When to push back
+
+Push back if the user asks to:
+
+- approve apply from source diff only
+- ignore replacement/delete risk because validation passed
+- skip drift detection for production stacks
+- widen IAM/network controls as a quick fix
+- use targeted apply/destroy without dependency analysis
+- combine unrelated cleanup with a risky production change

package/skills/aws/aws-iac-change-safety-review/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/cdk/v2/guide/best-practices.html
-- https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/best-practices.html
 - https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/drift-aware-change-sets.html
-- https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html
+- https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/event-detail-stack-drift-detection-change.html
+- https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/best-practices.html
+- https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-policy.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:
+- CloudFormation drift-aware change sets support three-way comparison and `REVERT_DRIFT` for supported resources.
+- CloudFormation drift-detection status change events expose drift status, drifted resource counts, operation status, and client request tokens as event evidence.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported AWS CloudFormation and AWS Config as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Sampled APIs `CloudFormation+CreateChangeSet`, `CloudFormation+DetectStackDrift`, and `CloudFormation+ValidateTemplate` were reported `isAvailableIn` in those regions.
+
+Review implications:
+- IaC safety review must inspect planned diff, replacement/delete risk, IAM/security policy impact, network exposure, data loss, drift, rollback, and approval evidence.
+- A valid template or available change-set API does not prove the proposed change is safe.