pulumi-overview

Name: pulumi-overview
Author: pulumi

206installs4forks

How to install pulumi-overview?

pulumi/agent-skills/pulumi-overview

$npx -y skills add pulumi/agent-skills --skill pulumi-overview

Installs into the current project.

Summary

Use this skill for any task that creates, modifies, inspects, or destroys cloud infrastructure or SaaS configuration, from one-off CLI operations to full multi-resource projects, across providers in the Pulumi ecosystem. A typical project spans many providers (AWS or Azure or GCP

Files · 1

View on GitHub

SKILL.md

1	# Pulumi
2
3	Pulumi is a tool for creating and managing cloud infrastructure: virtual machines, storage, Kubernetes clusters, databases, anything from any provider. You write code or run CLI commands, Pulumi previews what would change, then applies it. This skill walks three levels of working with Pulumi, from a single CLI command up to a project with policies and scheduled drift. Start at the smallest level that fits the task.
4
5	## The three levels
6
7	Level 1 is `pulumi do`, a CLI for direct CRUD against any provider, with no project files or programming language. Level 2 is a Pulumi project in Python, TypeScript, Go, C#, or Java, used once the work involves multiple related resources, loops or conditionals, reusable abstractions, or environment-specific variants. Level 3 layers Pulumi Cloud onto a project for ESC credentials and configuration, policy, hosted execution, drift detection, schedules, and audit.
8
9	\| Level \| Surface \| When to use \|
10	\|-------\|---------\|-------------\|
11	\| 1 \| `pulumi do` \| Single resource or multi-vendor bootstrapping \|
12	\| 2 \| Pulumi project (Python, TS, Go, C#, Java) \| Multiple resources, abstractions, environments \|
13	\| 3 \| ESC, policy, deployments, drift, schedules \| Governance, secrets, scheduled and hosted runs \|
14
15	When the directory has no existing Pulumi project, a user asking to create a single bucket is a Level 1 task; do not scaffold a new project for it. A request to provision a VPC with subnets and a Kubernetes cluster is Level 2 from the start. A request for nightly drift detection on an existing stack is Level 3.
16
17	Converting existing infrastructure code from another tool (Terraform, CloudFormation, CDK, ARM, or Bicep) is a separate path: route straight to the migration skills listed in the table at the end, independent of the level model.
18
19	Picking the right level requires knowing what is already in the directory. If you can inspect the filesystem, do so. If you cannot (restricted agent contexts), ask the user before any Pulumi command runs whether there is an existing Pulumi project in the directory. Don't run a Pulumi command to find out: commands that would otherwise require a login silently provision a new agent account, parallel to one the user may already own.
20
21	---
22
23	## Level 1: `pulumi do` for direct resource operations
24
25	Use `pulumi do` for one-shot resource operations against any provider. Examples: create a Cloudflare DNS record, create an S3 bucket for backups, create a GCP storage bucket for image uploads, stand up an Azure virtual machine, configure a Datadog monitor, register a Vercel deployment's domain in Cloudflare DNS. There is no project file, directory layout, or programming language involved.
26
27	`pulumi do` is stateless. Each command runs once and operates directly against the cloud provider: `create` provisions a resource and prints its cloud-side identifier, while `read`, `patch`, and `delete` act on a resource addressed by that identifier. Nothing is written to a Pulumi state file, so there is no resource graph and no `${...}` wiring between commands. To connect two resources, capture an output from one command and pass it as a literal value to the next.
28
29	When a Pulumi project (`Pulumi.yaml`) already exists in the directory, do not use `pulumi do` to mutate resources the project manages. Changes go through the program instead.
30
31	### First invocation and signup
32
33	The canonical invocation is `npx pulumi <command>`. It works on any machine with Node.js installed and requires no prior Pulumi setup. If `pulumi` is on PATH, the `npx` shim defers to it; otherwise the command runs from the npm registry. To confirm the CLI is available before any command that would trigger signup, run `npx pulumi version`; it does not touch Pulumi Cloud. The resource verbs (`create`, `read`, `patch`, `delete`, `list`) require CLI v3.243.0 or newer, where `pulumi do` gained resource support. `npx pulumi` fetches a current release, but a `pulumi` already on PATH may be older, so confirm the version is recent.
34
35	`pulumi do` writes no Pulumi state, but it resolves p

People who liked this also viewed

6 picks

Type

pulumi-overview

206installs4forks

View on GitHub

How to install pulumi-overview?

pulumi/agent-skills/pulumi-overview

$npx -y skills add pulumi/agent-skills --skill pulumi-overview

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Pulumi
2
3	Pulumi is a tool for creating and managing cloud infrastructure: virtual machines, storage, Kubernetes clusters, databases, anything from any provider. You write code or run CLI commands, Pulumi previews what would change, then applies it. This skill walks three levels of working with Pulumi, from a single CLI command up to a project with policies and scheduled drift. Start at the smallest level that fits the task.
4
5	## The three levels
6
7	Level 1 is `pulumi do`, a CLI for direct CRUD against any provider, with no project files or programming language. Level 2 is a Pulumi project in Python, TypeScript, Go, C#, or Java, used once the work involves multiple related resources, loops or conditionals, reusable abstractions, or environment-specific variants. Level 3 layers Pulumi Cloud onto a project for ESC credentials and configuration, policy, hosted execution, drift detection, schedules, and audit.
8
9	\| Level \| Surface \| When to use \|
10	\|-------\|---------\|-------------\|
11	\| 1 \| `pulumi do` \| Single resource or multi-vendor bootstrapping \|
12	\| 2 \| Pulumi project (Python, TS, Go, C#, Java) \| Multiple resources, abstractions, environments \|
13	\| 3 \| ESC, policy, deployments, drift, schedules \| Governance, secrets, scheduled and hosted runs \|
14
15	When the directory has no existing Pulumi project, a user asking to create a single bucket is a Level 1 task; do not scaffold a new project for it. A request to provision a VPC with subnets and a Kubernetes cluster is Level 2 from the start. A request for nightly drift detection on an existing stack is Level 3.
16
17	Converting existing infrastructure code from another tool (Terraform, CloudFormation, CDK, ARM, or Bicep) is a separate path: route straight to the migration skills listed in the table at the end, independent of the level model.
18
19	Picking the right level requires knowing what is already in the directory. If you can inspect the filesystem, do so. If you cannot (restricted agent contexts), ask the user before any Pulumi command runs whether there is an existing Pulumi project in the directory. Don't run a Pulumi command to find out: commands that would otherwise require a login silently provision a new agent account, parallel to one the user may already own.
20
21	---
22
23	## Level 1: `pulumi do` for direct resource operations
24
25	Use `pulumi do` for one-shot resource operations against any provider. Examples: create a Cloudflare DNS record, create an S3 bucket for backups, create a GCP storage bucket for image uploads, stand up an Azure virtual machine, configure a Datadog monitor, register a Vercel deployment's domain in Cloudflare DNS. There is no project file, directory layout, or programming language involved.
26
27	`pulumi do` is stateless. Each command runs once and operates directly against the cloud provider: `create` provisions a resource and prints its cloud-side identifier, while `read`, `patch`, and `delete` act on a resource addressed by that identifier. Nothing is written to a Pulumi state file, so there is no resource graph and no `${...}` wiring between commands. To connect two resources, capture an output from one command and pass it as a literal value to the next.
28
29	When a Pulumi project (`Pulumi.yaml`) already exists in the directory, do not use `pulumi do` to mutate resources the project manages. Changes go through the program instead.
30
31	### First invocation and signup
32
33	The canonical invocation is `npx pulumi <command>`. It works on any machine with Node.js installed and requires no prior Pulumi setup. If `pulumi` is on PATH, the `npx` shim defers to it; otherwise the command runs from the npm registry. To confirm the CLI is available before any command that would trigger signup, run `npx pulumi version`; it does not touch Pulumi Cloud. The resource verbs (`create`, `read`, `patch`, `delete`, `list`) require CLI v3.243.0 or newer, where `pulumi do` gained resource support. `npx pulumi` fetches a current release, but a `pulumi` already on PATH may be older, so confirm the version is recent.
34
35	`pulumi do` writes no Pulumi state, but it resolves p

People who liked this also viewed

6 picks

Type