gcx: Skill for Claude Code

Add Provider

Orchestrates adding a new Grafana product provider — from API discovery through verified implementation. Four stages, worked autonomously: the stage boundaries are checkpoints you satisfy, not approvals you wait for.

When to Use

• User wants to add CLI support for a Grafana Cloud product
• User says "add provider", "new provider", "integrate [product]"
• A bead task references provider implementation

When NOT to use: if all you need is standard CRUD on a type that is externally accessible and discoverable on /apis — gcx resources already covers that through dynamic discovery.

That test is about CRUD, not about the whole command surface. gcx dashboards and gcx alert are dedicated command trees over products that are on /apis, because their real operations (restore a version, export a policy tree) are not CRUD verbs. So a K8s-backed product can still warrant commands; run the placement analysis rather than stopping at "it's on /apis".

If the answer is a commands-only provider calling the K8s dynamic client, note that CONSTITUTION.md § Architecture Invariants makes internal/providers/dashboards/ the one documented exception (ADR 016) — a second requires explicit human approval and a CONSTITUTION change.

Entry paths

Invoked from integrate-with-gcx (the placement section already exists — necessity, command path, backend evidence, wiring, readiness). Then:

• Skip Stage 1 entirely if the placement section carries the API surface, auth model and readiness verdict. Record those findings and move on; do not re-research or re-classify what is already settled, and do not ask for approval of decisions that were made with evidence.
• Skip the Stage 2 decisions it already answers (tier, command surface, and whether the resource belongs in the resources pipeline). Answer only what is genuinely still open.
• The Stage 1 and Stage 2 blocking approvals do not apply on this path: you do not wait for sign-off before implementing. Build autonomously. If something is genuinely unsettled, discover it, or ask one targeted question carrying the evidence and a recommendation — never fall back to a blanket approval gate.
• Write documents only where they earn their keep. The Stage 2 artifacts are conditional on real architectural risk or a repository requirement, not mandatory paperwork:
  • ADR — only for a decision that is contested, hard to reverse, or departs from precedent: a new auth model, a client type the repo has not used, an adapter registration, a cross-cutting config change. "Reuse the stack token, hand-rolled HTTP client, commands-only" is the documented default across existing providers — record it in the PR body and move on.
  • Spec / per-stage documents — only when the work is genuinely staged across multiple PRs, which is what they exist to make resumable. A provider shipping in one change does not need them.
  • Smoke-test plan — always, because Stage 4 executes it and the repo requires real-instance verification. Keep it to the commands you actually implemented. This is a short command list in your working notes, not a standalone document and not a human gate.
• So: do Stage 2d (the smoke-command list) first, then Stage 3, then Stage 4 verification as written. Skipping straight to Stage 3 leaves Stage 4a with no plan to execute.