csharp-docs

github/awesome-copilot

Ensure C# types are documented with XML comments following best practices.

What is csharp-docs?

This skill enforces XML documentation standards for C# code, ensuring public and internal members are properly documented with summaries, remarks, parameters, and examples. Use it to maintain consistent, high-quality API documentation across your C# projects.

Document public members with XML comments including summary, remarks, and examples
Use structured XML tags (<summary>, <param>, <returns>, <exception>) for consistent documentation
Apply language-specific guidance for methods, properties, constructors, and generic types
Reference other types and members inline using <see cref> and <seealso> tags
Document method parameters with proper noun phrases and conditional logic for Boolean/enum types
Describe exceptions with clear conditions for when they are thrown

How to install csharp-docs

npx skills add https://github.com/github/awesome-copilot --skill csharp-docs

Claude Code

Cursor

Windsurf

Cline

How to use csharp-docs

1.Review the C# type or member that needs documentation
2.Add a <summary> tag with a brief, present-tense description starting with a verb
3.For methods, add <param> tags for each parameter using noun phrases and appropriate conditional wording
4.For methods, add <returns> tag describing the return value as a noun phrase
5.For properties, use 'Gets or sets...' or 'Gets...' in the summary and add <value> tag
6.Add <exception cref> tags for exceptions thrown directly by the member
7.Include <remarks> for implementation details or usage notes
8.Add <example> and <code> tags with language attribute for usage examples

Use cases

Good for

Adding XML documentation to existing C# libraries before publishing to NuGet
Ensuring API documentation consistency across a team's codebase
Documenting complex internal members to improve code maintainability
Generating online API reference documentation from XML comments
Standardizing parameter and return value descriptions across method signatures

Who it's for

C# developers writing public libraries or APIs
Teams maintaining large C# codebases
Open-source project maintainers
API documentation authors

csharp-docs FAQ

Should I document internal members?

Yes, it is encouraged to document internal members, especially if they are complex or not self-explanatory.

What format should parameter descriptions use?

Parameter descriptions should be noun phrases that don't specify the data type and begin with an introductory article. For Boolean parameters, use the form '<see langword="true" /> to ...; otherwise, <see langword="false" />'.

How should I document exceptions?

Use <exception cref> tags to document exceptions thrown directly by the member. Describe the condition under which it's thrown without starting with 'Thrown if' or 'If'.

Can I inherit documentation from base classes?

Yes, use <inheritdoc/> to inherit documentation from base classes or interfaces, unless there is a major behavior change that requires documenting the differences.

What tags should I use for code examples?

Use <example> tags containing <code> tags with a language attribute, for example <code language="csharp"> for C# code blocks.

Full instructions (SKILL.md)

Source of truth, from github/awesome-copilot.

name: csharp-docs description: 'Ensure that C# types are documented with XML comments and follow best practices for documentation.'

C# Documentation Best Practices

Public members should be documented with XML comments.
It is encouraged to document internal members as well, especially if they are complex or not self-explanatory.

Guidance for all APIs

Use <summary> to provide a brief, one sentence, description of what the type or member does. Start the summary with a present-tense, third-person verb.
Use <remarks> for additional information, which can include implementation details, usage notes, or any other relevant context.
Use <see langword> for language-specific keywords like null, true, false, int, bool, etc.
Use <c> for inline code snippets.
Use <example> for usage examples on how to use the member.
- Use <code> for code blocks. <code> tags should be placed within an <example> tag. Add the language of the code example using the language attribute, for example, <code language="csharp">.
Use <see cref> to reference other types or members inline (in a sentence).
Use <seealso> for standalone (not in a sentence) references to other types or members in the "See also" section of the online docs.
Use <inheritdoc/> to inherit documentation from base classes or interfaces.
- Unless there is major behavior change, in which case you should document the differences.

Methods

Use <param> to describe method parameters.
- The description should be a noun phrase that doesn't specify the data type.
- Begin with an introductory article.
- If the parameter is a flag enum, start the description with "A bitwise combination of the enumeration values that specifies...".
- If the parameter is a non-flag enum, start the description with "One of the enumeration values that specifies...".
- If the parameter is a Boolean, the wording should be of the form "<see langword="true" /> to ...; otherwise, <see langword="false" />.".
- If the parameter is an "out" parameter, the wording should be of the form "When this method returns, contains .... This parameter is treated as uninitialized.".
Use <paramref> to reference parameter names in documentation.
Use <typeparam> to describe type parameters in generic types or methods.
Use <typeparamref> to reference type parameters in documentation.
Use <returns> to describe what the method returns.
- The description should be a noun phrase that doesn't specify the data type.
- Begin with an introductory article.
- If the return type is Boolean, the wording should be of the form "<see langword="true" /> if ...; otherwise, <see langword="false" />.".

Constructors

The summary wording should be "Initializes a new instance of the <Class> class [or struct].".

Properties

The <summary> should start with:
- "Gets or sets..." for a read-write property.
- "Gets..." for a read-only property.
- "Gets [or sets] a value that indicates whether..." for properties that return a Boolean value.
Use <value> to describe the value of the property.
- The description should be a noun phrase that doesn't specify the data type.
- If the property has a default value, add it in a separate sentence, for example, "The default is <see langword="false" />".
- If the value type is Boolean, the wording should be of the form "<see langword="true" /> if ...; otherwise, <see langword="false" />. The default is ...".

Exceptions

Use <exception cref> to document exceptions thrown by constructors, properties, indexers, methods, operators, and events.
Document all exceptions thrown directly by the member.
For exceptions thrown by nested members, document only the exceptions users are most likely to encounter.
The description of the exception describes the condition under which it's thrown.
- Omit "Thrown if ..." or "If ..." at the beginning of the sentence. Just state the condition directly, for example "An error occurred when accessing a Message Queuing API."