@raishin/vanguard-frontier-agentic 2.7.1 → 2.9.0

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

@@ -5,10 +5,10 @@ Use this reference before privileged, destructive, traffic-changing, cost-changi
 ## Non-negotiables
 
 - Never ask users to paste secrets, access keys, session tokens, private keys, customer identifiers, or sensitive account data into chat.
-- Prefer official AWS MCP tools when exposed by the active runtime. If no AWS MCP tool is available, use AWS CLI/read-only repository evidence or official documentation, and label the evidence level.
+- Use read-only AWS MCP or read-only AWS CLI evidence for live state when available; otherwise use repository evidence, sanitized user evidence, or official documentation and label the evidence level.
 - Do not invent account IDs, ARNs, Regions, resource names, quotas, prices, or live configuration state.
 - Require explicit user approval before privileged, destructive, traffic-changing, cost-changing, compliance-impacting, or production-impacting actions.
-- Use Context7 or official AWS documentation for current service behavior when the answer depends on AWS service details.
+- Use current official AWS documentation for service behavior when the answer depends on AWS service details.
 - Keep remediation least-privilege, reversible, and scoped to the requested workload or account boundary.
 
 ## Stress checks

package/skills/aws/aws-iac-change-safety-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-iac-patch-executor/SKILL.md

@@ -4,8 +4,8 @@ description: Edit AWS IaC files including CloudFormation, SAM, CDK config, and T
 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.
+- [IaC Patch Safety Guide](references/iac-patch-safety.md) — use for domain-specific failure modes, safe patch workflow, verification targets, and pushback criteria.
 
 ## Response minimum
 

package/skills/aws/aws-iac-patch-executor/metadata.json

@@ -15,12 +15,13 @@
   "source_type": "original",
   "official_docs": [
     "https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/best-practices.html",
-    "https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-best-practices.html",
-    "https://docs.aws.amazon.com/cdk/v2/guide/best-practices.html"
+    "https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets-samples.html",
+    "https://docs.aws.amazon.com/cdk/v2/guide/home.html",
+    "https://docs.aws.amazon.com/prescriptive-guidance/latest/choose-iac-tool/cloudformation.html"
   ],
   "security_notes": "Can edit IaC files, not execute live infra changes. Never hide replacements, blast-radius risks, or IAM broadening. Always surface validation gaps and rollback concerns.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-iac-patch-executor",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.2"
 }

package/skills/aws/aws-iac-patch-executor/references/iac-patch-safety.md

@@ -0,0 +1,64 @@
+# IaC Patch Safety Guide
+
+Use this reference when editing CloudFormation, SAM, CDK, Terraform, or AWS-focused IaC files to correct defects while staying repo-scoped.
+
+## What people get wrong
+
+The lazy story is:
+
+> IaC patching is safe because it is only a file change.
+
+Wrong. A small IaC diff can delete data, replace resources, widen IAM, expose networks, or break rollback once applied.
+
+Common bad assumptions:
+
+- Syntax validation catches dangerous changes.
+- Resource replacement is acceptable unless production says otherwise.
+- Deleting a property is safer than setting it explicitly.
+- IAM wildcard is temporary and harmless.
+- Security group changes are easy to reason about by inspection.
+- Terraform plan/change set is optional for small patches.
+
+## High-risk diff classes
+
+Flag these before editing or recommending apply:
+
+- resource deletion or replacement
+- IAM action/resource/principal broadening
+- security group/NACL/route/public exposure changes
+- KMS key policy, secret, certificate, or data-store retention changes
+- database, queue, bucket, stream, or backup lifecycle changes
+- cross-account trust or SCP/permission boundary changes
+- drift-sensitive changes where live state may differ from repo
+
+## Minimum safe workflow
+
+1. Identify IaC framework and target environment.
+2. Inspect existing style and patch only the requested defect.
+3. Classify blast radius and high-risk diff class.
+4. Run static validation: template lint, synth, format, schema, or validate.
+5. If live execution is requested later, require plan/change-set/drift evidence first.
+6. Provide rollback: revert diff, prior parameter value, previous template, or state-safe rollback path.
+7. Keep live apply/deploy/destroy out of scope unless separately approved.
+
+## Verification targets
+
+- `cfn-lint`, `aws cloudformation validate-template`, `sam validate`
+- `cdk synth`, `cdk diff`
+- `terraform fmt`, `terraform validate`, `terraform plan` when applicable
+- CloudFormation replacement/delete indicators from change sets
+- drift detection output for existing stacks
+- policy validation for IAM/security-sensitive changes
+- project-specific tests and schema checks
+
+## When to push back
+
+Push back if the user asks to:
+
+- apply/deploy immediately after a repo patch
+- skip plan/change-set because the diff is small
+- use wildcard IAM to unblock validation
+- delete stateful resources without backup/retention proof
+- change production networking without rollback path
+- “clean up” unrelated IaC while fixing one issue
+

package/skills/aws/aws-iac-patch-executor/references/official-sources.md

@@ -1,5 +1,29 @@
 # Official sources
 
+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/AWSCloudFormation/latest/UserGuide/best-practices.html
-- https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-best-practices.html
-- https://docs.aws.amazon.com/cdk/v2/guide/best-practices.html
+- https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets-samples.html
+- https://docs.aws.amazon.com/cdk/v2/guide/home.html
+- https://docs.aws.amazon.com/prescriptive-guidance/latest/choose-iac-tool/cloudformation.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:
+- CloudFormation best practices include validating templates, creating change sets before updating stacks, using stack policies, logging CloudFormation calls with CloudTrail, using drift detection, configuring rollback triggers, and applying least privilege.
+- Change-set examples show that template edits, parameter changes, added/removed resources, and replacement fields can alter blast radius in different ways.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported AWS CloudFormation as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Sampled APIs `CloudFormation+ValidateTemplate`, `CloudFormation+CreateChangeSet`, and `CloudFormation+DetectStackDrift` were reported `isAvailableIn` in those regions.
+
+Review implications:
+- Patch execution must stay repo-scoped unless explicitly approved for live mutation; every patch needs minimal diff, validation output, expected plan/change-set effect, and rollback instructions.
+- Do not claim production safety from local syntax validation alone; replacement/delete risk and live drift require stronger evidence.

package/skills/aws/aws-iam-least-privilege-review/SKILL.md

@@ -4,8 +4,8 @@ description: Review AWS IAM identity policies, trust policies, resource policies
 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.
+- [IAM Policy and Trust Boundary Guide](references/iam-policy-trust-boundaries.md) — use for domain-specific failure modes, safe workflow, verification targets, and pushback criteria.
 
 ## Response minimum
 

package/skills/aws/aws-iam-least-privilege-review/metadata.json

@@ -15,13 +15,13 @@
   "source_type": "adapted",
   "official_docs": [
     "https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html",
-    "https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html",
     "https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html",
-    "https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html"
+    "https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-custom-policy-checks.html",
+    "https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started-reduce-permissions.html"
   ],
   "security_notes": "Prefer read-only inspection and minimum permission changes. Do not broaden IAM access, invent ARNs, or approve production trust changes without Access Analyzer validation where available.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-iam-least-privilege-review",
   "author": "github: Raishin",
-  "version": "0.1.2"
+  "version": "0.1.4"
 }

package/skills/aws/aws-iam-least-privilege-review/references/iam-policy-trust-boundaries.md

@@ -0,0 +1,59 @@
+# IAM Policy and Trust Boundary Guide
+
+Use this reference for AWS IAM identity policies, trust policies, resource policies, permission boundaries, SCPs, session policies, PassRole, federation, OIDC, Access Analyzer findings, and least-privilege remediation.
+
+## What people get wrong
+
+The lazy story is:
+
+> Remove wildcards and the policy becomes least privilege.
+
+Wrong. Least privilege is about actions, resources, conditions, trust, session context, permission boundaries, and how the role is reached. A narrow action on a dangerous resource can still be privilege escalation.
+
+Common bad assumptions:
+
+- Managed policies are safer than inline policies.
+- Trust policy principal is enough without conditions.
+- `iam:PassRole` is harmless if deployment needs it.
+- SCP denies prove workload least privilege.
+- Access Analyzer generated policy is complete authorization design.
+- OIDC federation is safe if the provider is official.
+
+## IAM failure modes
+
+- Broad trust allows external accounts, services, or web identities without audience, subject, source, or external ID constraints.
+- `iam:PassRole`, `sts:AssumeRole`, `iam:CreatePolicyVersion`, or permissions-boundary edits enable escalation.
+- Resource policies grant cross-account/public access bypassing identity-only review.
+- Conditions use wrong operator, key, or case; deny/allow precedence is misunderstood.
+- Session policies, permission boundaries, and SCPs interact differently than expected.
+- Break-glass or CI/CD roles accumulate production admin over time.
+
+## Minimum safe workflow
+
+1. Identify principal, resource, action path, caller context, account/Org boundary, and business need.
+2. Review effective access path: identity policy, trust policy, resource policy, boundary, SCP, session policy, and service control conditions.
+3. Classify escalation risk: PassRole, policy administration, KMS decrypt, network/security group, data exfiltration, secrets, and logging disablement.
+4. Reduce access by action, resource ARN, condition, tag, principal, source account/ARN, VPC endpoint, and time/session constraints where supported.
+5. Use IAM Access Analyzer, policy validation, and simulation as evidence inputs, not proof of production safety.
+6. Provide a minimal diff and explain what it grants, denies, and cannot prove.
+7. Require approval before live IAM changes, especially denies, trust changes, and production deploy roles.
+
+## Verification targets
+
+- identity policies, trust policies, resource policies, permission boundaries, SCPs, session policies, and permission sets
+- Access Analyzer external access and unused access findings, policy validation, generated policies, and simulate-principal-policy output
+- condition keys: ExternalId, SourceArn, SourceAccount, PrincipalOrgID, VPC endpoint, MFA, tags, audience/subject for OIDC
+- `iam:PassRole`, `sts:AssumeRole`, policy version/admin actions, KMS decrypt, S3/object access, Secrets Manager, and logging controls
+- CloudTrail evidence of actual usage, last accessed data, and role chaining/session name patterns
+- rollback path for policy denies, boundary changes, SCPs, and trust policy edits
+
+## When to push back
+
+Push back if the user asks to:
+
+- grant wildcard admin to unblock delivery
+- trust an external/OIDC principal without tight conditions
+- approve PassRole without target role and service constraints
+- rely on SCPs as least-privilege proof
+- remove denies or boundaries without blast-radius analysis
+- apply IAM changes live without simulation and rollback plan

package/skills/aws/aws-iam-least-privilege-review/references/official-sources.md

@@ -6,10 +6,24 @@ Use this reference only when you need source grounding for AWS service behavior
 
 Use these as starting points, not as proof of the user's live AWS state:
 - https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html
-- https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html
 - https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html
-- https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html
+- https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-custom-policy-checks.html
+- https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started-reduce-permissions.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:
+- IAM best practices call for least-privilege permissions, federation and temporary credentials, MFA, Access Analyzer policy generation/validation, removal of unused permissions, policy conditions, and cross-account/public-access analysis.
+- IAM policy documents grant permissions through identity-based, resource-based, and other policy types; least privilege requires narrowing actions, resources, conditions, and principals.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported IAM as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Sampled API `AccessAnalyzer+ValidatePolicy` was reported `isAvailableIn` in those regions; `IAM+GetPolicy` was `isAvailableIn` in `us-east-1` and `us-west-2`, and `Not Found` in `eu-west-1` and `ap-southeast-1`, so treat IAM as global/service-specific availability evidence rather than regional resource proof.
+
+Review implications:
+- Do not approve broad IAM from intent alone. Require action/resource/condition scope, Access Analyzer findings, last-accessed or CloudTrail evidence, boundary/SCP context, and break-glass exception handling.
+- Documentation cannot prove the user's actual principals, policies, or account guardrails.

package/skills/aws/aws-iam-least-privilege-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-iam-least-privilege-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-kms-secrets-lifecycle-steward/SKILL.md

@@ -4,8 +4,8 @@ description: Review AWS KMS and Secrets Manager lifecycle posture across key pol
 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.
+- [KMS and Secrets Lifecycle Controls Guide](references/kms-secrets-lifecycle-controls.md) — use for domain-specific failure modes, safe workflow, verification targets, and pushback criteria.
 
 ## Response minimum
 

package/skills/aws/aws-kms-secrets-lifecycle-steward/metadata.json

@@ -14,14 +14,14 @@
   "summary": "Review AWS KMS keys, key policies, grants, rotation, multi-Region keys, Secrets Manager, secret rotation, replication, caching, endpoint conditions, and break-glass access.",
   "source_type": "original",
   "official_docs": [
-    "https://docs.aws.amazon.com/kms/latest/developerguide/grant-best-practices.html",
-    "https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html",
-    "https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html",
-    "https://docs.aws.amazon.com/secretsmanager/latest/userguide/best-practices.html"
+    "https://docs.aws.amazon.com/kms/latest/developerguide/overview.html",
+    "https://docs.aws.amazon.com/kms/latest/developerguide/rotating-keys.html",
+    "https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html",
+    "https://docs.aws.amazon.com/secretsmanager/latest/userguide/mes-security.html"
   ],
   "security_notes": "Do not change key policies, grants, key deletion, secret rotation, or multi-Region encryption without impact analysis for access, recovery, auditability, and rollback.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-kms-secrets-lifecycle-steward",
   "author": "github: Raishin",
-  "version": "0.1.2"
+  "version": "0.1.4"
 }

package/skills/aws/aws-kms-secrets-lifecycle-steward/references/kms-secrets-lifecycle-controls.md

@@ -0,0 +1,59 @@
+# KMS and Secrets Lifecycle Controls Guide
+
+Use this reference for AWS KMS key policy, grants, aliases, rotation, multi-Region keys, imported key material, key deletion, Secrets Manager rotation, replication, VPC endpoints, resource policies, and application secret consumption.
+
+## What people get wrong
+
+The lazy story is:
+
+> Encryption is enabled and secrets rotate, so crypto posture is fine.
+
+Wrong. KMS and Secrets Manager failures are usually lifecycle failures: bad key policy, grant sprawl, broken rotation consumers, disabled replica keys, undecryptable backups, or irreversible key deletion.
+
+Common bad assumptions:
+
+- IAM policy alone controls KMS access.
+- Key aliases are stable security boundaries.
+- Automatic key rotation solves secret rotation.
+- Secret replication is harmless metadata.
+- VPC endpoints make secret retrieval private and authorized.
+- Scheduled key deletion is a normal cleanup task.
+
+## KMS/secrets failure modes
+
+- Key policy omits account/root enablement, break-glass, or required service principals.
+- Grants survive longer than workload need or permit unintended decrypt/data-key use.
+- KMS key disabled/deleted/rotated blocks RDS, EBS, S3, Lambda, backups, or secret replication.
+- Rotation Lambda updates the secret but not every consuming application or connection pool.
+- Secrets Manager resource policy allows cross-account access without org/source conditions.
+- Multi-Region key or replicated secret has asymmetric policy/KMS/VPC endpoint posture.
+
+## Minimum safe workflow
+
+1. Identify protected data, key/secret owners, consuming services, Regions, accounts, and recovery requirements.
+2. Review KMS key policy first, then IAM policies, grants, aliases, rotation, multi-Region state, and deletion schedule.
+3. Review secret lifecycle: creation, rotation, version staging labels, replication, resource policy, retrieval path, cache, and consumers.
+4. Check endpoint and policy conditions: VPC endpoint, principal org, source account/ARN, encryption context, and service principal.
+5. Verify recovery: break-glass, backup restore decryptability, replica key availability, and rollback of rotation.
+6. Recommend reversible policy/rotation fixes; key deletion, disablement, or secret deletion require explicit approval and impact proof.
+7. Separate configuration evidence from successful decrypt/restore/rotation evidence.
+
+## Verification targets
+
+- KMS key policy, IAM policies, grants, aliases, rotation, multi-Region key state, imported material, deletion schedule, and CloudTrail usage
+- encryption context, ViaService/source conditions, cross-account principals, and service-linked usage
+- Secrets Manager secret policy, KMS key, rotation Lambda, version staging labels, replication Regions, and last rotation status
+- VPC endpoint policy, CloudTrail events, application retrieval path, cache TTL, and error handling
+- RDS/EBS/S3/Lambda/ECS/EKS/AWS Backup dependencies on the key or secret
+- break-glass access, recovery tests, backup restore decryptability, and consumer rotation validation
+
+## When to push back
+
+Push back if the user asks to:
+
+- schedule KMS key deletion without dependency and restore proof
+- rotate secrets without consumer readiness and rollback plan
+- use broad decrypt permissions or wildcard key policies
+- treat aliases as immutable trust anchors
+- replicate secrets/keys without Region, KMS, and policy review
+- remove CloudTrail/log evidence while fixing access

package/skills/aws/aws-kms-secrets-lifecycle-steward/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/kms/latest/developerguide/grant-best-practices.html
-- https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html
-- https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html
-- https://docs.aws.amazon.com/secretsmanager/latest/userguide/best-practices.html
+- https://docs.aws.amazon.com/kms/latest/developerguide/overview.html
+- https://docs.aws.amazon.com/kms/latest/developerguide/rotating-keys.html
+- https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html
+- https://docs.aws.amazon.com/secretsmanager/latest/userguide/mes-security.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:
+- Secrets Manager supports managing secret lifecycle and automating credential rotation instead of hard-coded secrets.
+- Secrets Manager security guidance says rotation requires appropriate IAM policies and KMS/key trust policies, with scope that can vary by region.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported AWS KMS and AWS Secrets Manager as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Sampled APIs `KMS+DescribeKey` and `Secrets Manager+DescribeSecret` were reported `isAvailableIn` in those regions.
+
+Review implications:
+- Do not claim secret safety without evidence for rotation status, KMS key policy/grants, resource policy, replica/region scope, access path, audit logs, recovery windows, and application cutover behavior.
+- Key or secret existence does not prove least privilege, correct rotation, or safe deletion.

package/skills/aws/aws-kms-secrets-lifecycle-steward/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-kms-secrets-lifecycle-steward/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-landing-zone-governor/SKILL.md

@@ -4,8 +4,8 @@ description: Review and design AWS landing zones, AWS Control Tower environments
 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: compliance
 ---
 
@@ -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.
+- [Landing Zone Governance Controls Guide](references/landing-zone-governance-controls.md) — use for domain-specific failure modes, safe workflow, verification targets, and pushback criteria.
 
 ## Response minimum
 

package/skills/aws/aws-landing-zone-governor/metadata.json

@@ -14,14 +14,14 @@
   "summary": "Review AWS multi-account landing zones, Control Tower posture, Organizations structure, OUs, guardrails, logging, audit accounts, and account vending decisions.",
   "source_type": "original",
   "official_docs": [
+    "https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html",
     "https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html",
-    "https://docs.aws.amazon.com/controltower/latest/userguide/lz-update-best-practices.html",
-    "https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-aws-environment/understanding-landing-zones.html",
-    "https://docs.aws.amazon.com/prescriptive-guidance/latest/designing-control-tower-landing-zone/introduction.html"
+    "https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html",
+    "https://docs.aws.amazon.com/controltower/latest/controlreference/control-reference.html"
   ],
   "security_notes": "Do not collapse environments into one account for convenience. Treat weak OU design, missing centralized logging, unmanaged SCPs, and unclear account ownership as governance risks.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-landing-zone-governor",
   "author": "github: Raishin",
-  "version": "0.1.2"
+  "version": "0.1.4"
 }

package/skills/aws/aws-landing-zone-governor/references/landing-zone-governance-controls.md

@@ -0,0 +1,59 @@
+# Landing Zone Governance Controls Guide
+
+Use this reference for AWS landing zone, Control Tower, Organizations, OU, account vending, guardrail, delegated admin, centralized logging, and audit/security account reviews.
+
+## What people get wrong
+
+The lazy story is:
+
+> Control Tower deployed successfully, so the landing zone is governed.
+
+Wrong. Landing-zone governance fails through account sprawl, OU drift, missing delegated-admin scope, weak SCPs, logging gaps, and unclear account lifecycle ownership.
+
+Common bad assumptions:
+
+- OUs mirror the org chart safely.
+- SCPs are complete guardrails rather than coarse permission boundaries.
+- Centralized logging exists because an audit account exists.
+- Account vending is safe without lifecycle, budget, and ownership controls.
+- Sandbox accounts are low risk.
+- Control Tower drift is only an operational nuisance.
+
+## Landing-zone failure modes
+
+- Workloads are placed in OUs with wrong controls, data residency, or production isolation.
+- SCPs block break-glass or deployments, or fail to prevent risky services/Regions.
+- CloudTrail, Config, Security Hub, GuardDuty, Macie, IAM Access Analyzer, and log archive coverage differ across accounts/Regions.
+- Account factory/vending lacks owner, cost center, environment, network, identity, and decommission metadata.
+- Delegated administrator roles create hidden privilege concentration.
+- Shared network/log/security accounts become single points of governance failure.
+
+## Minimum safe workflow
+
+1. Identify organization scope, management account constraints, Control Tower state, OUs, Regions, and account inventory.
+2. Classify accounts by environment, data sensitivity, workload criticality, ownership, and lifecycle stage.
+3. Review preventive controls: SCPs, Control Tower controls, Region restrictions, IAM boundaries, and break-glass path.
+4. Review detective controls: organization trails, Config aggregators, Security Hub, GuardDuty, Macie, log archive, and alert routing.
+5. Check account vending and decommission workflow for owner, budget, network, identity, tagging, and closure criteria.
+6. Return governance gaps with blast radius, evidence level, owner, and staged remediation.
+7. Do not recommend management-account or SCP changes without explicit approval and rollback plan.
+
+## Verification targets
+
+- AWS Organizations OUs, accounts, delegated admins, SCPs, tag policies, backup policies, and Region restrictions
+- AWS Control Tower landing-zone version, enabled controls, drift status, Account Factory/account vending process
+- log archive/audit/security account design, CloudTrail organization trail, Config aggregator, and S3/KMS log protection
+- identity center/federation, break-glass, permission sets, and management-account access controls
+- shared networking accounts, VPC sharing, Transit Gateway ownership, and account baseline templates
+- account owner metadata, budgets, tags, support model, and decommission evidence
+
+## When to push back
+
+Push back if the user asks to:
+
+- flatten OUs for convenience without blast-radius analysis
+- deploy SCPs without testing break-glass and pipeline impact
+- call Control Tower deployment proof of full governance
+- skip centralized logs or delegated-admin coverage checks
+- create accounts without owner, budget, lifecycle, and data classification
+- mutate management-account controls from advisory review alone