Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

validating-plugins

Étoiles0

Forks0

Mis à jour2 juillet 2026 à 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

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

smithdak

smithdak/objectcore

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·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.

Plus depuis ce dépôt

même dépôt

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.