csharp-docs

Name: csharp-docs
Author: github

9.2kinstalls4.6kforks

How to install csharp-docs?

github/awesome-copilot/csharp-docs

$npx -y skills add github/awesome-copilot --skill csharp-docs

Installs into the current project.

Summary

Ensure that C# types are documented with XML comments and follow best practices for documentation.

Files · 1

View on GitHub

SKILL.md

1	# C# Documentation Best Practices
2
3	- Public members should be documented with XML comments.
4	- It is encouraged to document internal members as well, especially if they are complex or not self-explanatory.
5
6	## Guidance for all APIs
7
8	- 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.
9	- Use `<remarks>` for additional information, which can include implementation details, usage notes, or any other relevant context.
10	- Use `<see langword>` for language-specific keywords like `null`, `true`, `false`, `int`, `bool`, etc.
11	- Use `<c>` for inline code snippets.
12	- Use `<example>` for usage examples on how to use the member.
13	- 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">`.
14	- Use `<see cref>` to reference other types or members inline (in a sentence).
15	- Use `<seealso>` for standalone (not in a sentence) references to other types or members in the "See also" section of the online docs.
16	- Use `<inheritdoc/>` to inherit documentation from base classes or interfaces.
17	- Unless there is major behavior change, in which case you should document the differences.
18
19	## Methods
20
21	- Use `<param>` to describe method parameters.
22	- The description should be a noun phrase that doesn't specify the data type.
23	- Begin with an introductory article.
24	- If the parameter is a flag enum, start the description with "A bitwise combination of the enumeration values that specifies...".
25	- If the parameter is a non-flag enum, start the description with "One of the enumeration values that specifies...".
26	- If the parameter is a Boolean, the wording should be of the form "`<see langword="true" />` to ...; otherwise, `<see langword="false" />`.".
27	- 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.".
28	- Use `<paramref>` to reference parameter names in documentation.
29	- Use `<typeparam>` to describe type parameters in generic types or methods.
30	- Use `<typeparamref>` to reference type parameters in documentation.
31	- Use `<returns>` to describe what the method returns.
32	- The description should be a noun phrase that doesn't specify the data type.
33	- Begin with an introductory article.
34	- If the return type is Boolean, the wording should be of the form "`<see langword="true" />` if ...; otherwise, `<see langword="false" />`.".
35
36	## Constructors
37
38	- The summary wording should be "Initializes a new instance of the <Class> class [or struct].".
39
40	## Properties
41
42	- The `<summary>` should start with:
43	- "Gets or sets..." for a read-write property.
44	- "Gets..." for a read-only property.
45	- "Gets [or sets] a value that indicates whether..." for properties that return a Boolean value.
46	- Use `<value>` to describe the value of the property.
47	- The description should be a noun phrase that doesn't specify the data type.
48	- If the property has a default value, add it in a separate sentence, for example, "The default is `<see langword="false" />`".
49	- If the value type is Boolean, the wording should be of the form "`<see langword="true" />` if ...; otherwise, `<see langword="false" />`. The default is ...".
50
51	## Exceptions
52
53	- Use `<exception cref>` to document exceptions thrown by constructors, properties, indexers, methods, operators, and events.
54	- Document all exceptions thrown directly by the member.
55	- For exceptions thrown by nested members, document only the exceptions users are most likely to encounter.
56	- The description of the exception describes the condition under which it's thrown.
57	- 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."

People who liked this also viewed

6 picks

Type

grill-with-docsA relentless interview to sharpen a plan or design, which also creates docs (ADR's and glossary) as we go.SkillsJul 2026537k182k
lark-minutes飞书妙记：搜索妙记、查看妙记基础信息、下载/上传音视频、读取或编辑妙记的产物内容、改标题、替换说话人/关键词、申请妙记查看/编辑权限。当给出minute_token、本地音视频文件，要查/改/转妙记产物，或用户明确要主动申请妙记权限时使用；本地音视频转纪要/逐字稿优先走本 skill，不要用 ffmpeg/whisper 本地转写。不负责：获取会议关联妙记，或仅按自然语言标题定位纪要SkillsJul 2026379k16k
lark-markdown飞书 Markdown：查看、创建、上传、编辑和比较 Markdown 文件。当用户需要创建或编辑 Markdown 文件、读取、修改、局部 patch 或比较差异时使用。不负责将 Markdown 导入为飞书在线文档，也不负责文件搜索、权限、评论、移动、删除等云空间管理操作。SkillsJul 2026295k16k
docxUse this skill whenever the user wants to create, read, edit, or manipulate Word documents (.docx files) or Word templates (.dotx files). Triggers include: any mention of 'Word doc', 'word document', SkillsJul 2026157k163k
edit-articleSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026154k181k
lark-note飞书会议纪要（Note）直查：已知 note_id 时查询纪要详情、展示类型、关联文档 token，并读取 unified 原始逐字记录。当用户已持有 note_id，或从文档显式 vc-node-id 获得 note_id 时使用。不负责会议/日程/妙记定位、文档标题搜索或 Docx 正文读取。SkillsJul 2026154k16k

csharp-docs

9.2kinstalls4.6kforks

View on GitHub

How to install csharp-docs?

github/awesome-copilot/csharp-docs

$npx -y skills add github/awesome-copilot --skill csharp-docs

Installs into the current project.

Summary

Ensure that C# types are documented with XML comments and follow best practices for documentation.

Files · 1

View on GitHub

SKILL.md

1	# C# Documentation Best Practices
2
3	- Public members should be documented with XML comments.
4	- It is encouraged to document internal members as well, especially if they are complex or not self-explanatory.
5
6	## Guidance for all APIs
7
8	- 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.
9	- Use `<remarks>` for additional information, which can include implementation details, usage notes, or any other relevant context.
10	- Use `<see langword>` for language-specific keywords like `null`, `true`, `false`, `int`, `bool`, etc.
11	- Use `<c>` for inline code snippets.
12	- Use `<example>` for usage examples on how to use the member.
13	- 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">`.
14	- Use `<see cref>` to reference other types or members inline (in a sentence).
15	- Use `<seealso>` for standalone (not in a sentence) references to other types or members in the "See also" section of the online docs.
16	- Use `<inheritdoc/>` to inherit documentation from base classes or interfaces.
17	- Unless there is major behavior change, in which case you should document the differences.
18
19	## Methods
20
21	- Use `<param>` to describe method parameters.
22	- The description should be a noun phrase that doesn't specify the data type.
23	- Begin with an introductory article.
24	- If the parameter is a flag enum, start the description with "A bitwise combination of the enumeration values that specifies...".
25	- If the parameter is a non-flag enum, start the description with "One of the enumeration values that specifies...".
26	- If the parameter is a Boolean, the wording should be of the form "`<see langword="true" />` to ...; otherwise, `<see langword="false" />`.".
27	- 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.".
28	- Use `<paramref>` to reference parameter names in documentation.
29	- Use `<typeparam>` to describe type parameters in generic types or methods.
30	- Use `<typeparamref>` to reference type parameters in documentation.
31	- Use `<returns>` to describe what the method returns.
32	- The description should be a noun phrase that doesn't specify the data type.
33	- Begin with an introductory article.
34	- If the return type is Boolean, the wording should be of the form "`<see langword="true" />` if ...; otherwise, `<see langword="false" />`.".
35
36	## Constructors
37
38	- The summary wording should be "Initializes a new instance of the <Class> class [or struct].".
39
40	## Properties
41
42	- The `<summary>` should start with:
43	- "Gets or sets..." for a read-write property.
44	- "Gets..." for a read-only property.
45	- "Gets [or sets] a value that indicates whether..." for properties that return a Boolean value.
46	- Use `<value>` to describe the value of the property.
47	- The description should be a noun phrase that doesn't specify the data type.
48	- If the property has a default value, add it in a separate sentence, for example, "The default is `<see langword="false" />`".
49	- If the value type is Boolean, the wording should be of the form "`<see langword="true" />` if ...; otherwise, `<see langword="false" />`. The default is ...".
50
51	## Exceptions
52
53	- Use `<exception cref>` to document exceptions thrown by constructors, properties, indexers, methods, operators, and events.
54	- Document all exceptions thrown directly by the member.
55	- For exceptions thrown by nested members, document only the exceptions users are most likely to encounter.
56	- The description of the exception describes the condition under which it's thrown.
57	- 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."

People who liked this also viewed

6 picks

Type