Cloud & DevOps

Exact prompt

Create a safe production deployment plan for the change below. Recommend actions and commands for review; do not claim to execute anything.

Change and architecture context:
{{change_context}}

Verification and environment evidence:
{{verification_evidence}}

Operational constraints and authority:
{{operational_constraints}}

Instructions:
1. Identify affected services, data, interfaces, dependencies, regions, tenants, and user journeys from supplied evidence.
2. Separate prerequisites, deployment steps, migrations, configuration changes, cache or queue effects, and post-deployment checks.
3. Propose the smallest staged rollout supported by the platform, with health signals, observation windows, and explicit promotion criteria.
4. Define rollback or roll-forward steps, data compatibility limits, backup or restore evidence, and the latest safe decision point.
5. For every state-changing command, state target scope, required permission, expected output, failure handling, and a dry-run or read-only check when available.
6. Never include real credentials; use named placeholders and approved secret-injection mechanisms.
7. Add communication, ownership, incident escalation, and stop conditions.

Return assumptions, dependency order, reviewed command templates, observability matrix, rollback plan, and release checklist. Do not execute commands, disable safeguards, or suggest destructive cleanup without explicit authorization and verified targets.

Replace before use

Change and architecture context{{change_context}}

The diff or artifact, affected architecture, dependencies, data changes, and intended behavior.

Verification evidence{{verification_evidence}}

Builds, tests, scans, preview results, migration rehearsals, backups, and known gaps.

Operational constraints{{operational_constraints}}

Environments, change window, permissions, rollout mechanisms, SLOs, owners, and recovery limits.

Exact prompt

Review this infrastructure-as-code change using the diff, plan output, and environment context supplied. Do not apply the change.

Infrastructure diff:
{{infrastructure_diff}}

Plan or preview output:
{{plan_output}}

Environment standards and context:
{{environment_context}}

Instructions:
1. Map every proposed create, update, replacement, move, and destroy action to the code that caused it.
2. Flag unexpected scope, target-account or region ambiguity, dependency ordering, state drift, import or move requirements, and provider-version changes.
3. Review network exposure, identity permissions, encryption, secret references, logging, retention, backups, immutability, and deletion protection against supplied standards.
4. Assess availability, data-loss, quota, cost, and rollback implications, stating what requires live verification.
5. Treat hidden or sensitive plan values as secrets and never reconstruct or print them.
6. Require a fresh plan from the exact reviewed revision and environment before approval.
7. For destructive or replacement actions, specify explicit authorization, backup evidence, target verification, maintenance impact, and recovery rehearsal needed.

Return blocking findings first, action mapping, questions, safe validation commands, and an approval checklist. Do not apply, import, unlock, delete, or mutate state.

Replace before use

Infrastructure diff{{infrastructure_diff}}

The exact proposed code and dependency lock changes with repository context.

Plan or preview output{{plan_output}}

Redacted output tied to a known revision, target account, region, workspace, and timestamp.

Environment standards{{environment_context}}

Architecture, security controls, naming, ownership, policies, SLOs, state setup, and recovery requirements.

Exact prompt

Create an incident response runbook for the failure scenario below. Favor read-only diagnosis and reversible stabilization before invasive actions.

Service and architecture context:
{{service_context}}

Failure scenario and telemetry:
{{failure_evidence}}

Operational authority and recovery context:
{{recovery_context}}

Instructions:
1. Define trigger conditions, user impact, severity cues, incident roles, communication routes, and prerequisites.
2. Build a read-only diagnostic sequence that verifies time window, scope, dependencies, recent changes, saturation, errors, and data integrity.
3. For each check, state the expected signal, alternative interpretations, required permission, and sensitive fields to redact.
4. Rank reversible stabilization options with risks, capacity implications, monitoring, authorization, and rollback.
5. Place destructive, irreversible, or data-changing operations behind a clearly marked emergency gate with explicit incident-command approval, exact target validation, backup evidence, and recovery steps.
6. Use placeholders for account, cluster, namespace, service, region, and credentials; never embed secret values.
7. Add recovery confirmation, watch period, handoff, evidence preservation, and post-incident follow-up.

Return a decision tree, read-only commands, stabilization options, emergency gate, recovery checks, and ownership table. Do not claim the runbook fits an environment that has not been verified.

Replace before use

Service context{{service_context}}

Architecture, dependencies, environments, SLOs, ownership, data criticality, and normal operating signals.

Failure evidence{{failure_evidence}}

Observed symptoms, alerts, sanitized logs, metrics, traces, time window, and known recent changes.

Authority and recovery context{{recovery_context}}

Incident roles, permissions, backups, failover, rollback, communication, compliance, and escalation rules.

Exact prompt

Investigate the cloud cost anomaly below using supplied billing and operational evidence. Recommend verification and bounded actions; do not change resources.

Cost observation:
{{cost_observation}}

Billing and usage evidence:
{{billing_evidence}}

Architecture and ownership context:
{{architecture_context}}

Instructions:
1. Verify currency, billing period, account scope, credits, taxes, amortization, data freshness, and comparison baseline.
2. Break the change into service, account, region, resource, usage type, tag, and time contributions where the data permits.
3. Separate price changes, volume changes, new resources, scaling, retries, transfer, storage growth, commitment coverage, allocation gaps, and reporting artifacts.
4. Correlate material changes with deployments, incidents, traffic, schedules, and configuration using timestamps rather than assumptions.
5. Identify owners and missing tags without exposing customer data, account identifiers, or credentials.
6. Prioritize read-only checks and reversible containment; require explicit owner authorization, service-impact review, monitoring, and rollback before resizing, stopping, deleting, or changing retention.
7. Define how savings and service health would be verified after an approved change.

Return a quantified contribution table, hypotheses with evidence, read-only checks, owner questions, and guarded remediation options. Do not promise savings or issue destructive commands.

Replace before use

Cost observation{{cost_observation}}

The amount, currency, billing scope, dates, baseline, alert, and why the change appears unexpected.

Billing and usage evidence{{billing_evidence}}

Redacted exports, usage metrics, pricing details, tags, credits, and data-quality limitations.

Architecture and ownership context{{architecture_context}}

Services, accounts, regions, recent changes, expected demand, SLOs, owners, and change-control rules.