team-dpe

Claude Code toolkit for the Data Platform Engineering (DPE) team.

Installation

claude plugin install team-dpe@personio-claude-code-marketplace

What does this plugin do?

Skills for DPE's own tooling and repos. Currently: safe, phased removal of Snowflake schemas and other RBAC-carrying objects from Personio-Internal/snowflake-infrastructure.

remove-snowflake-schema

Guides the safe removal of a schema (or other object with derived RBAC, like a storage integration) from Personio-Internal/snowflake-infrastructure, as a sequence of PRs, each one confirmed working in DEV before the next is opened. That repo's Terragrunt pipeline applies its layers in a fixed order regardless of whether you're creating or destroying things, which means a naive "delete the schema and its RBAC in one PR" reliably breaks — an earlier layer destroys something a later layer still has a live reference to. This skill knows the repo's structure well enough to find every place that could reference what you're removing (including a couple of non-obvious dynamic mechanisms), and walks the change through the correct sequence instead.

It never touches Snowflake directly and never runs Terraform/Terragrunt against real state — its only output is pull requests. Verifying that DEV applied cleanly is done by reading GitHub Actions logs (read-only), and PROD is never approved automatically.

What you need

• gh CLI, authenticated against Personio-Internal.
• A working checkout of snowflake-infrastructure with terraform/terragrunt available (for local fmt/validation only — this plugin never runs plan or apply).
• To be inside the snowflake-infrastructure repo. The skill checks this and refuses to run anywhere else.

Quick Start

Remove the STAGING_PROD.OLD_VENDOR_SYNC schema, ticket DASD-1234

Example

> Remove the STAGING_PROD.OLD_VENDOR_SYNC and REPORTING_PROD.RPT_OLD_VENDOR schemas, ticket DASD-1234

Checked: OLD_VENDOR_SYNC is tagged PWI=False in STAGING_PROD (dynamic grant web applies,
~15 functional roles reference it). RPT_OLD_VENDOR is not tagged PWI=False and has one
hand-written grant in roles.tf (WORKATO_FR).

Proposed sequence:
  PR 1 — revoke OLD_VENDOR_SYNC's dynamic restricted-read grants (human_functional_roles.tf),
         roles stay alive
  PR 2 — remove RPT_OLD_VENDOR's hand-written grant from roles.tf
  PR 3 — exclude both schemas from rbac-core, destroying their access roles
  PR 4 — remove both schema entries from database_schemas.tf

Proceed with PR 1?

The skill opens each PR, tells you what to look for in the DEV apply log, and waits for your go-ahead — including an explicit stop before every PROD approval — before starting the next one.

Why would you want this?

• The failure mode this avoids is not obvious from reading the Terraform — it only shows up mid-apply, when an earlier layer's destroy changes real state before a later layer's already-computed plan runs against it. terraform plan cannot detect it in advance.
• One of the two things that actually reference a schema's RBAC is entirely dynamic (a PWI-tag-driven mechanism spanning ~60 functional roles) and won't turn up in a plain grep for the schema's name — this plugin knows to check for it every time.
• Manually working through this takes several fix-forward PRs the first time you hit it, because each layer boundary you didn't already know about surfaces its own separate failure. This plugin applies that whole sequence correctly from the start.