plan-ui-change

Plan and implement Blazor UI features by decomposing pages into focused components.

Updated Jul 2, 2026
One-click install
npx skills add https://github.com/ecoDriverltd/FoundryAgentsExperiment --skill plan-ui-change-ecodriverltd
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: plan-ui-change
Source: https://github.com/ecoDriverltd/FoundryAgentsExperiment/tree/main/.agents/skills/plan-ui-change
Command: npx skills add https://github.com/ecoDriverltd/FoundryAgentsExperiment --skill plan-ui-change-ecodriverltd

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Complex Blazor pages often grow into monolithic components that are hard to test, reuse, and maintain. This Skill guides the decomposition of multi-section UI features into small, composable components with clear state ownership and data flow, then implements them. ## 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, parameter flow downward, and EventCallback flow upward, with guidance on cascading values and scoped services. - Bottom-Up Implementation Order: Builds models, services, leaf components, containers, and finally the page component so every file compiles independently. - 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 and data flow map, then immediately creates each .razor file in dependency order. ## Quick Start Ask the agent to build a complex Blazor page such as a dashboard with filters, a data table, and a form, and it will plan the component decomposition and implement it.

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 a large Blazor page into components?▼

Identify each visual region with its own data, behavior, or layout responsibility and make it a separate component. Extract repeated list items, split sections exceeding roughly 150 lines of markup, and keep any single page component under about 200 lines of combined markup and code.

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

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

When should I use cascading values or scoped services in Blazor?▼

Use a cascading value or scoped service when data must cross more than two component levels without intermediate components needing it. This avoids parameter drilling, where ten or more parameters are passed through intermediaries and obscure intent.

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 EventCallback. It targets pages with three or more distinct visual sections or multiple interacting sub-features.

What order should Blazor components be implemented in?▼

Build bottom-up: models and DTOs first, then services, leaf components, container components, the page component, and finally DI configuration. Each component stays independently compilable and never references a component that does not exist yet.