CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

integrating-sdk-and-msbuild

Guides work on the SDK-MSBuild integration boundary. Consult when authoring or modifying SDK targets, working on dotnet CLI to MSBuild invocation, handling project-reference protocol, coordinating cross-repo changes with dotnet/sdk, debugging property resolution or import ordering, working on restore/build/publish/pack target chains, or dealing with Directory.Build.props/targets interaction.

Quality

92%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

82%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A well-crafted, expert-level patterns skill: dense with boundary-specific rules, concrete XML/CLI examples, and a useful symptom→cause diagnostic table, with no filler. The main gaps are minor — a couple of named patterns (incremental Inputs/Outputs, extension-point usage) lack executable examples, and the ~110-line body could shed detail into a one-level-deep reference file to keep SKILL.md a leaner overview.

Suggestions

Add a minimal working target snippet demonstrating correct incremental Inputs/Outputs declarations, since rule 3 requires them but no example is given (actionability).

Show a short example of extending $(BuildDependsOn) versus using BeforeTargets="Build" in the extension-points table (actionability).

Move the detailed evaluation-order semantics and design-time build contracts into a one-level-deep references/ file so SKILL.md stays a lean overview (progressive_disclosure).

DimensionReasoningScore

Conciseness

The body is lean and rule-dense: evaluation-order diagram, a minimal CORRECT/WRONG XML pair, compact tables for extension points and symptom→cause mapping, with no padding or explanation of concepts Claude already knows beyond one justifiable framing sentence ("MSBuild operates as a component within the .NET SDK..."). It matches 'Lean and efficient; assumes Claude's competence; every token earns its place'; it is above level 4, where noticeable over-explanation would remain.

5 / 5

Actionability

Mostly executable guidance: copy-paste XML (`<OutputType Condition="'$(OutputType)' == ''">Library</OutputType>`), concrete CLI invocations (`dotnet build --no-restore`, the `/t:Restore;Build` anti-pattern), and real target/property names (`_GetProjectReferenceTargetFrameworkProperties`, `SetTargetPath`/`GetTargetPath`, `SetTargetFramework`). It falls short of level 5 because some named rules lack a runnable example — e.g. incremental build `Inputs`/`Outputs` declarations are required by rule 3 but no sample target is shown, and the extension-points table gives no usage snippet.

4 / 5

Workflow Clarity

The multi-step processes are clearly sequenced — the project-reference protocol (outer dispatch → inner build → GetTargetPath) and the four-step cross-repo coordination protocol ending in "Test end-to-end with the SDK's MSBuild integration tests" — and the multi-targeting test checkpoint is stated. It is not level 5 because there are no explicit error-recovery feedback loops (e.g. what to do when the end-to-end test fails) and the symptom→cause table aids diagnosis without prescribing a verification sequence. It clears level 3, which requires missing or merely implicit checkpoints.

4 / 5

Progressive Disclosure

No bundle files exist (no references/, scripts/, or assets/ directories), so the skill is self-contained with no nested references to get lost in; section headers, tables, and the evaluation-order diagram make navigation easy. It scores 4 rather than 5 because at ~110 body lines the detailed reference material (full evaluation-order semantics, design-time build contracts, the bug table) is approaching the point where a one-level-deep reference file would keep SKILL.md as a leaner overview — the 5-anchor's ideal split is not fully realized; it is well above level 3, where structure would be genuinely disorganized or content clearly misplaced.

4 / 5

Total

17

/

20

Passed

Description

100%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

An exemplary description: third-person, concise, and dense with concrete domain-specific actions and trigger terms. Both the capability ('what') and the invocation conditions ('when') are explicit, and the terminology is exactly what a developer at this boundary would use. No changes needed.

DimensionReasoningScore

Specificity

The description enumerates multiple concrete actions — "authoring or modifying SDK targets", "handling project-reference protocol", "coordinating cross-repo changes with dotnet/sdk", "debugging property resolution or import ordering", "working on restore/build/publish/pack target chains", "dealing with Directory.Build.props/targets interaction" — comprehensively covering the SDK-MSBuild boundary domain. This matches the anchor 'Lists multiple specific concrete actions; comprehensive coverage'; it is not level 4, where minor coverage gaps would remain.

5 / 5

Completeness

It answers "what" ("Guides work on the SDK-MSBuild integration boundary") and "when" explicitly via the "Consult when ... or dealing with Directory.Build.props/targets interaction" clause with a long disjunction of concrete trigger scenarios. This is the anchor 'Clearly and explicitly answers both what AND when with concrete trigger phrases'; a 4 would require the when-clause to be less explicit, which it is not.

5 / 5

Trigger Term Quality

Natural trigger keywords a user would actually say are well covered with synonyms and concrete file/flag names: "SDK targets", "dotnet CLI", "MSBuild invocation", "project-reference protocol", "property resolution", "import ordering", "restore/build/publish/pack", "Directory.Build.props/targets". It sits at the anchor 'Comprehensive coverage of natural terms including synonyms and file extensions' rather than level 4, where common phrasings would be missing.

5 / 5

Distinctiveness Conflict Risk

It carves out a clear niche (the SDK-MSBuild integration boundary) with distinct triggers — project-reference protocol, Directory.Build.props/targets, cross-repo coordination with dotnet/sdk — that would rarely collide with other skills. Minimal conflict risk per the top anchor, not the level-4 anchor that presumes overlap with closely related skills.

5 / 5

Total

20

/

20

Passed

Validation

93%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

15

/

16

Passed

Repository

dotnet/msbuild

Path

.github/skills/integrating-sdk-and-msbuild/SKILL.md

Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.