Author and deploy AWS infrastructure with SST v4 and Pulumi

This skill provides expert guidance for SST v4, the Ion engine, a Pulumi-backed infrastructure-as-code framework where AWS resources are described in TypeScript via high-level sst.aws.* components such as Function, Bucket, Dynamo, Cron, Service, and Router, or raw aws.* Pulumi resources for the long tail, plus sst.Secret and sst.Linkable for wiring. It covers authoring sst.config.ts and infra/ modules, resource linking, testing, deployment, and troubleshooting, encoding lessons distilled from real multi-stack production projects. Since SST and Pulumi are third-party and evolve, it insists on verifying current component syntax via Context7 and AWS-side facts like service limits, IAM action names, and region availability via the AWS docs MCP rather than from memory. Before editing, it orients on the repo: reading sst.config.ts for app name, region, providers, and default tags, and the run() import order, which is the dependency order, checking for project-specific IaC rules, checking existing Vitest invariants that must stay green, and confirming the actual SST and Pulumi versions and package manager, running a version check to confirm v4/Ion rather than the CDK-based v2/v3 SST Classic.

Universal conventions that apply to any SST v4 and AWS project include controlling the Node runtime deliberately in one place via a global transform rather than trusting SST's default; never interpolating a Pulumi Output into a plain JavaScript template literal, since a bare interpolation type-checks and runs fine in dev mode but produces a broken ARN that only fails at deploy time and has caused real production outages; defaulting to two sequential pull requests when migrating a resource between Pulumi types, since Pulumi creates before destroying and uniqueness-constrained AWS names conflict otherwise; and preferring typed resources over the stringly-typed CloudControl escape hatch. Project-specific defaults worth adopting for consistency, but confirming per repo, include a fixed region and default tags, stage-gated removal and protect settings so production resources survive teardown, SSM Parameter Store as the out-of-graph contract for cross-app consumers while same-app Lambdas use SST's link mechanism for a real dependency edge with IAM, lazy dynamic imports of infra modules to keep hot-reload light, source-level Vitest tests asserting on resource names, shapes, and IAM scopes, and an observability gate requiring an alarm and structured logging on every new Lambda, queue, or schedule before merge.

Use it when writing or editing sst.config.ts, building infra/ modules, wiring resource links, running or troubleshooting a deploy, or migrating a resource between Pulumi types on an SST v4 (Ion) project - not SST Classic (v2 or v3, CDK-based), which is a different framework these patterns don't apply to.

Given an infrastructure change request, it produces authored SST and Pulumi resource code matching the repo's house style, source-level test assertions, and a deploy or migration plan - flagging any irreversible action such as a deploy, a teardown, or a type migration with the target AWS account before execution.

Context7 for current SST and Pulumi component syntax, AWS documentation MCP for verified AWS facts, Vitest for source-level infrastructure tests, and the AWS CLI identity check to confirm the target account before deploying.

Teams running production SST v4 infrastructure who need house-style-consistent, incident-informed patterns for authoring, testing, and safely migrating Pulumi-backed AWS resources - distinguishing universal rules from project-specific conventions along the way.