Official agent skill

Plan UI Change

by dotnet in dotnet/skills

Plan complex Blazor UI features by decomposing them into focused components.

OfficialMITAuto-check: warnings

Install Plan UI Change

The automated check flagged lines worth reading first. See the safety section below.

skills CLI
$ npx skills add dotnet/skills --skill plan-ui-change -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install dotnet/skills plan-ui-change --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/dotnet/skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/plugins/dotnet-blazor/skills/plan-ui-change .claude/skills/plan-ui-change && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
plan-ui-change
GitHub stars
5.6k
Used in
1 other repo
Token cost
~1.9k tokens
SKILL.md length
724 words
Files
1
Skills in repo
91
Repo updated
First seen
Licence
MIT

At a glance

Plan complex Blazor UI features by decomposing them into focused components.

  • Works in 5 steps: Map the Visual Regions → Classify Each Component → Design Data Flow → …
  • : building a complex Blazor page with multiple sections
  • SKILL.md covers Planning Workflow, Output Format, Anti-Patterns to Avoid and Guidelines
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Plan UI Change is an agent skill from dotnet/skills, published by the product's own GitHub organization. Plan complex Blazor UI features by decomposing them into focused components. USE FOR: building a complex Blazor page with multiple sections, planning component decomposition, designing a multi-section dashboard or layout, breaking down a large UI feature into composable components, pages with sidebars and content panels, any page with 3+ distinct visual sections or multiple interacting sub-features, identifying parent-child relationships and data flow. DO NOT USE FOR: creating new Blazor projects or apps from…

Its SKILL.md is about 1.9k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It works with Blazor. The repository describes itself as: Repository for skills to assist AI coding agents with .NET and C. The licence is MIT.

When your agent uses it

  • : building a complex Blazor page with multiple sections
  • Planning component decomposition
  • Designing a multi-section dashboard
  • Breaking down a large UI feature into composable components

Example prompts

  • “/plan-ui-change”

Workflow steps

5 steps, taken from the step headings in SKILL.md.

  1. Map the Visual Regions
  2. Classify Each Component
  3. Design Data Flow
  4. Identify Reuse Opportunities
  5. Order the Implementation

What it can do on your machine

Read from SKILL.md and the folder at commit 8d670fa. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are markdown).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Plan UI Change loads about 1.9k tokens when it runs. Until then it costs about 187 tokens; SKILL.md has 724 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~187
When it runs · the whole SKILL.md, loaded when a task matches
~1.9k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check: warnings

The automated check found patterns that need a careful read before installing.

  • WarningTells the agent its actions are pre-authorized / not to stop for confirmationSKILL.md:111
    **immediately proceed to implement** — never stop at just the plan or ask for confirmation before writing code. The pla

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from dotnet/skills at commit 8d670fa, republished under its MIT licence (© dotnet). 724 words, ~1,925 tokens.

Download SKILL.mdSave it as .claude/skills/plan-ui-change/SKILL.md (or your agent's skills folder).
name
plan-ui-change
description
Plan complex Blazor UI features by decomposing them into focused components. USE FOR: building a complex Blazor page with multiple sections, planning component decomposition, designing a multi-section dashboard or layout, breaking down a large UI feature into composable components, pages with sidebars and content panels, any page with 3+ distinct visual sections or multiple interacting sub-features, identifying parent-child relationships and data flow. DO NOT USE FOR: creating new Blazor projects or apps from scratch (use create-blazor-project), implementing a single individual component (use author-component), writing component code with parameters and EventCallback (use author-component), or simple single-component pages.
license
MIT

Plan a Blazor UI Change

When asked to build a complex UI feature, plan the component decomposition first, then immediately implement it. A single monolithic page component is almost never the right answer — break the UI into focused, composable components.

Planning Workflow

Step 1 — Map the Visual Regions

Read the request and identify every distinct visual region. Each region that has its own data, behavior, or layout responsibility is a candidate component.

Draw the component tree:

InventoryDashboard          (page — owns data, orchestrates layout)
├── StockSummaryBar         (read-only stats: total items, low-stock count, value)
├── InventoryFilters        (search box, category dropdown, stock-level toggle)
├── InventoryTable          (sortable table of products)
│   └── InventoryRow        (single product row with inline edit/delete)
└── AddProductForm          (slide-out form for new products)

Rules for identifying components:

  • Distinct responsibility — a region owns its own state or behavior → separate component
  • Repeated structure — items in a list, cards in a grid → extract the item template
  • Independent interactivity — a section that handles user input separately from its siblings → separate component
  • Size — any section that would exceed ~150 lines of markup on its own → split it
Step 2 — Classify Each Component

For every component in the tree, determine:

ComponentActionRender ModeState OwnedLines (est.)
InventoryDashboardCreateInteractiveServerproduct list, filter state~80
StockSummaryBarCreate(inherits)none — receives data~30
InventoryFiltersCreate(inherits)search text, selected category~60
InventoryTableCreate(inherits)sort column, sort direction~50
InventoryRowCreate(inherits)inline-edit mode flag~60
AddProductFormCreate(inherits)form model~80

A page component that exceeds ~200 lines of combined markup + code is too large. If your estimate puts a single component above that, split further.

Step 3 — Design Data Flow

Identify the state owner for each piece of data, then map how it flows:

InventoryDashboard (owns: products[], filters)
  │
  ├─ [Parameter] products ──→ StockSummaryBar (reads aggregate stats)
  │
  ├─ [Parameter] filters ──→ InventoryFilters
  │   └─ EventCallback<Filters> OnFiltersChanged ──→ InventoryDashboard
  │
  ├─ [Parameter] filteredProducts ──→ InventoryTable
  │   └─ [Parameter] product ──→ InventoryRow
  │       ├─ EventCallback<Product> OnSave ──→ InventoryTable ──→ InventoryDashboard
  │       └─ EventCallback<Product> OnDelete ──→ InventoryTable ──→ InventoryDashboard
  │
  └─ EventCallback<Product> OnProductAdded ←── AddProductForm

Rules:

  • Data always flows down through [Parameter]
  • Events always flow up through EventCallback<T>
  • The page/parent owns the data and passes filtered/transformed views to children
  • Children never mutate parameters — they notify the parent via callbacks
  • If data must cross more than 2 levels without intermediate components needing it, use a cascading value or a scoped service
Step 4 — Identify Reuse Opportunities

Before creating a new component, check if an existing component in the project can serve the purpose. Look for:

  • Existing list-item components that match the structure
  • Shared filter/search components already in the project
  • Generic components (e.g., DataTable<T>, Pagination) that accept templates

If a component will be used in more than one page, place it in a Shared/ or Components/ folder.

Step 5 — Order the Implementation

Build bottom-up — leaf components first, then parents that compose them:

  1. Models/DTOs — define the data shapes
  2. Services — data access, business logic (interface + implementation)
  3. Leaf components — components with no children (InventoryRow, StockSummaryBar)
  4. Container components — components that compose leaves (InventoryTable, InventoryFilters)
  5. Page component — wires everything together, registers routes
  6. Configuration — DI registration, render mode setup

Each component should be independently compilable. Never reference a component that doesn't exist yet.

Show full SKILL.md (285 more words)Show less

Output Format

Present the plan briefly, then immediately proceed to implement — never stop at just the plan or ask for confirmation before writing code. The plan is a thinking tool, not a deliverable.

markdown
## Component Plan: [Feature Name]

### Component Tree
[ASCII tree showing parent-child relationships]

### Component Table
| Component | Action | Render Mode | Purpose | Est. Lines |
|-----------|--------|-------------|---------|------------|
| ... | ... | ... | ... | ... |

### Data Flow
[State owner] → [Parameters down] → [EventCallbacks up]

### Implementation Order
1. [First file to create — why]
2. [Second file — why]
...

After outputting the plan, immediately begin implementing the components in the order listed. Do not wait for approval or ask "shall I proceed?" — the plan is a guide for you to follow, not a proposal for the user to approve.

Anti-Patterns to Avoid

Anti-PatternWhy It's WrongCorrect Approach
One page component with 500+ linesImpossible to test, reuse, or maintainDecompose into focused components
Passing 10+ parameters through intermediate componentsParameter drilling obscures intentUse cascading values or a scoped state service
Child component fetching its own data from an APIMultiple components making redundant callsParent owns data, passes via parameters
Inline rendering of list items with complex markupDuplicated logic, no reuse, hard to testExtract item template into its own component
Building everything in one file then "refactoring later"Refactoring rarely happens; the monolith shipsPlan the decomposition upfront
Generic components for one-off usageOver-engineering adds complexityOnly extract generics when reuse is proven

Guidelines

  • Plan briefly, then implement. Write a concise component table and data flow map, then immediately create the .razor files — never stop at just the plan.
  • Prefer many small components over one large one. A component with a single clear purpose is easier to understand, test, and reuse.
  • State ownership is the first decision. Before writing fetch logic, decide which component owns the data.
  • Build bottom-up. Create leaf components first so parent components can reference them immediately.
  • Name components after what they render, not what they do internally: ProductCard not ProductRenderer, OrderFilters not FilterHandler.

© dotnet, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in plugins/dotnet-blazor/skills/plan-ui-change of dotnet/skills.

Open the folder on GitHubat commit 8d670fa

Used in 1 other repository

We found 2 copies of this SKILL.md (exact, near-identical or edited) in other folders, from 1 other GitHub owner. This page covers the copy in dotnet/skills, which our catalogue first saw on October 7, 2026.

Compare with similar skills

Plan UI Change next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Plan UI Change compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Plan UI Change this skilldotnet/skills5.6k1 repos~1.9kAutomated safety check: WarnMIT
Aspnet Corefanslead/ReverseProxy.Store1632 repos~1.4kAutomated safety check: PassApache-2.0
Maui AI DebuggingRedth/Maui.Gtk101—~4.1kAutomated safety check: PassMIT
Test Firstdeanhume/html-minifier142—~876Automated safety check: PassMIT
QA TesterJocysCom/FocusLogger213—~12kAutomated safety check: PassGPL-3.0
Maui Hot Reload Diagnosticsdavidortinau/maui-skills174—~1.3kAutomated safety check: PassMIT

Similar skills

  • Aspnet Core

    fanslead/ReverseProxy.Store

    Build, review, refactor, or architect ASP.NET Core web applications using current official guidance for .NET web development.

    163 GitHub starsUsed in 2 repos~1.4k tokens
    Backend & APIsAuto-check passed
  • Maui AI Debugging

    Redth/Maui.Gtk

    End-to-end workflow for building, deploying, inspecting, and debugging .NET MAUI and MAUI Blazor Hybrid apps as an AI agent.

    101 GitHub stars~4.1k tokensUpdated 5 mo ago
    MobileAuto-check passed
  • Test First

    deanhume/html-minifier

    Enforces a strict test-driven development (TDD) workflow for the HTML Minifier repo.

    142 GitHub stars~876 tokensUpdated 21 days ago
    Testing & QAAuto-check passed
  • QA Tester

    JocysCom/FocusLogger

    Create and maintain automated tests in Microsoft-native/.NET projects with a minimal stack — MSTest runner, System.Windows.Automation for Windows desktop, Playwright for real browser smoke.

    213 GitHub stars~12k tokensUpdated 3 mo ago
    Testing & QAAuto-check passed
  • Maui Hot Reload Diagnostics

    davidortinau/maui-skills

    Diagnose and troubleshoot .NET MAUI Hot Reload issues (C Hot Reload, XAML Hot Reload, Blazor Hybrid).

    174 GitHub stars~1.3k tokensUpdated 3 mo ago
    MobileAuto-check passed
  • Code Review

    egil/Htmxor

    Reviews Htmxor pull requests against repository standards and their approved issue, specification, or pull request contract.

    164 GitHub stars~1.3k tokensUpdated yesterday
    DevelopmentAuto-check passed

More from dotnet/skills

All 91 skills in this repo
  • Official

    Resolves .NET runtime frames in Apple .ips crash logs to function names, source files and line numbers using dSYM symbols, atos and the Microsoft symbol server.

    5.6k GitHub starsUsed in 1 repo~2.4k tokens
    Auto-check passed
  • Official

    Resolves native crash frames from .NET Android tombstones to function names, source files and line numbers using BuildIds, Microsoft's symbol server and llvm-symbolizer.

    5.6k GitHub starsUsed in 1 repo~2.1k tokens
    Auto-check passed
  • Official

    Scans C# and .NET code for about 50 performance anti-patterns and reports prioritized findings with concrete fixes, at a scan depth you choose.

    5.6k GitHub starsUsed in 3 repos~3.1k tokens
    Auto-check passed
  • Official

    Statically pairs source files with test files to list code that no test references, using Roslyn for C# or tree-sitter for many languages, with no build.

    5.6k GitHub starsUsed in 1 repo~3.3k tokens
    Auto-check passed
  • Microbenchmarking

    dotnet/skills

    Official

    Activate this skill when BenchmarkDotNet (BDN) is involved in the task — creating, running, configuring, or reviewing BDN benchmarks.

    5.6k GitHub starsUsed in 3 repos~3.3k tokens
    Auto-check passed
  • Official

    Makes .NET projects compatible with Native AOT and trimming by resolving IL trim and AOT analyzer warnings through annotations rather than suppressions.

    5.6k GitHub starsUsed in 2 repos~4.2k tokens
    Auto-check passed

Works with

Questions about Plan UI Change

What does Plan UI Change do?

Plan complex Blazor UI features by decomposing them into focused components. Plan UI Change is an agent skill from dotnet/skills, published by the product's own GitHub organization. Plan complex Blazor UI features by decomposing them into focused components.

When should I use Plan UI Change?

Plan UI Change fits situations like: : building a complex Blazor page with multiple sections; planning component decomposition; designing a multi-section dashboard; breaking down a large UI feature into composable components.

How do I install Plan UI Change in Claude Code?

Run `npx skills add dotnet/skills --skill plan-ui-change -a claude-code`. Or copy the skill folder (plugins/dotnet-blazor/skills/plan-ui-change in dotnet/skills) into .claude/skills/plan-ui-change in your project. Claude Code loads it when a task matches its description.

How do I install Plan UI Change in Codex?

Run `npx skills add dotnet/skills --skill plan-ui-change -a codex`. Or copy the skill folder (plugins/dotnet-blazor/skills/plan-ui-change in dotnet/skills) into .agents/skills/plan-ui-change in your project. Codex loads it when a task matches its description.

Can I use Plan UI Change in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add dotnet/skills --skill plan-ui-change -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/plan-ui-change, .gemini/skills/plan-ui-change, .github/skills/plan-ui-change and .opencode/skills/plan-ui-change in your project.

What does Plan UI Change need to run?

SKILL.md names no scripts, command-line tools or credentials: Plan UI Change is instructions for the agent only.

Does Plan UI Change access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Plan UI Change safe to install?

Our automated static check of SKILL.md flagged 1 warning(s): tells the agent its actions are pre-authorized / not to stop for confirmation. Read the flagged lines before installing; the check is not a guarantee either way.

What licence does Plan UI Change use?

Plan UI Change is published under the MIT licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Plan UI Change use?

About 1.9k tokens (SKILL.md is roughly 7.7k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Plan UI Change?

Skills that share tags, products or a category with Plan UI Change: Aspnet Core (fanslead/ReverseProxy.Store, 163 stars), Maui AI Debugging (Redth/Maui.Gtk, 101 stars), Test First (deanhume/html-minifier, 142 stars) and QA Tester (JocysCom/FocusLogger, 213 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Plan UI Change?

dotnet (a GitHub organization, an official publisher) maintains it in dotnet/skills, which has 5,568 GitHub stars. The repository holds 91 skills in this directory. The repository was last updated on October 7, 2026.

Source: dotnet/skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.