doit-cloud-connect

DoiT Cloud Connect

Requires DoiT MCP tools and customer-authorized access to deployment tooling. Billing exports, account signup and data-ingestion completion are separate tasks. Loading this skill grants no permission to deploy or remove anything.

Choose the provider and deployment method

Identify the cloud, target scope, requested features and outcome, and the customer's existing resource controller and execution workflow.

Provider	Path
AWS	Supported. Read the AWS walkthrough.
Google Cloud (GCP)	Not implemented in these MCP tools yet.
Azure	Not implemented in these MCP tools yet.

For GCP or Azure, name the provider and explain that its Cloud Connect workflow is not implemented in these MCP tools yet. End that provider's execution path without calling AWS tools or inventing a setup procedure. For a request spanning several clouds, handle each provider separately.

For a supported provider, read the shared deployment rules and the relevant method reference:

• Terraform and OpenTofu, including Terragrunt.
• CloudFormation and StackSets, including CDK and CLI commands that deploy stacks.
• Scripts for direct cloud CLI commands or procedural setup.

Read additional method references when adapting between formats or working across controllers. For another controller, use the shared rules and its own preview.

Shared workflow

After selecting a supported provider, use the stages relevant to the requested operation:

1. Discover current state and ownership. Use list_cloud_connections and get_cloud_connection to inspect registration state, and inspect the owning source before proposing new resources or registration.
2. Get fresh requirements. Use get_cloud_connect_requirements for the selected features, per-feature permissions, identity trust, inputs and deployment prerequisites. These describe required access; they do not prove deployment or live access.
3. Inspect and adapt. Use the customer's repository and IaC/CLI tools to inspect artifacts as reference implementations. Modify, compose or translate them while preserving authoritative requirements, provider constraints and unrelated grants.
4. Review and validate. Show the proposed patch and concrete effects. Use dry_run_cloud_connection_change for planned API mutations and the controller's plan for cloud changes where available; explain what remains unverified. Carry existing authorization forward and confirm any removal whose effects are not already authorized.
5. Execute and reconcile. Deploy through the owning workflow and inspect terminal results. Use register_cloud_connection only when the final deployment has no automatic registrar (no retained DoiT Terraform provider resource or CloudFormation callback) and no connection exists yet; use update_cloud_connection or remove_cloud_connection for requested API changes. Preserve the final implementation's registration owner, avoid duplicate registration and follow the provider walkthrough's concurrency/retry rules.
6. Verify and report. Use verify_cloud_connect for fresh access checks and get_cloud_connection to inspect required follow-ups. Assess coverage and report observed results, remaining failures and uncertainty; keep registration, access health and data arrival distinct.