How do I install the CLI Compile Surface Hardening skill?

Run npx skillmds@latest add fritzandfriends/cli-compile-surface-hardening in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is CLI Compile Surface Hardening safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with CLI Compile Surface Hardening?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is CLI Compile Surface Hardening free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published CLI Compile Surface Hardening?

fritzandfriends (@fritzandfriends) published this skill. Their other Agent Skills are listed on their SkillMD profile.

CLI Compile Surface Hardening by fritzandfriends

Name: CLI Compile Surface Hardening
Author: fritzandfriends

File contents

Context

Use this when the migration CLI starts emitting more generated .razor.cs files or copying more legacy source into the output project. The goal is to preserve deterministic L1 behavior while preventing compile failures from style analyzers, generic Razor component inference, or unresolved markup references.

Patterns

In generated migration projects, prefer <EnforceCodeStyleInBuild>false</EnforceCodeStyleInBuild> over broad warning suppression when copied legacy files would otherwise fail repo-level IDE analyzers.
Add validator generic arguments with the BWFC component's actual generic parameter name, not an assumed TValue alias:
- RequiredFieldValidator → Type="string"
- CompareValidator / RangeValidator → InputType="string"
Run markup-driven member stub generation after the main code-behind transforms, using transformed Razor markup (metadata.MarkupContent) as the source of truth.
Stub only the deterministic missing-member shapes that are safe to infer mechanically:
- @MethodName() → render-method stub returning object?
- @_fieldName → private object? field
- OnClick="@HandlerName" and similar → void HandlerName(object? sender, EventArgs e)
Register new transforms in both production DI (src\BlazorWebFormsComponents.Cli\Program.cs) and tests\BlazorWebFormsComponents.Cli.Tests\TestHelpers.cs so the lightweight and full pipelines stay aligned.

Examples

src\BlazorWebFormsComponents.Cli\Transforms\Markup\ValidatorGenericTypeTransform.cs
src\BlazorWebFormsComponents.Cli\Transforms\CodeBehind\MarkupReferencedMemberStubTransform.cs
tests\BlazorWebFormsComponents.Cli.Tests\TransformUnit\CompiledCodeBehindStubPipelineTests.cs

Anti-Patterns

Suppressing all warnings/errors in the generated project when only code-style analyzers are the problem.
Injecting TValue="string" into BWFC validators that actually expose Type or InputType generic parameters.
Generating markup-reference stubs before markup transforms run, or reading original Web Forms markup instead of the transformed Razor output.
Emitting placeholder stubs for every @Identifier token; restrict deterministic generation to the specific reference shapes you can classify safely.

---name: cli-compile-surface-hardeningdescription: Keep migrated Blazor output compiling when more Web Forms artifacts stay on the generated compile surface---## ContextUse this when the migration CLI starts emitting more generated `.razor.cs` files or copying more legacy source into the output project. The goal is to preserve deterministic L1 behavior while preventing compile failures from style analyzers, generic Razor component inference, or unresolved markup references.## Patterns- In generated migration projects, prefer `<EnforceCodeStyleInBuild>false</EnforceCodeStyleInBuild>` over broad warning suppression when copied legacy files would otherwise fail repo-level IDE analyzers.- Add validator generic arguments with the BWFC component's actual generic parameter name, not an assumed `TValue` alias: - `RequiredFieldValidator` → `Type="string"` - `CompareValidator` / `RangeValidator` → `InputType="string"`- Run markup-driven member stub generation after the main code-behind transforms, using transformed Razor markup (`metadata.MarkupContent`) as the source of truth.- Stub only the deterministic missing-member shapes that are safe to infer mechanically: - `@MethodName()` → render-method stub returning `object?` - `@_fieldName` → private `object?` field - `OnClick="@HandlerName"` and similar → `void HandlerName(object? sender, EventArgs e)`- Register new transforms in both production DI (`src\BlazorWebFormsComponents.Cli\Program.cs`) and `tests\BlazorWebFormsComponents.Cli.Tests\TestHelpers.cs` so the lightweight and full pipelines stay aligned.## Examples- `src\BlazorWebFormsComponents.Cli\Transforms\Markup\ValidatorGenericTypeTransform.cs`- `src\BlazorWebFormsComponents.Cli\Transforms\CodeBehind\MarkupReferencedMemberStubTransform.cs`- `tests\BlazorWebFormsComponents.Cli.Tests\TransformUnit\CompiledCodeBehindStubPipelineTests.cs`## Anti-Patterns- Suppressing all warnings/errors in the generated project when only code-style analyzers are the problem.- Injecting `TValue="string"` into BWFC validators that actually expose `Type` or `InputType` generic parameters.- Generating markup-reference stubs before markup transforms run, or reading original Web Forms markup instead of the transformed Razor output.- Emitting placeholder stubs for every `@Identifier` token; restrict deterministic generation to the specific reference shapes you can classify safely.

Frequently asked questions

CLI Compile Surface Hardening