csharp-docs — GitHub Copilot skill: XML documentation
Guides XML documentation for C# types and members. Use it when a project needs consistent API comments and tag conventions.
npx skills add github/awesome-copilot --skill csharp-docsWhat csharp-docs does
This skill guides GitHub Copilot when it documents C# code. Public members should receive XML comments, while internal members are worth documenting when their behaviour or implementation is hard to infer. It uses <summary> for concise descriptions and <remarks> for supporting detail.
The guidance covers <param>, <typeparam>, and <returns> on methods, plus Gets, Gets or sets, and <value> wording for properties. It also covers references with <see cref>, examples using <example> and <code language="csharp">, inherited comments via <inheritdoc/>, and exception descriptions with <exception cref>.
Requiring comments on every public member means API additions will need more documentation work. That is a reason to check whether the repository follows the same convention.
What it helps with
- add XML comments to public C# members
- describe method parameters and return values
- write documentation for properties and constructors
- record exceptions callers may encounter
- add API references and code examples to comments
Example prompts for the agent
- “Add XML documentation to the public types and methods in `ApiClient.cs`.”
- “Review the C# comments in `Settings.cs` and apply the skill’s documentation rules.”
- “Document parameters and exceptions for the methods in `Parser.cs`.”
How to install csharp-docs
1Skills CLI (Vercel)
npx skills add github/awesome-copilot --skill csharp-docs2GitHub CLI
gh skill install github/awesome-copilot csharp-docs3Manually: put the files in place
.github/skills/csharp-docs/SKILL.md1Skills CLI (Vercel)
npx skills add github/awesome-copilot --skill csharp-docs -a claude-code2Manually: put the files in place
~/.claude/skills/csharp-docs/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/csharp-docs/
Manually: put the files in place
.agents/skills/csharp-docs/SKILL.mdFor all projects use ~/.agents/skills/
Manually: put the files in place
.cursor/skills/csharp-docs/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
Platform CLI
gemini skills install https://github.com/github/awesome-copilot --path skills/csharp-docsManually: put the files in place
.devin/skills/csharp-docs/SKILL.mdThe legacy .windsurf/skills/ path still works
Claude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
From the same set554
The whole set →Similar
Questions about csharp-docs
How do I install csharp-docs in GitHub Copilot?
Run npx skills add github/awesome-copilot --skill csharp-docs.
What does csharp-docs do?
The skill provides XML comment guidance for C# types, methods, properties, and exceptions. It helps keep API documentation wording and XML tags consistent.
How does csharp-docs handle inherited documentation?
It uses <inheritdoc/> for members that inherit documentation from a base class or interface. When behaviour changes substantially, the differences should be documented separately.
Source text
SKILL.md · MIT
--- 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."
© github · MIT · github/awesome-copilot