원클릭으로 Manus에서 모든 스킬 실행

validating-plugins

스타0

포크0

업데이트2026년 7월 2일 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.)

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

smithdak

smithdak/objectcore

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

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.

이 저장소의 다른 Skills

같은 저장소

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.