Suporte upstream incluído

Arquivos de suporte são incluídos em caminhos relativos à skill. Veja UPSTREAM-NOTICE.md para suas fontes fixadas, licenças, hashes e alterações de importação.

SST v4 para AWS

Quando Usar

Use esta skill quando precisar de um especialista em sST v4 (Ion) para gerenciar recursos da AWS como código com o framework baseado em Pulumi. Use ao escrever ou editar sst.config.ts, construir módulos infra/ (sst.aws.Function/Bucket/Dynamo/Cron/Service/Router, sst.Secret, sst.Linkable, recursos brutos aws.* Pulumi), conectar links de recursos,...

SST v4 (o motor "Ion") é um framework IaC baseado em Pulumi: você descreve recursos da AWS em TypeScript e SST/Pulumi os reconcilia em sua conta. Ele oferece componentes de sst.aws.* de alto nível (Function, Bucket, Dynamo, Cron, Service, …) que se expandem para muitos recursos subjacentes, além de uma saída de emergência para qualquer recurso aws.* bruto do Pulumi para o "long tail". Esta skill codifica uma maneira comprovada em produção de criar, vincular, testar, implantar e solucionar problemas de stacks SST na AWS — destilada de projetos reais de múltiplas stacks que pagaram por cada lição com um incidente de produção.

SST e Pulumi são de terceiros — verifique a sintaxe atual com o Context7 (resolve-library-id → query-docs para sst ou pulumi-aws) quando tiver dúvidas sobre as opções de um componente. Verifique fatos do lado da AWS (limites de serviço, IDs de modelo, nomes de ações IAM, disponibilidade de região) com o MCP da documentação da AWS, nunca de memória. Os padrões aqui são o como; a documentação é o o quê.

Quando você for invocado

Descubra em qual modo você está e pule para a referência correta:

Sempre leia a referência relevante antes de editar — elas carregam o porquê por trás de cada regra, o que importa mais do que a regra em si.

Orientação: leia o repositório antes de tocá-lo

Projetos SST são convencionais, mas não idênticos. Antes de editar, construa um mapa rápido para que sua alteração corresponda ao estilo da casa em vez de lutar contra ele:

1. sst.config.ts — o nome do aplicativo, home, provedores/região, defaultTags, quaisquer $transform globais (pin de runtime do Node, correções de bundle) e a ordem em que run() importa módulos infra/. A ordem de importação é a ordem de dependência; respeite-a.
2. infra/ — um arquivo por domínio (armazenamento, funções, api, observabilidade…). É aqui que os recursos são declarados. Verifique se há um infra/CLAUDE.md — esses projetos mantêm regras específicas de IaC lá, e é o arquivo mais valioso para ler primeiro.
3. infra/tests/ — asserções Vitest em nível de código-fonte que fixam invariantes de recursos. Se existirem, sua alteração deve mantê-los verdes e provavelmente precisará de uma nova asserção.
4. package.json / .nvmrc — gerenciador de pacotes (npm vs pnpm), versão do Node e as versões sst/pulumi realmente instaladas.

Execute npx sst version para confirmar que você está na v4/Ion (a assinatura $config + .sst/platform/). v2/v3 ("SST Classic", baseado em CDK) é um framework diferente — esses padrões não se aplicam lá.

As convenções, e quais são universais versus ajustáveis

Os projetos dos quais esta skill é construída compartilham um estilo deliberado. Parte dele é universal (verdadeiro para qualquer projeto SST v4 + AWS — aplique-o em todos os lugares); parte é específico do projeto (um padrão sensato que esses projetos escolheram — adote-o para consistência, mas reconheça que um projeto pode diferir).

Universal — estes princípios valem para qualquer projeto SST v4 + AWS:

• Controle o runtime do Node deliberadamente, em um só lugar. Não deixe ao acaso o que o SST instalado por padrão. O idioma é um único $transform(sst.aws.Function, (args) => { args.runtime ??= "nodejs24.x" }) global em run() — ??= está correto aqui (a transformação é executada antes que o componente aplique seu próprio padrão, então ele preenche apenas quando o usuário não definiu um). SST recente já usa um runtime Node atual por padrão, então verifique o instalado

…