@raishin/vanguard-frontier-agentic 2.7.1 → 2.9.0

package/skills/aws/aws-observability-incident-responder/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-observability-incident-responder/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-pipeline-fix-operator/SKILL.md

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

package/skills/aws/aws-pipeline-fix-operator/metadata.json

@@ -14,13 +14,14 @@
   "summary": "Repair AWS-oriented CI/CD pipeline definitions, buildspecs, deployment workflow config, and release wiring in-repo without triggering live execution.",
   "source_type": "original",
   "official_docs": [
-    "https://docs.aws.amazon.com/codebuild/latest/userguide/build-spec-ref.html",
-    "https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html",
-    "https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html"
+    "https://docs.aws.amazon.com/codepipeline/latest/userguide/troubleshooting.html",
+    "https://docs.aws.amazon.com/codebuild/latest/userguide/troubleshooting.html",
+    "https://docs.aws.amazon.com/codedeploy/latest/userguide/troubleshooting-deployments.html",
+    "https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-codepipeline-pipeline.html"
   ],
   "security_notes": "Repo write access only. Do not manually trigger pipelines, rotate secrets, or bypass approval gates from this role. Keep fixes explicit, reviewable, and reversible.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-pipeline-fix-operator",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.2"
 }

package/skills/aws/aws-pipeline-fix-operator/references/official-sources.md

@@ -1,5 +1,29 @@
 # Official sources
 
-- https://docs.aws.amazon.com/codebuild/latest/userguide/build-spec-ref.html
-- https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html
-- https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.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/codepipeline/latest/userguide/troubleshooting.html
+- https://docs.aws.amazon.com/codebuild/latest/userguide/troubleshooting.html
+- https://docs.aws.amazon.com/codedeploy/latest/userguide/troubleshooting-deployments.html
+- https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-codepipeline-pipeline.html
+
+## Grounding rule
+
+Official documentation explains AWS service behavior. It does not prove the user's current account, Region, quota, resource configuration, IAM boundary, pricing, entitlement, or operational state. Prefer read-only AWS MCP or CLI evidence, repository evidence, or sanitized user-provided evidence for current-state claims.
+
+## Current MCP/documentation refresh (2026-06-02)
+
+Service facts from official docs:
+- CodeDeploy troubleshooting separates deployment failures by lifecycle event, credentials, PKCS7 validation, file conflicts, DownloadBundle errors, health checks, and platform/script behavior.
+- CodePipeline can be represented as CloudFormation `AWS::CodePipeline::Pipeline`; repo-side fixes must keep pipeline resource semantics and IAM roles intact.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported AWS CodePipeline, AWS CodeBuild, and AWS CodeDeploy as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Sampled APIs `CodePipeline+GetPipelineState`, `CodeBuild+BatchGetBuilds`, and `CodeDeploy+GetDeployment` were reported `isAvailableIn` in those regions.
+
+Review implications:
+- Patch only the failing repo configuration unless explicitly authorized for live action. Require failing stage/action evidence, logs, minimal diff, validation command, and rollback.
+- Do not guess root cause from a failed pipeline status; correlate source revision, build logs, deployment events, roles, artifacts, and environment config.

package/skills/aws/aws-pipeline-fix-operator/references/pipeline-failure-analysis.md

@@ -0,0 +1,60 @@
+# Pipeline Failure Analysis Guide
+
+Use this reference when fixing CodePipeline, CodeBuild, CodeDeploy, GitHub Actions, GitLab, buildspecs, artifact paths, environment variables, or deployment wiring in repository files.
+
+## What people get wrong
+
+The lazy story is:
+
+> The pipeline failed, so patch the line that looks broken.
+
+Wrong. Pipeline failures are often evidence-routing problems: wrong revision, wrong artifact, wrong role, wrong environment, or a deployment failure surfacing as a build failure.
+
+Common bad assumptions:
+
+- The failed stage is the root cause.
+- Re-running is harmless.
+- Build logs contain no secrets.
+- Artifact path changes are low risk.
+- A green build means deploy safety.
+- Fixing CI config authorizes a live pipeline run.
+
+## Failure-mode map
+
+- **Source stage:** wrong branch, webhook, connection, commit, submodule, or artifact format.
+- **Build stage:** buildspec path, runtime image, env var, IAM role, dependency cache, test command, artifact upload.
+- **Deploy stage:** CodeDeploy lifecycle hook, ECS task set, Lambda alias, CloudFormation change set, missing permission.
+- **Approval/gate:** missing manual approval, stale approval, wrong condition, Lambda approval action failure.
+- **Cross-account:** artifact bucket/KMS/key policy, role trust, external ID, region mismatch.
+
+## Minimum safe workflow
+
+1. Identify provider and failing stage/action.
+2. Confirm source revision and artifact that failed.
+3. Inspect logs without exposing secrets.
+4. Patch the smallest repo-side cause.
+5. Preserve gates, approvals, artifact integrity, and rollback settings.
+6. Run local lint/test/build validators relevant to the changed file.
+7. State whether a live pipeline re-run is required and require approval for it.
+
+## Verification targets
+
+- pipeline definition or workflow YAML
+- buildspec and artifact paths
+- CodeBuild project env/runtime/image settings where represented in repo
+- CodeDeploy AppSpec and deployment group references
+- CloudFormation/CDK/Terraform pipeline resource definitions
+- IAM role references and KMS/artifact bucket wiring
+- failing log excerpt sanitized by the user or read-only tool output
+
+## When to push back
+
+Push back if the user asks to:
+
+- remove tests/gates to make the pipeline green
+- print or paste secret-bearing logs
+- re-run production deploys without approval
+- change artifact identity without release-owner signoff
+- widen deploy role permissions as a blind fix
+- ignore a failed post-deploy validation
+

package/skills/aws/aws-private-ca-issuer-review/SKILL.md

@@ -4,8 +4,8 @@ description: Use this skill when reviewing AWS ACM Private CA (Private Certifica
 allowed-tools: Read Grep Glob
 metadata:
   author: "github: Raishin"
-  version: "0.1.0"
-  updated: "2026-05-05"
+  version: "0.1.4"
+  updated: "2026-06-02"
   category: security
 ---
 
@@ -32,6 +32,7 @@ Load these only when needed:
 - [Workflow and output contract](references/workflow-and-output.md)
 - [Safety checklist](references/safety-checklist.md)
 - [Official sources](references/official-sources.md)
+- [Private CA Issuer Trust Boundaries Guide](references/private-ca-issuer-trust-boundaries.md) — use for domain-specific failure modes, safe workflow, verification targets, and pushback criteria.
 
 ## Response minimum
 

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”