plan-ui-change

Plans Blazor UI features by decomposing pages into focused composable components.

Updated Jul 20, 2026
One-click install
npx skills add https://github.com/Netcodr81/kinetic-reports --skill plan-ui-change-netcodr81
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: plan-ui-change
Source: https://github.com/Netcodr81/kinetic-reports/tree/main/.github/skills/plan-ui-change
Command: npx skills add https://github.com/Netcodr81/kinetic-reports --skill plan-ui-change-netcodr81

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Complex Blazor pages often become monolithic components with hundreds of lines of markup that are impossible to test, reuse, or maintain. This Skill guides the decomposition of large UI features into focused components with clear data flow before any code is written. ## Core Features & Use Cases - Component Decomposition Planning: Maps visual regions into a component tree, classifies each component by responsibility, render mode, and estimated size. - Data Flow Design: Defines state ownership and maps parameter-down, EventCallback-up data flow between parent and child components. - Bottom-Up Implementation Ordering: Sequences implementation from models and services through leaf components to the page component. - Use Case: When asked to build an inventory dashboard with a summary bar, filters, a sortable table, and an add-product form, the Skill produces a component tree, a data flow map, and an ordered implementation plan, then immediately builds each .razor file. ## Quick Start Ask the AI to plan and build a multi-section Blazor dashboard page with filters, a data table, and a form using this Skill.

Frequently Asked Questions about plan-ui-change

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I break down a complex Blazor page into components?▼

Identify each distinct visual region with its own data, behavior, or layout responsibility as a candidate component. Draw a component tree, classify each component by state ownership and estimated size, then build leaf components first before composing parents.

How should data flow between Blazor parent and child components?▼

Data flows down through [Parameter] attributes and events flow up through EventCallback<T>. The page or parent component owns the data and passes filtered views to children, which never mutate parameters directly.

When should I split a Blazor component into smaller components?▼

Split when a section has distinct responsibility, repeated structure, independent interactivity, or exceeds roughly 150 lines of markup. A page component over about 200 lines of combined markup and code is too large.

When should I not use component decomposition planning?▼

Skip this approach for simple single-component pages, creating new Blazor projects from scratch, or implementing one individual component with parameters and EventCallbacks. It targets pages with three or more distinct visual sections.

How do I avoid parameter drilling in Blazor component trees?▼

Avoid passing many parameters through intermediate components by using cascading values or a scoped state service when data must cross more than two levels. Keep direct parameters only for immediate parent-child communication.