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

$pwd:

core-add-module

Name: Core Add Module
Author: umbraco

// Add a new module to the core package (src/packages/core/). Use when adding shared UI framework infrastructure that all packages can use — e.g., a new extension system feature, a new utility, a new shared component pattern, a new picker, or a new workspace primitive. Core modules are imported as @umbraco-cms/backoffice/{module-name}. Also use when the user says things like "add a module to core", "create a new core feature", or "add shared infrastructure".

Manus에서 실행

$ git log --oneline --stat

stars:5,196

forks:2,880

updated:2026년 3월 27일 11:35

SKILL.md

readonly

name	core-add-module
description	Add a new module to the core package (src/packages/core/). Use when adding shared UI framework infrastructure that all packages can use — e.g., a new extension system feature, a new utility, a new shared component pattern, a new picker, or a new workspace primitive. Core modules are imported as @umbraco-cms/backoffice/{module-name}. Also use when the user says things like "add a module to core", "create a new core feature", or "add shared infrastructure".
allowed-tools	Read, Write, Edit, Grep, Glob

Add Core Module

Add a new module to the core package (src/packages/core/).

Naming conventions

Module names are singular (e.g., picker, sorter, entity-flag, modal, section)

What you need from the user

Module name — What to call it in singular form (kebab-case, e.g., picker, sorter, entity-flag)
Purpose — What shared infrastructure this provides

When to add to core vs. create a new package

Core module: Shared UI framework infrastructure used by multiple packages — extension primitives, pickers, validation, repository base classes, workspace utilities.
New package: Domain-specific CMS features (documents, media, webhook). Use the create-package skill instead.

Core modules should not implement CMS-specific features. They provide the building blocks that CMS feature packages use.

Files to create

src/packages/core/{module-name}/
├── index.ts                   # Public API exports
├── manifests.ts               # Extension registrations (if any)
├── constants.ts               # Module constants
└── types.ts                   # Module types

Step 1: Create the module directory and files

{module-name}/index.ts

The public API. Only export what other packages need:

export * from './constants.js';
export type * from './types.js';

Use export type * for type-only exports.

{module-name}/manifests.ts

Extension registrations for this module:

export const manifests: Array<UmbExtensionManifest> = [
	// Extension registrations
];

If the module has no extensions (pure utility), export an empty array.

{module-name}/constants.ts

// Aliases, context tokens, entity types

{module-name}/types.ts

// Type definitions, interfaces, meta types

Step 2: Wire into core's manifests.ts

Add the module's manifests to src/packages/core/manifests.ts:

import { manifests as {moduleName}Manifests } from './{module-name}/manifests.js';

// In the manifests array:
...{moduleName}Manifests,

The imports are in alphabetical order — insert in the right position.

Step 3: Add entry point to core's vite.config.ts

Add the module to the entry object in src/packages/core/vite.config.ts:

'{module-name}/index': './{module-name}/index.ts',

The entries are in alphabetical order — insert in the right position. This tells Vite to build the module as a separate entry point.

Step 4: Register the subpath export

Add to the exports field in the root package.json (src/Umbraco.Web.UI.Client/package.json):

"./{module-name}": "./dist-cms/packages/core/{module-name}/index.js"

This enables imports like @umbraco-cms/backoffice/{module-name}.

Step 5: Regenerate TypeScript config

npm run generate:tsconfig

This updates tsconfig.json paths so the new module resolves correctly in TypeScript.

How consumers import

After registration, other packages import from the module like:

import { MyThing } from '@umbraco-cms/backoffice/{module-name}';
import type { MyType } from '@umbraco-cms/backoffice/{module-name}';

Reference: existing core modules to study

Simple utility: src/packages/core/culture/ — repository + components, minimal surface
Extension primitive: src/packages/core/entity-action/ — kinds, base classes, shared element
Infrastructure: src/packages/core/repository/ — base classes for the data access pattern

Checklist

Module directory created under src/packages/core/
index.ts exports only the public API
manifests.ts exports extension registrations (or empty array)
constants.ts and types.ts created
Module manifests imported in src/packages/core/manifests.ts (alphabetical order)
Entry point added to src/packages/core/vite.config.ts (alphabetical order)
Subpath export added to root package.json
npm run generate:tsconfig executed
Compiles: npm run compile

related-skills.json

같은 저장소

umb-bump-version.md

from "umbraco/Umbraco-CMS"

Bump the Umbraco CMS version across all required files. Use when the user asks to bump, update, or set the version number — e.g., "bump version to 17.3.4", "set version to 18.0.0-rc", "update version". Accepts the target version as an argument.

2026-05-065.2k

general-add-value-summary.md

from "umbraco/Umbraco-CMS"

Add a value summary extension so a feature's typed value can be displayed compactly in collection views (e.g., table columns). Use when a feature or property editor already has a value type and needs a renderer for collection table cells. Two variants — simple (element only, no API call) and resolver (batch API resolution needed). Prerequisite: a value type constant must already exist — use the general-add-value-type skill first if it doesn't.

2026-05-065.2k

general-add-value-type.md

from "umbraco/Umbraco-CMS"

Add a new value type — a named, typed string constant that extends UmbValueTypeMap. Use when a feature needs to declare what type of value it holds so it can be referenced in collection columns or value summary manifests. Also use when a property editor needs to expose its value type for use in collection views.

2026-05-065.2k

general-create-repository.md

from "umbraco/Umbraco-CMS"

Create or extend a repository in the Umbraco backoffice. Covers detail (CRUD), item (batch lookup), collection (paginated list), and action-specific (publish, duplicate, move, etc.) repositories. Use when the user says "create a repository", "add a data source", or when a feature needs to fetch or post data. Each repository type has its own template — pick the right one based on the operation.

2026-04-145.2k

umb-review.md

from "umbraco/Umbraco-CMS"

Automated PR code review for Umbraco CMS. Analyzes changed files for intent, impact on consumers, breaking changes, architecture compliance, and code quality. Non-interactive — outputs a full structured review. Use this skill whenever the user asks to review a branch, review a PR, check their changes for issues, analyze a diff, or validate breaking change patterns — even if they don't say "review" explicitly. Does NOT apply to writing new code, fixing bugs, refactoring, explaining architecture, writing tests, or reviewing documentation content.

2026-04-015.2k

general-create-package.md

from "umbraco/Umbraco-CMS"

Create a new package in the Umbraco backoffice client with its first module. Use when adding a new domain feature area that needs its own package under src/packages/ — e.g., a new CMS feature like data types, tags, or relations. Packages are self-contained domain modules that can theoretically be uninstalled independently. Also use when the user says things like "scaffold a new package", "add a new feature package", or "create a new domain module".

2026-03-315.2k

package.json

"author": "umbraco"

"repository": "umbraco/Umbraco-CMS"

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

$ install --global

$ download --local

Manus에서 실행

$ useful --forSOC

소프트웨어 개발자컴퓨터 및 수학직15-1252L4

name	core-add-module
description	Add a new module to the core package (src/packages/core/). Use when adding shared UI framework infrastructure that all packages can use — e.g., a new extension system feature, a new utility, a new shared component pattern, a new picker, or a new workspace primitive. Core modules are imported as @umbraco-cms/backoffice/{module-name}. Also use when the user says things like "add a module to core", "create a new core feature", or "add shared infrastructure".
allowed-tools	Read, Write, Edit, Grep, Glob

Add Core Module

Add a new module to the core package (src/packages/core/).

Naming conventions

Module names are singular (e.g., picker, sorter, entity-flag, modal, section)

What you need from the user

Module name — What to call it in singular form (kebab-case, e.g., picker, sorter, entity-flag)
Purpose — What shared infrastructure this provides

When to add to core vs. create a new package

Core module: Shared UI framework infrastructure used by multiple packages — extension primitives, pickers, validation, repository base classes, workspace utilities.
New package: Domain-specific CMS features (documents, media, webhook). Use the create-package skill instead.

Core modules should not implement CMS-specific features. They provide the building blocks that CMS feature packages use.

Files to create

src/packages/core/{module-name}/
├── index.ts                   # Public API exports
├── manifests.ts               # Extension registrations (if any)
├── constants.ts               # Module constants
└── types.ts                   # Module types

Step 1: Create the module directory and files

{module-name}/index.ts

The public API. Only export what other packages need:

export * from './constants.js';
export type * from './types.js';

Use export type * for type-only exports.

{module-name}/manifests.ts

Extension registrations for this module:

export const manifests: Array<UmbExtensionManifest> = [
	// Extension registrations
];

If the module has no extensions (pure utility), export an empty array.

{module-name}/constants.ts

// Aliases, context tokens, entity types

{module-name}/types.ts

// Type definitions, interfaces, meta types

Step 2: Wire into core's manifests.ts

Add the module's manifests to src/packages/core/manifests.ts:

import { manifests as {moduleName}Manifests } from './{module-name}/manifests.js';

// In the manifests array:
...{moduleName}Manifests,

The imports are in alphabetical order — insert in the right position.

Step 3: Add entry point to core's vite.config.ts

Add the module to the entry object in src/packages/core/vite.config.ts:

'{module-name}/index': './{module-name}/index.ts',

The entries are in alphabetical order — insert in the right position. This tells Vite to build the module as a separate entry point.

Step 4: Register the subpath export

Add to the exports field in the root package.json (src/Umbraco.Web.UI.Client/package.json):

"./{module-name}": "./dist-cms/packages/core/{module-name}/index.js"

This enables imports like @umbraco-cms/backoffice/{module-name}.

Step 5: Regenerate TypeScript config

npm run generate:tsconfig

This updates tsconfig.json paths so the new module resolves correctly in TypeScript.

How consumers import

After registration, other packages import from the module like:

import { MyThing } from '@umbraco-cms/backoffice/{module-name}';
import type { MyType } from '@umbraco-cms/backoffice/{module-name}';

Reference: existing core modules to study

Simple utility: src/packages/core/culture/ — repository + components, minimal surface
Extension primitive: src/packages/core/entity-action/ — kinds, base classes, shared element
Infrastructure: src/packages/core/repository/ — base classes for the data access pattern

Checklist

Module directory created under src/packages/core/
index.ts exports only the public API
manifests.ts exports extension registrations (or empty array)
constants.ts and types.ts created
Module manifests imported in src/packages/core/manifests.ts (alphabetical order)
Entry point added to src/packages/core/vite.config.ts (alphabetical order)
Subpath export added to root package.json
npm run generate:tsconfig executed
Compiles: npm run compile

core-add-module

Add Core Module

Naming conventions

What you need from the user

When to add to core vs. create a new package

Files to create

Step 1: Create the module directory and files

{module-name}/index.ts

{module-name}/manifests.ts

{module-name}/constants.ts

{module-name}/types.ts

Step 2: Wire into core's manifests.ts

Step 3: Add entry point to core's vite.config.ts

Step 4: Register the subpath export

Step 5: Regenerate TypeScript config

How consumers import

Reference: existing core modules to study

Checklist

이 저장소의 다른 Skills

Add Core Module

Naming conventions

What you need from the user

When to add to core vs. create a new package

Files to create

Step 1: Create the module directory and files

{module-name}/index.ts

{module-name}/manifests.ts

{module-name}/constants.ts

{module-name}/types.ts

Step 2: Wire into core's manifests.ts

Step 3: Add entry point to core's vite.config.ts

Step 4: Register the subpath export

Step 5: Regenerate TypeScript config

How consumers import

Reference: existing core modules to study

Checklist

이 저장소의 다른 Skills