vybekiit 0.4.0 → 0.6.0

package/dist/global-skills/aws-cloudformation/references/check-cloudformation-template-compliance.script.md

@@ -0,0 +1,159 @@
+# Check CloudFormation Template Compliance
+
+## Overview
+
+Deterministic procedure for validating a CloudFormation template against security and compliance rules using cfn-guard. Works via the `cfn-guard` CLI or the Python `guardpycfn` binding.
+
+## Parameters
+
+- **template_content** (required): The CloudFormation template as a YAML or JSON string, a file path, or a URL to the template.
+- **rules_file_path** (optional): Path to a custom cfn-guard rules file. If omitted, you MUST obtain rules separately because cfn-guard has no built-in rule set. Recommended source: https://github.com/aws-cloudformation/aws-guard-rules-registry
+
+**Constraints for parameter acquisition:**
+
+- You MUST ask for all required parameters upfront in a single prompt rather than one at a time
+- You MUST support multiple input methods for the template:
+  - Direct input: Template content pasted directly
+  - File path: Path to a local template file
+  - URL: Link to a template in a repository or S3
+- You MUST confirm successful acquisition of the template content before proceeding
+
+## Steps
+
+### 1. Verify Dependencies
+
+Check which compliance mechanism is available.
+
+**Constraints:**
+
+- You MUST check in this order of preference:
+  1. `cfn-guard` CLI available on the user's system (verify with `which cfn-guard` or `cfn-guard --version`)
+  2. Python `guardpycfn` library (verify by attempting `import guardpycfn` in a throwaway Python command)
+- If cfn-guard is not installed, You MUST ask the user: "I can install `cfn-guard` (see https://docs.aws.amazon.com/cfn-guard/latest/ug/setting-up.html for install options). Do you want me to install it, or would you prefer to install it manually?"
+- You MUST NOT execute compliance checks or run any install command without the user's explicit approval because this changes the user's environment
+- If no mechanism is available and the user declines installation, You MUST ask whether to abort or proceed anyway (knowing the SOP cannot complete)
+- You MUST respect the user's decision to proceed, install, or abort
+
+### 2. Acquire Template Content
+
+Obtain the CloudFormation template from the user.
+
+**Constraints:**
+
+- You MUST ask the user which template(s) to check even if templates are discoverable in the working directory, because the user may only want a subset checked
+- You MUST read the template content from the provided source (file path, direct input, or URL)
+- You MUST confirm the template is non-empty and parseable as YAML or JSON before proceeding
+- If the template cannot be read or parsed, You MUST inform the user with the specific error and stop
+- You SHOULD recommend running the `validate-cloudformation-template` SOP first if the user has not already done so, because compliance checks assume a syntactically valid template
+
+### 3. Acquire Rules File (if needed)
+
+Determine which rules to apply.
+
+**Constraints:**
+
+- If the CLI or `guardpycfn` library is used, You MUST obtain a rules file because cfn-guard requires explicit rules:
+  - If the user provided `rules_file_path`, You MUST use it
+  - Otherwise, You MUST recommend the user download the AWS managed rules from https://github.com/aws-cloudformation/aws-guard-rules-registry
+- You MUST confirm the rules file is readable before proceeding
+
+### 4. Run Compliance Check
+
+Execute cfn-guard against the template using the best available mechanism.
+
+**Constraints:**
+
+- If `cfn-guard` CLI is available, You MUST invoke it with the template and rules file:
+  - Example: `cfn-guard validate --rules rules.guard --data template.yaml --output-format json`
+  - You MUST use `--output-format json` for structured output
+- Otherwise, if the Python `guardpycfn` library is available, You MUST invoke `guardpycfn.validate_with_guard(template_content, rules_content, verbose=True)`
+- You MUST NOT modify the template content before checking because the user needs to see violations against their actual template
+- You MUST capture the full output including rule IDs, resource names, resource types, and remediation messages
+
+### 5. Present Results
+
+Report compliance findings to the user.
+
+**Constraints:**
+
+- You MUST start the summary with: "Your template has X violations"
+- You MUST group related violations together (e.g., all PublicAccessBlock settings for an S3 bucket)
+- You MUST prioritize by severity: critical security issues first (encryption, public access), then best-practice recommendations (versioning, logging, replication)
+- For repeated sub-property violations on the same resource, You MUST show them once: "Settings (A, B, C, D) must all be true"
+- You MUST add context for optional features (e.g., ObjectLock and Replication may not be needed for all use cases)
+- For each violation, You MUST provide the specific CloudFormation properties to add or change
+- You MUST use inline YAML comments to explain why each property is needed
+- You MUST NOT show entire resource definitions when only specific properties need to change
+- If the template is fully compliant, You MUST confirm this clearly
+
+### 6. Recommend Next Steps
+
+Guide the user after compliance results.
+
+**Constraints:**
+
+- If critical security violations were found, You MUST recommend fixing them before deployment
+- You SHOULD help the user understand which violations are mandatory fixes versus optional improvements based on their use case
+- After fixes are applied, You SHOULD recommend re-running this SOP to confirm all violations are resolved
+- Once compliance passes, You SHOULD recommend the `cloudformation-pre-deploy-validation` SOP for final pre-deployment readiness
+
+## Examples
+
+### Example Input
+
+```yaml
+AWSTemplateFormatVersion: '2010-09-09'
+Resources:
+  MyBucket:
+    Type: AWS::S3::Bucket
+    Properties:
+      BucketName: my-app-data
+```
+
+### Example Output
+
+```
+Your template has 4 violations.
+
+**MyBucket (AWS::S3::Bucket) — Critical Security:**
+
+1. Public access not blocked. Add:
+   PublicAccessBlockConfiguration:
+     BlockPublicAcls: true        # Prevents public ACLs
+     BlockPublicPolicy: true      # Prevents public bucket policies
+     IgnorePublicAcls: true       # Ignores existing public ACLs
+     RestrictPublicBuckets: true  # Restricts public bucket access
+
+2. Server-side encryption not configured. Add:
+   BucketEncryption:
+     ServerSideEncryptionConfiguration:
+       - ServerSideEncryptionByDefault:
+           SSEAlgorithm: aws:kms  # KMS encryption at rest
+
+**MyBucket (AWS::S3::Bucket) — Best Practice:**
+
+3. Versioning not enabled. Add:
+   VersioningConfiguration:
+     Status: Enabled              # Protects against accidental deletes
+
+4. Access logging not configured. Add:
+   LoggingConfiguration:
+     DestinationBucketName: !Ref LogBucket
+
+**Advisory — Optional Enhancements:**
+ObjectLock and Replication rules also flagged. Evaluate based on your use case before adding.
+```
+
+## Troubleshooting
+
+### High violation count on simple templates
+Some rules check multiple sub-properties independently. A single missing `PublicAccessBlockConfiguration` block can produce 4 separate violations (one per sub-property). Group them mentally and fix the parent property.
+
+### False positives for optional features
+Rules like `S3_BUCKET_REPLICATION_ENABLED` and `S3_BUCKET_DEFAULT_LOCK_ENABLED` enforce best practices that may not apply to every bucket. Evaluate whether the feature is needed for your use case before adding it.
+
+### Custom rules not found
+If using a custom `rules_file_path`, ensure the file exists and follows cfn-guard rule syntax. Standalone CLI and `guardpycfn` usage both require obtaining rules separately (e.g., from the aws-guard-rules-registry).
+
+### cfn-guard not installed
+Install from https://docs.aws.amazon.com/cfn-guard/latest/ug/setting-up.html.

package/dist/global-skills/aws-cloudformation/references/cloudformation-pre-deploy-validation.script.md

@@ -0,0 +1,217 @@
+# CloudFormation Pre-Deploy Validation
+
+## Overview
+
+Deterministic procedure for running CloudFormation's pre-deployment validation feature. When a change set is created, CloudFormation automatically validates the template against three common failure causes before any resources are provisioned:
+
+1. **Property syntax validation** (FAIL) — Validates resource properties against AWS resource schemas (required properties, valid values, deprecated properties).
+2. **Resource name conflict validation** (FAIL) — Detects naming conflicts with existing resources in the account.
+3. **S3 bucket emptiness validation** (WARN) — Warns when deleting S3 buckets that contain objects.
+
+Validation errors are exposed through the `describe-events` API scoped to the change set. This procedure uses `call_aws` (preferred) or the AWS CLI to invoke these APIs directly. Note: The AWS MCP server is recommended for streamlined API invocation, but all steps can be performed using the AWS CLI alone.
+
+**Important:** The legacy `describe-stack-events` API does NOT return validation errors. You MUST use `describe-events --change-set-name <arn>` to retrieve validation results.
+
+## Parameters
+
+- **stack_name** (required): The CloudFormation stack name to create or update.
+- **template_source** (required): The template to deploy. One of:
+  - File path to a local template
+  - S3 URL of an uploaded template
+  - Template content provided directly
+- **change_set_type** (required): Either `CREATE` (new stack) or `UPDATE` (existing stack).
+- **region** (required): AWS region for deployment.
+- **parameters** (optional): Stack parameters as key-value pairs.
+- **capabilities** (optional): CloudFormation capabilities (e.g., `CAPABILITY_IAM`, `CAPABILITY_NAMED_IAM`) if the template creates IAM resources.
+
+**Constraints for parameter acquisition:**
+
+- You MUST ask for all required parameters upfront in a single prompt
+- You MUST support multiple input methods for the template (direct input, file path, S3 URL)
+- You MUST confirm successful acquisition of all parameters before proceeding
+
+## Steps
+
+### 1. Verify Dependencies
+
+Check which mechanism is available to invoke AWS APIs.
+
+**Constraints:**
+
+- You MUST check in this order of preference:
+  1. `call_aws` tool from the AWS MCP Server (preferred for sandboxed execution, audit logging, and observability)
+  2. AWS CLI (`aws`) available on the user's system (verify with `which aws` or `aws --version`)
+- You MUST verify the user has valid AWS credentials configured for the target account/region (e.g., `aws sts get-caller-identity --region <region>`). This read-only call is acceptable during verification because it does not modify any resources
+- You MUST ONLY check for availability and credential validity. You MUST NOT create change sets, execute change sets, or install missing dependencies during this step because creating a change set triggers actual CloudFormation operations and installation modifies the user's environment
+- If the AWS CLI is missing, You MUST ask the user explicitly before running any install command, using a prompt like: "I can install the AWS CLI via `<platform-specific command>`. Do you want me to install it, or would you prefer to install it manually?"
+- You MUST NOT run install commands without the user's explicit approval because this changes the user's environment
+- If credentials are missing or invalid, You MUST ask the user to configure credentials (e.g., via `aws configure`, environment variables, or their preferred credential provider) and MUST NOT proceed until credentials are confirmed
+- You MUST respect the user's decision to proceed, install, or abort
+
+### 2. Recommend Template-Level Pre-Validation
+
+Catch issues locally before consuming CloudFormation API quota.
+
+**Constraints:**
+
+- You SHOULD recommend running the `validate-cloudformation-template` SOP first to catch cfn-lint syntax and schema errors locally
+- You SHOULD recommend running the `check-cloudformation-template-compliance` SOP to catch security violations locally
+- If the user has already run these checks or explicitly skips them, You MUST proceed to the next step
+
+### 3. Upload Template (if needed)
+
+Prepare the template for the change set.
+
+**Constraints:**
+
+- If the template is small (≤ 51,200 bytes) and provided as content or a local file, You MAY pass it inline via `--template-body`
+- If the template exceeds 51,200 bytes, You MUST upload it to S3 and use `--template-url` because `--template-body` has a size limit
+- If the template is already at an S3 URL, You MUST use `--template-url` directly
+
+### 4. Create Change Set
+
+Create the change set to trigger pre-deployment validation. Validation runs automatically during change set creation — no opt-in is required.
+
+**Constraints:**
+
+- You MUST use a unique, descriptive change set name (e.g., `pre-deploy-validation-<timestamp>`)
+- You MUST use the appropriate `--change-set-type` (`CREATE` for new stacks, `UPDATE` for existing)
+- You MUST include `--capabilities` if the template creates IAM resources (e.g., `CAPABILITY_IAM`, `CAPABILITY_NAMED_IAM`)
+- You MUST invoke via `call_aws` (preferred) or the AWS CLI. Example CLI form:
+
+  ```
+  aws cloudformation create-change-set \
+    --stack-name <stack_name> \
+    --template-body file://<path> \
+    --change-set-name pre-deploy-validation-$(date +%s) \
+    --change-set-type CREATE \
+    --region <region> \
+    --capabilities CAPABILITY_IAM
+  ```
+
+  > **Notes:** Use `--template-url s3://...` instead of `--template-body` for templates exceeding 51,200 bytes. Include `--capabilities` only if the template creates IAM resources.
+- You MUST capture the returned change set ARN (Id) for the next step
+- You MUST explain to the user that creating a change set does NOT modify any resources because it only plans the changes and runs validation
+- You MUST wait for change set creation to reach a terminal status (`CREATE_COMPLETE`, `FAILED`) before checking validation results. Use `describe-change-set` to poll status.
+
+### 5. Retrieve Validation Results via describe-events
+
+Fetch validation results from the `describe-events` API.
+
+**Constraints:**
+
+- You MUST use `aws cloudformation describe-events --change-set-name <arn> --region <region>` (via `call_aws` or CLI)
+- You MUST NOT use `describe-stack-events` because the legacy stack events API does NOT return validation errors — it only surfaces resource provisioning events after execution
+- You MUST filter events where `EventType` equals `VALIDATION_ERROR` because these are the validation findings
+- For each validation event, You MUST extract:
+  - `ValidationName` — one of `PROPERTY_VALIDATION`, `RESOURCE_NAME_CONFLICT`, `S3_BUCKET_EMPTINESS`
+  - `ValidationStatus` — `FAILED` or `PASSED`
+  - `ValidationStatusReason` — detailed error message
+  - `ValidationPath` — property path in the template where the error occurred
+  - `ValidationFailureMode` — `FAIL` (blocks execution) or `WARN` (allows execution)
+- If no `VALIDATION_ERROR` events are returned, You MUST treat the change set as having passed all validations
+
+### 6. Present Results and Guide Remediation
+
+Report validation findings grouped by type and help the user fix issues.
+
+**Constraints:**
+
+- You MUST present results grouped by `ValidationName`:
+  - **Property syntax validation** — invalid property values or formats
+  - **Resource name conflict validation** — resources that conflict with existing resources
+  - **S3 emptiness validation** — S3 buckets that must be empty before deletion
+- For each failure, You MUST include the `ValidationPath` so the user can pinpoint the exact location in their template
+- For each failure, You MUST provide the specific template fix showing the corrected property or resource
+- You MUST clearly distinguish `FAIL` (execution blocked) from `WARN` (execution allowed) so the user knows what MUST be fixed versus what SHOULD be considered
+- If any `FAIL`-mode failures exist, You MUST recommend fixing the template and creating a new change set
+- You MUST NOT recommend executing a change set that has `FAIL`-mode validation failures because CloudFormation will block execution and the change set cannot succeed
+- If only `WARN`-mode issues exist, You SHOULD explain the warning and let the user decide
+
+### 7. Execute or Clean Up
+
+Guide the user on next steps after validation.
+
+**Constraints:**
+
+- If all validations passed (or only `WARN`-mode issues that the user accepts), You MUST ask the user for explicit approval before executing the change set
+- You MUST NOT execute the change set without explicit user approval because this will modify live infrastructure
+- You MUST NOT delete a stack without explicit user approval. Before deleting, You MUST verify the stack status is `REVIEW_IN_PROGRESS` by calling `describe-stacks`
+- To execute: `aws cloudformation execute-change-set --change-set-name <arn> --region <region>`
+- If the user does not want to execute:
+  - For `UPDATE`-type change sets: recommend deleting the change set to keep the stack clean: `aws cloudformation delete-change-set --change-set-name <arn> --region <region>`
+  - For `CREATE`-type change sets: You MUST recommend also deleting the stack (after user approval), because it remains in `REVIEW_IN_PROGRESS` state and will block future creates: `aws cloudformation delete-change-set --change-set-name <arn> --region <region>` followed by `aws cloudformation delete-stack --stack-name <stack_name> --region <region>`
+- If validation failed, You MUST recommend fixing the template and re-running from Step 4, since validation results are tied to a specific change set and modifying the template requires creating a new one
+- If the original change set used `--change-set-type CREATE`, You MUST warn the user that the stack now exists in `REVIEW_IN_PROGRESS` state. Before retrying with `--change-set-type CREATE`, the user MUST first delete the stack (with user approval). Alternatively, the user can delete only the failed change set and create a new `CREATE` change set against the same stack.
+
+## Examples
+
+### Example: Successful Validation
+
+```
+Change set "pre-deploy-validation-1713580000" created for stack "my-app-stack".
+
+Retrieved via: aws cloudformation describe-events --change-set-name arn:aws:cloudformation:...
+
+Validation results:
+  ✓ PROPERTY_VALIDATION: PASSED
+  ✓ RESOURCE_NAME_CONFLICT: PASSED
+  ✓ S3_BUCKET_EMPTINESS: PASSED
+
+The change set is ready to execute. Would you like to execute it now?
+```
+
+### Example: Failed Validation
+
+```
+Change set "pre-deploy-validation-1713580000" created for stack "my-app-stack".
+
+Retrieved via: aws cloudformation describe-events --change-set-name arn:aws:cloudformation:...
+
+✗ PROPERTY_VALIDATION (FAIL):
+  ValidationPath: /Resources/MyBucket/Properties/NotificationConfiguration/QueueConfigurations/0
+  ValidationStatusReason: required key [Event] not found
+
+  Fix (Resources/MyBucket/Properties/NotificationConfiguration/QueueConfigurations):
+    QueueConfigurations:
+      - Queue: !GetAtt MyQueue.Arn
+        Event: s3:ObjectCreated:*   # Required property was missing
+
+✗ RESOURCE_NAME_CONFLICT (FAIL):
+  ValidationPath: /Resources/MyDynamoDBTable/Properties/TableName
+  ValidationStatusReason: A table named "users-table" already exists in this account/region.
+
+  Fix: Make the name unique per stack:
+    TableName: !Sub "${AWS::StackName}-users-table"
+
+⚠ S3_BUCKET_EMPTINESS (WARN):
+  ValidationPath: /Resources/DataBucket
+  ValidationStatusReason: Bucket is not empty. Delete may fail.
+
+  Options:
+    - Empty the bucket before stack deletion
+    - Or set DeletionPolicy: Retain on the bucket resource
+
+2 FAIL-mode issues must be fixed before execution.
+Fix the template and create a new change set.
+```
+
+## Troubleshooting
+
+### describe-events returns empty or unknown command
+The `describe-events` API (scoped to change sets) requires AWS CLI support for the command. If it is not recognized, update the AWS CLI: `pip install --upgrade awscli` or `brew upgrade awscli`. If the command still returns nothing, confirm the change set ARN is correct and the change set has finished creating.
+
+### User calls describe-stack-events instead
+`describe-stack-events` returns events after the stack begins provisioning. It does NOT include pre-deployment validation errors. You MUST redirect the user to `describe-events --change-set-name <arn>`.
+
+### Change set stuck in CREATE_IN_PROGRESS
+Use `aws cloudformation describe-change-set --change-set-name <arn>` to check the status. Wait until it reaches `CREATE_COMPLETE` or `FAILED` before calling `describe-events`.
+
+### Change set status FAILED but no validation events
+If `describe-change-set` shows `Status: FAILED` with a `StatusReason` unrelated to validation (e.g., "No updates are to be performed"), the failure is not a pre-deployment validation issue. Investigate the `StatusReason` directly.
+
+### Missing s3:ListBucket permission
+S3 bucket emptiness validation requires `s3:ListBucket` permission on the buckets being deleted. If this validation is skipped or errors, verify the deploying role has this permission.
+
+### Validation passed but deployment still fails
+Pre-deployment validation catches three common classes of issues but cannot detect all runtime failures (resource limits, service constraints, IAM permissions, invalid AMI IDs). If deployment fails after validation passes, use the `troubleshoot-cloudformation-deployment` tool or SOP to diagnose the runtime failure.

package/dist/global-skills/aws-cloudformation/references/deploy-with-express-mode.script.md

@@ -0,0 +1,271 @@
+# Deploy with Express Mode
+
+## Overview
+
+Deterministic procedure for deploying CloudFormation stacks using **Express mode** — a deployment mode that completes stack operations as soon as resource configuration is applied, giving immediate confirmation to proceed to the next iteration. Resources continue becoming ready to serve traffic in the background.
+
+Express mode works with all existing CloudFormation templates and requires no template changes. It is recommended for development workflows where you iterate frequently and need fast deployment confirmation.
+
+**When to use Express mode:**
+
+- Iterating on infrastructure configurations during development
+- Deploying individual components of your application
+- Deploying dependent stacks that only need resource outputs (VPC IDs, endpoints, ARNs) to proceed
+- Building with AI agents that need fast feedback loops to validate and refine infrastructure
+- Prototyping and experimenting with new architectures
+
+**When NOT to use Express mode:**
+
+- Production workflows that require resources to serve traffic immediately after stack completion
+- Deployments where downstream consumers immediately hit endpoints (load balancers, CloudFront distributions, ECS services) after the operation completes
+
+**What Express mode skips:**
+
+1. Traffic readiness (e.g., EC2 instance reaching `running` state)
+2. Region propagation (e.g., CloudFront propagating to all edge locations, 5-10 minutes)
+3. Cleanup (e.g., network interface removal before Lambda function deletion)
+
+**What does NOT change:**
+
+- CloudFormation still processes all resources in dependency order
+- CloudFormation still retries dependent resources that encounter transient failures
+- CloudFormation still handles dependent resource failures
+
+## Parameters
+
+- **stack_name** (required): The CloudFormation stack name.
+- **template_source** (required): The template to deploy. One of:
+  - File path to a local template
+  - S3 URL of an uploaded template
+  - Template content provided directly
+- **operation** (required): One of `CREATE`, `UPDATE`, or `DELETE`.
+- **region** (required): AWS region for deployment.
+- **enable_rollback** (optional): Whether to enable rollback. Express mode disables rollback by default for fastest iteration. Set to `true` if the user wants rollback on failure.
+- **parameters** (optional): Stack parameters as key-value pairs.
+- **capabilities** (optional): CloudFormation capabilities (e.g., `CAPABILITY_IAM`, `CAPABILITY_NAMED_IAM`) if the template creates IAM resources.
+
+**Constraints for parameter acquisition:**
+
+- You MUST ask for all required parameters upfront in a single prompt
+- You MUST support multiple input methods for the template (direct input, file path, S3 URL)
+- You MUST confirm successful acquisition of all parameters before proceeding
+
+## Steps
+
+### 1. Verify Dependencies
+
+Check which mechanism is available to invoke AWS APIs.
+
+**Constraints:**
+
+- You MUST check in this order of preference:
+  1. `call_aws` tool from the AWS MCP Server (preferred for sandboxed execution, audit logging, and observability)
+  2. AWS CLI (`aws`) available on the user's system (verify with `which aws` or `aws --version`)
+- You MUST verify the user has valid AWS credentials configured for the target account/region (e.g., `aws sts get-caller-identity --region <region>`). This read-only call is acceptable during verification because it does not modify any resources
+- You MUST ONLY check for availability and credential validity. You MUST NOT create or modify stacks or install missing dependencies during this step
+- If the AWS CLI is missing, You MUST ask the user explicitly before running any install command
+- You MUST NOT run install commands without the user's explicit approval
+- If credentials are missing or invalid, You MUST ask the user to configure credentials and MUST NOT proceed until credentials are confirmed
+
+### 2. Confirm Express Mode is Appropriate
+
+Verify with the user that Express mode is the right choice for their use case.
+
+**Constraints:**
+
+- You MUST inform the user that Express mode completes when resource configuration is applied, and resources continue stabilizing in the background
+- You MUST ask whether the user's workflow requires resources to serve traffic immediately after the stack operation completes
+- If the user's workflow DOES require immediate traffic readiness (production serving, endpoint availability), You MUST recommend using the default deployment behavior instead
+- If the user is in a development/iteration workflow, You SHOULD proceed with Express mode
+- You MUST inform the user that rollback is disabled by default with Express mode. If the user wants rollback protection, You MUST include `"disableRollback": false` in the deployment configuration
+
+### 3. Upload Template (if needed)
+
+Prepare the template for the operation.
+
+**Constraints:**
+
+- If the template is small (≤ 51,200 bytes) and provided as content or a local file, You MAY pass it inline via `--template-body`
+- If the template exceeds 51,200 bytes, You MUST upload it to S3 and use `--template-url` because `--template-body` has a size limit
+- If the template is already at an S3 URL, You MUST use `--template-url` directly
+- This step does not apply to `DELETE` operations
+
+### 4. Execute Stack Operation with Express Mode
+
+Run the stack operation with the `--deployment-config` parameter set to Express mode.
+
+**Constraints:**
+
+- You MUST obtain explicit user approval before executing the operation because it creates, modifies, or deletes live infrastructure
+- You MUST use `--deployment-config '{"mode": "EXPRESS"}'` on the stack operation
+- If the user requested rollback, You MUST use `--deployment-config '{"mode": "EXPRESS", "disableRollback": false}'`
+- You MUST include `--capabilities` if the template creates IAM resources
+- You MUST NOT use `aws cloudformation deploy` because it does not support `--deployment-config`. Use `create-stack`, `update-stack`, or `delete-stack` instead.
+
+> **Note:** When using `call_aws`, pass the template content inline in the `TemplateBody` parameter — the `file://` syntax is AWS CLI-specific and does not work with `call_aws`.
+
+**Create a stack:**
+
+```
+aws cloudformation create-stack \
+  --stack-name <stack_name> \
+  --template-body file://<path> \
+  --region <region> \
+  --deployment-config '{"mode": "EXPRESS"}' \
+  --capabilities CAPABILITY_IAM
+```
+
+**Update a stack:**
+
+```
+aws cloudformation update-stack \
+  --stack-name <stack_name> \
+  --template-body file://<path> \
+  --region <region> \
+  --deployment-config '{"mode": "EXPRESS"}' \
+  --capabilities CAPABILITY_IAM
+```
+
+**Delete a stack:**
+
+```
+aws cloudformation delete-stack \
+  --stack-name <stack_name> \
+  --region <region> \
+  --deployment-config '{"mode": "EXPRESS"}'
+```
+
+**With rollback enabled:**
+
+```
+aws cloudformation create-stack \
+  --stack-name <stack_name> \
+  --template-body file://<path> \
+  --region <region> \
+  --deployment-config '{"mode": "EXPRESS", "disableRollback": false}' \
+  --capabilities CAPABILITY_IAM
+```
+
+### 5. Express Mode with Change Sets
+
+Express mode also works with change sets. The deployment configuration is stored with the change set and applied when executed.
+
+**Constraints:**
+
+- To use Express mode with a change set, supply `--deployment-config` at `create-change-set` time:
+
+  ```
+  aws cloudformation create-change-set \
+    --stack-name <stack_name> \
+    --template-body file://<path> \
+    --change-set-name <change_set_name> \
+    --deployment-config '{"mode": "EXPRESS"}' \
+    --region <region> \
+    --capabilities CAPABILITY_IAM
+  ```
+
+- You MUST NOT specify `--deployment-config` again at `execute-change-set` time because it is already stored with the change set
+- You SHOULD recommend the change set path when the user also wants pre-deployment validation before deploying with Express mode (change set creation runs all validation checks before execution)
+
+### 6. CDK Express Mode
+
+When the user is deploying with the AWS CDK, Express mode is activated with the `--express` flag.
+
+**Constraints:**
+
+- You MUST use `cdk deploy --express` to deploy with Express mode
+- To re-enable rollback: `cdk deploy --express --rollback`
+- Express mode applies to all CloudFormation deployments triggered by CDK, including multi-stack deployments
+- You MUST NOT recommend `cdk deploy --hotswap` as a substitute for Express mode — they are different capabilities:
+  - Express mode: full infrastructure changes through CloudFormation, no drift introduced
+  - CDK hotswap: code-only changes via direct service APIs, introduces drift (bypasses CloudFormation)
+
+### 7. Monitor Resource Readiness After Completion
+
+Guide the user on what to expect after Express mode completes.
+
+**Constraints:**
+
+- You MUST inform the user that resources continue stabilizing in the background after the operation reports complete
+- You SHOULD provide guidance on typical background stabilization timelines:
+  - CloudFront distribution: propagation to all edge locations (5-10 minutes)
+  - EC2 instance: health checks, reaching `running` state
+  - Lambda function delete: network interface cleanup
+  - ECS service: containers reaching desired capacity
+- You SHOULD recommend monitoring resource readiness through existing mechanisms: CloudWatch alarms, health checks, or service-specific dashboards
+- If a resource does not stabilize as expected, You SHOULD recommend redeploying the stack to retry the affected resources
+
+## Unsupported Features
+
+The following are NOT supported with Express mode. You MUST inform the user if their scenario involves any of these:
+
+- **Custom resources** (`AWS::CloudFormation::CustomResource` and `Custom::*`) — these follow default completion behavior even when Express mode is active
+- **StackSets** — Express mode is not supported for StackSet operations
+- **AWS SAM** — not supported
+- **`aws cloudformation deploy` CLI command** — does not support `--deployment-config`; use `create-stack` or `update-stack` instead
+- **Account-level default** — Express mode is activated per stack operation; there is no account-wide setting
+
+## Examples
+
+### Example: Create a stack with Express mode
+
+```
+$ aws cloudformation create-stack \
+    --stack-name my-dev-vpc \
+    --template-body file://vpc.yaml \
+    --region us-west-2 \
+    --deployment-config '{"mode": "EXPRESS"}'
+
+{
+  "StackId": "arn:aws:cloudformation:us-west-2:123456789012:stack/my-dev-vpc/abc123"
+}
+
+Stack "my-dev-vpc" creation completed (Express mode).
+Resources are configured. VPC ID, subnet IDs, and other outputs are available.
+Background stabilization (route propagation, NAT gateway activation) continues.
+```
+
+### Example: CDK deploy with Express mode
+
+```
+$ cdk deploy --express
+
+ ✅  MyDevStack
+
+Express mode: stack completed when resource configuration was applied.
+Outputs:
+  MyDevStack.VpcId = vpc-0abc123def456
+  MyDevStack.ApiEndpoint = https://abc123.execute-api.us-west-2.amazonaws.com
+
+Resources continue stabilizing in the background.
+```
+
+### Example: Express mode with rollback enabled
+
+```
+$ aws cloudformation update-stack \
+    --stack-name my-dev-vpc \
+    --template-body file://vpc-v2.yaml \
+    --region us-west-2 \
+    --deployment-config '{"mode": "EXPRESS", "disableRollback": false}'
+```
+
+## Troubleshooting
+
+### Resources not ready to serve traffic after stack completes
+This is expected behavior with Express mode. Resources receive their configuration immediately but may still be starting up, propagating, or cleaning up. Monitor resource-specific readiness through CloudWatch, health checks, or service dashboards. If a resource does not stabilize, redeploy the stack to retry.
+
+### `--deployment-config` not recognized
+The `--deployment-config` parameter requires a CLI version that supports Express mode. Update the AWS CLI to the latest version. If using CDK, use `--express` instead.
+
+### `deploy` command does not accept `--deployment-config`
+The `aws cloudformation deploy` command does not support `--deployment-config`. Use `create-stack` or `update-stack` directly. In CDK, use `cdk deploy --express`.
+
+### Custom resources do not complete faster
+Custom resources always follow default completion behavior regardless of Express mode. This is by design — custom resources define their own completion logic.
+
+### StackSets error with Express mode
+Express mode is not supported for StackSet operations. Remove `--deployment-config` when working with StackSets.
+
+### Rollback not happening on failure
+Express mode disables rollback by default. To re-enable, add `"disableRollback": false` to the deployment configuration JSON, or use `cdk deploy --express --rollback` in CDK.