kubedoop-dev

Plugin kubedoop-dev from marketplace whg517 in whg517/agents. Commands read from the repo's manifest — 1 month ago.

Skills (18)

• bump-operator-go

  Coordinate an operator-go dependency bump across Kubedoop operator repositories, including the v0.12.6 Gen 3 migration boundary, pilot-first rollout, per-repository verification, and the upstream claim re-verification pass. Use when the user asks to bump operator-go in one or more zncdatadev reposit

• chainsaw-e2e

  Run, debug, and author chainsaw end-to-end tests in zncdatadev operator repos. Use when running e2e tests locally, reproducing a chainsaw CI failure, writing a new e2e test case under test/e2e/, or setting up/tearing down the kind test cluster. Covers the make target sequence, the env vars that para

• chart-authoring

  Author or modify helm charts for zncdatadev operators — the deploy/helm/OPERATOR chart in each operator repo and the kubedoop-helm-charts aggregate repo. Use when editing chart templates or values.yaml, adding the chart for a new operator, fixing ct lint / ct install / chart-e2e failures, or when ch

• containers-images

  Build, modify, or add product container images in the zncdatadev containers repo (kubedoop-base, java-base, hadoop, zookeeper, kafka, hive, etc.). Use when bumping a product version, adding a new product image, changing a Dockerfile in containers/, or debugging a docker buildx bake / build.sh failur

• crd-design

  Decide the SHAPE of a Kubedoop CRD — what field, what type, which commons structure — from product research. Use when designing the CRD for a new operator, when adding a role or ANY new spec field to an existing one (including a single field like a tls or authentication block), or when reviewing a p

• e2e

  Run or debug a full or single-case Chainsaw end-to-end test in a Kubedoop operator repository, resolving the Kubernetes version from CI and keeping failures local for diagnosis. Use when the user asks for the kubedoop-dev e2e command or supplies an optional suite/case and Kubernetes version.

• framework-feedback

  Feed downstream operator experience back into the operator-go framework. Use after completing a feature in any zncdatadev *-operator repo, when copying logic between operators, when fighting or working around an operator-go API, or when developing an operator and operator-go together across repos. C

• gen3-migration

  Migrate a zncdatadev PRODUCT operator from the legacy BaseCluster architecture (Gen 2a flat / Gen 2b per-role packages) to the Gen 3 GenericReconciler + RoleGroupHandler framework. Use when refactoring kafka-operator, hdfs-operator, or any product operator still pinning operator-go ≤ v0.12.6 onto th

• issue-triage

  Triage an operator defect — a GitHub issue, a user bug report, or wrong behavior you hit yourself — against a zncdatadev operator: intake, classification, minimal reproduction, and the fix-with-regression-test contract. Use when handling an operator issue, when something an operator renders or does

• iterate

  Drive an existing Kubedoop operator change from reproduction or feature scope through research, design delta, implementation with Chainsaw coverage, verification, and framework feedback. Use for bug fixes, issue work, or feature additions in an existing zncdatadev operator.

• new-operator

  Drive the complete new Kubedoop operator pipeline from six-dimension product research through human-approved CRD design, Gen 3 scaffolding, smoke E2E, verification, and framework feedback. Use when the user asks to create or scaffold a new zncdatadev product operator.

• onboard

  Check Kubedoop contributor prerequisites, report a doctor table, explain the multi-repository workspace, and map common tasks to the installed toolkit. Use when onboarding a contributor or preparing a fresh development machine.

• operator-go-guardrails

  Guardrails and API reference for developing Kubedoop operators against the operator-go framework. Use when modifying reconcilers, role-group handlers, resource builders, CRD types (api/v1alpha1 or pkg/apis), config generation, extensions, or controller wiring in any zncdatadev *-operator repo or in

• operator-scaffold

  Scaffold a new Kubedoop product operator repo with the org-standard layout. Use when creating a *-operator repo whose design is already settled — this stage requires an approved design ADR (crd-design skill) built on a research document (product-research skill); for the full research-to-implementati

• product-research

  Research a data-platform product's real deployment behavior before Kubedoop operator work. Use before designing a CRD or scaffolding a new operator, when adding auth/logging/metrics-observability/scaling features whose product-side behavior is unverified, or when the user asks how a product deploys

• release-operator

  Release a zncdatadev operator or operator-go — tagging, release-version bumps, image publishing, helm chart publishing, and the CI gates a release must pass. Use when preparing or cutting a release, bumping an operator or operator-go release version, debugging a failed release workflow, or explainin

• verify-before-push

  Mirror Kubedoop CI locally before committing or pushing in any zncdatadev repo (operators, operator-go, containers, helm-charts). Use before creating a commit or PR, after editing API types, when lint/test/CRD-sync CI jobs fail on a PR (for chainsaw job failures see chainsaw-e2e; for chart-lint-test

• verify

  Run the Kubedoop CI-mirror gate for the current repository and record verification evidence for the exact HEAD. Use when the user asks to verify, check before push, run local CI gates, or invokes the kubedoop-dev verify workflow.

Slash commands (6)

• /kubedoop-dev:bump-operator-go

  Coordinated operator-go dependency bump across operator repos, with the v0.12.6-boundary guard

• /kubedoop-dev:e2e

  Run or debug chainsaw e2e in the current kubedoop operator repo (full suite or single case)

• /kubedoop-dev:iterate

  Drive an existing-operator iteration - understand (reproduce a problem, or scope a feature) → scoped research → design delta → implement with e2e → verify → feedback

• /kubedoop-dev:new-operator

  Drive the full new-operator pipeline - research → design (human gate) → scaffold → implement → e2e

• /kubedoop-dev:onboard

  Contributor onboarding - check prerequisites, explain the workspace, map the toolkit

• /kubedoop-dev:verify

  Run the org CI-mirror gate locally and record push-gate evidence

Subagents (4)

• e2e-debugger

  Diagnoses failing chainsaw e2e tests and operator misbehavior on a local kind cluster in zncdatadev operator repos. Use PROACTIVELY whenever a chainsaw case fails, an assert times out, a pod CrashLoops or resources render wrong on a local cluster, or e2e behaves differently from unit tests — instead

• framework-steward

  Reviews completed downstream operator changes from the operator-go framework's perspective — what should be promoted upstream, what exposed a framework defect. Use PROACTIVELY after any non-trivial feature lands in a zncdatadev *-operator repo, and when reviewing a diff that works around or extends

• gate-verifier

  Independent verification lane for zncdatadev repos — runs the CI-mirror gates (and targeted e2e when asked) and reports evidence-backed pass/fail. Use PROACTIVELY before claiming a task complete or pushing, so authoring and approval stay in separate contexts. It never edits code and never records ev

• product-researcher

  Researches how a data-platform product actually deploys and runs in production before any Kubedoop operator work. Use PROACTIVELY before designing a CRD or scaffolding a new operator, and when adding a feature that touches product behavior nobody has verified (auth modes, metrics/observability expos

Hooks (2)

• PreToolUse

  "${CLAUDE_PLUGIN_ROOT}/hooks/pre-push-gate.sh" "${CLAUDE_PLUGIN_ROOT}"

• PostToolUse

  "${CLAUDE_PLUGIN_ROOT}/hooks/api-codegen-reminder.sh"

Similar plugins