Skip to content

Commit 7c41ded

Browse files
samtrionsamtrion
committed
chore(template): sync with dailydevops/dotnet-template [skip ci]
1 parent 19ca4d0 commit 7c41ded

2 files changed

Lines changed: 116 additions & 37 deletions

File tree

‎.github/copilot-instructions.md‎

Lines changed: 34 additions & 37 deletions
Original file line numberDiff line numberDiff line change
@@ -1,51 +1,48 @@
1-
# Instructions for GitHub and VisualStudio Copilot
1+
# Copilot Instructions
22

3-
## General
3+
Use AI coding assistants, such as GitHub Copilot, to enhance productivity and maintain code quality.
44

5-
* Make only high confidence suggestions when reviewing code changes.
6-
* Always use the latest version C#, currently C# 13 features.
7-
* Never change `global.json` unless explicitly asked to.
8-
* Never change `Directory.Build.props` unless explicitly asked to.
9-
* Never change `Directory.Build.targets` unless explicitly asked to.
10-
* Never change `Directory.Packages.props` unless explicitly asked to.
5+
## General
116

12-
## Code Style
7+
* MUST allow internet research before suggesting changes or new implementations.
138

14-
* Use `var` when the type is obvious from the right side of the assignment.
15-
* Use `Argument.ThrowIfNull(x)` instead of `if (x == null) throw new ArgumentNullException(nameof(x))`, when nuget package `NetEvolve.Arguments` is referenced.
16-
* Use `ArgumentNullException.ThrowIfNull(x)` instead of `if (x == null) throw new ArgumentNullException(nameof(x))`, when nuget package `NetEvolve.Arguments` is not referenced.
9+
## Technology Research
1710

18-
## Formatting
11+
* MUST research current best practices for C# development before implementing new code patterns.
12+
* MUST verify compatibility and performance implications of new libraries or frameworks.
13+
* MUST check for updated documentation and migration guides for existing dependencies.
1914

20-
* Apply code-formatting style defined in `.editorconfig`.
21-
* Prefer file-scoped namespace declarations and single-line using directives.
22-
* Insert a newline before the opening curly brace of any code block (e.g., after `if`, `for`, `while`, `foreach`, `using`, `try`, etc.).
23-
* Ensure that the final return statement of a method is on its own line.
24-
* Use pattern matching and switch expressions wherever possible.
25-
* Use `nameof` instead of string literals when referring to member names.
26-
* Ensure that XML doc comments are created for any public APIs. When applicable, include `<inheritdoc />` for derived members.
15+
## Business Context Research
2716

28-
### Arrays and Collections
17+
* MUST understand the business requirements and context before proposing technical solutions.
18+
* MUST consider the impact on existing workflows and user experience.
19+
* MUST evaluate the cost-benefit ratio of proposed changes or new implementations.
2920

30-
* Prefer `Enumerable.Empty<T>()` or `Array.Empty<T>()` over `null` returns.
21+
## Decision References
3122

32-
## Nullable Reference Types
23+
* MUST document all decisions in `decisions/` folder using `templates/adr.md` format.
24+
* MUST treat "accepted" decisions as mandatory requirements with highest precedence.
25+
* MUST respect decision states:
26+
- **accepted**: mandatory requirements
27+
- **proposed**: optional considerations
28+
- **deprecated**: avoid in new implementations
29+
- **superseded**: forbidden, follow superseding decision instead
30+
* MUST use the `instructions` frontmatter property as primary AI guidance for each decision.
3331

34-
* Declare variables non-nullable, and check for `null` at entry points.
35-
* Always use `is null` or `is not null` instead of `== null` or `!= null`.
36-
* Trust the C# null annotations and don't add null checks when the type system says a value cannot be null.
37-
* Apply `NotNullAttribute` and other nullable attributes for any public APIs.
32+
## Configuration Files
3833

39-
## Testing
34+
These files control project-wide settings and should remain unchanged unless specifically requested.
4035

41-
* We prefer to use [TUnit](https://github.com/thomhurst/TUnit) with [Microsoft.Testing.Platform](https://learn.microsoft.com/dotnet/core/testing/microsoft-testing-platform-intro).
42-
* If TUnit is not available, we use [XUnit](https://xunit.net/).
43-
* Do not emit "Act", "Arrange" or "Assert" comments.
44-
* We do not use any mocking framework at the moment.
45-
* Copy existing style in nearby files for test method names and capitalization.
36+
* MUST NEVER change `.editorconfig` unless explicitly asked to.
37+
* MUST NEVER change `.gitignore` unless explicitly asked to.
38+
* MUST NEVER change `global.json` unless explicitly asked to.
39+
* MUST NEVER change `Directory.Build.props` unless explicitly asked to.
40+
* MUST NEVER change `Directory.Build.targets` unless explicitly asked to.
41+
* MUST NEVER change `Directory.Packages.props` unless explicitly asked to.
4642

47-
### Running tests
43+
## Code Reviews and Implementation
4844

49-
1. Build from the root with `dotnet build <solutionfile>`.
50-
2. If that produces errors, fix those errors and build again. Repeat until the build is successful.
51-
3. To then run tests, use a command similar to this `dotnet test <solutionfile>` (using the path to whatever projects are applicable to the change).
45+
* MUST always review AI-generated code for correctness, security, and performance.
46+
* MUST provide constructive feedback and suggestions for improvement.
47+
* MUST consider the context of the code being reviewed or implemented, including business requirements and technical constraints.
48+
* MUST apply all relevant instructions and guidelines from `.github/instructions/*.instructions.md` files during both code review and implementation.

‎templates/adr.md‎

Lines changed: 82 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,82 @@
1+
<!-- List of authors who contributed to this decision. Include full names and roles if applicable. -->
2+
authors:
3+
- Name Surname <!-- Replace with actual name -->
4+
- Another Name Surname <!-- Add more authors as needed -->
5+
6+
<!--
7+
The patterns this decision applies to. Each entry is a glob pattern that matches files affected by this decision.
8+
Example:
9+
applyTo:
10+
- "**/*.cs" # Applies to all C# files
11+
- "src/**/*.razor" # Applies to all Blazor components in src folder
12+
- "tests/**/*.sql" # Applies to all SQL files in tests folder
13+
-->
14+
applyTo:
15+
- "**/*" <!-- Replace with specific glob patterns -->
16+
17+
<!-- The date this ADR was initially created in YYYY-MM-DD format. -->
18+
created: YYYY-MM-DD
19+
20+
<!--
21+
The most recent date this ADR was updated in YYYY-MM-DD format.
22+
IMPORTANT: Update this field whenever the decision is modified.
23+
-->
24+
lastModified: YYYY-MM-DD
25+
26+
<!--
27+
The current state of this ADR. If superseded, include references to the superseding ADR.
28+
Valid values: proposed, accepted, deprecated, superseded
29+
-->
30+
state: proposed
31+
32+
<!--
33+
A compact AI LLM compatible definition of this decision.
34+
This should be a precise, structured description that AI systems can easily parse and understand.
35+
Include the core decision, key rationale, and primary impact in 1-2 concise sentences.
36+
-->
37+
instructions: |
38+
Compact definition of the decision made and its core purpose.
39+
Key rationale and primary impact on the project or development process.
40+
---
41+
<!-- REQUIRED: Filename MUST follow the format: YYYY-MM-DD-Title (replace all spaces with hyphens) -->
42+
# Title <!-- A concise title that summarizes the decision. Use a format like "Decision: [Short Description of Decision]". -->
43+
44+
<!--
45+
A brief summary of the decision. This should be a short paragraph that captures the essence of the decision made.
46+
-->
47+
48+
## Context
49+
50+
<!--
51+
Provide a detailed explanation of the problem or issue that led to this decision. Include background information, constraints, and any relevant context to help readers understand why this decision was necessary.
52+
-->
53+
54+
## Decision
55+
56+
<!--
57+
Clearly state the decision made. Describe the chosen solution or approach in detail, including any specific technologies, tools, or methods involved.
58+
-->
59+
60+
## Consequences
61+
62+
<!--
63+
Explain the implications of this decision. What are the expected benefits, trade-offs, and potential risks? How will this decision impact the project or organization?
64+
-->
65+
66+
## Alternatives Considered
67+
68+
<!--
69+
List and describe other options that were considered. For each alternative, explain why it was not chosen. Include pros and cons, feasibility, and any other relevant factors.
70+
-->
71+
72+
## Related Decisions (Optional)
73+
74+
<!--
75+
Provide links or references to other ADRs that are related to this decision. Explain how they are connected and why they are relevant.
76+
Use markdown link syntax to reference other decisions: [Decision Title](./YYYY-MM-DD-decision-filename.md)
77+
If there are no related decisions, this section may be omitted or include a note stating "None at this time."
78+
79+
Example:
80+
- [Centralized Package Version Management](./2025-07-10-centralized-package-version-management.md) - Related because this decision impacts how we manage dependencies
81+
- [Conventional Commits](./2025-07-10-conventional-commits.md) - This decision affects our commit message format which impacts versioning
82+
-->

0 commit comments

Comments
 (0)