alibabacloud-executing-plans

Alibaba Cloud Executing Plans

AUTHORITATIVE GUIDANCE — MANDATORY COMPLIANCE

This skill executes validated Terraform code via Alibaba Cloud IaC Service (remote execution). It creates real cloud resources that cost money. Safety gates are non-negotiable.

ALL CLI operations MUST use MCP tool AlibabaCloud___CallCLI — never use Bash to run aliyun commands directly.

---

PREREQUISITE CHECK — MANDATORY

Before proceeding, verify BOTH prerequisites:

1. Validation passed — check tasks/status.json has status: "validated" (internal check, don't expose to user)
2. User explicitly confirmed they want to execute

If EITHER is missing, STOP IMMEDIATELY:

• Not validated? → Invoke alibabacloud:validate first
• No user confirmation? → Ask user before proceeding

---

Triggers

Activate when:

• User explicitly asks to execute/apply the Terraform plan
• User confirms they want to proceed after validation passes

NEVER activate automatically. This skill requires explicit user intent.

Rules

1. Single deploy approval, granted upstream — The user authorizes deployment ONCE in alibabacloud-validate's gate. Inside this skill the entire plan → apply chain runs automatically. Never add a second confirmation between plan and apply.
2. Plan before apply, results always shown — Always run terraform plan first AND surface its output to the user before apply. The user can interrupt mid-stream if the plan reveals something unexpected, but the default flow does not stop to ask.
3. MCP only — ALL aliyun CLI commands MUST go through AlibabaCloud___CallCLI, never through Bash
4. Inline content — Read .tf files locally, then pass content as string to --code (MCP cannot access local files)
5. Record everything — All outputs recorded to tasks/
6. Support rollback — Provide destroy option if apply fails
7. Poll for completion — IaC Service is async; use sequential MCP calls to poll
8. ⚠️ Destructive operations (destroy) require double confirmation
9. Persist state_id — IaC Service keeps the Terraform state remotely keyed by state_id. This skill MUST write it back to tasks/status.json (under state.state_id) on every Plan / Apply / Destroy and MUST pass the saved value on every subsequent Day-2 call. Losing the state_id orphans the remote state and forces a fresh deploy (potential duplicate resources).
10. Source-of-truth integrity — Some failures are only discoverable at apply time (SKU offline in target AZ, zone out-of-capacity, etc.). Any spec change forced by such a failure MUST be written back to BOTH designs/design.md (with a Decisions Log entry) AND designs/terraform/*.tf BEFORE re-running plan/apply. Never hot-patch the in-flight apply — Day-2 iterations re-read these files and will redeploy the broken spec if it isn't fixed at the source.