A Claude Code skill is a reusable procedure that the agent can load for a particular task. For .NET developers, a useful first skill is not a miniature platform or a universal architecture guide. It is a bounded workflow you already repeat: inspect an endpoint change, identify affected contracts, and produce a review report that separates evidence from assumptions.
That distinction keeps the skill understandable. Repository facts describe what the solution is. A skill describes how to perform a recurring job. Permissions determine which tools may run. A reviewable workflow needs all three, but a skill file does not replace the other two.
Information checked October 9, 2026 against the current Claude Code skills reference. Frontmatter and loading behavior are volatile details; consult that reference when adopting or changing a skill. The examples below have not been exercised.
Choose a procedure with a visible output
Start with a job whose result a developer can inspect. “Improve code quality” is too broad. “Review the changed endpoint for validation, authorization, response shape, persistence effects, and missing verification” is specific enough to guide discovery and evaluate the output.
The skill should have a clear input, a bounded procedure, and a recognizable result. Here the input is the current diff in an existing ASP.NET Core repository. The procedure traces changed behavior into real collaborating code. The result is a concise report with file references, supported findings, and unrun checks.
This does not mean every review must use the same checklist. A library API, worker service, and HTTP endpoint have different boundaries. Name the skill for its actual job and avoid expanding it whenever a neighboring task appears.
There are two plausible starting points. A general review skill is reusable across more projects but needs the model to rediscover conventions. A project-specific endpoint-review skill can reference known modules and test patterns but requires maintenance when the repository changes. For a first team workflow, specificity often makes the procedure easier to audit.
The broader distinction between reusable procedures and other customization surfaces is explored in custom agents and skills for a terminal coding agent. That article concerns another client, so its file conventions should not be copied as Claude Code configuration.
Separate repository facts from workflow instructions
A target framework, solution path, and central package-management policy are repository facts. They belong in the repository's established instruction surface or in source files the skill reads. A review sequence belongs in the skill.
Duplicating the same facts in several places creates drift. If a skill hardcodes a test project that later moves, the workflow can quietly inspect the wrong surface. Prefer pointing it toward the authoritative manifest and requiring it to read what exists.
The skill also should not redefine the project's architecture. If the repository uses vertical slices, the skill can ask the agent to identify the relevant slice and preserve its conventions. It should not instruct every task to create repositories, services, validators, and mapping layers regardless of existing code.
This matters for .NET solutions where a visible controller or endpoint may be only the entry point. The behavior can depend on middleware, domain methods, persistence, serialization, or background work. ASP.NET Core middleware and processing-pipeline boundaries provide useful context for thinking about those collaborating surfaces.
A good skill directs investigation without pretending that the checklist already knows the answer. It says what evidence to look for and how to report missing evidence.
Put the skill in project scope
The official documentation identifies .claude/skills/<skill-name>/SKILL.md as the project location. A skill's Markdown body contains its procedure, while YAML frontmatter provides fields such as its name, description, and invocation controls.
Project scope is appropriate when the procedure belongs to a repository and should be reviewed with its source. A personal skill can be useful across projects, but it is not a reliable way to distribute a shared team workflow. The documentation also describes enterprise and plugin locations; those are unnecessary for this first example.
Here is an unexercised PowerShell preparation command for a sanitized checkout:
New-Item -ItemType Directory -Force -Path 'C:\work\Shipping\.claude\skills\review-dotnet-endpoint'
The command creates only the skill directory. It does not configure tool permissions, install packages, or register a server. Creating a directory is not proof that a session has discovered its contents.
The current docs say a newly created top-level skills directory may need /reload-skills if it did not exist when the session started. Existing watched skill directories have live detection for SKILL.md text. Check the installed client's behavior rather than assuming that every customization file reloads the same way.
Project skill discovery also depends on where the session starts and applicable policy. Keep the first example at the repository root to avoid teaching nested discovery and worktree fallback as prerequisites for a simple procedure.
Write one complete, bounded SKILL.md
Save the following illustrative content as .claude\skills\review-dotnet-endpoint\SKILL.md. It intentionally requests review rather than edits or execution. The procedure is useful even when validation belongs on a separate remote runner.
---
name: review-dotnet-endpoint
description: Review a changed ASP.NET Core endpoint and its affected contracts. Use when a developer requests endpoint-change review.
disable-model-invocation: true
---
Review the current endpoint change without editing files.
Read the repository instructions and relevant project manifests.
Inspect the diff and identify the endpoint's existing behavior.
Trace validation, authorization, response mapping, and persistence
through the real collaborating code.
For each changed contract, identify the assertion that would fail
if the requested behavior were absent. Do not treat a test name,
mock arrangement, or passing summary as proof.
Do not run builds, tests, migration commands, deployment commands,
or external write tools unless separately authorized for this task.
Do not create commits or publish changes.
Return:
- Scope: changed endpoint and relevant collaborating files.
- Findings: concrete behavior, file reference, and supporting evidence.
- Verification: checks actually run, with results and environment.
- Gaps: proposed checks, assumptions, and missing infrastructure.
If there are no supported findings, say so. Do not invent defects
to fill the report, and do not describe unrun checks as passing.
The frontmatter uses documented fields. disable-model-invocation: true prevents Claude from automatically loading this skill; the user can invoke it explicitly. That is appropriate for an intentionally requested review procedure.
The body has a narrower purpose than a general coding prompt. It tells the agent what to inspect and how to report its conclusions. It also names operations that are outside the procedure. Those instructions are guidance, not a replacement for permissions or environmental isolation.
Notice what is absent: no broad allowed-tools grant, no deployment command, no orchestration, and no hook registration. Optional fields are useful when needed, but including them in a first example can hide the basic model under unrelated capabilities.
The skill is not guaranteed to find every defect. It makes expectations explicit and repeatable so a developer can judge whether the resulting review followed the intended boundary.
Invoke the skill and inspect what actually loaded
The skills reference documents invocation with /skill-name. In an interactive Claude Code session for this project, invoke the procedure with:
/review-dotnet-endpoint
This example is an invocation, not a shell command. It should be typed at the Claude Code prompt. A terminal trying to execute it as a filesystem path is using the wrong surface.
Use /skills to inspect the available skills when diagnosing discovery. A missing skill can indicate the wrong directory, an unavailable setting source, a frontmatter problem, or applicable organization policy. Do not immediately duplicate the file into several locations.
Names can collide. The current reference says personal skills take precedence over project skills with the same name, with enterprise precedence above both. A unique, descriptive project name reduces the chance of invoking a different procedure accidentally.
Invocation is only one part of acceptance. Read the resulting report and check whether it inspected the intended diff, referenced relevant files, and distinguished unrun checks. A skill that appears in the menu but produces an unsupported conclusion is not validated merely because discovery worked.
Keep supporting material deliberate
A skill directory can contain supporting files. That can be useful when the procedure needs a repository-specific reference checklist or report format. The body should tell the agent when and why to read each file rather than treating the folder as an unlimited knowledge dump.
For example, an endpoint-review reference could explain the repository's established error response format and where authorization policies live. It should point to authoritative code or documentation rather than duplicate a long list that will become stale.
The simplest path is often a single SKILL.md until the procedure becomes difficult to maintain. Splitting too early introduces indirection: reviewers must jump between files to understand a short workflow. Keeping everything inline has the opposite cost once the body becomes a large manual.
Choose based on the size and stability of the material. A small output contract belongs in the body. A long domain reference that changes independently may deserve a separate file.
Do not put credentials, connection strings, or private infrastructure details into a reusable skill. Procedure reuse should not become credential distribution. External access belongs in the appropriate client configuration and execution identity.
Avoid executable context until it serves a real need
The official skills reference documents dynamic context injection, where a command embedded in skill content runs and its output becomes part of the prompt. That can provide a live diff or current status, but it also changes the file from passive instructions into a source of executable behavior.
For a first review skill, asking Claude to inspect the diff through approved tools is easier to reason about. It avoids hiding execution in a file that appears to be documentation.
If dynamic injection later becomes useful, review the command as code. Identify its working directory, input, output, side effects, and permissions. An apparently read-only script can invoke helpers or custom tooling with broader effects.
Non-interactive execution adds another consideration. The current headless reference says bare mode skips automatic skill discovery. A workflow that depends on a project skill should not assume that a bare session loads it implicitly.
That difference is not a defect. Bare mode favors explicit startup configuration, while ordinary project sessions can discover repository customizations. State which environment the procedure expects, and avoid pretending one launch command fits both.
Validate the procedure with contrasting cases
Skill validation is about behavior, not just YAML parsing. Use cases that expose whether the report can distinguish supported findings from guesses. A small endpoint change with a missing validation test is a useful case. So is a change with existing adequate coverage and no demonstrated defect.
The second case matters. A skill that always emits warnings can look thorough while inventing problems. The procedure should allow an honest “no supported findings” result and still explain its inspected scope.
For verification gaps, provide a scenario where tests cannot run. The report should name the missing environment and keep proposed commands separate from executed results. Meaningful unit and integration coverage helps identify which boundary a proposed check would exercise.
For a permission boundary, deny an operation that the skill might otherwise request. The expected response is a clear limitation, not a fallback that quietly changes the intended check or claims success.
These are proposed validation cases, not tests performed for this article. Actual adoption should collect outputs from the installed client under the repository's authorized execution policy.
Maintain the skill as part of the workflow
Review a skill when the repository's conventions or validation topology changes. A moved test project, a new error format, or a different authorization mechanism can invalidate assumptions even when the skill's frontmatter remains valid.
Avoid adding every discovered lesson permanently. Some details belong to a single task, while others describe a recurring contract. A skill should preserve the repeatable procedure and leave task-specific facts in the task report.
The existing .NET terminal-agent workflow article is relevant here: useful automation remains bounded and reviewable. Reusable instructions improve consistency, but they do not eliminate the need to evaluate the produced changes.
A skill also should not accumulate release authority because review often happens near a commit. Reviewing a diff, committing it, pushing it, and deploying it are separate actions. Keep those boundaries visible rather than combining them into one convenient command.
Frequently asked questions
What is a Claude Code skill?
It is a reusable Markdown procedure with optional YAML frontmatter. The current documentation describes automatic loading when relevant and explicit invocation with /skill-name. A skill can provide reference knowledge or guide a bounded task.
Where should a team store a .NET skill?
For a repository-specific procedure, use the documented project location, .claude/skills/<skill-name>/SKILL.md. Review it alongside repository changes. Personal skills are useful locally but are not the same as a shared project procedure.
Does disable-model-invocation prevent manual use?
No. The documented field prevents automatic model invocation while retaining user invocation. It is useful when the procedure should run only after an explicit request rather than whenever the model considers it relevant.
Does a skill enforce its no-build instruction?
Not by itself. The instruction shapes model behavior. Permissions and the execution environment determine whether tools can run. A critical prohibition should not depend solely on the model interpreting a Markdown sentence.
Should a first skill include hooks and helper scripts?
Only if the recurring job actually requires them. A single review procedure can begin with one file and an explicit output contract. Hooks and executable context introduce additional lifecycle and failure behavior that deserve separate review.
How do you know the skill works?
Observe discovery, invocation, scope adherence, and report quality across contrasting scenarios. Check that it identifies supported problems, permits no-findings results, and labels missing evidence. Parsing the file is only a configuration check.
Reuse the procedure, not the conclusion
A reusable Claude Code skill for .NET work is valuable when it makes a recurring job clearer. It can identify the input, direct relevant investigation, and require evidence-shaped output without broadening authority.
The conclusion must still come from the current repository and task. A skill helps the agent ask the right questions; it does not precompute the answers.