# Awsx Breaking Change Evaluation

> Tactical AWSX breaking-change evaluation guidance for pulumi-awsx. Use when assessing schema changes, generated SDK surface changes, child resource identity changes, aliases, changed defaults, provider or region behavior changes, and upgrade impact for existing users.

- Skill: `pulumi/awsx-breaking-change-evaluation` (Agent Skill, multi-file: 8 files)
- Install (CLI): `npx skillmds@latest add pulumi/awsx-breaking-change-evaluation`
- Raw SKILL.md: https://api.skillmd.com/api/skills/pulumi/awsx-breaking-change-evaluation/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: pulumi (https://skillmd.com/u/pulumi)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/pulumi/awsx-breaking-change-evaluation

---


# AWSX Breaking Change Evaluation

Use this skill to evaluate whether an AWSX change is compatibility-sensitive or
breaking for existing users.

This skill is for risk classification and required evidence. For component shape
guidance, use `$awsx-component-design`. For proof strategy, use
`$awsx-test-authoring`.

## Rule Index

- `rules/public-schema-surface.md`: schema and generated SDK public-surface
  changes.
- `rules/code-vs-behavior-breaks.md`: code-level breaks versus preview/update
  behavior changes.
- `rules/child-identity-and-aliases.md`: child logical names, parentage, URNs,
  aliases, and migration paths.
- `rules/defaults-and-supporting-resources.md`: defaults, default-created
  resources, tags, and supporting-resource changes.
- `rules/provider-region-behavior.md`: provider and region propagation changes.
- `rules/upstream-inherited-breaks.md`: changes inherited from `@pulumi/aws` or
  AWS behavior versus AWSX-added breakage.

## How To Use

1. Identify the user-visible surface touched by the change: schema, generated
   SDKs, child resource identity, defaults, providers/regions, or preview/update
   behavior.
2. Read the matching rule file.
3. Classify the change as clearly safe, compatibility-sensitive, or breaking.
4. If compatibility-sensitive, require evidence: schema comparison, generated
   diff, mock test, provider-upgrade preview, targeted acceptance test, or an
   explicit maintainer decision.
5. Check the upgrade scenarios that match the change: existing user code still
   compiles, existing stack preview is stable, child resource identity remains
   compatible, and new programs get the intended behavior.
6. Report the classification and evidence. Do not smooth uncertainty into a
   confident answer.

## Stop Early

Stop before approving compatibility if:

- existing user code might need to change;
- existing stacks might preview replacements, creates, deletes, or changed
  inputs after upgrade;
- child names, parentage, aliases, provider tokens, module paths, defaults, or
  output presence changed;
- the only evidence is that TypeScript compiles;
- the change is inherited from upstream but AWSX may be adding extra behavior on
  top.