New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Official agent skill

Directory Build Organization

by dotnet in dotnet/skills

USE ONLY for (1) two or more projects with repeated MSBuild policy, targets, or package versions, or (2) an existing Directory.Build.props/targets/rsp hierarchy with an import, placement, or…

OfficialMITAuto-check passed

Install Directory Build Organization

skills CLI
$ npx skills add dotnet/skills --skill directory-build-organization -a claude-code

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

GitHub CLI
$ gh skill install dotnet/skills directory-build-organization --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-msbuild/skills/directory-build-organization .claude/skills/directory-build-organization && 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
directory-build-organization
GitHub stars
5.6k
Used in
1 other repo
Token cost
~2.8k tokens
SKILL.md length
904 words
Files
4 (incl. references)
Skills in repo
91
Repo updated
First seen
Licence
MIT

At a glance

USE ONLY for (1) two or more projects with repeated MSBuild policy, targets, or package versions, or (2) an existing Directory.Build.props/targets/rsp hierarchy with an import, placement, or…

  • Works in 7 steps: Audit all .csproj files — Catalog every… → Create root Directory.Build.props — Move… → Create root Directory.Build.targets —… → …
  • SKILL.md covers Intent control, Directory.Build.props vs…, Directory.Build.props and Directory.Build.targets, plus 6 more sections
  • Calls dotnet

What it does

Directory Build Organization is an agent skill from dotnet/skills, published by the product's own GitHub organization. USE ONLY for (1) two or more projects with repeated MSBuild policy, targets, or package versions, or (2) an existing Directory.Build.props/targets/rsp hierarchy with an import, placement, or layering defect. A one-project repo without an existing Directory.Build file is outside scope; do not load this skill. Covers centralizing shared policy and targets, Directory.Packages.props across projects, parent hierarchy/import structure, props-versus-targets placement, and folder/project exceptions. An existing hierarchy…

Its SKILL.md is about 2.8k tokens, which your agent loads only when the skill is triggered. The skill folder holds 4 other files, including reference files (for example `references/common-patterns.md`, `references/multi-level-examples.md` and `references/targetframework-props-pitfall.md`).

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

Example prompts

  • “/directory-build-organization”

Workflow steps

7 steps, taken from the first numbered list in SKILL.md.

  1. Audit all .csproj files — Catalog every , , and custom across the solution. Note which settings repeat and which are project-specific.
  2. Create root Directory.Build.props — Move shared property defaults (LangVersion, Nullable, TreatWarningsAsErrors, metadata) here. These are…
  3. Create root Directory.Build.targets — Move custom build targets, post-build validation, and any properties that depend on SDK-defined…
  4. Create Directory.Packages.props — Enable Central Package Management (ManagePackageVersionsCentrally), list all PackageVersion entries, and…
  5. Set up multi-level hierarchy — Create inner Directory.Build.props files for src/ and test/ folders with distinct settings. Use…
  6. Simplify .csproj files — Remove all centralized properties, version attributes, and duplicated targets. Each project should only contain…
  7. Validate — Run restore/build against the discovered .sln, .slnx,

What it can do on your machine

Read from SKILL.md and the folder at commit a660de8. 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

    Shell commands in SKILL.md call:

    • dotnet

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

  • Network

    Links to these hosts (documentation or services it may open):

    • learn.microsoft.com

    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

Directory Build Organization loads about 2.8k tokens when it runs, and up to ~5k if it reads all its reference files. Until then it costs about 182 tokens; SKILL.md has 904 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~182
When it runs · the whole SKILL.md, loaded when a task matches
~2.8k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~5k

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 passed

The automated check found no risky patterns in SKILL.md.

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 a660de8, republished under its MIT licence (© dotnet). 904 words, ~2,754 tokens.

Download SKILL.mdSave it as .claude/skills/directory-build-organization/SKILL.md (or your agent's skills folder). This skill also uses 3 other files; get the full folder from GitHub.
name
directory-build-organization
description
USE ONLY for (1) two or more projects with repeated MSBuild policy, targets, or package versions, or (2) an existing Directory.Build.props/targets/rsp hierarchy with an import, placement, or layering defect. A one-project repo without an existing Directory.Build file is outside scope; do not load this skill. Covers centralizing shared policy and targets, Directory.Packages.props across projects, parent hierarchy/import structure, props-versus-targets placement, and folder/project exceptions. An existing hierarchy defect remains in scope when only one project is affected. For property value or condition semantics use property-patterns. Exclude legacy-to-SDK migration and non-MSBuild systems.
license
MIT

Organizing Build Infrastructure with Directory.Build Files

Intent control

  • For "should we", "how should we organize", "recommend", "advise", or review requests, inspect the actual project files and return a proposed layout only. Do not create or edit files unless the user explicitly asks to apply, move, centralize, or clean up the configuration.
  • Before summarizing, verify which project retains each project-specific property, item, or target. Name the actual file; do not infer it from sibling names.
  • Recommend a verification command only after discovering a real .sln, .slnx, .proj, or project file at that path. If no repo-root entry point exists, give commands for the discovered projects or state that the entry point was not found.
  • Every advice response must explain that Microsoft.Common.props searches upward from each project and automatically imports the nearest Directory.Build.props early; project values can then override shared defaults. Explain the equivalent late Microsoft.Common.targets import when recommending Directory.Build.targets.

Directory.Build.props vs Directory.Build.targets

Understanding which file to use is critical. They differ in when they are imported during evaluation:

Evaluation order:

Microsoft.Common.props imports Directory.Build.props early
→ project body and package/project imports evaluate
→ Microsoft.Common.targets imports Directory.Build.targets late
Use .props forUse .targets for
Setting property defaultsCustom build targets
Common item definitionsLate-bound property overrides
Properties projects can overridePost-build steps
Assembly/package metadataConditional logic on final values
Analyzer PackageReferencesTargets that depend on SDK-defined properties

Rule of thumb: Properties and items go in .props. Custom targets and late-bound logic go in .targets.

Because .props is imported before the project file, the project can override any value set there. Because .targets is imported after everything, it gets the final say—but projects cannot override .targets values.

⚠️ Critical: TargetFramework Availability in .props vs .targets

Property conditions on $(TargetFramework) in .props files silently fail for single-targeting projects — the property is empty during .props evaluation. Move TFM-conditional properties to .targets instead. ItemGroup and Target conditions are not affected.

See targetframework-props-pitfall.md for the full explanation.

Directory.Build.props

Good candidates: language settings, assembly/package metadata, build warnings, code analysis, common analyzers.

xml
<Project>
  <PropertyGroup>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
    <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
    <EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>
    <Company>Contoso</Company>
    <Authors>Contoso Engineering</Authors>
  </PropertyGroup>
</Project>

Do NOT put here: project-specific TFMs, project-specific PackageReferences, targets/build logic, or properties depending on SDK-defined values (not available during .props evaluation).

Directory.Build.targets

Good candidates: custom build targets, late-bound property overrides (values depending on SDK properties), post-build validation.

xml
<Project>
  <Target Name="ValidateProjectSettings" BeforeTargets="Build">
    <Error Text="All libraries must target netstandard2.0 or higher"
           Condition="'$(OutputType)' == 'Library' AND '$(TargetFramework)' == 'net472'" />
  </Target>

  <PropertyGroup>
    <!-- DocumentationFile depends on OutputPath, which is set by the SDK -->
    <DocumentationFile Condition="'$(IsPackable)' == 'true'">$(OutputPath)$(AssemblyName).xml</DocumentationFile>
  </PropertyGroup>
</Project>

Directory.Packages.props (Central Package Management)

Central Package Management (CPM) provides a single source of truth for all NuGet package versions. See https://learn.microsoft.com/en-us/nuget/consume-packages/central-package-management for details.

Enable CPM in Directory.Packages.props at the repo root:

xml
<Project>
  <PropertyGroup>
    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
  </PropertyGroup>

  <ItemGroup>
    <PackageVersion Include="Microsoft.Extensions.Logging" Version="8.0.0" />
    <PackageVersion Include="Newtonsoft.Json" Version="13.0.3" />
    <PackageVersion Include="xunit" Version="2.9.0" />
    <PackageVersion Include="xunit.runner.visualstudio" Version="2.8.2" />
  </ItemGroup>

  <ItemGroup>
    <!-- GlobalPackageReference applies to ALL projects — great for analyzers -->
    <GlobalPackageReference Include="StyleCop.Analyzers" Version="1.2.0-beta.556" />
    <GlobalPackageReference Include="Microsoft.CodeAnalysis.NetAnalyzers" Version="8.0.0" />
  </ItemGroup>
</Project>

Directory.Build.rsp

Contains default MSBuild CLI arguments applied to all builds under the directory tree.

Example Directory.Build.rsp:

/maxcpucount
/nodeReuse:false
/consoleLoggerParameters:Summary;ForceNoAlign
/warnAsMessage:MSB3277
  • Works with both msbuild and dotnet CLI in modern .NET versions
  • Great for enforcing consistent CI and local build flags
  • Each argument goes on its own line

Multi-level Directory.Build Files

MSBuild only auto-imports the first Directory.Build.props (or .targets) it finds walking up from the project directory. To chain multiple levels, explicitly import the parent at the top of the inner file. See multi-level-examples for full file examples.

xml
<Project>
  <Import Project="$([MSBuild]::GetPathOfFileAbove('Directory.Build.props', '$(MSBuildThisFileDirectory)../'))"
         Condition="Exists('$([MSBuild]::GetPathOfFileAbove('Directory.Build.props', '$(MSBuildThisFileDirectory)../'))')" />

  <!-- Inner-level overrides go here -->
</Project>

Example layout:

repo/
  Directory.Build.props          ← repo-wide (lang version, company info, analyzers)
  Directory.Build.targets        ← repo-wide targets
  Directory.Packages.props       ← central package versions
  src/
    Directory.Build.props        ← src-specific (imports repo-level, sets IsPackable=true)
  test/
    Directory.Build.props        ← test-specific (imports repo-level, sets IsPackable=false, adds test packages)

Artifact Output Layout (.NET 8+)

Set <ArtifactsPath>$(MSBuildThisFileDirectory)artifacts</ArtifactsPath> in Directory.Build.props to automatically produce project-name-separated bin/, obj/, and publish/ directories under a single artifacts/ folder, avoiding bin/obj clashes by default. See common-patterns for the directory layout and additional patterns (conditional settings by project type, post-pack validation).

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

Workflow: Organizing Build Infrastructure

  1. Audit all .csproj files — Catalog every <PropertyGroup>, <ItemGroup>, and custom <Target> across the solution. Note which settings repeat and which are project-specific.
  2. Create root Directory.Build.props — Move shared property defaults (LangVersion, Nullable, TreatWarningsAsErrors, metadata) here. These are imported before the project file so projects can override them.
  3. Create root Directory.Build.targets — Move custom build targets, post-build validation, and any properties that depend on SDK-defined values (e.g., OutputPath, TargetFramework for single-targeting projects) here. These are imported after the SDK so all properties are available.
  4. Create Directory.Packages.props — Enable Central Package Management (ManagePackageVersionsCentrally), list all PackageVersion entries, and remove Version= from PackageReference items in .csproj files.
  5. Set up multi-level hierarchy — Create inner Directory.Build.props files for src/ and test/ folders with distinct settings. Use GetPathOfFileAbove to chain to the parent.
  6. Simplify .csproj files — Remove all centralized properties, version attributes, and duplicated targets. Each project should only contain what is unique to it.
  7. Validate — Run restore/build against the discovered .sln, .slnx, .proj, or project path, for example dotnet restore <entrypoint> && dotnet build <entrypoint>. If no root entrypoint exists, validate each discovered project explicitly instead of claiming a repo-root build. Use dotnet msbuild <project> -pp:output.xml to inspect the final merged view.

Troubleshooting

ProblemCauseFix
Directory.Build.props isn't picked upFile name casing wrong (exact match required on Linux/macOS)Verify exact casing: Directory.Build.props (capital D, B)
Properties from .props are ignored by projectsProject sets the same property after the importMove the property to Directory.Build.targets to set it after the project
Multi-level import doesn't workMissing GetPathOfFileAbove import in inner fileAdd the <Import> element at the top of the inner file (see Multi-level section)
Properties using SDK values are empty in .propsSDK properties aren't defined yet during .props evaluationMove to .targets which is imported after the SDK
Directory.Packages.props not foundFile not at repo root or not named exactlyMust be named Directory.Packages.props and at or above the project directory
Property condition on $(TargetFramework) doesn't match in .propsTargetFramework isn't set yet for single-targeting projects during .props evaluationMove property to .targets, or use ItemGroup/Target conditions instead (which evaluate late)

Diagnosis: Use the preprocessed project output to see all imports and final property values:

bash
dotnet msbuild -pp:output.xml MyProject.csproj

This expands all imports inline so you can see exactly where each property is set and what the final evaluated value is.

© 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

SKILL.md and 3 other files (references) in plugins/dotnet-msbuild/skills/directory-build-organization of dotnet/skills.

  • SKILL.md
  • references/common-patterns.md
  • references/multi-level-examples.md
  • references/targetframework-props-pitfall.md

Open the folder on GitHubat commit a660de8

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

Directory Build Organization 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.

Directory Build Organization compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Directory Build Organization this skilldotnet/skills5.6k1 repos~2.8kAutomated safety check: PassMIT
Minimax DOCXpoco-ai/poco-claw1.4k7 repos~3.9kAutomated safety check: PassMIT
Microsoft Skill CreatorMicrosoftDocs/mcp1.9k3 repos~2.1kAutomated safety check: PassCC-BY-4.0
Speckit ConstitutionWeihanLi/WeihanLi.Common24211 repos~2.1kAutomated safety check: PassApache-2.0
Copilot Session Failure Analysisdotnet/maui23k—~3.4kAutomated safety check: PassMIT
Microsoft Code ReferenceMicrosoftDocs/mcp1.9k4 repos~1.1kAutomated safety check: PassCC-BY-4.0

Similar skills

  • Minimax DOCX

    poco-ai/poco-claw

    Professional DOCX document creation, editing, and formatting using OpenXML SDK (.NET).

    1.4k GitHub starsUsed in 7 repos~3.9k tokens
    Documents & OfficeAuto-check passed

  • Microsoft Skill Creator

    MicrosoftDocs/mcp

    Official

    Create agent skills for Microsoft technologies using official documentation.

    1.9k GitHub starsUsed in 3 repos~2.1k tokens
    Agent WorkflowsAuto-check passed

  • Speckit Constitution

    WeihanLi/WeihanLi.Common

    Create or update the project constitution from interactive or provided principle inputs, ensuring all dependent templates stay in sync.

    242 GitHub starsUsed in 11 repos~2.1k tokens
    DevelopmentAuto-check passed

  • Copilot Session Failure Analysis

    dotnet/maui

    Official

    Mines local Copilot CLI session logs for dotnet/maui to rank costly or failing runs, tag recurring failure modes, propose repo edits and emit guard evals.

    23k GitHub stars~3.4k tokensUpdated today
    Agent WorkflowsAuto-check passed

  • Microsoft Code Reference

    MicrosoftDocs/mcp

    Official

    Find working code samples, verify API signatures, and fix Microsoft SDK errors using official docs.

    1.9k GitHub starsUsed in 4 repos~1.1k tokens
    DevelopmentAuto-check passed

  • Update .NET OS Packages

    dotnet/core

    Official

    Audits and updates os-packages.json files listing the Linux packages each .NET release needs per distro, then regenerates the Markdown from the JSON.

    22k GitHub stars~2.3k tokensUpdated today
    DevelopmentAuto-check passed

More from dotnet/skills

All 91 skills in this repo

  • Apple Crash Log .NET Symbolication

    dotnet/skills

    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

  • Android Tombstone Symbolication

    dotnet/skills

    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

  • Analyzing .NET Performance

    dotnet/skills

    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

  • Find Untested Sources

    dotnet/skills

    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

  • .NET Native AOT Compatibility

    dotnet/skills

    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 Directory Build Organization

What does Directory Build Organization do?

USE ONLY for (1) two or more projects with repeated MSBuild policy, targets, or package versions, or (2) an existing Directory.Build.props/targets/rsp hierarchy with an import, placement, or…. Directory Build Organization is an agent skill from dotnet/skills, published by the product's own GitHub organization.props/targets/rsp hierarchy with an import, placement, or layering defect.

How do I install Directory Build Organization in Claude Code?

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

How do I install Directory Build Organization in Codex?

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

Can I use Directory Build Organization 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 directory-build-organization -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/directory-build-organization, .gemini/skills/directory-build-organization, .github/skills/directory-build-organization and .opencode/skills/directory-build-organization in your project.

What does Directory Build Organization need to run?

Going by SKILL.md and its folder, Directory Build Organization needs the command-line tools its instructions call (dotnet).

Does Directory Build Organization access the network?

SKILL.md names 1 domain. As links in the text: learn.microsoft.com. This is read from the text; nothing was executed.

Is Directory Build Organization safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Directory Build Organization use?

Directory Build Organization 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 Directory Build Organization use?

About 2.8k tokens (SKILL.md is roughly 11k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 2.2k tokens, read only when the agent opens those files.

What are the alternatives to Directory Build Organization?

Skills that share tags, products or a category with Directory Build Organization: Minimax DOCX (poco-ai/poco-claw, 1.4k stars), Microsoft Skill Creator (MicrosoftDocs/mcp, 1.9k stars), Speckit Constitution (WeihanLi/WeihanLi.Common, 242 stars) and Copilot Session Failure Analysis (dotnet/maui, 23k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Directory Build Organization?

dotnet (a GitHub organization, an official publisher) maintains it in dotnet/skills, which has 5,576 GitHub stars. The repository holds 91 skills in this directory. The repository was last updated on October 8, 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.