Add Pulumi Provider Package

VerifiedCaution

Guided 7-step workflow to add a new provider package to the Pulumi Registry, including YAML metadata creation, validation, and community list updates.

Sby Skills Guide Bot
DevelopmentBeginner
9/13/2026
Claude Code
#pulumi#registry#provider-packages#metadata#yaml

Recommended for

Automated summary

This skill walks through adding a new provider package to the Pulumi Registry, from gathering package details to generating the metadata YAML file.

Strengths

  • Rigid seven-step sequential workflow with a progress counter shown before every step
  • Actually validates the GitHub repository with `gh api` and the schema file with WebFetch before writing any YAML
  • Clearly separates community packages from first-party providers, each with its own reference file
  • Auto-detects the latest release tag to fill in the package version

Limitations

  • Heavily dependent on Claude Code tooling (`AskUserQuestion`, WebFetch, `gh`) and on GitHub-hosted repositories
  • The reference files it points to (YAML template, first-party checklist) are external and not included in the provided SKILL.md
  • Only produces registry metadata — no provider code and no actual publishing step
When to use it

Use it when you need to register a new community or official Pulumi provider without hand-writing the YAML metadata structure.

When not to use it

Avoid it when the provider is not hosted on GitHub, when the `gh` CLI is unavailable, or when you are editing a package already listed in the registry.

Security analysis

Caution
Quality score82/100

The skill is a legitimate registry workflow and does not instruct destructive, exfiltrating, or obfuscated actions. It uses bash/gh and WebFetch for verification and writes local package metadata, which is powerful but appropriate. The main concern is that user-supplied values are interpolated into shell commands and URLs without explicit validation, so it is best treated as caution rather than safe.

Findings
  • •Interpolates user-provided package/repository values into shell commands (e.g., gh api repos/{owner}/{repo}) without explicit sanitization or validation of shell metacharacters.
  • •Writes and modifies repository files, including themes/default/data/registry/packages/{name}.yaml and community-packages/package-list.json, though user confirmation is required before file creation.
How this analysis is made

Examples

Add a community provider
/new-package — I'd like to add the pulumiverse Datadog provider to the Pulumi Registry as a community package. The repo is https://github.com/pulumiverse/pulumi-datadog.
Add a first-party provider
/new-package — Add a new first-party Pulumi provider named `acme`, repo https://github.com/pulumi/pulumi-acme, schema at provider/cmd/pulumi-resource-acme/schema.json.
Validate before generating YAML
Use the new-package skill to check that https://github.com/myorg/pulumi-widgets is public and that its schema.json is reachable, then draft the registry YAML for review.

description: Guided workflow to add a new provider package to the Pulumi Registry user-invocable: true

New Package

Use this when: You want to add a new provider package to the Pulumi Registry, either as a community package or a first-party Pulumi provider.


Usage

/new-package

Walks through a guided process to create the package YAML metadata, validate the provider, and optionally add it to the community package list.


Process

CRITICAL SUCCESS CRITERIA: Complete all 7 steps in sequence. Every step is mandatory. DO NOT SKIP ANY STEP OR END THE WORKFLOW PREMATURELY!

Step Counter: Display progress before each step as: [Step X/7] followed by the step heading.

References: This skill uses reference files for templates and validation:

  • new-package:references:yaml-template - Canonical YAML structure
  • new-package:references:package-list-format - Community package list entry format
  • new-package:references:first-party-checklist - First-party provider setup checklist

[Step 1/7] Determine Package Type

Use AskUserQuestion to ask:

Question: "What type of package are you adding?"

Options:

  1. Community package - Third-party provider published by the community (e.g., pulumiverse)
  2. First-party Pulumi provider - Official Pulumi provider (published by Pulumi)

Store the selection for later steps.


[Step 2/7] Gather Package Information

Use AskUserQuestion to collect the following (ask in sequence, one at a time):

  1. Package name — The short name for the provider (lowercase, hyphens allowed). Example: datadog, cloudflare, my-provider
  2. Repository URL — The GitHub repository URL. Example: https://github.com/pulumiverse/pulumi-example
  3. Display title — The human-readable title. Example: Datadog, Cloudflare, My Provider
  4. Description — Brief description of what the provider does (1-2 sentences)
  5. Publisher — The publisher name. Example: Pulumi, pulumiverse, MyOrg
  6. Category — One of: Cloud, Database, Infrastructure, Monitoring, Network, Utility, Version Control System
  7. Schema file path — Path to the schema JSON file within the repo. Example: provider/cmd/pulumi-resource-example/schema.json

For community packages, also ask: 8. Is this a component provider? (yes/no)

For first-party packages, default component: false (can be overridden).


[Step 3/7] Validate Repository

Verify the repository exists and is accessible:

gh api repos/{owner}/{repo} --jq '.full_name'
  • If the repo exists, display confirmation with repo details (description, stars, language)
  • If the repo doesn't exist or is inaccessible, report error and ask user to verify the URL
  • Check if the repo is public (required for community packages)

[Step 4/7] Validate Schema File

Construct the schema file URL and verify it's reachable:

For GitHub repos, construct the raw URL:

https://raw.githubusercontent.com/{owner}/{repo}/{default-branch}/{schema-file-path}

Use WebFetch to check if the URL returns valid content:

  • If reachable, display confirmation
  • If not reachable, warn the user and ask if they want to continue with a different URL or path
  • Try common default branches: main, master

[Step 5/7] Create Package YAML

Generate the YAML file using the template from new-package:references:yaml-template.

Actions:

  1. Determine the latest version by checking the repo's releases:

    gh api repos/{owner}/{repo}/releases/latest --jq '.tag_name' 2>/dev/null || echo "v0.0.1"
    
  2. Generate the YAML content with all gathered information

  3. Display the complete YAML for review:

    Package YAML Preview:
    ─────────────────────────────────────────
    [YAML content]
    ─────────────────────────────────────────
    
    File: themes/default/data/registry/packages/{name}.yaml
    
  4. Use AskUserQuestion to confirm:

    • Create file (Recommended) - Write the YAML file
    • Edit values - Modify specific fields
    • Cancel - Exit without creating
  5. Write the file to themes/default/data/registry/packages/{name}.yaml


[Step 6/7] Update Package List or Note First-Party Setup

Community Package Path

Add an entry to community-packages/package-list.json:

  1. Read the current file
  2. Add the new entry in the correct alphabetical position within the include array
  3. Display the change for confirmation
  4. Write the updated file

See new-package:references:package-list-format for the entry format.

First-Party Package Path

Skip package-list.json modification. Instead, display the first-party setup checklist:

See new-package:references:first-party-checklist for the complete checklist.

Key message: "First-party providers use repository_dispatch events. The provider repository needs to be configured to send resource-provider dispatch events to pulumi/registry via the publish-provider-update.yml workflow."


[Step 7/7] Validate and Next Steps

  1. Run /validate-package {name} to verify the new package

  2. Display completion summary:

    New package added successfully!
    
    Package: {name}
    Type: {community|first-party}
    File: themes/default/data/registry/packages/{name}.yaml
    {If community: Added to community-packages/package-list.json}
    
    Next steps:
    - Review the generated YAML file
    - Run /shipit to commit and create a PR
    {If first-party: - Configure repository_dispatch in the provider repo}
    
  3. Offer to run /shipit to commit and create a PR


Critical Workflow Rules

  1. Progress Display: Always display step number "[Step X/7]" before each heading
  2. Sequential Execution: Never skip ahead - complete each step before moving to next
  3. User Approval: Get explicit approval before writing files (Step 5)
  4. Validation: Always run validate-package at the end
  5. Error Handling: If a step fails, don't proceed - offer retry or cancel

From the file to a first result

The download contains exactly the content displayed on this page. This copy may differ from the latest version in the source repository.

View the source and supporting files

This download contains SKILL.md only. Any scripts, references, templates and dependencies are not included. Get the required files from the source, preserving their directory structure, before continuing.

1. Download the file

Download SKILL.md

From the root of a test project, save the file as .skill-downloads/add-pulumi-provider-package-mtzb82t2/SKILL.md, or use the command below. This folder is for inspecting the skill before installation.

Command for macOS/Linux or WSL: requires a POSIX shell and curl. On Windows without WSL, use the download button and create the folder manually.

mkdir -p '.skill-downloads/add-pulumi-provider-package-mtzb82t2' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/add-pulumi-provider-package-mtzb82t2/download' --output '.skill-downloads/add-pulumi-provider-package-mtzb82t2/SKILL.md.part' && mv '.skill-downloads/add-pulumi-provider-package-mtzb82t2/SKILL.md.part' '.skill-downloads/add-pulumi-provider-package-mtzb82t2/SKILL.md'

2. Check prerequisites

Read SKILL.md before using it. If it references scripts or external services, inspect them and prepare the required access in your test environment.

No recognized prerequisites section in this file. This does not mean it is self-contained: libraries, tools and access requirements may be mentioned elsewhere in the content or source repository.

The platforms on this page are catalog indications. The paths below follow tool documentation; they do not prove this skill has been run in those tools. No minimum tool version is confirmed for this listing.

3. Load the skill

This file does not provide a usable name/description header for this native procedure. It remains available to download and inspect; use the manual method below.

Manual method or another tool: attach SKILL.md to a conversation, or open it in an agent that can read files. Include any required supporting resources. No universal folder is recognized by every tool.

4. Try a first task

Use a short, synthetic input: an API endpoint, a small document or an interface brief. In a new conversation, attach the file or give the agent its path, then adapt this request:

Read .skill-downloads/add-pulumi-provider-package-mtzb82t2/SKILL.md and apply its instructions to this example: [describe a test input]. Identify any missing files, dependencies or access. Produce the result requested by the skill without inventing data or running unreviewed scripts.

Expected result: output matching the skill instructions, or a precise list of missing prerequisites. A read confirmation alone does not validate a first use. If an external resource is unavailable, that path remains untested.

Related skills