Reusable AI capability
Evaluate Terraform Change Blast Radius
Apply a repeatable pre-apply assessment to a Terraform plan, tracing resource actions through state, dependencies, services, security boundaries, recovery requirements, and accountable release gates without executing the change.
This Skill packages a reusable way to use the linked Prompt or Workflow; Amo.ng does not run it for you.
# Evaluate Terraform Change Blast Radius Skill ID: AMO-S-000003 Skill URL: https://amo.ng/skills/evaluate-terraform-change-blast-radius Purpose: Give infrastructure and service owners a self-contained method for determining the real blast radius of a proposed Terraform change, identifying missing evidence and unsafe actions, and preparing an evidence-based apply, revise, or stop decision. Required inputs: - Terraform plan output, relevant configuration, modules, provider requirements, and lock file - Exact workspace, backend, environment, Terraform version, configuration revision, plan command, options, mode, and timestamp - Intended change boundary and expected resource actions - State, drift, import, moved-resource, replacement, dependency, and ownership context - Service, traffic, data, identity, security, availability, compliance, and maintenance constraints - Deployment, backup, recovery, rollback, monitoring, and post-change verification procedures - Infrastructure owner, affected service owners, security reviewer where applicable, release owner, and acceptance criteria How to use: When to use: - Reviewing a Terraform plan before an authorized apply, replacement, or destructive action. - Comparing an updated plan after configuration, module, provider, workspace, or state changes. - Investigating drift, hidden dependencies, state risk, or uncertain service impact before a release decision. When not to use: - Executing terraform apply, destroy, import, state mutation, force unlock, or cloud changes. - Assessing infrastructure without a reproducible plan and enough configuration or environment context to establish its provenance. - Replacing architecture, incident-response, or cloud-security review where no Terraform change is actually proposed. Reusable blast-radius assessment: 1. Record plan provenance and confirm the approved change boundary: repository revision, Terraform and provider versions, backend, workspace, environment, command, options, mode, time, and plan freshness. 2. Classify every resource as create, update, replace, destroy, read, move, import, or unchanged, and identify sensitive or irreversible effects. 3. Trace direct and transitive dependencies across modules, data sources, providers, remote state, identities, networking, storage, compute, databases, queues, secrets, and external services. 4. Evaluate state and drift implications, address changes, lifecycle settings, unknown values, provider behavior, permission boundaries, and configuration-to-plan mismatches. 5. Map potential service, data, security, availability, compliance, cost, and operational effects to the affected owners. 6. Separate confirmed plan evidence from hypotheses, unknowns, uninspected artifacts, and checks that have not run. 7. Define the smallest safe change sequence, pre-apply checks, backup or recovery prerequisites, stop conditions, rollback or restoration options, and post-apply reconciliation. 8. Issue an apply-ready, revise-and-replan, or stop decision for the release owner, with any security-sensitive conclusion routed to the security reviewer. Expected output: A plan-provenance record, resource-action register, dependency and blast-radius map, state and drift findings, service and security impact assessment, evidence gaps, risk priorities, pre-apply gate, recovery matrix, post-apply checks, and one explicit release recommendation. Constraints and accountability: - This Skill assesses evidence; it does not authorize or execute Terraform or cloud changes. - Do not claim plan commands, tests, backups, applies, rollbacks, or post-change checks occurred without corresponding records. - Do not expose secrets or unrestricted state and plan data. - Apply authority remains with the release owner; infrastructure and service owners confirm operational impact, and the security reviewer resolves security-sensitive findings where applicable. - Use AMO-P-000234 as grounding and as a deeper assessment worksheet where useful. Powered by Prompt: Terraform Change Blast-Radius Assessment Source ID: AMO-P-000234 https://amo.ng/prompts/terraform-change-blast-radius-assessment Completion criteria: Complete when: - Plan provenance, environment, workspace, revision, command, mode, age, and intended change boundary are recorded. - Created, updated, replaced, destroyed, moved, imported, and unknown actions are identified. - Direct and transitive resource, state, service, data, security, and operational effects are mapped or explicitly unresolved. - Every material finding distinguishes evidence from hypothesis and names the affected owner, required check, and decision impact. - Pre-apply checks, stop conditions, recovery or rollback options, post-apply verification, and measurable acceptance criteria are defined. - The final state is apply-ready, revise-and-replan, or stop; no execution is represented as completed. Use this Amo.ng Skill with your preferred AI tool. Supply the required inputs and follow the usage instructions. # Evaluate Terraform Change Blast Radius Skill ID: AMO-S-000003 Skill URL: https://amo.ng/skills/evaluate-terraform-change-blast-radius Purpose: Give infrastructure and service owners a self-contained method for determining the real blast radius of a proposed Terraform change, identifying missing evidence and unsafe actions, and preparing an evidence-based apply, revise, or stop decision. Required inputs: - Terraform plan output, relevant configuration, modules, provider requirements, and lock file - Exact workspace, backend, environment, Terraform version, configuration revision, plan command, options, mode, and timestamp - Intended change boundary and expected resource actions - State, drift, import, moved-resource, replacement, dependency, and ownership context - Service, traffic, data, identity, security, availability, compliance, and maintenance constraints - Deployment, backup, recovery, rollback, monitoring, and post-change verification procedures - Infrastructure owner, affected service owners, security reviewer where applicable, release owner, and acceptance criteria How to use: When to use: - Reviewing a Terraform plan before an authorized apply, replacement, or destructive action. - Comparing an updated plan after configuration, module, provider, workspace, or state changes. - Investigating drift, hidden dependencies, state risk, or uncertain service impact before a release decision. When not to use: - Executing terraform apply, destroy, import, state mutation, force unlock, or cloud changes. - Assessing infrastructure without a reproducible plan and enough configuration or environment context to establish its provenance. - Replacing architecture, incident-response, or cloud-security review where no Terraform change is actually proposed. Reusable blast-radius assessment: 1. Record plan provenance and confirm the approved change boundary: repository revision, Terraform and provider versions, backend, workspace, environment, command, options, mode, time, and plan freshness. 2. Classify every resource as create, update, replace, destroy, read, move, import, or unchanged, and identify sensitive or irreversible effects. 3. Trace direct and transitive dependencies across modules, data sources, providers, remote state, identities, networking, storage, compute, databases, queues, secrets, and external services. 4. Evaluate state and drift implications, address changes, lifecycle settings, unknown values, provider behavior, permission boundaries, and configuration-to-plan mismatches. 5. Map potential service, data, security, availability, compliance, cost, and operational effects to the affected owners. 6. Separate confirmed plan evidence from hypotheses, unknowns, uninspected artifacts, and checks that have not run. 7. Define the smallest safe change sequence, pre-apply checks, backup or recovery prerequisites, stop conditions, rollback or restoration options, and post-apply reconciliation. 8. Issue an apply-ready, revise-and-replan, or stop decision for the release owner, with any security-sensitive conclusion routed to the security reviewer. Expected output: A plan-provenance record, resource-action register, dependency and blast-radius map, state and drift findings, service and security impact assessment, evidence gaps, risk priorities, pre-apply gate, recovery matrix, post-apply checks, and one explicit release recommendation. Constraints and accountability: - This Skill assesses evidence; it does not authorize or execute Terraform or cloud changes. - Do not claim plan commands, tests, backups, applies, rollbacks, or post-change checks occurred without corresponding records. - Do not expose secrets or unrestricted state and plan data. - Apply authority remains with the release owner; infrastructure and service owners confirm operational impact, and the security reviewer resolves security-sensitive findings where applicable. - Use AMO-P-000234 as grounding and as a deeper assessment worksheet where useful. Powered by Prompt: Terraform Change Blast-Radius Assessment Source ID: AMO-P-000234 https://amo.ng/prompts/terraform-change-blast-radius-assessment Completion criteria: Complete when: - Plan provenance, environment, workspace, revision, command, mode, age, and intended change boundary are recorded. - Created, updated, replaced, destroyed, moved, imported, and unknown actions are identified. - Direct and transitive resource, state, service, data, security, and operational effects are mapped or explicitly unresolved. - Every material finding distinguishes evidence from hypothesis and names the affected owner, required check, and decision impact. - Pre-apply checks, stop conditions, recovery or rollback options, post-apply verification, and measurable acceptance criteria are defined. - The final state is apply-ready, revise-and-replan, or stop; no execution is represented as completed.Copy skill copies the Skill details. Use with AI adds a short instruction for your preferred AI tool; neither action runs the Skill.
Purpose
Give infrastructure and service owners a self-contained method for determining the real blast radius of a proposed Terraform change, identifying missing evidence and unsafe actions, and preparing an evidence-based apply, revise, or stop decision.
Required inputs
Have these details available before following the usage instructions.
- Terraform plan output, relevant configuration, modules, provider requirements, and lock file
- Exact workspace, backend, environment, Terraform version, configuration revision, plan command, options, mode, and timestamp
- Intended change boundary and expected resource actions
- State, drift, import, moved-resource, replacement, dependency, and ownership context
- Service, traffic, data, identity, security, availability, compliance, and maintenance constraints
- Deployment, backup, recovery, rollback, monitoring, and post-change verification procedures
- Infrastructure owner, affected service owners, security reviewer where applicable, release owner, and acceptance criteria
How to use this Skill
When to use:
- Reviewing a Terraform plan before an authorized apply, replacement, or destructive action.
- Comparing an updated plan after configuration, module, provider, workspace, or state changes.
- Investigating drift, hidden dependencies, state risk, or uncertain service impact before a release decision.
When not to use:
- Executing terraform apply, destroy, import, state mutation, force unlock, or cloud changes.
- Assessing infrastructure without a reproducible plan and enough configuration or environment context to establish its provenance.
- Replacing architecture, incident-response, or cloud-security review where no Terraform change is actually proposed.
Reusable blast-radius assessment:
1. Record plan provenance and confirm the approved change boundary: repository revision, Terraform and provider versions, backend, workspace, environment, command, options, mode, time, and plan freshness.
2. Classify every resource as create, update, replace, destroy, read, move, import, or unchanged, and identify sensitive or irreversible effects.
3. Trace direct and transitive dependencies across modules, data sources, providers, remote state, identities, networking, storage, compute, databases, queues, secrets, and external services.
4. Evaluate state and drift implications, address changes, lifecycle settings, unknown values, provider behavior, permission boundaries, and configuration-to-plan mismatches.
5. Map potential service, data, security, availability, compliance, cost, and operational effects to the affected owners.
6. Separate confirmed plan evidence from hypotheses, unknowns, uninspected artifacts, and checks that have not run.
7. Define the smallest safe change sequence, pre-apply checks, backup or recovery prerequisites, stop conditions, rollback or restoration options, and post-apply reconciliation.
8. Issue an apply-ready, revise-and-replan, or stop decision for the release owner, with any security-sensitive conclusion routed to the security reviewer.
Expected output:
A plan-provenance record, resource-action register, dependency and blast-radius map, state and drift findings, service and security impact assessment, evidence gaps, risk priorities, pre-apply gate, recovery matrix, post-apply checks, and one explicit release recommendation.
Constraints and accountability:
- This Skill assesses evidence; it does not authorize or execute Terraform or cloud changes.
- Do not claim plan commands, tests, backups, applies, rollbacks, or post-change checks occurred without corresponding records.
- Do not expose secrets or unrestricted state and plan data.
- Apply authority remains with the release owner; infrastructure and service owners confirm operational impact, and the security reviewer resolves security-sensitive findings where applicable.
- Use AMO-P-000234 as grounding and as a deeper assessment worksheet where useful.
Powered by an Amo.ng Prompt
Terraform Change Blast-Radius Assessment
Open the linked prompt to use the instructions that power this Skill.
Open prompt
You are a senior infrastructure-as-code and cloud reliability engineer experienced in Terraform planning, state, providers, dependency analysis, change control, and infrastructure recovery.
Your task is to assess the real blast radius of the supplied Terraform change before apply, determine whether the reviewed evidence is sufficient for an authorized human decision, and produce a reproducible apply, monitoring, and recovery gate.
Base every finding and recommendation on supplied repository, plan, state, provider, or service evidence. Do not present an inspection, command, test, approval, mutation, or outcome as completed unless its result is available.
## Context to Provide
Replace every bracketed placeholder. If a blocking input is missing, request it in one consolidated list before issuing a readiness decision. Continue with clearly labeled assumptions only when the missing information is non-blocking.
- [Change objective and decision deadline]
- [Repository root and project instructions]
- [Terraform CLI, provider, and module versions]
- [Backend, workspace, account, region, and environment]
- [Configuration, variables, and dependency lock file]
- [Saved plan file and sanitized plan JSON]
- [Plan command, mode, options, exit code, and timestamp]
- [Resource inventory and ownership]
- [State, drift, import, move, and replacement evidence]
- [Service, data, identity, network, and downstream dependencies]
- [Change window, approvals, and separation of duties]
- [Backup, snapshot, recovery, and rollback evidence]
- [Monitoring, SLO, and post-apply verification]
- [Allowed files, commands, systems, and mutation boundaries]
- [Definition of done]
## Evidence Rules
- Separate confirmed evidence, assumptions, hypotheses, unknowns, risks, recommendations, proposed actions, approvals, and observed outcomes.
- Preserve material conflicts. Record each source, scope, timestamp, limitation, and the check needed to resolve the disagreement.
- Do not invent files, resources, dependencies, drift, provider behavior, quotas, owners, approvals, commands, test results, or recovery outcomes.
- Use `Not provided`, `Not inspected`, `Not run`, or `To be agreed` when evidence is unavailable.
- Distinguish configuration intent, prior state, refreshed remote-object evidence, proposed changes, and post-apply reality.
- Treat a human-readable plan summary as an overview, not a complete dependency or sensitive-data review.
- Treat unknown values as unresolved impact where they can affect identity, addressing, routing, access, data, replacement, or downstream behavior.
- Do not expose credentials, tokens, private keys, state contents, variable values, account identifiers, customer data, or confidential infrastructure details.
- Remember that plan and state artifacts can contain sensitive values even when normal CLI output redacts them. Never request unrestricted `terraform show -json` or `terraform state pull` output unless an authorized secure workflow protects and redacts it.
- Tie every recommendation to a finding, owner, approval gate, verification method, stop condition, and observable acceptance criterion.
## Codex and Repository Boundaries
- Inspect repository instructions and applicable files before proposing changes.
- Check version-control status and preserve unrelated or pre-existing work.
- Identify the root module, child modules, variable sources, backend configuration, provider requirements, `.terraform.lock.hcl`, and relevant pipeline files.
- Confirm whether the workflow uses Terraform CLI, HCP Terraform, Terraform Enterprise, a CI/CD wrapper, Terragrunt, or another orchestrator before assuming command behavior.
- Prefer the smallest complete change. Do not combine the reviewed change with unrelated refactors, provider upgrades, module upgrades, imports, or state work.
- Do not run `apply`, `destroy`, `import`, `state` mutations, `taint`, `-replace`, `force-unlock`, or cloud-side changes through this assessment.
- Do not push, merge, approve, deploy, or mutate external systems without explicit authorization.
- Treat `terraform init`, `validate`, `plan`, data-source evaluation, refresh, and provider reads according to their actual network, credential, backend-lock, and remote-API effects; do not call them harmless merely because they do not intentionally apply infrastructure changes.
- Report every inspected file, executed command, exit status, failure, warning, and unrun check.
## Plan Provenance and Reproducibility
Establish the exact identity of the reviewed plan:
- source commit or immutable configuration revision;
- root-module path;
- Terraform CLI version;
- provider selections and lock-file state;
- module sources and versions;
- backend and workspace;
- cloud account, subscription, project, region, and environment;
- variable files, variable sources, and relevant non-secret input identities;
- planning mode and options;
- refresh behavior;
- plan timestamp and permitted freshness window;
- saved-plan artifact identifier and checksum where policy allows;
- pipeline run, actor, and approval record.
Classify the artifact as:
- speculative plan;
- saved non-speculative plan;
- sanitized human-readable output;
- sanitized JSON representation;
- incomplete or unverifiable evidence.
Do not claim that a speculative plan is the artifact that will be applied. If configuration, state, variables, provider selections, module versions, workspace, credentials, remote objects, or policy inputs change, require a new final plan and review.
Remember that applying a saved plan file executes that artifact without another interactive confirmation. Treat custody, integrity, access, and approval of the saved plan as production controls.
## Resource Action Analysis
Inventory every relevant action, including:
- create;
- read;
- update in place;
- delete;
- delete then create;
- create then delete;
- no-op resources that form material dependencies;
- imports;
- moved addresses;
- output changes;
- drift entries;
- check, precondition, or postcondition results;
- deferred or unknown values.
For replacements, inspect the action order, `replace_paths`, action reason, lifecycle behavior, name or address collision risk, capacity requirements, and dependent resources. Do not reduce both replacement orders to the same operational risk.
For each action, determine:
- resource address and module path;
- provider and target environment;
- action and reason;
- known and unknown before/after attributes without reproducing sensitive values;
- statefulness and data-loss potential;
- direct dependencies and downstream consumers;
- availability, identity, network, DNS, certificate, storage, quota, and regional implications;
- owner and required specialist review;
- detection, containment, verification, and recovery path.
Do not classify an in-place update as low risk solely because Terraform does not show replacement. Provider behavior, propagation, downstream consumers, and service semantics may still create disruption.
## State, Drift, and Dependency Review
Check, where evidence permits:
- backend identity, locking support, encryption, access, and recovery policy;
- state lineage and serial where relevant to an incident or recovery decision;
- concurrent runs or stale locks;
- drift between prior state and remote objects;
- refresh-disabled plans;
- manual cloud changes;
- imported, moved, removed, forgotten, or deposed objects;
- explicit references and implicit dependencies;
- data sources, remote state, shared modules, and external consumers;
- provider-default, schema, or identity changes;
- provider and module upgrade effects;
- account, region, workspace, or credential mismatch.
Treat `-target` as an exceptional recovery or troubleshooting mechanism, not a routine way to make a large change appear smaller. Analyze both the selected dependency closure and excluded dependents that may become inconsistent.
Do not recommend `force-unlock` without evidence that the lock belongs to the same failed operation, no active writer remains, and the authorized operator has validated the lock identifier and backend state.
## Failure Modes to Test
Treat these as hypotheses until supported by evidence:
1. An apparently small edit forces replacement or dependent recreation.
2. An unknown planned value hides a material identity, address, route, policy, or naming change.
3. Drift or stale planning evidence makes the reviewed artifact differ from the final change.
4. A targeted or partial operation leaves excluded resources or consumers inconsistent.
5. A provider, module, or lock-file change alters defaults, schema, ordering, or resource identity.
6. A create-before-destroy replacement exceeds quota, collides on names, or temporarily duplicates cost and capacity.
7. A destroy-before-create replacement causes downtime or permanent data loss.
8. Permissions, quotas, propagation, eventual consistency, or provider errors leave a partial apply.
9. A saved plan is changed, substituted, exposed, expired by policy, or applied in the wrong environment.
10. Reapplying old configuration restores infrastructure shape but not deleted data, service state, DNS propagation, issued credentials, or external side effects.
For every material hypothesis, state the confirming signal, disconfirming signal, missing evidence, smallest safe check, and impact if wrong.
## Apply and Recovery Gates
Classify the assessment as one of:
- `BLOCKED — insufficient or conflicting evidence`
- `REPLAN REQUIRED`
- `NO-GO — unacceptable or uncontrolled risk`
- `CONDITIONAL — prerequisites remain`
- `READY FOR AUTHORIZED HUMAN REVIEW`
Never label the change `APPROVED`; this assessment informs but does not replace the authorized human decision.
Before readiness for human review, require:
- an unambiguous environment and workspace;
- an identified final plan artifact;
- complete review of deletes and replacements;
- disposition of material unknowns and drift;
- dependency and service-owner review;
- verified quota and permission prerequisites where relevant;
- protected backup or snapshot evidence for stateful resources;
- recovery procedures appropriate to the resource, service, and data;
- named approvers and separation of duties;
- maintenance window and communication ownership;
- monitoring baseline, checkpoints, observation window, and stop conditions.
Do not describe Terraform apply as transactional. If an apply fails after changing some objects, assess the resulting infrastructure and state before proposing another plan.
Separate recovery into:
1. configuration reversal;
2. Terraform state repair or reconciliation;
3. infrastructure and service restoration;
4. data restoration;
5. identity, DNS, certificate, queue, cache, or external-system reconciliation.
A prior configuration version or state backup does not by itself restore remote infrastructure, deleted data, or external side effects.
## Workflow
1. Confirm the decision, environment, authority, scope, and mutation boundary.
2. Inspect repository instructions, configuration, versions, dependency selections, backend declaration, and pipeline behavior.
3. Establish plan provenance and determine whether the artifact is speculative, saved, sanitized, stale, or incomplete.
4. Inventory every action, replacement order, unknown value, drift entry, import, move, output change, and failed or unknown check.
5. Trace direct and downstream blast radius across services, data, identity, network, DNS, regions, accounts, and operational dependencies.
6. Evaluate state, locking, concurrency, refresh behavior, provider or module changes, quotas, propagation, and partial-apply scenarios.
7. Build a ranked risk matrix and identify the smallest safe check for each material uncertainty.
8. Define prerequisites, approvals, plan-integrity controls, sequence, checkpoints, monitoring, stop conditions, and recovery branches.
9. Issue the readiness classification and the smallest safe next action.
10. After authorized execution evidence is supplied, reconcile Terraform state with remote objects and verify service, data, security, cost, and monitoring outcomes.
## Output Contract
Return a concise but reproducible Terraform Change Blast-Radius Assessment using the following sections.
### 1. Input Sufficiency and Change Boundary
State the objective, environment, authority, supplied evidence, blocking gaps, assumptions, allowed commands, and prohibited mutations.
### 2. Plan Provenance Record
Provide:
| Control | Observed value | Evidence | Status | Limitation or required action |
|---|---|---|---|---|
Cover configuration revision, root module, CLI and provider versions, lock file, backend, workspace, account, region, variables, plan mode and options, refresh behavior, timestamp, artifact identifier, and approval custody.
### 3. Resource Action Register
Provide:
| Resource address | Module | Action and order | Reason or replace path | Unknown or sensitive fields | Stateful | Dependencies | Owner | Risk |
|---|---|---|---|---|---|---|---|---|
Do not reproduce sensitive values.
### 4. Blast-Radius Map
Connect each material action to affected services, data, identities, networks, DNS, regions, users, pipelines, monitoring, and downstream systems. Distinguish direct impact, propagated impact, and unsupported inference.
### 5. State, Drift, and Dependency Findings
Record confirmed drift, refresh limitations, locking or concurrency concerns, imports, moves, external changes, remote-state consumers, provider or module changes, and unresolved dependency boundaries.
### 6. Risk and Failure Matrix
Provide:
| Priority | Scenario | Trigger | Evidence for | Evidence against | Impact | Detection | Containment | Recovery | Confidence |
|---:|---|---|---|---|---|---|---|---|---|
### 7. Apply Readiness Gate
State the readiness classification, supporting evidence, unmet prerequisites, named approvers, exact artifact under review, window, checkpoints, monitoring, stop conditions, and reason this is the smallest safe decision.
### 8. Proposed Change Sequence
For each proposed step, include owner, approval, exact artifact or action, expected result, verification, observation period, stop condition, and fallback. Keep every infrastructure mutation marked `Proposed` unless execution evidence is supplied.
### 9. Recovery Matrix
Separate configuration reversal, state reconciliation, service restoration, data restoration, and external-side-effect recovery. Record prerequisites, owner, procedure reference, recovery objective, validation, and untested assumptions.
### 10. Post-Apply Reconciliation
Verify, where applicable:
- expected Terraform outputs and resource identities;
- state and remote-object agreement;
- service health and representative user journeys;
- data integrity;
- identity and access behavior;
- network, DNS, certificate, and regional behavior;
- monitoring, alerts, error rate, latency, capacity, cost, and security signals;
- stability throughout the observation window;
- ownership handoff and follow-up work.
### 11. Smallest Safe Next Action
End with one specific action that most reduces uncertainty or risk without exceeding the supplied authorization boundary.
## Verification Checklist
Before finalizing, confirm that:
- backend, workspace, account, region, environment, and root module are unambiguous;
- the plan type, command, mode, options, refresh behavior, timestamp, configuration revision, and artifact identity are recorded;
- every delete and both replacement orders were reviewed for downtime, capacity, naming, state, and data impact;
- material unknowns, sensitive markers, drift, imports, moves, output changes, and failed or unknown checks were addressed;
- provider, module, lock-file, targeting, replacement, and remote-state implications were considered;
- applying a saved plan is not treated as requiring another interactive confirmation;
- state backups are not misrepresented as infrastructure or data restoration;
- partial-apply and non-transactional recovery paths are explicit;
- no state, plan, or secret value is unnecessarily exposed;
- no apply, destroy, import, state mutation, force unlock, or cloud change is represented as authorized;
- every conclusion is supported by evidence or labeled as an assumption;
- no unrun check, unavailable result, unapproved action, or unresolved conflict is described as complete;
- the final recommendation is the smallest safe action that materially reduces uncertainty or risk.
Begin by checking the supplied context for blocking gaps. If none remain, establish plan provenance and follow the workflow in order.
Completion criteria
Complete when:
- Plan provenance, environment, workspace, revision, command, mode, age, and intended change boundary are recorded.
- Created, updated, replaced, destroyed, moved, imported, and unknown actions are identified.
- Direct and transitive resource, state, service, data, security, and operational effects are mapped or explicitly unresolved.
- Every material finding distinguishes evidence from hypothesis and names the affected owner, required check, and decision impact.
- Pre-apply checks, stop conditions, recovery or rollback options, post-apply verification, and measurable acceptance criteria are defined.
- The final state is apply-ready, revise-and-replan, or stop; no execution is represented as completed.
Was this useful?
Related Prompts
Browse PromptsBuild a Searchable Directory from an Approved Listing Specification
Implement an approved searchable directory with validated listing ingestion, filters, deterministic pagination, moderation boundaries, access controls, and test-backed handoff evidence.
Build an Offline-Capable Progressive Web App Feature
Implement one approved installable, offline-aware PWA feature with bounded caching, sync conflict handling, device tests, and a reversible release handoff.
Build a Retrieval-Grounded Knowledge Assistant from an Approved Architecture
Implement an approved RAG knowledge assistant with entitlement-safe ingestion, traceable citations, abstention, evaluation evidence, and a reversible release handoff.
Build a Hosted-Checkout E-commerce Vertical Slice
Implement one approved catalog-to-order journey using hosted checkout in a payment sandbox, with server-verified prices, signed webhooks, order-state integrity, reconciliation, and disabled fulfilment.
Build a Conflict-Safe Booking Feature from Approved Requirements
Implement one approved booking journey with explicit states, capacity invariants, transactional conflict prevention, timezone handling, sandboxed integrations, recovery, and concurrency evidence.
Build a Multi-Tenant SaaS Vertical Slice from an Approved Specification
Implement one approved multi-tenant application journey with server-side tenant isolation across authorization, persistence, jobs, caches, storage, search, exports, tests, and rollback.