Run any Skill in Manus with one click

validating-plugins

Stars0

Forks0

UpdatedJuly 2, 2026 at 11:06

The reference for what makes an ObjectCore plugin valid — the hard load-error rules (manifest shape, kebab-case, component placement) and the eval-coverage gate. Use when a plugin fails to load or validate, when reviewing a plugin before it enters the catalog, or when diagnosing which hard rule a plugin manifest breaks. (A stale or drifted marketplace.json is building-the-catalog's territory.)

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

smithdak

smithdak/objectcore

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	validating-plugins
description	The reference for what makes an ObjectCore plugin valid — the hard load-error rules (manifest shape, kebab-case, component placement) and the eval-coverage gate. Use when a plugin fails to load or validate, when reviewing a plugin before it enters the catalog, or when diagnosing which hard rule a plugin manifest breaks. (A stale or drifted marketplace.json is building-the-catalog's territory.)

Validating plugins (the rule reference)

Validation proves a plugin loads and is gated; it is the floor the eval gate sits on. The rules below are enforced by registry-core (validateAll) and the eval harness — /validate runs them.

Hard load errors (Claude Code rejects the plugin)

name is kebab-case, required, and unique in the catalog.
repository is a string, never an object.
keywords is an array, never a string.
Components live at the plugin root — commands/, agents/, skills/, hooks/. .claude-plugin/ holds only plugin.json.
Marketplace name is kebab-case and not on Anthropic's reserved list.

Catalog invariants (the seam)

marketplace.json is a build artifact — derived by deriveCatalog, never hand-edited. Every plugin dir maps to exactly one catalog entry and vice-versa (no stale, no duplicate, no orphan).
After changing a plugin, re-derive with bun run build:marketplace; bun run check:catalog fails if the committed file drifts.

Gate invariants (beyond loading)

Every catalog entry has a description (output eval) — an entry with none is invisible in /plugin.
Every skill has a positive activation case (coverage eval) — a skill with no case targeting it would enter the catalog ungated.
Every activation case routes correctly (activation eval) — positives fire the intended skill; negatives, including confusability negatives, fire nothing.

Order of operations

Structural validation (does it load?) → coverage (is every skill gated?) → activation (do the skills actually fire?). A plugin is catalog-ready only when all three are green.

More from this repository

same repository

choosing-a-seeded-theme

smithdak/objectcore

Pick a READY-MADE seeded design theme instead of authoring one — the curated preset inventory (inkwell = quiet, editorial, warm paper; cathode = loud, technical, emissive) and when a preset beats a custom grill. Use when the user wants a quick-start design system, an off-the-shelf look, or asks which seeded preset/theme to pick — NOT for defining custom brand foundations from scratch (that is defining-design-tokens) and NOT for adding modes to existing tokens (that is theming-with-tokens).

2026-07-020

defining-design-tokens

smithdak/objectcore

The grilling gate for AUTHORING a new design system or token set — turn a vague brand into a decided DTCG design-token spec before any scaffolding. Use at the start of /design, when brand direction (color, type, spacing, motion) is still fuzzy, or when deciding the token foundations and tiers. For a ready-made starting point instead of a custom grill, use choosing-a-seeded-theme.

2026-07-020

curating-knowledge

smithdak/objectcore

Add or curate an entry in ObjectCore's factory knowledge base (a lesson, pattern, gotcha, or decision) stored under knowledge/. Use when a durable, reusable engineering lesson emerges, a design decision is made, or the knowledge base needs pruning.

2026-07-020

building-the-catalog

smithdak/objectcore

Reference for how the ObjectCore marketplace catalog is derived — the deriveCatalog seam, the source/sink ports, and the sync invariant. Use when changing how marketplace.json is produced, when marketplace.json is stale, drifted, or out of sync with the plugin dirs, or when reasoning about the Git/DB source swap. (A plugin failing the manifest rules is validating-plugins' territory.)

2026-07-020

design-foundations

smithdak/objectcore

The reference for CONSUMING a token-based design system so UI stays on-brand — pick the semantic token by ROLE, never a raw hex or scale step. Use when building, styling, or reviewing a component, page, or any visual output that must match the design system (choosing colors, spacing, type, radius, or motion).

2026-06-270

theming-with-tokens

smithdak/objectcore

How to add dark mode or multi-brand theming to a token-based design system the RIGHT way — multiple token sets combined by a resolver with semantic aliases re-pointed per theme, never duplicated components. Use when adding a color mode, a second brand, or any theme axis over existing design tokens.

2026-06-270

name	validating-plugins
description	The reference for what makes an ObjectCore plugin valid — the hard load-error rules (manifest shape, kebab-case, component placement) and the eval-coverage gate. Use when a plugin fails to load or validate, when reviewing a plugin before it enters the catalog, or when diagnosing which hard rule a plugin manifest breaks. (A stale or drifted marketplace.json is building-the-catalog's territory.)

Validating plugins (the rule reference)

Hard load errors (Claude Code rejects the plugin)

name is kebab-case, required, and unique in the catalog.
repository is a string, never an object.
keywords is an array, never a string.
Components live at the plugin root — commands/, agents/, skills/, hooks/. .claude-plugin/ holds only plugin.json.
Marketplace name is kebab-case and not on Anthropic's reserved list.

Catalog invariants (the seam)

marketplace.json is a build artifact — derived by deriveCatalog, never hand-edited. Every plugin dir maps to exactly one catalog entry and vice-versa (no stale, no duplicate, no orphan).
After changing a plugin, re-derive with bun run build:marketplace; bun run check:catalog fails if the committed file drifts.

Gate invariants (beyond loading)

Every catalog entry has a description (output eval) — an entry with none is invisible in /plugin.
Every skill has a positive activation case (coverage eval) — a skill with no case targeting it would enter the catalog ungated.
Every activation case routes correctly (activation eval) — positives fire the intended skill; negatives, including confusability negatives, fire nothing.

Order of operations

Structural validation (does it load?) → coverage (is every skill gated?) → activation (do the skills actually fire?). A plugin is catalog-ready only when all three are green.