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).

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.

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.

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.)

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.)

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).

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.

Turn a pinned plugin spec into a concrete PluginSpec the scaffolder can emit — choosing components, drafting each skill's trigger surface, and writing the activation eval cases. Use after specifying, when converting a spec into the JSON for bun run forge:scaffold.

Draft a pull-request title and description that summarize the commits on a branch relative to its base branch. Use when the user is opening a pull request, asks for a PR description or title, or wants a branch summarized for reviewers.

Draft a clear, conventional-commits-style git commit message that summarizes the staged diff. Use when the user is about to commit, asks for a commit message, or wants their commit wording improved.

The grilling gate for plugin-forge — turn a vague plugin request into a pinned spec before any planning or scaffolding. Use at the start of /forge, when a generation request is underspecified, or when the scope of a plugin keeps shifting.

Reference for the vocabulary and principles that make a skill predictable — the spec plugin-forge writes against. Use when authoring or reviewing a skill's metadata, body, or reference layers.

Reference for how ObjectCore releases plugins — the Changesets-driven version -> tag {plugin}--v{semver} -> SHA-pin -> attest flow, and the provenance rule for MCP-bundling plugins. Use when cutting a release, adding a changeset, bumping a plugin version, debugging the release CI, or reasoning about pinned catalog (git-subdir) sources.

Reference for the two ObjectCore meta-plugin archetypes — generator and governance — and the meta-spec the engine expands. Use when designing a new meta-plugin, choosing its archetype, or deciding whether something should be a meta-plugin at all.