@raishin/vanguard-frontier-agentic 2.8.0 → 2.10.0

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

package/skills/aws/aws-s3-data-perimeter-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-s3-data-perimeter-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-security-posture-hardening/SKILL.md

@@ -4,8 +4,8 @@ description: Review broad AWS security posture across Security Hub CSPM, GuardDu
 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.
+- [Security Posture Prioritization Guide](references/security-posture-prioritization.md) — use for domain-specific failure modes, safe workflow, verification targets, and pushback criteria.
 
 ## Response minimum
 

package/skills/aws/aws-security-posture-hardening/metadata.json

@@ -14,14 +14,14 @@
   "summary": "Harden AWS security posture across Security Hub CSPM, GuardDuty, Inspector, Macie, Config, IAM, logging, encryption, public exposure, and remediation workflow.",
   "source_type": "original",
   "official_docs": [
-    "https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-v2-recommendations.html",
-    "https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-controls-reference.html",
-    "https://docs.aws.amazon.com/securityhub/latest/userguide/enable-standards.html",
-    "https://docs.aws.amazon.com/securityhub/latest/userguide/guardduty-controls.html"
+    "https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub-v2.html",
+    "https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html",
+    "https://docs.aws.amazon.com/inspector/latest/user/what-is-inspector.html",
+    "https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html"
   ],
   "security_notes": "Do not treat a green dashboard as proof of security. Verify service coverage, Regions, delegated admin, Config recording, suppressions, public exposure, and remediation evidence.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-security-posture-hardening",
   "author": "github: Raishin",
-  "version": "0.1.2"
+  "version": "0.1.4"
 }

package/skills/aws/aws-security-posture-hardening/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/securityhub/latest/userguide/securityhub-v2-recommendations.html
-- https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-controls-reference.html
-- https://docs.aws.amazon.com/securityhub/latest/userguide/enable-standards.html
-- https://docs.aws.amazon.com/securityhub/latest/userguide/guardduty-controls.html
+- https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub-v2.html
+- https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html
+- https://docs.aws.amazon.com/inspector/latest/user/what-is-inspector.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:
+- Security Hub unifies cloud security signals, exposure detection, automated response paths, and third-party integrations.
+- IAM Access Analyzer can identify external/internal access, unused IAM access, validate policies, and generate policies from CloudTrail activity.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported Security Hub and GuardDuty as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Sampled APIs `SecurityHub+GetFindings`, `GuardDuty+ListDetectors`, and `AccessAnalyzer+ListFindings` were reported `isAvailableIn` in those regions.
+
+Review implications:
+- Hardening requires enabled-service coverage, org aggregation, finding severity/age, exceptions, IAM exposure, public access, encryption/logging gaps, and remediation ownership.
+- Security tool availability does not prove detectors are enabled, findings are triaged, or controls are enforced.

package/skills/aws/aws-security-posture-hardening/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-security-posture-hardening/references/security-posture-prioritization.md

@@ -0,0 +1,59 @@
+# Security Posture Prioritization Guide
+
+Use this reference when prioritizing AWS Security Hub CSPM, GuardDuty, Inspector, Macie, Config, CloudTrail, IAM, public exposure, vulnerability, and compliance posture findings.
+
+## What people get wrong
+
+The lazy story is:
+
+> Sort Security Hub findings by severity and fix the highs first.
+
+Wrong. Finding severity is an input, not a priority model. Real risk depends on exploitability, exposure, asset criticality, compensating controls, account scope, and remediation blast radius.
+
+Common bad assumptions:
+
+- Security Hub enabled means all relevant controls are covered.
+- GuardDuty finding absence means no threat activity.
+- Inspector vulnerability severity equals business priority.
+- Public exposure findings are all equally urgent.
+- CloudTrail configured in one account/Region proves audit coverage.
+- Auto-remediation is safe for posture hardening.
+
+## Security-posture failure modes
+
+- Delegated administrator and organization coverage miss member accounts or Regions.
+- Security Hub standards are enabled but findings are suppressed, stale, or unowned.
+- GuardDuty, Inspector, Macie, Config, or CloudTrail are partially deployed or not routed to responders.
+- IAM findings are remediated with broad deny/allow changes that break workloads.
+- Public S3, security group, ALB, API Gateway, or CloudFront exposure lacks data classification context.
+- Remediation deletes evidence, disables logging, rotates secrets without consumers, or changes KMS policies unsafely.
+
+## Minimum safe workflow
+
+1. Confirm organization/account/Region scope and which services are actually enabled.
+2. Normalize findings by resource, owner, business criticality, exposure path, data sensitivity, and active threat evidence.
+3. Separate detection gaps from resource misconfigurations and vulnerability remediation.
+4. Prioritize by risk: internet exposure plus sensitive data, identity escalation, logging gaps, exploitable vulnerabilities, and active GuardDuty signals.
+5. Recommend least-privilege, reversible remediation with validation and rollback notes.
+6. Track exceptions, suppressions, compensating controls, and due dates explicitly.
+7. Do not execute auto-remediation from this review skill.
+
+## Verification targets
+
+- Security Hub/CSPM standards, finding workflow status, suppression rules, and delegated admin/account coverage
+- GuardDuty detectors, findings, malware protection, trusted/threat lists, and alert routing
+- Inspector coverage for EC2/ECR/Lambda and vulnerable package/resource context
+- Macie jobs/classification findings for sensitive data exposure
+- Config recorders, conformance packs, aggregators, and CloudTrail organization trails/log integrity
+- IAM Access Analyzer, public access findings, security group exposure, S3 Block Public Access, KMS key policy, and secret rotation evidence
+
+## When to push back
+
+Push back if the user asks to:
+
+- treat compliance score as actual security risk
+- suppress findings without owner, reason, expiry, and compensating control
+- run broad auto-remediation on production resources
+- widen IAM/network access to clear a finding
+- claim organization coverage from a single account sample
+- remove logs/evidence while remediating

package/skills/aws/aws-security-posture-hardening/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-serverless-production-readiness/SKILL.md

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

package/skills/aws/aws-serverless-production-readiness/metadata.json

@@ -14,14 +14,14 @@
   "summary": "Review AWS Lambda and serverless workloads for IAM, concurrency, event sources, retries, DLQs, observability, secrets, performance, cost, and rollback readiness.",
   "source_type": "original",
   "official_docs": [
+    "https://docs.aws.amazon.com/lambda/latest/dg/durable-execution-sdk-retries.html",
+    "https://docs.aws.amazon.com/lambda/latest/dg/governance-observability.html",
     "https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html",
-    "https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html",
-    "https://docs.aws.amazon.com/lambda/latest/operatorguide/monitoring-observability.html",
-    "https://docs.aws.amazon.com/lambda/latest/dg/monitoring-metrics.html"
+    "https://docs.aws.amazon.com/serverless/latest/devguide/serverless-samples.html"
   ],
   "security_notes": "Do not approve serverless workloads that lack least-privilege execution roles, retry/DLQ semantics, concurrency controls, observability, idempotency, and rollback evidence.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-serverless-production-readiness",
   "author": "github: Raishin",
-  "version": "0.1.2"
+  "version": "0.1.4"
 }