@raishin/vanguard-frontier-agentic 2.8.0 → 2.9.0

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

package/skills/aws/aws-landing-zone-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/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
 
 ## 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:
+- AWS Control Tower automates multi-account governance with controls, account provisioning, and drift prevention/detection around a landing zone.
+- AWS multi-account landing-zone guidance emphasizes OU structure, workload isolation, and separating production from non-production environments.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported AWS Control Tower and AWS Organizations as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Sampled product availability is not proof that a landing zone is enabled, healthy, drift-free, or compliant in the user's organization.
+
+Review implications:
+- Require evidence for organization structure, OUs/accounts, SCPs, delegated admin, controls/guardrails, identity center, logging/audit accounts, network boundaries, and drift.
+- Do not infer landing-zone health from service availability; inspect Control Tower state, Organizations policy attachments, Config/CloudTrail coverage, and exceptions.

package/skills/aws/aws-landing-zone-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, 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-landing-zone-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-live-deployment-guarded-operator/SKILL.md

@@ -4,8 +4,8 @@ description: Operate guarded live AWS deployment changes with explicit account,
 allowed-tools: Read Grep Glob
 metadata:
   author: "github: Raishin"
-  version: "0.1.0"
-  updated: "2026-05-05"
+  version: "0.1.3"
+  updated: "2026-06-02"
   category: delivery
 ---
 

package/skills/aws/aws-live-deployment-guarded-operator/metadata.json

@@ -14,14 +14,14 @@
   "summary": "Operate guarded live AWS deployment changes only after explicit target confirmation, approval checkpoints, dry-run or preview evidence, rollback readiness, and post-change verification.",
   "source_type": "original",
   "official_docs": [
-    "https://docs.aws.amazon.com/cli/v1/reference/sts/get-caller-identity.html",
+    "https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html",
+    "https://docs.aws.amazon.com/config/latest/developerguide/codedeploy-deployment-group-auto-rollback-enabled.html",
     "https://docs.aws.amazon.com/codepipeline/latest/userguide/approvals.html",
-    "https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-change-calendar.html",
-    "https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html"
+    "https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/drift-aware-change-sets.html"
   ],
   "security_notes": "This role may work in repos connected to live AWS credentials. Never run live deployment mutations without explicit target confirmation, preview evidence, approval, rollback readiness, and post-change verification.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-live-deployment-guarded-operator",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.3"
 }

package/skills/aws/aws-live-deployment-guarded-operator/references/official-sources.md

@@ -1,12 +1,29 @@
 # Official sources
 
-Primary AWS documentation used to shape this guarded live-AWS role:
+Use this reference only when you need source grounding for AWS service behavior or the detailed source list.
 
-- https://docs.aws.amazon.com/cli/v1/reference/sts/get-caller-identity.html
+## AWS documentation
+
+Use these as starting points, not as proof of the user's live AWS state:
+- https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html
+- https://docs.aws.amazon.com/config/latest/developerguide/codedeploy-deployment-group-auto-rollback-enabled.html
 - https://docs.aws.amazon.com/codepipeline/latest/userguide/approvals.html
-- https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-change-calendar.html
-- https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html
+- https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/drift-aware-change-sets.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 automates deployments for EC2, Lambda, and ECS and supports deployment types such as rolling and blue/green traffic shifting depending on compute platform.
+- AWS Config has a managed rule checking whether CodeDeploy deployment groups have auto rollback enabled.
 
-## Source-grounding rule
+Sampled live evidence:
+- Read-only regional availability sampling reported AWS CodeDeploy and AWS CloudFormation as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Sampled APIs `CodeDeploy+GetDeployment`, `CodePipeline+GetPipelineState`, and `CloudFormation+CreateChangeSet` were reported `isAvailableIn` in those regions.
 
-Use official AWS documentation as the source of truth for service behavior. Use Context7 only as a supplementary guideline for agent-guardrail design when it helps clarify stricter instruction patterns; do not let secondary examples override AWS service docs.
+Review implications:
+- Live deployment operation must be approval-gated and evidence-driven: current deployment state, rollback trigger, health alarms, blast radius, change set/diff, and stop/rollback command path.
+- Do not perform or recommend live mutation from stale docs or repo-only evidence.

package/skills/aws/aws-live-ecs-rollout-guard/SKILL.md

@@ -4,8 +4,8 @@ description: Guard live Amazon ECS and Fargate rollout actions with ecs service,
 allowed-tools: Read Grep Glob WebFetch
 metadata:
   author: "github: Raishin"
-  version: "0.1.0"
-  updated: "2026-05-05"
+  version: "0.1.3"
+  updated: "2026-06-02"
   category: delivery
 ---
 

package/skills/aws/aws-live-ecs-rollout-guard/metadata.json

@@ -14,14 +14,14 @@
   "summary": "Guard live Amazon ECS and Fargate rollout actions with service targeting, deployment circuit breaker or alarm checks, rollback posture, and explicit approval before mutation.",
   "source_type": "original",
   "official_docs": [
-    "https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-circuit-breaker.html",
-    "https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-alarm-failure.html",
-    "https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-failure-detection.html",
-    "https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_service_deployment_events.html"
+    "https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-deployment.html",
+    "https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-steps-ecs.html",
+    "https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/bluegreen-deployments.html",
+    "https://docs.aws.amazon.com/AmazonECS/latest/developerguide/troubleshooting.html"
   ],
   "security_notes": "Live ECS rollout actions require exact service targeting, health evidence, rollback posture, and explicit approval. Never treat force-new-deployment as a harmless default.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-live-ecs-rollout-guard",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.3"
 }

package/skills/aws/aws-live-ecs-rollout-guard/references/official-sources.md

@@ -1,12 +1,29 @@
 # Official sources
 
-Primary AWS documentation used to shape this guarded live-AWS role:
+Use this reference only when you need source grounding for AWS service behavior or the detailed source list.
 
-- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-circuit-breaker.html
-- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-alarm-failure.html
-- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-failure-detection.html
-- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_service_deployment_events.html
+## AWS documentation
 
-## Source-grounding rule
+Use these as starting points, not as proof of the user's live AWS state:
+- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-deployment.html
+- https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-steps-ecs.html
+- https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/bluegreen-deployments.html
+- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/troubleshooting.html
 
-Use official AWS documentation as the source of truth for service behavior. Use Context7 only as a supplementary guideline for agent-guardrail design when it helps clarify stricter instruction patterns; do not let secondary examples override AWS service docs.
+## 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:
+- ECS service deployment history tracks lifecycle states, circuit breaker failures, CloudWatch alarms, rollbacks, and recent deployment history.
+- ECS blue/green deployments with CodeDeploy shift traffic between replacement task sets and can use lifecycle hooks; rollback depends on deployment configuration and health signals.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported Amazon ECS, AWS Fargate, and AWS CodeDeploy as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Sampled APIs `ECS+DescribeServices`, `ECS+DescribeTasks`, `CloudWatch+DescribeAlarms`, and `CodeDeploy+GetDeployment` were reported `isAvailableIn` in those regions.
+
+Review implications:
+- Guard live ECS rollout with current service/deployment state, stopped-task reasons, target health, alarms, deployment controller, desired/running counts, and rollback/stop path.
+- Regional/API availability does not prove a service is safe to roll forward.

package/skills/aws/aws-live-iac-change-guard/SKILL.md

@@ -4,8 +4,8 @@ description: Guard live CloudFormation, SAM, CDK, and Terraform-backed AWS infra
 allowed-tools: Read Grep Glob WebFetch
 metadata:
   author: "github: Raishin"
-  version: "0.1.0"
-  updated: "2026-05-05"
+  version: "0.1.3"
+  updated: "2026-06-02"
   category: delivery
 ---