Add Ignite UI Blazor skill

[kotlarmilos]

Summary

This moves the changes from #994 to a branch in dotnet/skills so the evaluation workflows can run. It adds guidance for integrating Ignite UI components into Blazor applications and an evaluation for split Blazor Web Apps.

Validation

The evaluation checks package references, service registration in the server and client projects, _Imports.razor usage, asset linking, and file-specific setup instructions.

[github-actions]

Skill Coverage Report

	Plugin	Skill	Covered	Coverage

[Copilot]

Copilot review overview

🟡 Changes recommended

The eval and skill guidance contain a few correctness/robustness issues that can cause false passes/fails or mislead copy/paste setup steps.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review tier: Lite
Findings: 2 · 1

New issues introduced by this change (3)

Severity	Finding
	tests/​dotnet-blazor/​use-igniteui-blazor/​eval.yaml — The negative check for the GridLite stylesheet is overly specific (it only fails if the response…
	tests/​dotnet-blazor/​use-igniteui-blazor/​eval.yaml — This grader requires a specific theme file (themes/light/bootstrap.css), but the prompt/rubric…
	plugins/​dotnet-blazor/​skills/​use-igniteui-blazor/​SKILL.md — The comment listing alternative Blazor framework scripts omits the required _framework/ prefix,…

What changed in this PR

Adds a new dotnet-blazor skill and accompanying evaluation to guide (and test) Ignite UI Blazor Lite/GridLite integration across several Blazor project types, with emphasis on file-oriented setup steps for split Blazor Web Apps.

Changes:

• Introduces use-igniteui-blazor skill guidance covering packages, service registration, _Imports.razor, asset linking, and render-mode notes.
• Adds a new eval.yaml with multiple stimuli to validate the skill’s responses for split Web Apps, Blazor Server, MAUI Blazor Hybrid, and grid-only scenarios.

File	Description
tests/​dotnet-blazor/​use-igniteui-blazor/​eval.yaml	Adds eval scenarios/graders to validate concrete, file-specific Ignite UI setup guidance across project types.
plugins/​dotnet-blazor/​skills/​use-igniteui-blazor/​SKILL.md	Adds the skill documentation and routing metadata for integrating Ignite UI Blazor Lite/GridLite in Blazor apps.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

👋 @kotlarmilos — this PR has 3 unresolved review thread(s). When you're ready, please address the feedback and push an update; the triage bot will pick up the next state automatically. (Add the no-stale label to silence further pings.)

[AbhitejJohn]

Thanks for putting this together. I completed a multi-model review and also checked the evaluation design. The structural checks pass, but there is no skilled-versus-baseline result for this head yet, and the current five-stimulus design has no tolerance for a tie. I left focused comments on the new issues that are not already covered by the existing review threads.

(Copilot, commenting on Abhitej's behalf.)

[AbhitejJohn]

Thanks for documenting this path. Could we correct the payload guidance here? The shipped implementation leaves ModulesToLoad empty for AddIgniteUIBlazor() and lets components request modules on first render. Passing Igb...Module types preloads those modules during startup, so it increases the initial transfer rather than trimming it. The fifth eval stimulus and rubric repeat the same inversion, so could we update both to describe this as a startup warm-up/first-render latency trade-off?

(Copilot, commenting on Abhitej's behalf.)

[AbhitejJohn]

Could we scope this requirement to IgniteUI.Blazor.Lite and add the GridLite-only contract explicitly? The GridLite package README says no service registration or manual JavaScript bundle is required, and the package has no app.bundle.js. As written, a GridLite-only user can follow this unconditional step and add invalid Lite setup. A short GridLite branch saying "no AddIgniteUIBlazor(), no app.bundle.js; add the namespace and GridLite stylesheet only" would also align the skill with stimulus 4.

(Copilot, commenting on Abhitej's behalf.)

[AbhitejJohn]

Could we replace these bare negative substring graders with checks for prescriptive usage, or leave this distinction to the rubric? A correct answer such as "do not call AddIgniteUIBlazor() and do not add app.bundle.js for GridLite" fails both hard graders. The same negation-blind issue appears at lines 169-171, and this repo already documents and fixes this failure mode in tests/dotnet-test/test-anti-patterns/eval.yaml. Since the skilled arm is more likely to know and explicitly rule out these names, the current checks can bias the comparison against it.

(Copilot, commenting on Abhitej's behalf.)

[AbhitejJohn]

Could we add at least one more distinct preference stimulus before treating this eval as sufficient evidence? check_eval_quality.py reports exactly five preference stimuli, so one tie leaves only four discordant votes and makes a passing verdict impossible. runs: 5 measures reliability for the same five tasks; it does not add statistical power. A separate expect_activation: false case for a plain Blazor request with no Ignite UI would also verify the routing boundary in the description, although that dormancy case would not count toward the preference floor.

(Copilot, commenting on Abhitej's behalf.)