К основному содержанию
скилл GitHub Copilot официальный · GitHub

csharp-docs — скилл для GitHub Copilot

Добавляет правила XML-документации для C# API. Пригодится, когда нужно оформить публичные типы, методы и свойства единообразно.

Установить в Claude Code · Через Skills CLI (Vercel) Все способы и платформы ↓
npx skills add github/awesome-copilot --skill csharp-docs -a claude-code
Открыть на GitHub

Что делает csharp-docs

Скилл направляет GitHub Copilot при написании XML-комментариев для C#. Он требует документировать публичные члены и советует описывать сложные внутренние. Для кратких описаний применяются `, а детали и примеры размещаются в и `.

Для методов он задаёт правила для `, и , включая формулировки для Boolean, перечислений и out-параметров. Также охватывает , ссылки , и наследование документации через `.

Отдельные правила есть для конструкторов и свойств: Gets, Gets or sets, `` и описание значения по умолчанию. Ставить стоит командам, которые поддерживают публичный C# API; для короткого внутреннего прототипа такая строгость может мешать.

Какие задачи решает

  • добавить XML-комментарии к публичным C# членам
  • описать параметры и возвращаемые значения методов
  • оформить документацию Boolean-свойств
  • указать исключения через ``
  • унаследовать комментарии базового типа через ``

Примеры запросов агенту

  • «Добавь XML-документацию ко всем публичным типам в этом C# проекте.»
  • «Оформи комментарии метода с ``, `` и ``.»
  • «Проверь XML-комментарии свойств по правилам csharp-docs.»

Как установить csharp-docs

1Через Skills CLI (Vercel)

npx skills add github/awesome-copilot --skill csharp-docs -a claude-code

2Вручную: положить файлы

~/.claude/skills/csharp-docs/SKILL.md

Папка скилла целиком; для одного проекта — .claude/skills/csharp-docs/

Похожие

skill-creator официальный anthropics Помогает создать новый скилл, доработать существующий и проверить результат через тестовые промпты и оценки. Claude Code Claude.ai 414 180установок grill-with-docs Matt Pocock Скилл проводит жёсткое интервью по плану или дизайну и по ходу создаёт ADR и глоссарий. Подойдёт перед началом сложной разработки. Claude Code 1 219 756установок setup-matt-pocock-skills Matt Pocock Настраивает репозиторий для инженерных скиллов Matt Pocock: трекер задач, метки triage и правила доменной документации. Запускайте перед первым использованием набора. Claude Code 1 052 851установок handoff Matt Pocock Собирает текущий диалог в документ передачи, чтобы другой агент продолжил работу с нужным контекстом. Нужен при смене сессии или исполнителя. Claude Code 1 038 491установок triage Matt Pocock Скилл проводит issue и внешние PR через роли триажа, проверку и подготовку брифа для агента. Подойдёт мейнтейнеру, который разбирает очередь задач. Claude Code 990 453установок domain-modeling Matt Pocock Скилл помогает уточнять термины проекта, вести GLOSSARY.md и фиксировать архитектурные решения в ADR. Нужен, когда модель предметной области меняется. Claude Code 876 391установок

Вопросы о csharp-docs

Как установить csharp-docs в GitHub Copilot?

Выполните npx skills add github/awesome-copilot --skill csharp-docs. Альтернативная команда: gh skill install github/awesome-copilot csharp-docs.

Что делает csharp-docs?

Скилл задаёт правила XML-документации для C# типов и членов API. Он описывает применение тегов для сводок, параметров, результатов, примеров и исключений.

Как csharp-docs документирует свойства и конструкторы?

Для конструкторов он задаёт формулировку сводки о создании экземпляра класса или структуры. Для свойств определяет начала Gets и Gets or sets, а значение предлагает описывать в ``.

Исходный текст

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

Смотрите также

Спонсоры проекта

Компании, которые помогают держать аналитику открытой