Add Ignite UI Blazor skill - #994
Conversation
There was a problem hiding this comment.
Pull request overview
This pull request introduces a new dotnet-blazor skill that guides developers through integrating Ignite UI (including GridLite) into Blazor apps—especially split Blazor Web Apps—and adds a capability eval to validate that the skill produces concrete, file-oriented setup steps.
Changes:
- Added a new skill document (
SKILL.md) describing NuGet packages, service registration,_Imports.razor, host-page assets, and render-mode guidance for Ignite UI in Blazor. - Added a new evaluation spec (
eval.yaml) to test that responses include the required packages,AddIgniteUIBlazor()registration,_Imports.razorusage, and asset linking details.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| tests/dotnet-blazor/use-igniteui-blazor/eval.yaml | Adds a capability eval that checks for key Ignite UI integration details in the model output. |
| plugins/dotnet-blazor/skills/use-igniteui-blazor/SKILL.md | Adds the new skill guidance for installing/configuring Ignite UI (Lite + GridLite) across Blazor project types. |
Suppressed comments (2)
plugins/dotnet-blazor/skills/use-igniteui-blazor/SKILL.md:84
- The fingerprinted asset example also uses the
_content/IgniteUI.Blazor/...root; if the intent is to document the Lite package setup, this should reference the Lite asset root for consistency with the rest of the setup steps.
<link rel="stylesheet" href="@Assets["_content/IgniteUI.Blazor/themes/light/bootstrap.css"]" />
plugins/dotnet-blazor/skills/use-igniteui-blazor/SKILL.md:79
- The theme path description still points to
_content/IgniteUI.Blazor/themes/, which doesn’t match the recommendedIgniteUI.Blazor.Litepackage in this skill. Aligning the documented_contentroot avoids confusion about which static asset base path to use.
Theme files under `_content/IgniteUI.Blazor/themes/` are `{light|dark}/{bootstrap|material|fluent|indigo}.css` — link exactly one.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| - type: output-contains | ||
| config: | ||
| substring: server and client Program.cs | ||
| - type: prompt |
|
Tagging @danroth27 and @javiercn to help review. |
|
/evaluate |
There was a problem hiding this comment.
Review details
Suppressed comments (4)
plugins/dotnet-blazor/skills/use-igniteui-blazor/SKILL.md:74
- The static web asset paths in this example point at
_content/IgniteUI.Blazor/..., which corresponds to the non-Lite package. Since this skill instructs installingIgniteUI.Blazor.Lite, the CSS/JS URLs should use_content/IgniteUI.Blazor.Lite/...or users will get 404s and the components won’t load.
<link href="_content/IgniteUI.Blazor/themes/light/bootstrap.css" rel="stylesheet" />
...
<script src="_content/IgniteUI.Blazor/app.bundle.js"></script>
<script src="_framework/blazor.web.js"></script> <!-- or blazor.server.js / blazor.webassembly.js / blazor.webview.js -->
plugins/dotnet-blazor/skills/use-igniteui-blazor/SKILL.md:79
- This path should also use the
IgniteUI.Blazor.Litestatic asset root to match the package name used elsewhere in the skill; otherwise the guidance is inconsistent and likely wrong for OSS Lite installs.
Theme files under `_content/IgniteUI.Blazor/themes/` are `{light|dark}/{bootstrap|material|fluent|indigo}.css` — link exactly one.
tests/dotnet-blazor/use-igniteui-blazor/eval.yaml:46
- This grader is very brittle: the skill text says “both the server and the client
Program.cs”, which won’t match the exact substringserver and client Program.cs. Using a case-insensitive regex makes the check resilient while still enforcing that both sides are mentioned.
- type: output-contains
config:
substring: server and client Program.cs
- type: prompt
plugins/dotnet-blazor/skills/use-igniteui-blazor/SKILL.md:84
- This fingerprinted asset example should use the
IgniteUI.Blazor.Litestatic asset root to match the package name used elsewhere in the skill; otherwise it won’t resolve for OSS Lite installs.
<link rel="stylesheet" href="@Assets["_content/IgniteUI.Blazor/themes/light/bootstrap.css"]" />
- Files reviewed: 2/2 changed files
- Comments generated: 0 new
- Review effort level: Lite
|
|
@kdinev , @kotlarmilos : Would you mind moving these changes to a branch against this repo please? That would help get PR evaluations going. They do not run against branches in forks. |
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
Suppressed comments (2)
Previously missed (2) — in code that hasn't changed since the last review.
plugins/dotnet-blazor/skills/use-igniteui-blazor/SKILL.md:83
- The Razor example for fingerprinted assets uses nested double quotes (href="@assets["..."]"), which won’t compile because the attribute string terminates early. Use single quotes around the HTML attribute (or assign the value to a variable) so the indexer string literal is parsed correctly.
```razor
<link rel="stylesheet" href="@Assets["_content/IgniteUI.Blazor/themes/light/bootstrap.css"]" />
**plugins/dotnet-blazor/skills/use-igniteui-blazor/SKILL.md:91**
* The GridLite section only mentions the stylesheet path, but GridLite also requires its own JS bundle when used in a grid-only setup. Without referencing the GridLite app.bundle.js, users can end up with a grid that doesn’t render.
IgniteUI.Blazor.GridLite ships its own stylesheet from its own asset root:
<link href="_content/IgniteUI.Blazor.GridLite/css/themes/light/bootstrap.css" rel="stylesheet" /></details>
…ssue I noticed with the skill
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
Suppressed comments (1)
plugins/dotnet-blazor/skills/use-igniteui-blazor/SKILL.md:91
- This GridLite stylesheet example uses a concrete light/bootstrap path that the split-app eval explicitly forbids in output. Making the example path generic reduces the chance the model will echo the exact forbidden substring in non-grid answers while still documenting the correct asset root.
<link href="_content/IgniteUI.Blazor.GridLite/css/themes/light/bootstrap.css" rel="stylesheet" />
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
Suppressed comments (2)
Previously missed (1) — in code that hasn't changed since the last review.
plugins/dotnet-blazor/skills/use-igniteui-blazor/SKILL.md:22
- This skill has no markdown ordered-list workflow steps (
1. ...lines), so skill-validator will emit the warning "No numbered workflow steps". Adding a short ordered workflow list improves agent adherence and avoids that warning.
# Application Setup & Component Registration
## 1. NuGet package
tests/dotnet-blazor/use-igniteui-blazor/eval.yaml:142
- The grid-only scenario uses
output-does-not-contain(unsupported) and also forbids the substringapp.bundle.js, while the rubric requires adding the Ignite UI script. These constraints are internally inconsistent and will likely make the scenario ungradable or force an incorrect answer.
- type: output-does-not-contain
config:
substring: AddIgniteUIBlazor
- type: output-does-not-contain
config:
substring: app.bundle.js
- type: output-contains
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
🔵 Needs a closer look
Review details
Suppressed comments (5)
Previously missed (4) — in code that hasn't changed since the last review.
tests/dotnet-blazor/use-igniteui-blazor/eval.yaml:18
- The prompt explicitly names
AddIgniteUIBlazor(), which makes the stimulus more leading/overfit than necessary (the graders already assert the method name appears in the answer). Consider rephrasing this bullet to ask for the required Ignite UI service registration without cueing the exact API name.
5. Any note about where AddIgniteUIBlazor() has to be called in a split app.
plugins/dotnet-blazor/skills/use-igniteui-blazor/SKILL.md:46
- This sentence is phrased as applying to all "Blazor Web App" projects, but the requirement to call
AddIgniteUIBlazor()in bothProgram.csfiles is specific to split Web Apps that actually have separate Server and Client projects (and especially InteractiveAuto). For a server-only Web App there is no clientProgram.cs. Consider tightening the wording to avoid misguiding users on the default single-project Web App template.
**Blazor Web App:** call `AddIgniteUIBlazor()` in **both** the server and the client `Program.cs`.
plugins/dotnet-blazor/skills/use-igniteui-blazor/SKILL.md:75
- The comment listing alternative framework scripts omits the
_framework/prefix, which could lead users to copy/paste an incorrect script path. Elsewhere in this repo the examples consistently use_framework/<script>.js(e.g., plugins/dotnet-aspnetcore/skills/convert-blazor-server-to-webapp/SKILL.md:145-150).
<script src="_framework/blazor.web.js"></script> <!-- or blazor.server.js / blazor.webassembly.js / blazor.webview.js -->
tests/dotnet-blazor/use-igniteui-blazor/eval.yaml:7
- This eval has exactly 5 preference-eligible stimuli, which is the eligibility floor but is fragile: CONTRIBUTING.md notes that with exactly 5 stimuli a single tie makes a pass unreachable (it leaves only 4 discordant votes). Consider adding at least one more discriminating stimulus (e.g., a dormancy guard does not count toward the floor) to reduce tie risk and make the verdict more reliable.
stimuli:
plugins/dotnet-blazor/skills/use-igniteui-blazor/SKILL.md:22
- This SKILL.md uses numbered headings ("## 1.") but no actual ordered-list step lines (e.g., "1. ").
skill-validatoronly counts ordered-list markers (regex^\d+\.\s) for the "Numbered workflow steps" check and will warn when none are present (eng/skill-validator/src/Check/SkillProfiler.cs:261-262). Add a small ordered-list workflow near the top so the skill passes that convention.
# Application Setup & Component Registration
## 1. NuGet package
- Files reviewed: 2/2 changed files
- Comments generated: 0 new
- Review effort level: Lite
|
@kotlarmilos Could you create a new branch in the repo, and I'll PR the change against that branch and that branch will be PRed against main for the workflow runs like @AbhitejJohn has requested? Alternative option is to give repo rights to our team to create branches and I'll handle it myself. |
There was a problem hiding this comment.
🔵 Needs a closer look
Review details
Suppressed comments (2)
plugins/dotnet-blazor/skills/use-igniteui-blazor/SKILL.md:26
- The NuGet install snippet currently shows adding both IgniteUI.Blazor.Lite and IgniteUI.Blazor.GridLite unconditionally, which can encourage always installing both packages even when the user wants a grid-only or no-grid setup. Consider adding brief guidance in the snippet/comments to make GridLite clearly optional.
dotnet add package IgniteUI.Blazor.Lite # OSS core UI components (MIT)
dotnet add package IgniteUI.Blazor.GridLite # OSS lightweight grid (MIT)
plugins/dotnet-blazor/skills/use-igniteui-blazor/SKILL.md:78
- Section 4 says "Both tags are required" without qualifying that this applies to the IgniteUI.Blazor.Lite components. Since the doc also calls out GridLite’s separate, grid-only stylesheet path, this reads as contradictory for grid-only setups. Scope the "both tags" requirement to the Lite package to avoid confusion.
Both tags are required: without the stylesheet components render unstyled, without `app.bundle.js` they do not render at all. `app.bundle.js` must come **before** the Blazor framework script.
- Files reviewed: 2/2 changed files
- Comments generated: 0 new
- Review effort level: Lite
| ```html | ||
| <link href="_content/IgniteUI.Blazor/themes/light/bootstrap.css" rel="stylesheet" /> | ||
| ... | ||
| <script src="_content/IgniteUI.Blazor/app.bundle.js"></script> |
There was a problem hiding this comment.
Is this manual script tag still required? IgniteUI.Blazor.Lite 0.1.1 already ships an IgniteUI.Blazor.Lite.*.lib.module.js Blazor JavaScript initializer that loads app.bootstrap.js and the component bundles. I verified in a default .NET 10 Blazor Web App that the components load and render correctly without adding app.bundle.js to App.razor. Could this guidance rely on the initializer instead, and document any older framework or hosting-model cases where a manual script is still necessary?
There was a problem hiding this comment.
@danroth27 Good catch! That was required, but the state of the skill is from before the change you mention. I will update accordingly.
There was a problem hiding this comment.
Just to add some context.
As you said, app.bundle.js is loaded automatically through the .lib.module.js initializer.
On the other hand, our docs still show a script tag for cases that use Ignite UI for Blazor global functions such as igRegisterScript. The explicit reference gives a reliable point to run that code.
If those functions aren't needed during page load, app.bundle.js doesn't need to be referenced explicitly.
Please take a look related discussion: IgniteUI/igniteui-blazor#233
There was a problem hiding this comment.
Yup, @jsakamotoIGJP made all valid points;
While we could leave the guidance that the script is only needed in some cases, I'd much rather drop it (leave it as legacy elsewhere), tackle the user scripts registration and completely update guidance for new code in this skill. Will need a lil bit to tackle, and thus delay the skill a bit if you don't mind. Will update on progress as soon as I can.
PS: The app.bundle.js is a bit a legacy artifact on our end - it was shipped before modules became a thing, and like these things often do, it stuck. Safety in stability and so on.
Co-authored-by: Daniel Roth <daroth@microsoft.com>
There was a problem hiding this comment.
🟡 Changes recommended
The skill guidance currently risks misguiding GridLite-only vs Lite setups (packages and required assets), which can cause incorrect integration instructions and eval failures.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Review details
Suppressed comments (2)
plugins/dotnet-blazor/skills/use-igniteui-blazor/SKILL.md:26
- The package snippet currently reads like IgniteUI.Blazor.GridLite is always installed alongside IgniteUI.Blazor.Lite, but several supported scenarios are GridLite-only or Lite-only. Marking GridLite as optional here will prevent the skill from recommending unnecessary package installs.
dotnet add package IgniteUI.Blazor.GridLite # OSS lightweight grid (MIT)
plugins/dotnet-blazor/skills/use-igniteui-blazor/SKILL.md:88
- This paragraph mentions when to use the GridLite stylesheet, but it doesn’t explicitly call out that GridLite-only setups omit AddIgniteUIBlazor() and app.bundle.js (a key distinction vs IgniteUI.Blazor.Lite). Making that explicit will help the skill avoid suggesting unnecessary startup/script changes for grid-only apps.
`IgniteUI.Blazor.GridLite` ships its own stylesheet from its own asset root, but should be used only if you are using the GridLite component exclusively. If you are using other Ignite UI components, do not link (or suggest) the GridLite stylesheet — use the main theme stylesheet above instead.
- Files reviewed: 2/2 changed files
- Comments generated: 1
- Review effort level: Lite
| Both tags are required: without the stylesheet components render unstyled, without `app.bundle.js` they do not render at all. `app.bundle.js` must come **before** the Blazor framework script. | ||
|
|
|
@AbhitejJohn I don't have push permissions to create a new branch on the repo. Could you please help us with that? |
| <link href="_content/IgniteUI.Blazor/themes/light/bootstrap.css" rel="stylesheet" /> | ||
| ... | ||
| <script src="_content/IgniteUI.Blazor/app.bundle.js"></script> | ||
| <script src="_framework/blazor.web.js"></script> <!-- or blazor.server.js / blazor.webassembly.js / blazor.webview.js --> |
There was a problem hiding this comment.
💡 Regression — For MAUI Blazor Hybrid, BlazorWebView starts Blazor natively, so the host page should preserve <script src="_framework/blazor.webview.js" autostart="false"></script>. The current snippet presents blazor.webview.js as interchangeable with the auto-starting framework scripts, so an agent producing a complete MAUI host page could emit an incomplete tag. A one-line MAUI-specific callout would avoid that risk.
Flagged by: 3/3 reviewers after dispute; calibrated as non-blocking after source-level verification.
| substring: IgniteUI.Blazor.GridLite | ||
| - type: output-not-contains | ||
| config: | ||
| substring: AddIgniteUIBlazor |
There was a problem hiding this comment.
output-not-contains checks (AddIgniteUIBlazor here and app.bundle.js below) also reject a correct explanation such as "do not call AddIgniteUIBlazor() or add app.bundle.js for GridLite-only." This was reproduced against the repository-pinned Vally 0.14.0 grader: correct negated prose receives score 0. Match actual usage syntax, such as an AddIgniteUIBlazor( invocation or an <script ...app.bundle.js> tag, instead of banning the bare terms.
Flagged by: 2/3 reviewers; empirically reproduced.
| substring: _content/IgniteUI.Blazor/themes/light/bootstrap.css | ||
| - type: output-matches | ||
| config: | ||
| pattern: '(?:both|each)[\s\S]{0,80}(?:[Ss]erver[\s\S]{0,80}[Cc]lient|[Cc]lient[\s\S]{0,80}[Ss]erver)' |
There was a problem hiding this comment.
both or each near Server and Client text anywhere in the response; it is not tied to AddIgniteUIBlazor or either Program.cs. Direct probes showed that it passes generic architecture prose and negated advice such as "do not register in both Server and Client," while sufficiently separated correct wording can fail. Tie the assertion to positive registration in both projects rather than word proximity alone.
Flagged by: 2/3 reviewers; empirically reproduced.
PureWeen
left a comment
PureWeen
left a comment
There was a problem hiding this comment.
Adversarial review summary
Two eval correctness defects should be addressed:
⚠️ The GridLite-only negative substring graders penalize correct explanatory negations. This was reproduced using the repository-pinned Vally 0.14.0 implementation.⚠️ The split-app Server/Client proximity regex produces both false positives and false negatives and does not establish dual service registration. This was reproduced with direct regex probes.
One non-blocking documentation clarification is also suggested:
- 💡 Preserve the MAUI-specific
autostart="false"requirement when showingblazor.webview.js. First-party template and runtime source confirm the contract, although no native runtime reproduction was performed.
The five scenarios cover the intended project variants, but the two grader defects weaken the reliability of the grid-only and split-app cases. Existing review feedback about legacy app.bundle.js guidance and GridLite package/setup distinctions was not duplicated.
Methodology: 3 independent reviewers with adversarial consensus, followed by targeted empirical revalidation. Review event: COMMENT.
| - Adds @using IgniteUI.Blazor.Controls to _Imports.razor so the components are available everywhere that needs them | ||
| - Includes both the Ignite UI theme stylesheet and app.bundle.js in the host page, with app.bundle.js before the Blazor framework script | ||
| - Does not suggest the GridLite stylesheet, which is only needed for a grid-only setup | ||
| - Keeps the answer specific to the relevant files instead of giving only general guidance |
There was a problem hiding this comment.
@rendermode Interactive* (or extend this rubric, though a separate scenario gives a cleaner signal).
Flagged by: 3/3 reviewers.
| defaults: | ||
| timeout: 10m | ||
| runs: 5 | ||
| stimuli: |
There was a problem hiding this comment.
💡 Testing — This eval has no dormancy contract even though the skill explicitly routes general render-mode and architecture questions to create-blazor-project. Because this skill also contains broad Blazor/render-mode vocabulary, it can incorrectly activate for a generic “which Blazor render mode should I choose?” request and the eval would never detect that routing regression. Add an expect_activation: false stimulus with no Ignite UI terms at that nearest sibling boundary.
Flagged by: 3/3 reviewers.
| substring: blazor.webassembly.js | ||
| - type: output-matches | ||
| config: | ||
| pattern: 'Igb[A-Za-z]+Module' |
There was a problem hiding this comment.
💡 Testing — Igb[A-Za-z]+Module accepts any single module-shaped token, including IgbGridModule, even though this scenario explicitly rules out grid usage and asks about inputs, a combo, and a dialog. That lets a contradictory answer satisfy the deterministic module check. Require the requested component modules, for example Igb(Input|Combo|Dialog)Module with enough assertions to establish the intended preload set, while leaving the “preload does not gate rendering” semantics to the prompt rubric.
Flagged by: 3/3 reviewers.
PureWeen
left a comment
PureWeen
left a comment
There was a problem hiding this comment.
Additional eval review
A focused second pass using the repository’s eval-authoring rules found three additional non-duplicate improvements:
⚠️ 3/3 reviewers: positively test the Blazor Web App static-SSR/render-mode failure that the skill claims to solve.- 💡 3/3 reviewers: add an
expect_activation: falseboundary case for generic render-mode/architecture questions with no Ignite UI requirement. - 💡 3/3 reviewers: tighten the generic module-name regex so a grid or unrelated module cannot satisfy the input/combo/dialog scenario.
The broader proposal to convert all mention checks into syntax/order checks was rejected: those semantic requirements are already valid prompt-grader responsibilities, and the concrete negative-grader/order defects are covered by existing threads. Prior feedback about the exact-five-stimulus floor and the split prompt naming AddIgniteUIBlazor() was also not duplicated.
Test coverage assessment: the project-type matrix is broad, but it omits one core positive behavior (interactive render mode) and all routing-restraint coverage. Methodology: 3 independent reviewers with adversarial consensus. Review event: COMMENT.
|
Moving this work to #1111 so the evaluation workflows can run against a branch in |
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
Summary
This pull request adds a new skill for integrating Ignite UI components into Blazor applications, along with an evaluation test for the skill. The main focus is to provide clear, file-oriented guidance for adding and configuring Ignite UI in various Blazor project types, especially split Blazor Web Apps.
Related issue
Validation
Introduced a new evaluation YAML (
eval.yaml) that tests the skill’s ability to provide concrete, file-specific integration steps for using Ignite UI in a split Blazor Web App. The evaluation checks for explicit package references, service registration in both server and client, correct_Imports.razorusage, proper asset linking, and file-oriented instructions.Checklist
eng/known-domains.txtfor any new external domains referenced by skill content.