Csharp Docs
Add consistent XML documentation to C# public and internal APIs so generated docs and IDE tooltips stay clear for solo-maintained .NET codebases.
Overview
csharp-docs is an agent skill most often used in Build (also Ship) that ensures C# types and members use XML documentation comments following Microsoft documentation best practices.
Install
npx skills add https://github.com/github/awesome-copilot --skill csharp-docsWhat is this skill?
- Present-tense third-person `<summary>` for every documented member
- `<remarks>`, `<example>`, and `<code language="csharp">` for usage and context
- `<see cref>`, `<seealso>`, and `<inheritdoc/>` for cross-references and inheritance
- `<param>`, `<returns>`, and `<exception>` patterns for methods
- Guidance for `<see langword>` and `<c>` inline code and keywords
Adoption & trust: 8.9k installs on skills.sh; 34.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your .NET code ships without consistent XML comments, so generated API docs and IDE help are empty or misleading.
Who is it for?
Indie builders maintaining a C# API, SDK, or backend service who want doc generation and Copilot hints to stay accurate as the codebase evolves.
Skip if: Greenfield prototypes where you intentionally defer all documentation until after product-market fit with no published API surface.
When should I use this skill?
User needs C# types documented with XML comments and documentation best practices for public or internal APIs.
What do I get? / Deliverables
Public and complex internal members gain structured XML comments with summaries, examples, and cross-references suitable for published or team-consumed API documentation.
- XML comments on targeted types and members
- Examples and cross-references aligned with doc generator output
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
API documentation quality is decided while you write types and methods, not only at launch-time doc passes. Docs is the canonical shelf for XML comment standards—even when the code lives in backend services.
Where it fits
Add `<summary>` and `<param>` tags while implementing a new service interface in a solo SaaS backend.
Document complex internal helpers with `<remarks>` so agent-assisted refactors do not drop behavioral nuance.
Check pull requests for missing XML on newly public members before merging to main.
Polish cref and example blocks before publishing NuGet XML documentation to GitHub Pages.
How it compares
Use for inline XML comment standards on C# members, not for writing end-user manuals or OpenAPI-only HTTP descriptions.
Common Questions / FAQ
Who is csharp-docs for?
Solo and small-team .NET developers who want IDE and generated docs to reflect real behavior on public and important internal APIs.
When should I use csharp-docs?
During Build while adding types and methods; during Ship review before merging API changes; when refreshing XML before a NuGet or internal package release.
Is csharp-docs safe to install?
It guides comment text only—review the Security Audits panel on this Prism page for the hosting skill package like any other catalog entry.
SKILL.md
READMESKILL.md - Csharp Docs
# 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 conditio