Review Process

Every contribution — a new plugin, an added artifact, an edit — goes through review before it merges. Submissions move from issue to PR automatically via the issue-to-PR pipeline; review happens on the PR.

This page is the maintainer’s checklist. If you’re contributing, knowing what reviewers look for helps you ship cleanly the first time.

Pre-merge gate

Before any human review, every PR runs the build workflow in .github/workflows/validate.yml:

astro sync — runs the Zod schemas in src/content.config.ts to verify the plugin bundle’s frontmatter, plugin.json, and rba-meta.json are well-formed.
npm run build — confirms the catalog still renders. A broken rba-meta.json enum, a missing required file, or a malformed SKILL.md frontmatter will fail the build.
scripts/validate-bundles.mjs — enforces the bundle structure rules in CLAUDE.md: SKILL.md ≤ 500 lines, no blanket Bash permissions, skill folder name matches frontmatter name, no product artifacts hiding in .claude/, required files present.

A red workflow means the contribution isn’t ready — the bot leaves a comment with the error, and the contributor edits the issue to retry. Don’t manually fix red builds on behalf of the contributor unless the issue is genuinely a bot bug.

Plugin bundle review

A new plugin must ship as a complete bundle. Verify:

plugins/<slug>/.claude-plugin/plugin.json exists with name, version, description, and author. No RBA-custom fields in this file.
plugins/<slug>/rba-meta.json exists with at least one populated facet (platforms, disciplines, lifecycle, tags, or outcomes), or primitive: true for cross-cutting foundation primitives.
rba-meta.json includes useful values for whichever facets apply. These power filtering on /search/ and /skills/browse/ — an empty rba-meta.json means the plugin is hard to discover.
README.md renders as the plugin’s detail page. It should cover what’s in the bundle, when to use it, and how to install it.
At least one artifact is present (skills/, agents/, commands/, hooks/hooks.json, .mcp.json, or resources/). No half-bundles.
Plugin slug is kebab-case and matches the directory name and plugin.json name.

Plugins describe themselves with multiple optional facets rather than picking one tier. Question the facets if they feel incomplete or off:

Facet	Populate when…
`platforms[]`	Only useful when working in that vendor’s stack
`disciplines[]`	Specific to how one discipline does its job
`outcomes[]`	Success is defined by an outward deliverable (`seo`, `performance`, `accessibility-audit`)
`lifecycle[]`	Tied to one or more project phases (`plan`, `build`, `test-and-review`, `operate`)
`primitive: true`	Anyone at RBA could use it, regardless of role/platform/outcome — a cross-cutting primitive

A “Sitecore content-modeling skill for a BA” sets both platforms: ["sitecore"] and disciplines: ["strategy"] so it surfaces in both filters. Plugins are no longer forced into a single bucket — populate every facet that genuinely applies.

Skill review (`plugins/<plugin>/skills/<skill>/SKILL.md`)

Frontmatter has name (kebab-case, matching folder name) and description (one sentence).
argument-hint is present if the skill is typically invoked with arguments.
allowed-tools follows least-privilege. Never bare Bash. Use Bash(specific-command *) patterns. Prefer domain-scoped WebFetch(domain:example.com) over bare WebFetch.
SKILL.md is under 500 lines. Depth lives in sibling files (examples.md, reference.md, templates.md) in the same folder. The validator enforces this.
Persona is domain-specific — not “helpful assistant”. The skill should think like the role it serves.
Methodology phases explain both the what and the why.
Output format is an explicit template, not vague guidance.
Optional facet fields (platforms, disciplines, lifecycle, tags) are arrays of strings if declared, and only declared when they genuinely differ from the plugin’s rba-meta.json defaults.
You ran the skill in a Claude Code session and the output was useful.

The canonical working example is plugins/research/skills/research/SKILL.md. The full authoring standards live at /contributing/standards/skills/.

Other artifact review

Agents (plugins/<plugin>/agents/<name>.md):

Frontmatter has name, description, and tools (the agent’s allowlist).
System prompt is scoped to a discrete kind of work — review, audit, research — not “general helper”.
Tool allowlist follows least-privilege.

MCP servers (plugins/<plugin>/.mcp.json):

Server entry has command, args, and env documented in the plugin README.
Default config is deny-and-scope — users opt in to specific permissions per project.
Plugin README documents the secrets/credentials the server needs and where they should live.

Hooks (plugins/<plugin>/hooks/hooks.json):

Hook fires on the right lifecycle event (PreToolUse, PostToolUse, Stop, etc.).
Failure mode is loud — exit non-zero with a clear message rather than silently mutating state.
Plugin README explains what the hook guarantees and what triggers it.

Slash commands (plugins/<plugin>/commands/<name>.md):

Frontmatter has description. Optionally argument-hint, allowed-tools.
Justification for not being a skill: the workflow is strictly user-triggered, no auto-discovery wanted.

Resources (plugins/<plugin>/resources/<name>.md):

The resource is self-contained — a reader can use it without external setup.
Resource type (skeleton, template, reference architecture, runbook) is clear from the page.

Reviewer roles

Any RBA team member can review. Best results come from getting both:

Domain expert — Someone who does this kind of work and can judge whether the output is genuinely useful in practice.
Different role — Someone outside the target discipline who can test whether the methodology is clear to non-experts.

For platform plugins, get a reviewer who has shipped on that platform. For outcome plugins, get someone who has owned that deliverable. For role plugins, get a practitioner in that role.

Versioning

Plugins evolve as patterns get sharper:

Minor changes (wording tweaks, additional examples, new tags) — one reviewer is enough. Bump the version in plugin.json if the artifact’s behavior changes.
Major changes (new variables, restructured methodology, behavior-altering frontmatter changes) — at least two reviewers. Note the breaking change in the PR description and increment the major version.
New plugins — at least one reviewer who works in the target facet/domain (matching platforms, disciplines, or outcomes). PR description should state which existing plugins this overlaps with and why this one is justified.

When updating an existing artifact, the PR description should answer: what’s different, why, and what existing usage might break.