csharp-docs
Документирование кода C#
Что получите
XML-комментарии в коде C# с описанием поведения и использования выбранных элементов.
Что передать
Код C# и сведения о его поведении, которые нужно отразить в документации.
Проверен состав файлов. Запуск не тестировался. Что проверено
Оценки пользователей
Как использовать
Помогает разработчикам C# оформлять XML-комментарии к типам и членам классов. Описывает назначение, параметры, возвращаемые значения, свойства и условия возникновения исключений.
- Передайте публичные типы и члены, которым нужны комментарии; при желании включите сложные внутренние элементы.
- Кратко опишите назначение и добавьте сведения о параметрах, результатах, значениях свойств и исключениях.
- Дополните документацию примерами и ссылками на связанные элементы; при наследовании отметьте существенные отличия поведения.
Условия работы
- Публичные члены должны быть документированы; документирование внутренних членов рекомендуется, особенно если они сложны.
- Описываются все исключения, выбрасываемые непосредственно элементом, и наиболее вероятные для пользователя исключения вложенных вызовов.
Пример запроса после установки
Добавь XML-документацию к публичному классу обработки заказов: объясни параметры, возвращаемые значения, свойства и условия исключений, включив короткий пример использования метода создания заказа.
Пример составлен по инструкции автора; результат запуска не проверялся.
Основание: инструкция закреплённой версииДля установки
Передайте промпт агенту, поддерживающему этот скилл. Подключения и инструменты для работы скилла настраиваются отдельно.
Совместимые агенты
Совместимость указана для инструкций. Запуск в каждом приложении не тестировался; для веб-чата способ подключения может отличаться.
Файлы скилла
GitHubЧитать инструкцию SKILL.md
Исходный текст закреплённой версии.
--- 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."
Проверка и особенности
Автоматическая проверка источника и файлов
Автоматически проверены публичный репозиторий, лицензия, заголовок SKILL.md, состав текстового пакета и Git-хеш каждого файла. Пакеты с исполняемыми файлами и срабатываниями применённых статических правил не включены. Ручной аудит всех инструкций и функциональный запуск не проводились. Внешние инструменты и сервисы не проверялись. Проверка не гарантирует безопасность.
В публичном списке установок на 2026-10-09 у скилла было 9 635 установок. Порог отбора — 1 000 установок. Число установок показывает распространённость, а не качество или безопасность инструкции.
- Проверка состава
- 09.10.2026
- Проверенная версия
82701c24b994- Файлы с кодом
- Не указаны в данных проверки
- Изменения на GitHub
- Нужна повторная проверкаПоследняя проверка: 11.10.2026
Репозиторий и лицензия
Это показатели всего репозитория, а не установки скилла. Снимок требует обновления.
- Последняя активность GitHub
- 09.10.2026
- Лицензия
- MIT
- Добавлен в каталог
- 09.10.2026
Полный текст лицензии
MIT License Copyright GitHub, Inc. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Ещё в этой категории
Все в категорииОбсуждение
ПравилаПользовались этим скиллом? Делитесь опытом без регистрации. Все комментарии проверяет модератор.
