feat: plugin-validator skill config for claude and codex#2468
Conversation
|
Hello! 👋 This repository uses Auto for releasing packages using PR labels. ✨ This PR can be merged but will not trigger a new release. To trigger a new release add the |
| @@ -0,0 +1 @@ | |||
| @../../skills/validate-plugin.md | |||
There was a problem hiding this comment.
We have to create the skills inside codex, otherwise it does not directly recognize from root. Claude does it if the root has SKILLS.md.
There was a problem hiding this comment.
Pull request overview
This pull request adds AI agent skill configurations for validating Grafana plugins using the official @grafana/plugin-validator tool. The skill enables Claude Code and Codex to run plugin validation directly from their interfaces, providing developers with automated feedback on plugin compliance.
Changes:
- Added validate-plugin skill that builds plugins (frontend and optionally backend), packages them as zip archives, and runs validation using npx or docker
- Integrated the skill into both Claude Code (via
.claude/skills/) and Codex (via.codex/skills/) by referencing the shared skill definition - Provided step-by-step instructions for AI agents to execute validation with error handling and user feedback
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 10 comments.
| File | Description |
|---|---|
| packages/create-plugin/templates/common/.config/AGENTS/skills/validate-plugin.md | Main skill definition with bash commands for building, packaging, and validating Grafana plugins |
| packages/create-plugin/templates/common/.codex/skills/validate-plugin/SKILL.md | Codex skill registration with frontmatter referencing the shared skill definition |
| packages/create-plugin/templates/common/.claude/skills/validate-plugin/SKILL.md | Claude skill registration referencing the shared skill definition |
packages/create-plugin/templates/common/.config/AGENTS/skills/validate-plugin.md
Outdated
Show resolved
Hide resolved
packages/create-plugin/templates/common/.config/AGENTS/skills/validate-plugin.md
Outdated
Show resolved
Hide resolved
packages/create-plugin/templates/common/.config/AGENTS/skills/validate-plugin.md
Outdated
Show resolved
Hide resolved
packages/create-plugin/templates/common/.config/AGENTS/skills/validate-plugin.md
Outdated
Show resolved
Hide resolved
packages/create-plugin/templates/common/.config/AGENTS/skills/validate-plugin.md
Show resolved
Hide resolved
packages/create-plugin/templates/common/.claude/skills/validate-plugin/SKILL.md
Show resolved
Hide resolved
packages/create-plugin/templates/common/.config/AGENTS/skills/validate-plugin.md
Outdated
Show resolved
Hide resolved
packages/create-plugin/templates/common/.config/AGENTS/skills/validate-plugin.md
Outdated
Show resolved
Hide resolved
packages/create-plugin/templates/common/.config/AGENTS/skills/validate-plugin.md
Outdated
Show resolved
Hide resolved
packages/create-plugin/templates/common/.config/AGENTS/skills/validate-plugin.md
Outdated
Show resolved
Hide resolved
|
|
||
| Always use the bash commands below directly. Do NOT use MCP tools for validation. | ||
|
|
||
| ## Usage |
There was a problem hiding this comment.
these are instructions for the LLM. not the user. are you telling the LLM to use /validate-plugin or the user?
There was a problem hiding this comment.
For the LLM, I am trying to compare like which is the better way to validate the plugin - through MCP or SKILLS. If we have an MCP registered with validated plugin in the description, it uses the MCP. So the above instruction is to directly use the CLI command.
|
|
||
| ## Steps | ||
|
|
||
| 1. Check if `npx` or `docker` is available. npx is preferred, docker is the fallback: |
There was a problem hiding this comment.
docker is prefered for the validator, not npx
There was a problem hiding this comment.
I see, when I ran from the Codex CLI or Claude code CLI npx runs way faster.
There was a problem hiding this comment.
that's because it is skipping the security checks (which are inside the docker image) that's why it runs faster. But that's actually a good point. the security checks are very important at submission not necessarily on a fast-dev environment
There was a problem hiding this comment.
Can we use the same runner as the plugin is scaffolded with?
There was a problem hiding this comment.
For running the validator? Wouldn't it be better to use npx or docker? Since it is standalone CLI tool not tied to the plugin's package manager? and if nodejs is installed which is a requirement for plugin development npx is present.
packages/create-plugin/templates/common/.config/AGENTS/skills/validate-plugin.md
Outdated
Show resolved
Hide resolved
mckn
left a comment
There was a problem hiding this comment.
Great work on this and I think this is a great start! I'm a bit concerned that we are duplicating information about e.g. how to build the plugin. If we make updates to how the plugin is built we now also need to update this skill.
One idea is that we introduce another skill that provides information about how to, by reading the plugin, understand how to build the plugin. Then we can reference that skill in this skill and only say that the plugin needs to be built before running the validation.
The benefit of doing it that way would be that we can simplify this skill and it will only focus on the steps for how to validate the plugin.
|
|
||
| ## Steps | ||
|
|
||
| 1. Check if `npx` or `docker` is available. npx is preferred, docker is the fallback: |
There was a problem hiding this comment.
Can we use the same runner as the plugin is scaffolded with?
|
|
||
| 3. Build the frontend following the build instructions in `.config/AGENTS/instructions.md`: | ||
| ```bash | ||
| npm run build |
There was a problem hiding this comment.
We should use the package manager that the plugin is scaffolded with.
| ``` | ||
| If the build fails, stop and report the error to the user. | ||
|
|
||
| 4. If `HAS_BACKEND` is non-zero (backend plugin detected), build the backend following the build instructions in `.config/AGENTS/instructions.md`: |
There was a problem hiding this comment.
Is it possible to introduce a skill that we can rely on regarding information about the plugin?
So provide a skill for how to detect what kind of plugin it and how it is built.
For running the validator, we don't need to use the plugin's package manager, right?
@mckn I totally agree with the package manager finding logic - but for build and other stuff, we are instructing the AI to read the AGENTS/instructions.md. Creating a skill to figure out what build is basically reading the instruction.md or reading the package.json - since skill can be invoked using From claude's doc -> skills are way to orchestrate a sequence of actions to achieve something. |
| ``` | ||
| If `RUN_ENGINE` is `none`, stop immediately and tell the user: "Neither npx nor docker is installed. Please install Node.js (for npx) or Docker to run the plugin validator." | ||
|
|
||
| 2. Find `src/plugin.json` (or `plugin.json`) in the plugin directory and extract the plugin ID and whether it has a backend. Sanitize `PLUGIN_ID` to only allow characters valid in a Grafana plugin ID: |
There was a problem hiding this comment.
Figure out, if the plugin has the backend for building purposes.
| HAS_BACKEND=$(grep -c '"backend" *: *true' src/plugin.json || true) | ||
| ``` | ||
|
|
||
| 3. Detect the package manager. Check the `packageManager` field in `package.json` first, then fall back to lock file detection: |
There was a problem hiding this comment.
For front-end building, running the build with same package manager that plugin is scaffolded.
156100e to
d177222
Compare
| ## Usage | ||
|
|
||
| ``` | ||
| /build-plugin |
There was a problem hiding this comment.
@mckn added separate skill for building the plugin.
- Figures out package manager using package.json
- Checks if it has a backend based on
backendprop of package.json - Build using instructions.md and
run buildand mage as fallbacks
9360b45 to
bf08111
Compare
xnyo
left a comment
There was a problem hiding this comment.
Just one small comment but the rest LGTM! Great job! 🙌
|
|
||
| ## Important | ||
|
|
||
| Always use the bash commands below directly. Do NOT use MCP tools for validation. |
There was a problem hiding this comment.
Does the agent already know it should use the MCP server if it's available?
There was a problem hiding this comment.
Yeah, it does, I was comparing the MCP vs Skills. But they are more of a complimentary to each other. Skills workflows, MCP specific single tool.
jackw
left a comment
There was a problem hiding this comment.
Approving to unblock (codeowners). Left a couple of comments.
| grep '"packageManager"' package.json | sed -E 's/.*"packageManager" *: *"([^@]+).*/\1/' | ||
| elif [ -f "pnpm-lock.yaml" ]; then | ||
| echo "pnpm" | ||
| elif [ -f "bun.lock" ] || [ -f "bun.lockb" ]; then |
There was a problem hiding this comment.
I would suggest removing this as we don't officially support bun.
| 5. Run the validator with JSON output using `$RUN_ENGINE` from step 1 and `$ZIP_NAME` from step 4: | ||
| If `$RUN_ENGINE` is `npx`: | ||
| ```bash | ||
| npx --cache .cache/npm -y @grafana/plugin-validator@latest -jsonOutput $ZIP_NAME |
There was a problem hiding this comment.
What's the need to set the --cache path?
There was a problem hiding this comment.
when running from codex it is using the ~/.cache for npx cache and permission denied error is returned, so we are setting it to use the plugins .cache folder.
What this PR does / why we need it:
PoC for https://github.com/grafana/grafana-catalog-team/issues/677
/build-pluginskillAdd skill to run
/validate-pluginfrom claude code and codex:dist/folder for validationEx(claude code):

/validate-pluginEx(codex):

$validate-pluginIf we have an MCP server registered for validating the plugin, the skills will use the MCP server tool to call the plugin-validator.