upstream-patches

Pulumi keeps a stack of small private fixes layered on top of somebody else's Terraform provider code. This is how those fixes get edited, dropped, or re-applied on a newer version of that borrowed code, without anyone editing the borrowed copy by hand.

WHEN TO USE

SCOPE

USE FOR

Fix a bug that one of those private changes introduced, by editing that change itself.
Find which of the stored fixes touches a given file or function before editing anything.
Remove one unwanted piece of a stored fix while keeping the rest of it intact.
Re-apply every stored fix on top of a newer version of the borrowed provider code.
Delete one of those stored fixes entirely once it is no longer needed.

This is a saved copy of the skill's SKILL.md instructions. It may differ from the upstream file or the version you install.

In this document (12)

Upstream Patches

upstream/ is a git submodule pointing to the upstream Terraform provider. patches/ contains patch files applied on top of it. Use ./scripts/upstream.sh to manage patch state.

Default Behavior

If fixing a regression introduced by an existing patch, amend the owning patch commit.
Do not create a new patch unless the user explicitly asks.

Commands Reference

Command	Description
`./scripts/upstream.sh init`	Initialize upstream and apply patches to working directory
`./scripts/upstream.sh init -f`	Destructively discard checkout/rebase state and re-initialize upstream
`./scripts/upstream.sh checkout`	Create branch with patches as commits for editing
`./scripts/upstream.sh rebase -i`	Interactively edit patch commits
`./scripts/upstream.sh rebase -o <commit>`	Rebase patches onto a new upstream commit
`./scripts/upstream.sh check_in`	Write commits back to patches and exit checkout mode

Guardrails

Never commit directly to upstream/ without checkout/check_in.
Direct edits under upstream/ outside checkout are ephemeral during upgrade-provider; the tool resets submodule state.
Do not hand-edit patches/*.patch unless intentionally doing raw patch surgery.
Prefer non-interactive rewrite flow over interactive rebase for agents.

Find Owning Patch First

Before editing patch content, identify the owning patch/commit.

./scripts/upstream.sh checkout

# Find candidate patch files by touched file path or unique hunk text
rg -n "path/to/file|unique_symbol" patches/*.patch

# Optional: inspect candidate patch header/hunks
sed -n '1,120p' patches/00NN-Example.patch

# Map patch file to commit in upstream checkout branch
patch=patches/00NN-Example.patch
subject=$(sed -n 's/^Subject: \[PATCH\] //p' "$patch" | head -n1)
cd upstream
git log --oneline pulumi/patch-checkout --grep "$subject"

# If needed, disambiguate by touched path
git log --oneline pulumi/patch-checkout -- path/to/file
cd ..

If rg is unavailable, use grep -En for the patch search. Set target_sha to the owning commit and edit that commit, not HEAD.

Amend Existing Patch (Preferred, Non-Interactive)

./scripts/upstream.sh checkout
cd upstream

target_sha=<owning-commit-sha>
base_sha=$(git rev-parse "${target_sha}^")
tmp_branch="rewrite-${target_sha:0:8}"

# Rebuild history from parent of target commit
git checkout -b "$tmp_branch" "$base_sha"
git cherry-pick "$target_sha"

# Apply fix and amend target commit
# ...edit files...
git add <files>
git commit --amend --no-edit

# Replay remaining commits
git cherry-pick "${target_sha}..pulumi/patch-checkout"

# If cherry-pick conflicts occur:
#   resolve files
#   git add <resolved files>
#   git cherry-pick --continue

# Move checkout branch to rewritten history
git branch -f pulumi/patch-checkout HEAD
git checkout pulumi/patch-checkout
git branch -D "$tmp_branch"
cd ..

Interactive fallback:

./scripts/upstream.sh checkout
./scripts/upstream.sh rebase -i
# mark target commit as edit, amend, then continue

Remove Entire Patch

Use when a patch should be deleted completely.

rm patches/00NN-Description.patch
./scripts/upstream.sh checkout
./scripts/upstream.sh check_in

Remove Part of a Patch

Use when only selected hunks/files should be removed from an existing patch.

Find owning patch/commit (target_sha) and use the amend workflow above.
Revert only unwanted changes from the target commit, then amend.

Example during amend step:

cd upstream
# Restore specific docs-only files from parent of amended commit
git checkout HEAD^ -- path/to/docs-only-file path/to/another-doc-file
git add path/to/docs-only-file path/to/another-doc-file
git commit --amend --no-edit
cd ..

Create New Patch (Only If Requested)

./scripts/upstream.sh checkout
cd upstream
# ...make changes...
git add <files>
git commit -m "Describe new patch"
cd ..
./scripts/upstream.sh check_in

Rebasing Patches to a New Upstream Version

./scripts/upstream.sh checkout

# Rebase onto the new upstream commit
./scripts/upstream.sh rebase -o <new_commit_sha>
# Resolve any conflicts that arise

# Write updated patch files
./scripts/upstream.sh check_in

Verification Checklist

Before check_in:

Confirm expected patch count change (0 by default; -1 for full patch removal).
Confirm whether target patch should remain present (default yes) or be removed (explicit deletion case).
Confirm you are editing the owning commit, not adding a new commit by accident.

After check_in:

Verify patch count matches expectation.
Verify target patch number/purpose is still present when expected.
Verify no unexpected new 00NN-*.patch was introduced.

Interrupted Checkout or Rebase

Preserve work by default. Inspect git -C upstream status, complete the active git am/rebase, verify that every patch was applied, and run ./scripts/upstream.sh check_in before rerunning automation. An interrupted checkout invokes git am separately for each patch, so later patch files may not have been reached.

Use ./scripts/upstream.sh init -f only when intentionally discarding all interrupted work. It can remove conflict resolution, patch commits, operation metadata, and untracked files; it is not routine recovery for a stuck checkout.

Needs a Pulumi Terraform-bridged provider repository. Set that up first — this skill doesn't include it. One of 14 skills in the pulumi/agent-skills package.

Run this outside your AI tool, using Node.js 22.20.0 or newer. Skills CLI 1.7.2 skips skill selection; prompts cancel installation without an interactive terminal. If choosing Project when asked about installation scope, open your project's folder before running this.

Install checklist

Check selected tools if a picker appears; Claude Code may be unchecked under Additional agents. ↑/↓ moves, Space toggles selections, Enter confirms.
Without a tool picker, check Installing to: for your intended tool. Stop if it names a different tool.
If asked, choose Symlink (Recommended) for shared files or Copy to all agents for separate copies; review the summary before confirming installation.
Install the find-skills skill? defaults to Yes, adding another skill for all projects. Choose No if you don't want that extra installation.

Skills CLI 1.7.2 sends install data to skills.sh by default, including the source, skill names, target tools and file details; GitHub sources are reported only when GitHub confirms the repository is public, while other remote sources can also be reported. Confirmed-public GitHub sources also trigger a security-audit request. Before installing, set the environment variable DO_NOT_TRACK=1 or DISABLE_TELEMETRY=1 to disable both.

npx skills add pulumi/agent-skills --skill "upstream-patches" --full-depth

After installing for Claude Code, open it in the installation project if you chose Project; Global makes the skill available across projects on this computer. Once Claude Code loads the skill, its description helps Claude decide when to use it.

If installation created a top-level skills folder that did not exist when your Claude Code session started, run /reload-skills in that session. Run it again after later changes in that folder.

What's inside

Files included with this skill.

View on GitHub

Same repository

cloudformation-to-pulumi
Convert, migrate, or import AWS CloudFormation stacks or templates into Pulumi programs. Load this skill whenever a user wants to move from CloudFormation to Pulumi, convert a CFN template, import existing CloudFormation-managed resources into Pulumi, or asks about CloudFormation-to-Pulumi migration in any form. Also load when the user mentions cdk-importer in a migration context.Read full description
package-usage
Track which stacks across a Pulumi organization use a specific package and at what versions. Use for cross-stack audits, identifying outdated or unmaintained package versions across many stacks, finding affected stacks before publishing breaking changes to a component package, or planning coordinated upgrade rollouts. Do NOT use for upgrading a cloud provider package (pulumi-aws, pulumi-azure-native, pulumi-gcp, pulumi-kubernetes, etc.) in a single project — use skill provider-upgrade instead. Do NOT use for general infrastructure creation, resource provisioning, or how-to questions about a package.Read full description
provider-upgrade
Upgrade any Pulumi provider to a newer version and reconcile the resulting diff. Use when users want to upgrade or update a provider (including editing package.json, requirements.txt, pyproject.toml, go.mod, or Pulumi.yaml to bump a provider SDK), check for breaking changes before or during an upgrade, fix resources that broke after a provider upgrade, or resolve unexpected replacements, creates, or deletes in a post-upgrade preview. Applies to all providers (aws, azure-native, gcp, kubernetes, aws-native, cloudflare, datadog, etc.) — not just Tier 1. Do NOT use for querying which stacks use what package versions; use skill package-usage for cross-stack audits. Do NOT use for general infrastructure tasks.Read full description
pulumi-arm-to-pulumi
Convert or migrate Azure ARM (Azure Resource Manager) templates, Bicep templates, or code to Pulumi, including importing existing Azure resources. This skill MUST be loaded whenever a user requests migration, conversion, or import of ARM templates, Bicep templates, ARM code, Bicep code, or Azure resources to Pulumi.Read full description
pulumi-automation-api
Load this skill when a user asks how to run Pulumi programmatically, embed Pulumi in an application, orchestrate multiple stacks in code, build a self-service infrastructure portal, replace pulumi CLI shell scripts with code, or use the Pulumi Automation API (LocalWorkspace, createOrSelectStack, inline programs). Also load for questions about multi-stack sequencing, parallel deployments, or passing outputs between stacks via code.Read full description
pulumi-best-practices
Load when the user is writing, reviewing, or debugging Pulumi TypeScript/Python programs; asks about Output<T> or apply() usage; wants to create ComponentResource classes; needs to refactor resources without destroying them (aliases); is setting up secrets or config; or is configuring a pulumi preview/up CI workflow. Also load for questions about resource dependency order, parent/child resource relationships, or pulumi.interpolate.Read full description