extension-points
Provides standard practices for extending MSBuild project files and managing custom build logic.
Install
mkdir -p .claude/skills/extension-points && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/14643" && unzip -o skill.zip -d .claude/skills/extension-points && rm skill.zipInstalls to .claude/skills/extension-points
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Guide for MSBuild extensibility: CustomBefore/CustomAfter hooks, wildcard imports with alphabetic ordering, import gating with control properties, NuGet package build extension layout (build/buildTransitive), and the MicrosoftCommonPropsHasBeenImported guard. Only activate in MSBuild/.NET build context. USE FOR: diagnosing and fixing MSBuild import and hook patterns, reviewing and fixing extension point anti-patterns in Directory.Build files, fixing missing Exists() guards on imports that break fresh clones, fixing NuGet package hooks being silently dropped instead of appended, making build targets extensible for other projects, injecting custom logic into the build pipeline, creating NuGet packages that extend the build, conditionally disabling imports. DO NOT USE FOR: target authoring patterns (use target-authoring), props vs targets placement (use directory-build-organization), general anti-patterns (use msbuild-antipatterns), non-MSBuild build systems.Key capabilities
- →Implement CustomBefore/CustomAfter hooks in MSBuild
- →Use wildcard imports with alphabetic ordering
- →Implement import gating with control properties
- →Lay out NuGet package build extensions
- →Diagnose and fix MSBuild import patterns
- →Create custom extension points
How it works
The skill provides guidance on using CustomBefore/CustomAfter hooks, wildcard imports, and control properties for import gating. It also details the layout for NuGet package build extensions and how to create custom extension points.
Inputs & outputs
When to use extension-points
- →Creating CustomBefore/CustomAfter hooks
- →Implementing NuGet build extension layouts
- →Setting up import gating with control properties
About this skill
MSBuild Extension Points
How the MSBuild pipeline provides hooks for SDKs, NuGet packages, repos, and users to inject custom logic.
CustomBefore / CustomAfter Hooks
Every major .targets file defines import hooks:
<PropertyGroup>
<CustomBeforeMicrosoftCommonTargets Condition="'$(CustomBeforeMicrosoftCommonTargets)' == ''">
$(MSBuildExtensionsPath)\v$(MSBuildToolsVersion)\Custom.Before.Microsoft.Common.targets
</CustomBeforeMicrosoftCommonTargets>
</PropertyGroup>
<Import Project="$(CustomBeforeMicrosoftCommonTargets)"
Condition="'$(CustomBeforeMicrosoftCommonTargets)' != '' and Exists('$(CustomBeforeMicrosoftCommonTargets)')"/>
<!-- ... core targets ... -->
<Import Project="$(CustomAfterMicrosoftCommonTargets)"
Condition="'$(CustomAfterMicrosoftCommonTargets)' != '' and Exists('$(CustomAfterMicrosoftCommonTargets)')"/>
Rules
- Default path includes version (
v$(MSBuildToolsVersion)) for side-by-side installations. - Always check
Exists(). The file may not be present on every machine. - Append to the property (don't overwrite) to chain multiple hooks:
<PropertyGroup>
<CustomBeforeMicrosoftCommonTargets>
$(CustomBeforeMicrosoftCommonTargets);$(MSBuildThisFileDirectory)MyExtension.targets
</CustomBeforeMicrosoftCommonTargets>
</PropertyGroup>
Wildcard Import Directories
MSBuild imports all files in extension directories, sorted alphabetically:
<Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Imports\Microsoft.Common.props\ImportBefore\*"
Condition="'$(ImportByWildcardBeforeMicrosoftCommonProps)' == 'true'
and Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Imports\Microsoft.Common.props\ImportBefore')" />
Key paths
| Property | Resolves to | Scope |
|---|---|---|
$(MSBuildUserExtensionsPath) | %APPDATA%\Microsoft\MSBuild | Per-user |
$(MSBuildExtensionsPath) | MSBuild install directory | Machine-wide |
$(MSBuildProjectExtensionsPath) | obj/ directory | Per-project (NuGet) |
Name files with numeric prefixes for ordering: 01-first.props, 02-second.props.
Import Gating — Control Properties
Every wildcard import is gated by a boolean property:
<PropertyGroup>
<ImportByWildcardBeforeMicrosoftCommonProps
Condition="'$(ImportByWildcardBeforeMicrosoftCommonProps)' == ''">true</ImportByWildcardBeforeMicrosoftCommonProps>
<ImportDirectoryBuildProps
Condition="'$(ImportDirectoryBuildProps)' == ''">true</ImportDirectoryBuildProps>
</PropertyGroup>
Available control properties
| Property | What it disables |
|---|---|
ImportDirectoryBuildProps | Directory.Build.props auto-discovery |
ImportDirectoryBuildTargets | Directory.Build.targets auto-discovery |
ImportProjectExtensionProps | NuGet-generated *.props in obj/ |
ImportProjectExtensionTargets | NuGet-generated *.targets in obj/ |
ImportByWildcardBefore* | Machine-level ImportBefore extensions |
ImportByWildcardAfter* | Machine-level ImportAfter extensions |
NuGet Package Build Extension Layout
NuGet packages inject build logic via build/ or buildTransitive/ folders:
MyPackage/
build/
MyPackage.props ← imported via *.props wildcard
MyPackage.targets ← imported via *.targets wildcard
buildTransitive/
MyPackage.props ← imported by transitive consumers
MyPackage.targets
Rules
- File names must match the package ID exactly.
build/affects direct consumers only.buildTransitive/affects the entire dependency chain.- Props are imported early (before the project), targets are imported late (after the project).
Source Tree vs Packed Layout
When reviewing a NuGet build-extension package, the source layout in the repository can legitimately differ from the packed layout inside the produced .nupkg. This is a common source of false-positive "import points at a missing file" findings.
Three packaging mechanisms reshape the layout at pack time:
-
.nuspec<file src=… target=…>mappings — copy a single source file into multiple per-TFM targets:<!-- Source tree has ONE shared file: buildTransitive\common\MyAdapter.props Pack rewrites it to per-TFM targets inside the .nupkg: buildTransitive\net462\MyAdapter.props buildTransitive\net8.0\MyAdapter.props buildTransitive\net9.0\MyAdapter.props --> <files> <file src="buildTransitive\common\MyAdapter.props" target="buildTransitive\net462\MyAdapter.props" /> <file src="buildTransitive\common\MyAdapter.props" target="buildTransitive\net8.0\MyAdapter.props" /> <file src="buildTransitive\common\MyAdapter.props" target="buildTransitive\net9.0\MyAdapter.props" /> </files>In the
<file>element, atargetending in\is treated as a folder (filename preserved fromsrc); atargetending in a filename renames the file. -
.csproj<PackagePath>metadata on<None Update=…>or<Content Include=…>items — same effect via SDK pack. Use one item per destination to keep the mapping unambiguous:<ItemGroup> <None Include="buildTransitive\common\MyAdapter.props" Pack="true" PackagePath="buildTransitive\net8.0\MyAdapter.props" /> <None Include="buildTransitive\common\MyAdapter.props" Pack="true" PackagePath="buildTransitive\net9.0\MyAdapter.props" /> </ItemGroup>NuGet/SDK pack also accepts a semicolon-separated list (
PackagePath="buildTransitive\net8.0\;buildTransitive\net9.0\") to fan one source out to multiple destinations, but the multi-item form above is harder to misread. -
SDK conventions —
IncludeBuildOutput,BuildOutputTargetFolder,IncludeContentInPackautomatically place built outputs underlib/<tfm>/orbuild/<tfm>/.
Implication for reviewers
A forwarder like the following inside a packed build/net462/ folder is not a "missing-file" bug, even if the source tree has no buildTransitive/net462/ directory:
<!-- In packed build/net462/MyAdapter.props -->
<Project>
<Import Project="$(MSBuildThisFileDirectory)..\..\buildTransitive\net462\MyAdapter.props" />
</Project>
Before flagging an unguarded <Import> inside a build/<tfm>/ or buildTransitive/<tfm>/ folder:
- Look for
*.nuspecin the project directory and its immediate parent directory (do not walk further up). Read every<file target=…>whosetargetmatches the imported path. - Read the
.csprojfor<PackagePath>metadata on<None>/<Content>items. - Only flag the import if the target path is missing from both the source tree and the projected package layout.
See also msbuild-antipatterns AP-13 ("NuGet package forwarders" exception).
Import Guard Pattern
The .targets file ensures .props was imported using a guard property:
<!-- End of Microsoft.Common.props -->
<PropertyGroup>
<MicrosoftCommonPropsHasBeenImported>true</MicrosoftCommonPropsHasBeenImported>
</PropertyGroup>
<!-- Top of Microsoft.Common.CurrentVersion.targets -->
<Import Project="Microsoft.Common.props"
Condition="'$(MicrosoftCommonPropsHasBeenImported)' != 'true'" />
This handles projects that only import .targets.
Directory.Build Discovery
MSBuild walks up the directory tree to find the nearest Directory.Build.props:
<_DirectoryBuildPropsBasePath>
$([MSBuild]::GetDirectoryNameOfFileAbove('$(MSBuildProjectDirectory)', 'Directory.Build.props'))
</_DirectoryBuildPropsBasePath>
Only the nearest file is discovered. Nested hierarchies must explicitly import parents:
<!-- src/Directory.Build.props -->
<PropertyGroup>
<_ParentPropsPath>$([MSBuild]::GetPathOfFileAbove('Directory.Build.props', '$(MSBuildThisFileDirectory)../'))</_ParentPropsPath>
</PropertyGroup>
<Import Project="$(_ParentPropsPath)" Condition="'$(_ParentPropsPath)' != ''" />
Creating Your Own Extension Point
<!-- MySDK.targets -->
<Project>
<Import Project="MySDK.props" Condition="'$(MySDKPropsImported)' != 'true'" />
<PropertyGroup>
<CustomBeforeMySDK Condition="'$(CustomBeforeMySDK)' == ''">$(MSBuildProjectDirectory)\MySDK.Before.targets</CustomBeforeMySDK>
<CustomAfterMySDK Condition="'$(CustomAfterMySDK)' == ''">$(MSBuildProjectDirectory)\MySDK.After.targets</CustomAfterMySDK>
</PropertyGroup>
<Import Project="$(CustomBeforeMySDK)" Condition="Exists('$(CustomBeforeMySDK)')" />
<PropertyGroup>
<MySDKBuildDependsOn>BeforeMySDKBuild;CoreMySDKBuild;AfterMySDKBuild</MySDKBuildDependsOn>
</PropertyGroup>
<Target Name="MySDKBuild" DependsOnTargets="$(MySDKBuildDependsOn)" />
<Target Name="BeforeMySDKBuild" />
<Target Name="AfterMySDKBuild" />
<Target Name="CoreMySDKBuild">
<!-- implementation -->
</Target>
<Import Project="$(CustomAfterMySDK)" Condition="Exists('$(CustomAfterMySDK)')" />
</Project>
Common Pitfalls
- Missing
Exists()on optional imports causes build failures when files are absent. Exception: imports inside publishedbuild/<tfm>/andbuildTransitive/<tfm>/folders of a NuGet package are a package contract — the target is guaranteed by the packed layout (see "Source Tree vs Packed Layout" above). Don't guard them and don't flag them. - Overwriting Custom properties* drops prior hooks. Append with
;separator. - NuGet package file names not matching package ID silently skips the import.
- Nested Directory.Build.props without parent import loses repo-root settings.
When not to use it
- →When dealing with target authoring patterns
- →When dealing with props vs targets placement
- →When dealing with general MSBuild anti-patterns
Limitations
- →The skill is only applicable in MSBuild/.NET build contexts
- →It does not cover non-MSBuild build systems
- →It does not cover target authoring patterns
How it compares
This skill offers specific patterns and rules for extending MSBuild, providing structured methods for injecting custom logic, unlike ad-hoc modifications.
Compared to similar skills
extension-points side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| extension-points (this skill) | 0 | 2mo | No flags | Advanced |
| openspec-onboard | 10 | 6mo | Review | Beginner |
| workflow-orchestration-patterns | 10 | 2mo | No flags | Advanced |
| meta-automation-architect | 7 | 8mo | Review | Advanced |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
openspec-onboard
studyzy
Guided onboarding for OpenSpec - walk through a complete workflow cycle with narration and real codebase work.
workflow-orchestration-patterns
wshobson
Design durable workflows with Temporal for distributed systems. Covers workflow vs activity separation, saga patterns, state management, and determinism constraints. Use when building long-running processes, distributed transactions, or microservice orchestration.
meta-automation-architect
comzine
Use when user wants to set up comprehensive automation for their project. Generates custom subagents, skills, commands, and hooks tailored to project needs. Creates a multi-agent system with robust communication protocol.
hive-mind-advanced
ruvnet
Advanced Hive Mind collective intelligence system for queen-led multi-agent coordination with consensus mechanisms and persistent memory
openspec-new-change
studyzy
使用实验性的产出物工作流启动一个新的 OpenSpec 变更。当用户想要通过结构化的分步方法创建新功能、修复或修改时使用。
router-first-architecture
parcadei
Router-First Architecture