arcane

Opens a well-formed pull request for the Arcane repository following project conventions. Use when asked to create, open, or submit a pull request, or to push a branch and request a review. Enforces sentence-form PR titles (the symbol-based `type[scope]: Subject` format stays on commits — labels carry type and scope on the PR), branch naming conventions, structured PR body, and Assisted-by transparency trailer.

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.

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.

Guide for authoring Pulumi ComponentResource classes. Use when creating reusable infrastructure components, designing component interfaces, setting up multi-language support, or distributing component packages.

Debug a Pulumi update or preview that failed: read the failure Pulumi already recorded, find what caused it, and fix it. Load this skill when the user asks to debug, diagnose, or fix a failed update or preview, or points at a failing `pulumi up` or `pulumi preview`. Don't load it for authoring new infrastructure, migrations, or provider upgrades; those have their own skills.

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, Kubernetes, Cloudflare, Auth0, Datadog, Vercel, and others), and Pulumi drives them through one CLI, one state model, and one credential layer. Trigger even when the user does not name Pulumi; phrasings like "deploy this app," "provision a database," "stand up a VPC," "configure Auth0," "set up Datadog monitoring," or "tear down staging" qualify. Also trigger for tasks that migrate, port, or convert existing infrastructure code (Terraform, CloudFormation, CDK, Bicep, ARM) to Pulumi. Do not trigger for application runtime code that reads or writes data via cloud SDKs; that is application code, not infrastructure.

Writes and updates Architecture Decision Records (ADR) in docs/decisions/. Use it to document an architectural choice or record why a technology was selected ("write an ADR", "document this decision", "update ADR-00N", "this should be an ADR"), or right after a significant design decision worth preserving — even if an ADR wasn't explicitly requested.

Use this skill whenever the user wants an on-demand CloudNative-PG (CNPG) backup in this Arcane repository — phrases like "backup pocket-id", "backup openbao", "backup atuin", "backup paperless", "backup the apps database", or "backup all postgres in lungmen". Also use it when the user names a logical database (atuin, n8n, immich, paperless, forgejo, linkding, …) without knowing which CNPG cluster owns it. Discover the matching cluster from `projects/` via the bundled discovery script, map it to a kubectl context, require explicit confirmation, then create and verify a plugin-based Backup.

Use this skill whenever a CloudNative-PG cluster is in a broken or degraded state and the cause is not immediately known — phrases like "my database is down", "CNPG cluster is broken", "immich can't connect to postgres", "WAL disk full", "CrashLoopBackOff on the DB pod", "barman archiving error", or "postgres not starting". Also trigger when the user describes symptoms of a CNPG failure (pods restarting, services depending on postgres unavailable, backup not completing) without naming the exact cause. This skill diagnoses the cluster, matches the error pattern against known incidents in `docs/incidents/`, finds the linked procedure, and executes it.

Opens a high-quality GitHub issue for the Arcane repository when the agent identifies work that should be tracked — a bug found in passing, a follow-up surfaced by a post-mortem, an enhancement worth proposing, an out-of-scope improvement that shouldn't expand the current change. Use this skill whenever you would otherwise say "we should also do X later" or "this deserves its own issue". Enforces sentence-form titles (no commit symbol format — labels carry type and scope), the project's label taxonomy, a focused body skeleton (TL;DR / Context / Proposal / Acceptance criteria / Notes), and the Assisted-by attribution footer.

Creates properly formatted Git commits following Arcane project conventions. Use this skill whenever the user wants to commit changes, stage files, write a commit message, or finalize work — including phrases like "commit this", "commit everything", "make a commit", "stage and commit", or "create a commit message". Also triggers when the user finishes a coding task and the next logical step is to persist the changes to git. Enforces symbol-based type format with mandatory square-bracket scope, structured body, and Assisted-by transparency trailer per emerging open-source standards.

Build, push, and upgrade Proxmox LXC appliances in the chezmoi.sh project. Use when asked to build an LXC image, upload it to Proxmox, upgrade a running container, or add a new LXC appliance using the shared library.

Produces a rigorous, blame-free post-mortem analysis of a failure event — missed targets, failed launches, broken processes, bad hires, outages, or any outcome that diverged significantly from expectations. Use this skill whenever the user wants to analyze what went wrong, understand root causes, write a post-mortem, do a retrospective on a failure, figure out why something failed, debrief after a missed deadline or quarter, review a production incident, or extract lessons from a negative outcome. Also trigger when phrases like "what went wrong", "why did this fail", "let's look back at what happened", "retrospective on the incident", "lessons learned", "we need to understand why X happened", or "postmortem" / "post-mortem" / "blameless postmortem" appear. Even when the user doesn't use those exact words — if they describe a failure and want to understand causes and prevent recurrence, this is the right skill.