@raishin/vanguard-frontier-agentic 2.8.0 → 2.10.0

package/skills/aws/aws-api-edge-delivery-review/references/observability-incident-playbook.md

@@ -0,0 +1,110 @@
+# API and Edge Observability / Incident Playbook
+
+Use this reference for API Gateway, CloudFront, WAF, Shield, or ALB edge incidents involving 4xx/5xx spikes, latency, throttling, false positives, cache poisoning, origin failures, bot traffic, or unexpected cost.
+
+## What people get wrong
+
+The naive story is:
+
+> We have dashboards, so we can debug the edge.
+
+Wrong. Edge incidents cross services. If request IDs, logs, WAF decisions, cache behavior, and origin metrics cannot be correlated, dashboards become theater.
+
+Common bad assumptions:
+
+- 4xx means client fault.
+- 5xx means origin fault.
+- WAF blocks are always attacks.
+- CloudFront cache hit ratio is always good when high.
+- API Gateway throttles prove abuse rather than mis-sized quotas.
+- Cost spikes are separate from reliability incidents.
+
+## Evidence to collect first
+
+Capture the time window and compare against a clean baseline.
+
+Minimum evidence set:
+
+- affected hostnames, paths, methods, status codes
+- CloudFront distribution and cache behavior
+- API Gateway API/stage/route, if applicable
+- WAF web ACL/rule/action/labels, if applicable
+- origin target and origin health
+- recent deployments, WAF changes, DNS/certificate changes, or cache policy changes
+- customer impact and business priority
+
+## Failure-mode map
+
+### 4xx spike
+
+Check:
+
+- authorizer failures
+- resource policy denies
+- WAF blocks/challenges/CAPTCHA
+- CORS/preflight failures
+- missing routes or base-path mappings
+- signed URL/cookie failures
+- request size/header validation
+
+### 5xx spike
+
+Check:
+
+- origin health and target group status
+- API Gateway integration errors/timeouts
+- Lambda/backend errors
+- CloudFront origin connection attempts/timeouts
+- certificate/TLS origin mismatch
+- DNS/origin failover behavior
+
+### Latency spike
+
+Check:
+
+- cache hit ratio and origin latency
+- API Gateway integration latency vs total latency
+- backend saturation
+- WAF inspection overhead from expensive rules
+- regional vs global path differences
+
+### False-positive WAF incident
+
+Check:
+
+- rule ID/rule group/label
+- sampled requests/logs
+- recent managed rule updates or overrides
+- path-specific exception options
+- count-mode rollback
+
+## Minimum safe incident workflow
+
+1. State the exact time window and affected edge path.
+2. Identify whether the symptom begins at viewer, edge, WAF, API Gateway, or origin.
+3. Correlate metrics and logs across services.
+4. Identify the smallest reversible mitigation.
+5. Prefer count/allow exception scoped by path/header/method over disabling a whole managed rule group.
+6. Record rollback and post-incident hardening actions.
+
+## Verification targets
+
+Use read-only evidence when available:
+
+- CloudFront standard/real-time logs or distribution metrics
+- API Gateway access logs and execution metrics
+- WAF logs/sampled requests and rule metrics
+- CloudWatch alarms and metric math dashboards
+- origin target health and backend logs
+- CloudTrail events for recent configuration changes
+- Cost Explorer / usage evidence if request volume or logging cost spiked
+
+## When to push back
+
+Push back if the user asks to:
+
+- disable the entire WAF to fix one false positive
+- increase throttles without checking origin capacity
+- invalidate all cache paths as a generic rollback
+- ignore missing logs and “just infer” root cause
+- call the incident resolved without post-mitigation metrics

package/skills/aws/aws-api-edge-delivery-review/references/official-sources.md

@@ -5,11 +5,67 @@ 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/apigateway/latest/developerguide/security-best-practices.html
-- https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html
-- https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html
-- https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-awswaf.html
+
+### API Gateway
+
+- API Gateway security best practices
+  https://docs.aws.amazon.com/apigateway/latest/developerguide/security-best-practices.html
+- API Gateway throttling and quotas
+  https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html
+
+### CloudFront
+
+- Restrict access to an Amazon S3 origin with CloudFront OAC
+  https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html
+- Add custom headers to origin requests
+  https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/add-origin-custom-headers.html
+- Require HTTPS between CloudFront and an S3 origin
+  https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-cloudfront-to-s3-origin.html
+- Use AWS WAF protections with CloudFront
+  https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-awswaf.html
+
+### AWS WAF / Shield
+
+- How AWS WAF works
+  https://docs.aws.amazon.com/waf/latest/developerguide/how-aws-waf-works.html
+- AWS Managed Rules for AWS WAF
+  https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups.html
+- Best practices for anti-DDoS
+  https://docs.aws.amazon.com/waf/latest/developerguide/waf-anti-ddos-best-practices.html
+- How AWS Shield and Shield Advanced work
+  https://docs.aws.amazon.com/waf/latest/developerguide/ddos-overview.html
+- Automatic application-layer DDoS mitigation with Shield Advanced
+  https://docs.aws.amazon.com/waf/latest/developerguide/ddos-automatic-app-layer-response.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, 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:
+
+- API Gateway security best-practice guidance points reviewers to IAM, CloudWatch, CloudTrail, AWS Config, Security Hub CSPM, and JWT authorizers as API security controls.
+- API Gateway throttling and quotas are separate control layers; account/stage/method throttles, usage plans, and downstream capacity must be reviewed together.
+- CloudFront OAC is the current S3-origin protection path; legacy OAI exists but is not the preferred new pattern. OAC/S3 bucket policy and SSE-KMS permissions must be reviewed together.
+- CloudFront custom origin headers can help origin request shaping, but AWS documents headers CloudFront cannot add and separate guidance for forwarding `Authorization`; do not treat custom headers as a complete security boundary.
+- AWS WAF web ACLs use rules, rule groups, labels, WCUs, dashboards, bot analysis, and metrics; AWS Managed Rules should be tested before production blocking.
+- AWS anti-DDoS guidance calls for baseline traffic patterns, CloudWatch metrics, and staging tests; Shield Standard is automatic, while Shield Advanced adds additional protections for eligible resources.
+
+Sampled live evidence:
+
+- Read-only regional availability sampling reported `isAvailableIn` for Amazon API Gateway, Amazon CloudFront, AWS WAF, and AWS Shield in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Read-only API availability sampling reported `WAFV2+GetWebACL`, `WAFV2+ListRuleGroups`, and `CloudWatch+DescribeAlarms` as `isAvailableIn` in those sampled regions.
+- `CloudFront+GetDistribution` sampled as `isAvailableIn` in `us-east-1` and `us-west-2`, and `Not Found` in `eu-west-1` and `ap-southeast-1`; treat CloudFront API evidence as global/service-specific rather than normal regional workload proof.
+
+Stale or missing guidance corrected:
+
+- The prior reference set was too generic and lacked component-specific guidance for API Gateway, CloudFront, WAF/Shield, and cross-service incident triage.
+- It did not call out API type differences, JWT/authZ separation, cache-key sensitivity, OAC vs OAI, WAF count-mode limits, managed-rule staging, Shield Advanced scope, or evidence correlation across edge services.
+- It did not provide verification targets or pushback criteria comparable to the stronger AgentCore references.
+
+Review implications:
+
+- Public edge exposure is not acceptable without evidence for authN/authZ, throttling/quotas, TLS, origin protection, WAF/Shield posture, logging, alarms, and rollback.
+- CloudFront distribution state, cache behavior, origin policy, WAF decisions, API Gateway stages/routes, and quotas must come from repo/live evidence, not documentation alone.
+- Treat sampled live evidence as regional/API availability only; it does not prove the user's resources are configured safely.

package/skills/aws/aws-api-edge-delivery-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-api-edge-delivery-review/references/waf-shield-abuse-controls.md

@@ -0,0 +1,97 @@
+# WAF, Shield, and Abuse Controls Guide
+
+Use this reference when the review scope includes AWS WAF web ACLs, managed rules, custom rules, rate-based rules, Bot Control, Shield Advanced, Firewall Manager, labels, logging, or abuse/DDoS posture.
+
+## What people get wrong
+
+The lazy story is:
+
+> We attached WAF, so abuse is handled.
+
+Wrong. A web ACL can be ineffective, too broad, too expensive, noisy, or dangerous if rules are untested or exclusions are careless.
+
+Common bad assumptions:
+
+- Managed rule groups can be enabled straight to block in production.
+- Count mode means protected.
+- Rate-based rules work without baseline traffic knowledge.
+- Bot Control labels are automatically safe to block on.
+- WAF logs are optional because CloudWatch metrics exist.
+- Shield Advanced means no app-layer DDoS planning is needed.
+
+## Officially grounded controls
+
+Current AWS docs ground these WAF/Shield controls:
+
+- Web ACLs, rules, rule groups, labels, WCUs, dashboards, and bot analysis.
+- AWS Managed Rules with explicit guidance to test rule groups before production deployment.
+- Rate, CAPTCHA/challenge, SQLi/XSS-style request inspection, and label-based handling.
+- Anti-DDoS best practices: establish traffic baselines, monitor CloudWatch metrics, and test in staging.
+- Shield Standard is automatically included; Shield Advanced adds additional DDoS protections for eligible resources.
+
+## Non-negotiable review checks
+
+### 1. Identify scope and attachment
+
+Capture whether the web ACL is for CloudFront/global or regional resources such as ALB/API Gateway/AppSync.
+
+Verify:
+
+- associated resource(s)
+- default action
+- rule priority order
+- managed/custom rule groups
+- WCU headroom
+- count/block/challenge/CAPTCHA actions
+- labels and label match rules
+
+### 2. Test managed rules before blocking
+
+Require count-mode observation or staged rollout for new or changed managed rule groups unless there is an active incident requiring emergency block.
+
+### 3. Rate limits need baselines
+
+Rate-based rules should be tied to:
+
+- normal request-rate baseline
+- attack threshold
+- aggregation key
+- exception list
+- false-positive rollback
+- CloudWatch/WAF-log validation
+
+### 4. Logging is evidence, not decoration
+
+WAF logs are needed to explain blocked/allowed traffic, labels, rule matches, false positives, and cost/noise tradeoffs.
+
+## Minimum safe workflow
+
+1. Map protected resources and web ACL scope.
+2. Inspect default action and rule priority.
+3. Review managed rule groups, custom rules, labels, WCU, and overrides.
+4. Check rate-based rules against baseline traffic.
+5. Verify logging, metrics, dashboards, and alarm coverage.
+6. Define false-positive rollback and emergency block procedure.
+7. If Shield Advanced is claimed, verify protected resources and response/escalation path.
+
+## Verification targets
+
+Use read-only evidence when available:
+
+- WAFv2 web ACL, rules, rule groups, and logging configuration
+- CloudFront/API Gateway/ALB association
+- WAF sampled requests and log destinations
+- CloudWatch metrics: allowed, blocked, counted, challenged, CAPTCHA, rule matches
+- Shield Advanced protection status where claimed
+- Firewall Manager policy if multi-account governance is in scope
+
+## When to push back
+
+Push back if the design says:
+
+- “turn on every managed rule in block mode”
+- “we do not need WAF logs”
+- “Count mode means protected”
+- “one global rate limit fits all endpoints”
+- “allowlist our office IPs broadly”
+- “Shield Advanced means WAF tuning is unnecessary”

package/skills/aws/aws-api-edge-delivery-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-bedrock-agent-security-governor/SKILL.md

@@ -4,8 +4,8 @@ description: Review Amazon Bedrock agents, AgentCore, Guardrails, knowledge base
 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: security
 ---
 
@@ -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.
+- [Bedrock Agent Attack Surface Guide](references/bedrock-agent-attack-surface.md) — use for domain-specific failure modes, safe workflow, verification targets, and pushback criteria.
 
 ## Response minimum
 

package/skills/aws/aws-bedrock-agent-security-governor/metadata.json

@@ -20,8 +20,8 @@
     "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-how.html"
   ],
   "security_notes": "Do not grant broad tool or data access to Bedrock agents. Require least privilege, prompt-injection tests, guardrail coverage, PII controls, observability, and kill-switch/rollback design.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-bedrock-agent-security-governor",
   "author": "github: Raishin",
-  "version": "0.1.2"
+  "version": "0.1.4"
 }

package/skills/aws/aws-bedrock-agent-security-governor/references/bedrock-agent-attack-surface.md

@@ -0,0 +1,59 @@
+# Bedrock Agent Attack Surface Guide
+
+Use this reference for Amazon Bedrock agents, AgentCore, Guardrails, Knowledge Bases, action groups, memory, tool/MCP integrations, prompt-injection defenses, PII handling, encryption, logging, and least-privilege review.
+
+## What people get wrong
+
+The lazy story is:
+
+> Guardrails plus IAM makes a Bedrock agent safe.
+
+Wrong. Agent risk comes from composition: prompt instructions, retrieved data, memory, tool schemas, action-group permissions, logging, and downstream APIs interact in ways a single control cannot prove safe.
+
+Common bad assumptions:
+
+- Guardrails are an authorization boundary.
+- Knowledge Base retrieval is safe if the S3/OpenSearch source is trusted.
+- Action groups are safe because Lambda has IAM.
+- Memory improves UX without creating poisoning or retention risk.
+- Tool descriptions cannot leak sensitive implementation details.
+- Model access availability proves agent production readiness.
+
+## Bedrock-agent failure modes
+
+- Prompt injection causes tool calls, data exfiltration, or policy bypass through retrieved context.
+- Knowledge Base metadata filters do not enforce user-level authorization.
+- Action group Lambda role can mutate or read resources beyond the agent use case.
+- Guardrails block output but not downstream side effects already triggered by tools.
+- Logs/traces capture prompts, PII, retrieved documents, credentials, or tool payloads.
+- Memory or session state stores sensitive data without retention, deletion, or tenant boundary controls.
+
+## Minimum safe workflow
+
+1. Identify agent, model, Region, users, data classification, tools/action groups, knowledge sources, memory, and output channels.
+2. Map trust boundaries: user prompt, system prompt, retrieved context, tool schema, Lambda/action group, downstream API, and logs.
+3. Review Guardrails as defense-in-depth, not authorization; check denied topics, sensitive information filters, contextual grounding, and intervention telemetry.
+4. Verify least privilege for action groups, service roles, knowledge base data sources, KMS keys, and logging destinations.
+5. Define adversarial evals: prompt injection, data leakage, unauthorized retrieval, unsafe tool call, refusal, and jailbreak cases.
+6. Require observability with redaction: guardrail interventions, tool calls, model errors, token/cost, latency, and audit events.
+7. Do not approve production release without eval evidence, rollback/fallback, and owner signoff.
+
+## Verification targets
+
+- Bedrock agent configuration, model, aliases/versions, Guardrails, prompts, orchestration, and action group schemas
+- Knowledge Base data source, sync status, metadata filters, vector store access, S3/KMS policies, and tenant/data boundaries
+- action group Lambda/API permissions, IAM trust, resource policies, network access, and side-effect controls
+- AgentCore runtime/gateway/memory/tool integration boundaries where applicable
+- CloudWatch/CloudTrail logs, GenAI observability, prompt/tool redaction, retention, and alerting
+- eval suite for injection, leakage, unsafe tool invocation, grounding, PII handling, and cost/latency thresholds
+
+## When to push back
+
+Push back if the user asks to:
+
+- treat Guardrails as a complete security boundary
+- allow agent tools to mutate production without approval gates
+- use broad Bedrock, Lambda, S3, or KMS permissions
+- skip adversarial prompt and retrieval evals
+- log raw prompts, retrieved documents, or tool payloads broadly
+- claim agent safety from documentation or service availability alone

package/skills/aws/aws-bedrock-agent-security-governor/references/official-sources.md

@@ -12,4 +12,17 @@ Use these as starting points, not as proof of the user's live AWS state:
 
 ## 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, or operational state. Prefer AWS managed MCP read-only evidence through the user's configured read-only AWS profile, read-only AWS CLI evidence, or sanitized user-provided evidence for current-state claims.
+
+## Current MCP/documentation refresh (2026-06-02)
+
+Service facts from official docs:
+- Bedrock prompt-injection guidance says Guardrails can detect prompt attacks, but customers still need application controls such as input validation, guardrail association, and safer prompt design.
+- Bedrock CloudTrail guidance covers Bedrock API activity; logging proves calls occurred, not whether an agent decision was safe.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported `isAvailableIn` for Amazon Bedrock in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+
+Review implications:
+- Guardrails and prompt-injection controls reduce risk; they do not prove a specific agent, action group, knowledge base, or tool integration is safe.
+- Require evidence for IAM scope, data-source boundaries, logging, model/tool invocation paths, memory retention, PII handling, and kill-switch behavior before production readiness claims.

package/skills/aws/aws-bedrock-agent-security-governor/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-bedrock-agent-security-governor/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-change-impact-advisor/SKILL.md

@@ -4,8 +4,8 @@ description: Assess AWS change impact using change sets, deployment blast radius
 allowed-tools: Read Grep Glob WebFetch
 metadata:
   author: "github: Raishin"
-  version: "0.1.0"
-  updated: "2026-05-05"
+  version: "0.1.2"
+  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.
 - This role is non-destructive by default. Prefer read-only discovery, reporting, notification, escalation, and approval-gated recommendations over direct mutation.
 - Separate confirmed facts from inference. If state was not queried or shown, say so.
 - Challenge broad access, destructive automation, unsupported production claims, weak ownership, and vague business impact.
@@ -40,6 +40,7 @@ Load these only when needed:
 - [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review, advisory workflow, or formatting the final answer.
 - [Safety checklist](references/safety-checklist.md) — use before privileged, 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.
+- [Change Impact Assessment Guide](references/change-impact-assessment.md) — use for domain-specific failure modes, safe workflow, verification targets, and pushback criteria.
 
 ## Response minimum
 

package/skills/aws/aws-change-impact-advisor/metadata.json

@@ -20,8 +20,8 @@
     "https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/design_principles.html"
   ],
   "security_notes": "This role is advisory only. Do not approve execution from weak evidence. Require explicit rollback, dependency, owner, and communication clarity before treating a change as low-risk.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-change-impact-advisor",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.2"
 }

package/skills/aws/aws-change-impact-advisor/references/change-impact-assessment.md

@@ -0,0 +1,59 @@
+# Change Impact Assessment Guide
+
+Use this reference when assessing planned AWS changes, rollback readiness, blast radius, maintenance windows, change calendars, dependency risk, and go/no-go recommendations.
+
+## What people get wrong
+
+The lazy story is:
+
+> If the deployment tool accepts the change, impact is understood.
+
+Wrong. Tool acceptance is not impact analysis. A valid change can still replace stateful resources, breach a freeze window, break downstream consumers, or leave the business without a rollback decision.
+
+Common bad assumptions:
+
+- A CloudFormation change set, Terraform plan, or pipeline diff is automatically business-safe.
+- Low line-count equals low blast radius.
+- Rollback exists because Git can revert the commit.
+- Change calendars and maintenance windows are scheduling details, not controls.
+- A service owner approval covers dependent teams.
+- Read-only evidence from one Region proves global readiness.
+
+## Change-specific failure modes
+
+- Change set or plan hides replacement, delete, interruption, or data-retention risk.
+- Dependency owners are missing for shared VPCs, IAM roles, KMS keys, event buses, queues, DNS, or certificates.
+- Rollback requires data migration reversal, alias retargeting, previous image digests, parameter restoration, or manual state repair.
+- Maintenance window conflicts with business freeze, AWS Health event, support case, or downstream release.
+- Monitoring and alarms do not cover the changed path.
+- Approval is given by the implementer instead of an accountable service owner.
+
+## Minimum safe workflow
+
+1. Identify the change type, target account/Region/environment, owner, and requested execution window.
+2. Gather repository diff, change set/plan if available, affected services, dependencies, and rollback artifact.
+3. Classify blast radius: customer-facing, data-bearing, identity/network, cost-affecting, or control-plane only.
+4. Check scheduling controls: change calendar, maintenance window, freeze period, AWS Health context, and stakeholder availability.
+5. Separate confirmed evidence from assumptions; do not fill unknowns with optimism.
+6. Return a go/no-go recommendation with blockers, conditions, rollback notes, and communication plan.
+7. Keep the role advisory; do not approve or execute the change from this skill.
+
+## Verification targets
+
+- change set, Terraform plan, CDK diff, SAM/CloudFormation diff, or pipeline release notes
+- resource replacement/delete/interruption indicators
+- rollback artifact: previous template, alias target, image digest, parameter set, migration rollback, or restore point
+- impacted AWS services, accounts, Regions, VPCs, IAM principals, data stores, queues, DNS records, and certificates
+- maintenance window, Change Calendar/Change Manager request, approval record, and on-call coverage
+- CloudWatch alarms, AWS Health events, support cases, and incident backlog relevant to the change window
+
+## When to push back
+
+Push back if the user asks to:
+
+- declare low risk from a diff without blast-radius evidence
+- ignore replacement/delete risk because validation passed
+- proceed without owner approval or rollback artifact
+- execute during a freeze, health event, or unresolved incident without risk acceptance
+- treat advisory review as deployment approval
+- hide unknowns from stakeholders

package/skills/aws/aws-change-impact-advisor/references/official-sources.md

@@ -10,3 +10,16 @@ Use this reference when grounding current AWS service behavior for this role.
 ## Grounding rule
 
 Docs explain service behavior. They do not prove the user's deployed state, ownership, SLAs, budget posture, or current incident reality.
+## Current MCP/documentation refresh (2026-06-02)
+
+Service facts from official docs:
+- CloudFormation drift-aware change sets support three-way comparison and can use `REVERT_DRIFT` to revert out-of-band changes where supported.
+- Change-set and drift evidence is pre-change evidence only; it does not prove stakeholder approval, runtime health, or rollback readiness.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported `isAvailableIn` for AWS CloudFormation and AWS Config in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Sampled APIs `CloudFormation+CreateChangeSet` and `CloudFormation+DetectStackDrift` were reported `isAvailableIn` in those regions.
+
+Review implications:
+- Change sets and drift checks are evidence inputs, not approval by themselves.
+- Require owner, blast radius, dependencies, rollback path, monitoring, communication plan, and explicit decision authority before go/no-go recommendations.

package/skills/aws/aws-ci-cd-release-engineer/SKILL.md

@@ -4,8 +4,8 @@ description: Review AWS CI/CD and release safety across CodePipeline, CodeBuild,
 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.
+- [Release Safety and Provenance Guide](references/release-safety-and-provenance.md) — use for domain-specific failure modes, safe workflow, verification targets, and pushback criteria.
 
 ## Response minimum
 

package/skills/aws/aws-ci-cd-release-engineer/metadata.json

@@ -20,8 +20,8 @@
     "https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html"
   ],
   "security_notes": "Do not approve production pipelines without artifact integrity, least-privilege deploy roles, quality/security gates, deployment telemetry, rollback criteria, and post-deploy validation.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-ci-cd-release-engineer",
   "author": "github: Raishin",
-  "version": "0.1.2"
+  "version": "0.1.4"
 }

package/skills/aws/aws-ci-cd-release-engineer/references/official-sources.md

@@ -12,4 +12,18 @@ Use these as starting points, not as proof of the user's live AWS state:
 
 ## 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, or operational state. Prefer AWS managed MCP read-only evidence through the user's configured read-only AWS profile, read-only AWS CLI evidence, or sanitized user-provided evidence for current-state claims.
+
+## Current MCP/documentation refresh (2026-06-02)
+
+Service facts from official docs:
+- AWS Well-Architected operational guidance recommends build/deployment management systems and automated change management to reduce manual deployment error.
+- CodeDeploy rollback documentation is relevant to deployment safety, but rollback behavior still depends on each deployment group/application configuration.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported `isAvailableIn` for AWS CodePipeline, AWS CodeBuild, and AWS CodeDeploy in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Sampled APIs `CodePipeline+GetPipelineState` and `CodeDeploy+GetDeployment` were reported `isAvailableIn` in those regions.
+
+Review implications:
+- Pipeline existence is not release safety. Require gates, test evidence, artifact integrity/provenance, least-privilege deployment roles, telemetry, rollback criteria, and post-deploy validation.
+- Docs do not prove the user's pipeline configuration, branch protections, approvals, or production deployment state.