@raishin/vanguard-frontier-agentic 2.8.0 → 2.9.0

package/skills/aws/aws-private-ca-issuer-review/metadata.json

@@ -3,19 +3,25 @@
   "name": "AWS Private CA Issuer Review",
   "type": "skill",
   "provider": "aws",
-  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
   "summary": "Review AWS ACM Private Certificate Authority issuer configurations for cert-manager, covering CA hierarchy safety, certificate template ARN scope, IRSA permissions minimization, validity period alignment, CRL reachability, and cross-account PCA usage patterns.",
   "source_type": "original",
   "official_docs": [
+    "https://docs.aws.amazon.com/privateca/latest/userguide/ca-best-practices.html",
+    "https://docs.aws.amazon.com/privateca/latest/userguide/PCACertInstall.html",
     "https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html",
-    "https://github.com/cert-manager/aws-privateca-issuer",
-    "https://docs.aws.amazon.com/privateca/latest/userguide/UsingTemplates.html",
-    "https://docs.aws.amazon.com/privateca/latest/userguide/crl-planning.html",
-    "https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html"
+    "https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html"
   ],
   "security_notes": "Using a Root CA ARN in AWSPCAIssuer exposes the root of trust directly to cert-manager. A SubordinateCACertificate template allows cert-manager to issue intermediate CAs, enabling an attacker with cert-manager IRSA access to create a shadow CA trusted by the entire corporate PKI. IRSA role must exclude acm-pca:DeleteCertificateAuthority and acm-pca:CreateCertificateAuthority.",
-  "last_verified": "2026-05-02",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-private-ca-issuer-review",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.4"
 }

package/skills/aws/aws-private-ca-issuer-review/references/official-sources.md

@@ -1,22 +1,29 @@
 # Official sources
 
-Use this reference only when you need source grounding for AWS Private CA behavior or the detailed source list.
+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/privateca/latest/userguide/
-- https://docs.aws.amazon.com/privateca/latest/userguide/CT-CreateCertificate.html
-- https://docs.aws.amazon.com/privateca/latest/userguide/PcaIssueCert.html
-- https://docs.aws.amazon.com/privateca/latest/userguide/CT-IssueCertificate.html
-- https://docs.aws.amazon.com/privateca/latest/userguide/crl-planning.html
-- https://github.com/cert-manager/aws-privateca-issuer
+- https://docs.aws.amazon.com/privateca/latest/userguide/ca-best-practices.html
+- https://docs.aws.amazon.com/privateca/latest/userguide/PCACertInstall.html
+- https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html
+- https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html
 
-## cert-manager AWS PCA issuer plugin
+## Grounding rule
 
-- https://cert-manager.io/docs/configuration/issuers/
-- https://github.com/cert-manager/aws-privateca-issuer/blob/main/pkg/api/v1beta1/types.go
+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.
 
-## Grounding rule
+## Current MCP/documentation refresh (2026-06-02)
+
+Service facts from official docs:
+- AWS Private CA best practices include documenting CA structure and policies, minimizing root CA use, giving root CA its own account, separating administrator and issuer roles, managed revocation, CloudTrail, and blocking public CRL access.
+- Installing CA certificates differs for root and subordinate CAs and depends on compatible signing algorithms and activation steps.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported AWS Private CA and ACM as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Sampled APIs `ACM PCA+DescribeCertificateAuthority` and `ACM+DescribeCertificate` were reported `isAvailableIn` in those regions.
 
-Official documentation explains AWS service behavior. It does not prove the user's current PCA hierarchy, IRSA trust policy, CRL reachability, RAM share scope, or live cert-manager configuration. Prefer live AWS MCP/CLI evidence or sanitized user-provided YAML for current-state claims.
+Review implications:
+- Issuer review requires CA hierarchy, policy/OID constraints, revocation path, issuer/admin separation, key protection, CloudTrail, certificate templates, renewal, and trust-store impact evidence.
+- CA availability does not prove safe issuance policy or trust boundary.

package/skills/aws/aws-private-ca-issuer-review/references/private-ca-issuer-trust-boundaries.md

@@ -0,0 +1,59 @@
+# Private CA Issuer Trust Boundaries Guide
+
+Use this reference for AWS ACM Private CA issuer reviews involving cert-manager `AWSPCAIssuer`, `AWSPCAClusterIssuer`, IRSA, certificate templates, subordinate CA usage, CRL reachability, cross-account CA sharing, and Kubernetes certificate issuance.
+
+## What people get wrong
+
+The lazy story is:
+
+> cert-manager can issue certificates, so the issuer is configured correctly.
+
+Wrong. A working issuer can still mint the wrong certificate class, use the wrong CA tier, bypass namespace boundaries, break revocation, or grant cert-manager CA-administration permissions.
+
+Common bad assumptions:
+
+- A ROOT CA ARN is acceptable if issuance works.
+- Any ACM PCA template is safe for workloads.
+- IRSA permissions can be broad because cert-manager is trusted infrastructure.
+- CRL distribution is optional for private workloads.
+- Cross-account PCA sharing removes the need for tight security-account controls.
+- Long workload certificate duration is operationally safer.
+
+## Private-CA failure modes
+
+- `AWSPCAIssuer` or `AWSPCAClusterIssuer` references a root CA instead of subordinate CA.
+- Certificate template allows subordinate CA issuance instead of end-entity certificates.
+- IRSA role includes `CreateCertificateAuthority`, `DeleteCertificateAuthority`, broad resource `*`, or unrelated PCA actions.
+- Cluster-scoped issuer allows namespaces to request certificates outside their trust boundary.
+- CRL S3 distribution point is unreachable from clients, disabling practical revocation.
+- Cross-account RAM/shared CA policy grants issuance without namespace/cluster/account guardrails.
+
+## Minimum safe workflow
+
+1. Identify issuer kind, namespace scope, CA ARN, CA type, template ARN, Kubernetes service account, and IRSA role.
+2. Verify CA hierarchy: workload issuers use subordinate CA, not root CA; root remains offline/highly restricted.
+3. Verify certificate template is end-entity only unless there is explicit approved subordinate-CA issuance use case.
+4. Review IAM/IRSA for minimum issuance actions: IssueCertificate, GetCertificate, DescribeCertificateAuthority.
+5. Check certificate duration, renewBefore, key usages, SANs, namespace boundaries, and approval policy.
+6. Verify CRL/OCSP/revocation distribution reachability and audit logging.
+7. Require explicit approval before changing CA, issuer, template, or IRSA policy.
+
+## Verification targets
+
+- cert-manager `Certificate`, `Issuer`, `ClusterIssuer`, `AWSPCAIssuer`, and `AWSPCAClusterIssuer` YAML fields
+- ACM Private CA type, state, ARN, certificate template ARN, CRL configuration, audit report, and CloudTrail issuance events
+- IRSA role trust policy, service account annotation, IAM actions/resources, and permissions boundary/SCP effects
+- Kubernetes namespace/RBAC boundaries, approver policy, cert-manager logs/events, and certificate request status
+- CRL S3 bucket policy, KMS policy, network reachability, client trust stores, and revocation test evidence
+- cross-account RAM/shared CA permissions and security-account ownership
+
+## When to push back
+
+Push back if the user asks to:
+
+- issue workload certificates directly from a root CA
+- allow cert-manager to mint subordinate CAs
+- grant broad ACM PCA admin actions to IRSA
+- ignore CRL reachability or revocation evidence
+- approve long-lived workload certificates without risk acceptance
+- treat successful issuance as proof of safe PKI posture

package/skills/aws/aws-rds-aurora-performance-investigator/SKILL.md

@@ -4,8 +4,8 @@ description: Investigate Amazon RDS and Aurora-specific incidents involving late
 allowed-tools: Read Grep Glob WebFetch
 metadata:
   author: "github: Raishin"
-  version: "0.1.2"
-  updated: "2026-05-05"
+  version: "0.1.4"
+  updated: "2026-06-02"
   category: observability
 ---
 
@@ -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.
+- [RDS and Aurora Performance Evidence Guide](references/rds-aurora-performance-evidence.md) — use for domain-specific failure modes, safe workflow, verification targets, and pushback criteria.
 
 ## Response minimum
 

package/skills/aws/aws-rds-aurora-performance-investigator/metadata.json

@@ -14,14 +14,14 @@
   "summary": "Investigate Amazon RDS and Aurora latency, connection exhaustion, slow queries, lock waits, replica lag, storage pressure, failover, Performance Insights, and database capacity risk.",
   "source_type": "original",
   "official_docs": [
-    "https://docs.aws.amazon.com/devopsagent/latest/userguide/about-aws-devops-agent-devops-agent-skills.html",
-    "https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_BestPractices.html",
-    "https://docs.aws.amazon.com/prescriptive-guidance/latest/amazon-rds-monitoring-alerting/performance-insights-tools.html",
+    "https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.LoggingAndMonitoring.html",
+    "https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.html",
+    "https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/limitless-monitoring.pi.html",
     "https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html"
   ],
   "security_notes": "Do not recommend resizing, failover, parameter changes, or index changes without evidence separating CPU, I/O, lock, query-plan, storage, connection, and application-driver causes.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-rds-aurora-performance-investigator",
   "author": "github: Raishin",
-  "version": "0.1.2"
+  "version": "0.1.4"
 }

package/skills/aws/aws-rds-aurora-performance-investigator/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/devopsagent/latest/userguide/about-aws-devops-agent-devops-agent-skills.html
-- https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_BestPractices.html
-- https://docs.aws.amazon.com/prescriptive-guidance/latest/amazon-rds-monitoring-alerting/performance-insights-tools.html
+- https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.LoggingAndMonitoring.html
+- https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.html
+- https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/limitless-monitoring.pi.html
 - https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.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:
+- RDS logging and monitoring guidance includes CloudWatch, CloudTrail, Enhanced Monitoring, Performance Insights, SNS, and Trusted Advisor as reliability evidence sources.
+- Aurora Performance Insights monitors DB load and supports filtering by waits and SQL; AWS docs also flag Performance Insights mode/lifecycle considerations that must be checked for current deployments.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported Amazon RDS, Amazon Aurora, and Amazon CloudWatch as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Sampled APIs `RDS+DescribeDBInstances` and `PI+DescribeDimensionKeys` were reported `isAvailableIn` in those regions.
+
+Review implications:
+- Performance investigation needs time window, DB load/AAS, wait events, top SQL, CPU/IO/memory/network, connection counts, storage, engine version, failover events, and recent changes.
+- Availability of RDS APIs does not prove Performance Insights is enabled or that query-level evidence exists.

package/skills/aws/aws-rds-aurora-performance-investigator/references/rds-aurora-performance-evidence.md

@@ -0,0 +1,59 @@
+# RDS and Aurora Performance Evidence Guide
+
+Use this reference for Amazon RDS/Aurora latency, connection exhaustion, slow SQL, lock waits, replica lag, failover behavior, storage pressure, CPU/I/O saturation, Performance Insights, Enhanced Monitoring, and database capacity investigations.
+
+## What people get wrong
+
+The lazy story is:
+
+> Resize the database; CPU or connections are high.
+
+Wrong. Database incidents often come from query plans, locks, connection pools, I/O, replication, failover, storage, or application behavior. Resizing can hide root cause and increase cost without fixing the workload.
+
+Common bad assumptions:
+
+- High CPU is the root cause.
+- More connections improves throughput.
+- Replica lag means the reader is too small.
+- Performance Insights top SQL is always the culprit.
+- Failover success means no user impact.
+- Storage autoscaling removes storage risk.
+
+## RDS/Aurora failure modes
+
+- Connection pool storms exhaust DB connections or memory.
+- Lock waits/deadlocks make healthy CPU look misleading.
+- Query plan regression or missing index increases DB load and I/O.
+- Aurora replica lag, cluster cache behavior, or writer/read endpoint routing causes stale or slow reads.
+- Storage, burst balance, IOPS, temp space, or transaction logs saturate before CPU.
+- Maintenance, parameter changes, failover, or backups correlate with performance but are not inspected.
+
+## Minimum safe workflow
+
+1. Identify engine, deployment topology, instance classes, writer/readers, timeframe, symptoms, and customer impact.
+2. Build evidence timeline from CloudWatch, Performance Insights, Enhanced Monitoring, RDS events, logs, and deployment changes.
+3. Separate symptoms from hypotheses: CPU, connections, waits, locks, I/O, storage, SQL, replication, failover, and app traffic.
+4. Inspect top SQL/waits, connection pool settings, recent schema/parameter changes, and slow query/error logs where available.
+5. Recommend low-risk mitigations first: query/index review, pool tuning, throttling callers, read routing, alarm thresholds, or controlled scaling.
+6. Require approval for failover, reboot, parameter apply, scale, index creation, or query kill actions.
+7. State what cannot be proven without database logs, PI data, or workload context.
+
+## Verification targets
+
+- CloudWatch metrics: CPUUtilization, DatabaseConnections, FreeableMemory, Read/WriteIOPS, Read/WriteLatency, DiskQueueDepth, FreeStorageSpace, ReplicaLag, Deadlocks
+- Performance Insights DB load, waits, top SQL, dimensions, and retention/Advanced mode availability
+- Enhanced Monitoring OS process/thread evidence and RDS/Aurora events
+- slow query/error logs, lock/deadlock evidence, query plans, indexes, transaction age, and connection pool config
+- cluster topology, endpoints, failover history, parameter groups, maintenance window, backups, and storage settings
+- recent deployments, migrations, traffic changes, batch jobs, and application error rates
+
+## When to push back
+
+Push back if the user asks to:
+
+- resize before inspecting waits, SQL, and connections
+- kill sessions or fail over without impact/rollback approval
+- ignore application connection pool behavior
+- create indexes in production without plan and lock/space analysis
+- call top SQL root cause without workload and wait context
+- treat replica lag as purely instance-size problem

package/skills/aws/aws-rds-aurora-performance-investigator/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-rds-aurora-performance-investigator/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-resilience-bcdr-review/SKILL.md

@@ -4,8 +4,8 @@ description: Review AWS resilience and business continuity strategy across RTO/R
 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: resilience
 ---
 
@@ -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.
+- [BCDR Recovery Evidence Guide](references/bcdr-recovery-evidence.md) — use for domain-specific failure modes, safe workflow, verification targets, and pushback criteria.
 
 ## Response minimum
 

package/skills/aws/aws-resilience-bcdr-review/metadata.json

@@ -14,14 +14,14 @@
   "summary": "Review AWS resilience and business continuity across RTO/RPO, backup, multi-AZ, multi-Region, failover, game days, runbooks, drift, and recovery validation.",
   "source_type": "original",
   "official_docs": [
-    "https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html",
-    "https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html",
-    "https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_testing_resiliency_failure_injection_resiliency.html",
-    "https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html"
+    "https://docs.aws.amazon.com/wellarchitected/2023-10-03/framework/rel_planning_for_recovery_disaster_recovery.html",
+    "https://docs.aws.amazon.com/resilience-hub/latest/userguide/resilience-checks.html",
+    "https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html",
+    "https://docs.aws.amazon.com/route53/latest/developerguide/dns-failover.html"
   ],
   "security_notes": "Do not accept backup configuration as recovery proof. Require restore tests, RTO/RPO evidence, drift controls, owner/runbook clarity, and blast-radius analysis.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-resilience-bcdr-review",
   "author": "github: Raishin",
-  "version": "0.1.2"
+  "version": "0.1.4"
 }

package/skills/aws/aws-resilience-bcdr-review/references/bcdr-recovery-evidence.md

@@ -0,0 +1,59 @@
+# BCDR Recovery Evidence Guide
+
+Use this reference for AWS resilience, business continuity, disaster recovery, RTO/RPO, failover/failback, backup/restore, game days, runbooks, and recovery validation reviews.
+
+## What people get wrong
+
+The lazy story is:
+
+> We have backups and multi-AZ, so recovery is covered.
+
+Wrong. BCDR is proven by exercised recovery against business objectives. Configuration without restore/failover evidence is a promise, not a capability.
+
+Common bad assumptions:
+
+- Backup success equals restore success.
+- Multi-AZ equals disaster recovery.
+- Multi-Region replication guarantees low RPO.
+- DNS failover is enough for application recovery.
+- Runbooks prove operators can execute under pressure.
+- Resilience Hub assessment replaces game days.
+
+## BCDR failure modes
+
+- RTO/RPO targets are not defined per business process or data tier.
+- Backups are encrypted, retained, or replicated but not restorable by the recovery team.
+- Failover path lacks identity, network, DNS, KMS, secrets, quota, or dependency readiness.
+- Data replication produces split-brain, stale reads, or unreconciled writes.
+- Failback is undefined or riskier than failover.
+- Recovery automation depends on the same failed Region/account/service.
+
+## Minimum safe workflow
+
+1. Define workload scope, critical business functions, RTO/RPO, MTPD, and dependency tiers.
+2. Map recovery strategy: backup/restore, pilot light, warm standby, active/passive, or active/active.
+3. Verify recovery prerequisites: backups, replication, IAM, KMS, DNS, network, quotas, secrets, and runbooks.
+4. Demand restore/failover test evidence, not just configuration.
+5. Review failback, data reconciliation, customer communication, and post-recovery monitoring.
+6. Prioritize gaps by business impact, recovery objective miss, and remediation complexity.
+7. Keep destructive failover/failback operations approval-gated.
+
+## Verification targets
+
+- RTO/RPO by workload component and business owner approval
+- AWS Backup plans/vaults/copy jobs, restore jobs, restore testing, retention, vault lock, and KMS access
+- Resilience Hub assessment, recommendations, and policy target evidence
+- Route 53 health checks, Application Recovery Controller routing controls/readiness checks, DNS TTL, and traffic-shift runbooks
+- database/storage replication lag, consistency model, point-in-time restore, and reconciliation plan
+- game-day results, recovery runbook timestamps, operator roles, and post-test corrective actions
+
+## When to push back
+
+Push back if the user asks to:
+
+- accept backup configuration without restore evidence
+- claim RTO/RPO compliance without timed tests
+- ignore failback and reconciliation
+- perform failover tests without stakeholder approval
+- rely on one Region/account for recovery control plane
+- hide recovery gaps because the architecture is “multi-AZ”

package/skills/aws/aws-resilience-bcdr-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/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html
-- https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html
-- https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_testing_resiliency_failure_injection_resiliency.html
+- https://docs.aws.amazon.com/wellarchitected/2023-10-03/framework/rel_planning_for_recovery_disaster_recovery.html
+- https://docs.aws.amazon.com/resilience-hub/latest/userguide/resilience-checks.html
 - https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html
+- https://docs.aws.amazon.com/route53/latest/developerguide/dns-failover.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:
+- Well-Architected reliability guidance says DR strategy should meet recovery objectives using approaches such as backup/restore, standby, or active/active.
+- Resilience Hub checks can evaluate RTO/RPO targets and service-specific resilience patterns across services including RDS/Aurora, S3, DynamoDB, EC2, EBS, Lambda, EKS, SNS, SQS, ECS, ELB, API Gateway, Route 53, ARC, and Step Functions.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported AWS Resilience Hub, AWS Backup, and Route 53 as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Sampled API `Backup+ListBackupVaults` was reported `isAvailableIn` in those regions.
+
+Review implications:
+- BCDR review requires explicit RTO/RPO, dependency map, backup/replication evidence, failover runbook, restore/failover test results, DNS/traffic plan, and rollback criteria.
+- Tool checks do not prove business recovery readiness without exercised tests.

package/skills/aws/aws-resilience-bcdr-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, 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-resilience-bcdr-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-s3-data-perimeter-governor/SKILL.md

@@ -4,8 +4,8 @@ description: Review Amazon S3 data perimeter and exposure posture across Block P
 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.
+- [S3 Data Perimeter Controls Guide](references/s3-data-perimeter-controls.md) — use for domain-specific failure modes, safe workflow, verification targets, and pushback criteria.
 
 ## Response minimum
 

package/skills/aws/aws-s3-data-perimeter-governor/metadata.json

@@ -14,14 +14,14 @@
   "summary": "Review Amazon S3 data perimeter, Block Public Access, Object Ownership, ACL removal, bucket/access point policies, TLS-only access, encryption, replication, lifecycle, and exposure risk.",
   "source_type": "original",
   "official_docs": [
-    "https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html",
     "https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html",
-    "https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html",
-    "https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-with-s3-policy-actions.html"
+    "https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-points.html",
+    "https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies.html",
+    "https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html"
   ],
   "security_notes": "Do not broaden S3 public or cross-account access. Prefer Block Public Access, disabled ACLs, scoped policies, TLS-only conditions, encryption, logging, and Access Analyzer validation.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-s3-data-perimeter-governor",
   "author": "github: Raishin",
-  "version": "0.1.2"
+  "version": "0.1.4"
 }

package/skills/aws/aws-s3-data-perimeter-governor/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/AmazonS3/latest/userguide/security-best-practices.html
 - https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html
-- https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html
-- https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-with-s3-policy-actions.html
+- https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-points.html
+- https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies.html
+- https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.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:
+- S3 Block Public Access can be configured at account, bucket, access point, and organization levels; IAM Access Analyzer for S3 can review public buckets.
+- S3 access points support shared dataset access patterns, VPC restrictions, IAM policies, and object-operation controls.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported S3, Security Hub, and GuardDuty as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Sampled APIs `S3+GetBucketPolicy`, `S3+GetPublicAccessBlock`, and `AccessAnalyzer+ListFindings` were reported `isAvailableIn` in those regions.
+
+Review implications:
+- Data perimeter review needs bucket/access point policies, BPA state, encryption, VPC endpoint policy, organization/SCP context, Access Analyzer findings, replication, logging, and exception approvals.
+- Public-access absence alone does not prove tenant/data perimeter safety.

package/skills/aws/aws-s3-data-perimeter-governor/references/s3-data-perimeter-controls.md

@@ -0,0 +1,59 @@
+# S3 Data Perimeter Controls Guide
+
+Use this reference for Amazon S3 data perimeter reviews covering Block Public Access, Object Ownership, ACL removal, bucket/access point policies, VPC endpoint conditions, TLS-only access, encryption, replication, logging, and cross-account access.
+
+## What people get wrong
+
+The lazy story is:
+
+> Block Public Access is on, so the bucket is safe.
+
+Wrong. S3 exposure is a policy system. Public blocking helps, but data can still leak through broad principals, cross-account trust, access points, replication, CloudFront origins, VPC endpoint policies, logging gaps, and weak object ownership assumptions.
+
+Common bad assumptions:
+
+- `Principal: *` is safe if conditions look specific.
+- ACLs no longer matter everywhere because Object Ownership exists.
+- VPC endpoint conditions prove private-only access.
+- SSE-S3/SSE-KMS proves authorization and data minimization.
+- Access points simplify policy without changing risk.
+- Server access logging or CloudTrail data events are enabled unless proven.
+
+## S3-specific failure modes
+
+- Bucket policy allows public, cross-account, or organization-wide access without prefix/resource boundaries.
+- Access point or Multi-Region Access Point policy bypasses intended bucket guardrails.
+- Block Public Access differs at account, bucket, and access-point layers.
+- Object Ownership/ACL state allows unexpected object-owner access or breaks writers.
+- VPC endpoint policy, `aws:SourceVpce`, `aws:PrincipalOrgID`, and TLS conditions are missing or misapplied.
+- Replication, lifecycle expiration, inventory, logging, or Macie coverage excludes sensitive prefixes.
+
+## Minimum safe workflow
+
+1. Identify bucket, account, Region, data classification, access patterns, writers/readers, and prefixes.
+2. Review account-level and bucket-level Block Public Access plus Object Ownership and ACL posture.
+3. Inspect bucket policy, access point policies, VPC endpoint policies, KMS key policy, and cross-account principals together.
+4. Verify data perimeter conditions: organization, VPC endpoint, TLS, encryption, source account, source ARN, and prefix scope.
+5. Check logging/detection: CloudTrail data events, S3 server access logs, Storage Lens, Macie, Access Analyzer, and Security Hub findings.
+6. Recommend smallest reversible policy/control changes; destructive delete/lifecycle changes require separate approval.
+7. State what live evidence was sampled and what remains unknown.
+
+## Verification targets
+
+- S3 Block Public Access at account, bucket, and access point level
+- Object Ownership, ACL state, bucket policy, access point policy, and Multi-Region Access Point policy
+- IAM/SCP/VPC endpoint/KMS policies affecting access
+- policy conditions: `aws:PrincipalOrgID`, `aws:SourceVpce`, `aws:SecureTransport`, `s3:prefix`, `aws:SourceArn`, `aws:SourceAccount`
+- CloudTrail data events, server access logs, S3 Inventory, Storage Lens, Macie classification, Access Analyzer, and Security Hub findings
+- replication/lifecycle/object lock/retention settings for sensitive prefixes
+
+## When to push back
+
+Push back if the user asks to:
+
+- allow broad cross-account or public access without data-owner approval
+- disable Block Public Access to “fix” application access
+- rely on encryption as a substitute for authorization
+- remove logs, Object Lock, retention, or replication without compliance review
+- trust a single bucket policy snippet without account/SCP/KMS/endpoint context
+- patch production bucket policies without rollback and access test plan