Skip to content

docs: align xml documentation and code comment policy #151

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
senrecep merged 1 commit into from
Oct 10, 2026
Merged

docs: align xml documentation and code comment policy #151

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .claude/rules/csharp.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -14,3 +14,4 @@ paths: ["**/*.cs"]
- Functional types (Result, Maybe, Any) use implicit operators for ergonomic construction — maintain this pattern in new types.
- Record types are preferred over classes for immutable value objects.
- `TreatWarningsAsErrors=true` is global — never suppress a warning without understanding why it fires.
- XML documentation comments (`///`) on public APIs are expected. No inline code comments (`//`, `/* */`) that explain code.
1 change: 1 addition & 0 deletions .kimi/skills/csharp-conventions/SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,3 +15,4 @@ description: C# coding conventions for CSharpEssentials. Use when writing, revie
- Functional types (Result, Maybe, Any) use implicit operators for ergonomic construction; maintain this pattern in new types.
- Record types are preferred over classes for immutable value objects.
- `TreatWarningsAsErrors=true` is global; never suppress a warning without understanding why it fires.
- XML documentation comments (`///`) on public APIs are expected. No inline code comments (`//`, `/* */`) that explain code.
2 changes: 1 addition & 1 deletion AGENTS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -45,7 +45,7 @@ Releases are automated with [release-please](https://github.com/googleapis/relea
- Don't add `// TODO` to committed code — either implement it or track it as an issue.
- Don't add new packages to `Directory.Packages.props` without checking existing entries.
- Don't break multi-targeting — test against all declared target frameworks.
- Don't add docstrings or comments unless explicitly asked.
- Don't add inline code comments (`//`, `/* */`) that explain code unless explicitly asked. XML documentation comments (`///`) on public APIs are expected.
- Don't create placeholder/stub implementations.

## Boundaries
Expand Down
4 changes: 2 additions & 2 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -154,7 +154,7 @@ We use GitHub issues to track public bugs. Report a bug by [opening a new issue]

- Use 4 spaces for indentation
- Follow C# coding conventions
- Write XML documentation for public APIs
- Write XML documentation for public APIs; do not add inline code comments that explain code
- Keep methods small and focused
- Use meaningful names for variables and methods

Expand All @@ -168,7 +168,7 @@ We use GitHub issues to track public bugs. Report a bug by [opening a new issue]
## Documentation

- Update relevant documentation
- Include XML comments for public APIs
- Include XML documentation comments (`///`) for public APIs
- Update README.MD if needed (package table, badges)
- Update the package `Readme.MD` and the matching `.well-known/agent-skills/<package>/SKILL.md` when a public API changes
- Do not bump the version or edit `CHANGELOG.md` in a feature pull request; release-please generates both
Expand Down
Loading