PaperclipOrg
Claude Agent Skill · by Github

Csharp Docs

The csharp-docs skill ensures that C# types and members are documented with XML comments according to best practices, providing developers with standardized gui

Install
Terminal · npx
$npx skills add https://github.com/github/awesome-copilot --skill csharp-docs
Works with Paperclip

How Csharp Docs fits into a Paperclip company.

Csharp Docs drops into any Paperclip agent that handles this kind of work. Assign it to a specialist inside a pre-configured PaperclipOrg company and the skill becomes available on every heartbeat — no prompt engineering, no tool wiring.

S
SaaS FactoryPaired

Pre-configured AI company — 18 agents, 18 skills, one-time purchase.

$27$59
Explore pack
Source file
SKILL.md62 lines
Expand
---name: csharp-docsdescription: '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."