manage-components

name	manage-components
description	Create or update a Kendo UI component across kendo-themes packages. For new components, scaffolds core skeleton with null variables, theme overrides for targeted themes, HTML spec, templates, visual tests, and unit tests. For existing components, audits the current state, produces a change plan, and applies SCSS variable changes, layout/theme updates, HTML spec modifications, and test additions. Use this skill when the user wants to add a new component, update a component's design, change styling values, add new states or options, or align a component with design assets.
argument-hint	[component-name] e.g. chip, button, info-bar
metadata	{"internal":true}

Component

Create or update a Kendo UI component across the monorepo.

Read ../_shared/component-context.md for naming conventions, theme paths, and common gotchas.

When to use

• New component — "add an InfoBar component", "create SCSS and HTML for a Rating"
• Update component — "update the chip based on this design", "change button padding", "add a warning state to badge"
• Partial update — "just update the chip variables in default and fluent"

For individual sub-tasks without the full orchestration, use the sub-skills directly: scss-variables, scss-styles, html-spec, html-template, html-test, html-a11y.

Inputs

Input	Required	Description
Component name	Yes	kebab-case (e.g., chip, info-bar, smart-badge)
Operation	No	create or update. Inferred from whether the component exists.
Target themes	No	all or a list like default, fluent. Default: all for new, ask for updates.
Assets / design reference	For updates	Figma link, image, design tokens, or text description of changes
Description	For new	One sentence describing what the component does
Dependencies	No	Other components this depends on (e.g., icon, button)
HTML element	No	Root HTML element (div, span, button, nav). Default: div
Has size	No	Whether component supports sm/md/lg sizes. Default: true
Has theme color	No	Whether component supports theme colors. Default: false
Key variables	No	e.g., bg, text, border, padding, font-size
States	No	e.g., hover, focus, active, disabled, selected
Options	No	e.g., size, fillMode, themeColor, rounded
Scope	No	For updates: variables, layout, theme, html, tests, or all. Default: all

Procedure — New Component

Step 1: Derive naming constants

Use the naming derivation table from ../_shared/component-context.md.

Step 2: Research a reference component

Find an existing component of similar complexity in packages/core/scss/components/. See reference component guidance in ../_shared/component-context.md.

If the user doesn't specify variables/states/options, use reasonable defaults based on the reference.

Step 3: Create SCSS variables

Use the manage-scss-variables skill to create variables in core (null !default) and all targeted themes (concrete values + @forward maps).

Step 4: Create SCSS styles, module, and register

Use the manage-scss-styles skill to:

• Create layout and theme mixins in core and targeted themes
• Create _index.scss in each targeted theme
• Register the component in each theme's index.scss

Step 5: Create HTML spec

Use the manage-html-specs skill to create constants.ts, {component}.spec.tsx, and index.ts.

Step 6: Create HTML templates

Use the manage-html-templates skill to create at least one default template.

Step 7: Create visual tests

Use the manage-html-tests skill to create test files covering default, states, sizes, and fill modes as applicable.

Step 8: Create unit test

Create units/default/{component}.test.ts using the template from ../_shared/file-templates.md.

Step 9: Validate

Run the validation steps from ../_shared/component-context.md.

Procedure — Update Component

Step 1: Derive naming constants

Use the naming derivation table from ../_shared/component-context.md.

Step 2: Audit the current state

Read and catalog the component's current implementation across all targeted packages:

File	Path	Purpose
Core variables	packages/core/scss/components/{component}/_variables.scss	Null declarations — source of truth
Core layout	packages/core/scss/components/{component}/_layout.scss	Structural mixin
Core theme	packages/core/scss/components/{component}/_theme.scss	Visual mixin
Theme variables	packages/{theme}/scss/{component}/_variables.scss	Concrete values + @forward map
Theme layout/theme	packages/{theme}/scss/{component}/_layout.scss, _theme.scss	Theme-specific overrides
Theme index	packages/{theme}/scss/{component}/_index.scss	Entry point and dependencies
HTML spec	packages/html/src/{component}/{component}.spec.tsx	States, options, render function
HTML templates	packages/html/src/{component}/templates/*.tsx	Template variants
HTML tests	packages/html/src/{component}/tests/*.tsx	Visual test scenarios

Extract: variable inventory, states, options, CSS classes, dependencies.

Step 3: Analyze design assets and produce change plan

Compare assets against current state. Categorize each change:

Change type	Example	Affected files
New variable	Add $kendo-chip-gap	Core + theme _variables.scss, @forward map
Value change	padding k-spacing(2) → k-spacing(3)	Theme _variables.scss only
New state	Add selected	Core _theme.scss, HTML spec, test file
New option	Add size: 'xlarge'	Core + theme _variables.scss, HTML spec, test file
Layout change	inline-flex → flex	Core _layout.scss
Visual change	Add box-shadow on focus	Core _theme.scss, theme variables
HTML structure	Add wrapper element	HTML spec, templates, tests

Step 4: Present the change plan

Present the plan and wait for user confirmation before editing:

## Change Plan: {component}
### Target themes: {theme list}
### Changes:
1. **[Type]** — {description}
   - Files: {list}
   - Details: {edits}
### Summary: Variables +N/~N/-N, Files modified N, Files created N

Step 5: Apply variable changes

Use the manage-scss-variables skill. Follow the checklist in references/update-checklist.md.

Step 6: Apply style and module changes

Use the manage-scss-styles skill for layout, theme, and _index.scss changes.

Step 7: Apply HTML spec changes

Use the manage-html-specs skill for structure, state, or option changes.

Step 8: Update or add templates

Use the manage-html-templates skill for new or modified template variants.

Step 9: Update or add visual tests

Use the manage-html-tests skill to ensure coverage for every visible change.

Step 10: Validate

Run the validation steps from ../_shared/component-context.md.

Step 11: Report

Metric	Count
Themes updated	N
Variables added / changed / removed	N / N / N
Core files modified	N
Theme files modified	N
HTML files modified	N
Test files added/modified	N
SCSS compilation	PASS/FAIL
TypeScript check	PASS/FAIL

Gotchas

See shared gotchas in ../_shared/component-context.md. Additionally:

• New components: register the component in packages/{theme}/scss/index.scss, preserving existing dependency/import order (do not alphabetize). packages/{theme}/scss/all.scss is just a wrapper. When target themes is not all, always create core and HTML files regardless.
• Updates — audit first: never assume the current state. Read the files first; components vary in complexity.
• Don't touch themes the user didn't ask for — if they said "update default and fluent", leave the rest alone.
• Preserve existing variable order — add new variables near related ones.
• Check calc/derived variables — some variables depend on others. Changing a base may require updating derived ones.
• HTML spec changes cascade — changing the render function affects all templates and tests.
• Don't remove variables without deprecation — confirm breaking change with user first.