This file defines guidance for coding agents and contributors working in this repository.
- This file applies to the entire repository.
- If a future subdirectory-level AGENTS.md is added, the closer file overrides this file for that subtree.
- Human maintainer instructions in issues/PR comments take precedence over this document.
- Solution:
Nogic.WritableOptions.slnx - Main library:
src/Nogic.WritableOptions - Tests:
test/Nogic.WritableOptions.Tests - Sandboxes/examples:
sandbox/* - Target SDKs in this repo include .NET 10 and .NET 8.
Before making changes, review:
CONTRIBUTING.md.editorconfig- Existing patterns in
src/andtest/
Use existing style and APIs unless a requested change requires otherwise.
Use these commands from repository root:
dotnet restore
dotnet csharpier format .
dotnet format
dotnet build
dotnet testAgent expectations:
- Make the smallest change that solves the requested problem.
- Add or update tests when behavior changes.
- Do not include unrelated refactors.
- Keep commits logically scoped when asked to prepare commit-ready work.
- After code changes, verify the editor shows no new warnings or errors caused by the change.
- After code changes, run:
dotnet format styledotnet format analyzersdotnet csharpier format .dotnet test
- Follow
.editorconfigand current code style. - Do not use non-ASCII characters for variable names.
- Keep public API changes explicit and intentional.
- Prefer readability over cleverness.
- Add brief comments only where logic is non-obvious.
- For library changes, run relevant tests in
test/Nogic.WritableOptions.Tests. - For broader or cross-cutting changes, run full
dotnet test. - If a change touches formatting/style-sensitive areas, run:
dotnet format styledotnet format analyzersdotnet csharpier format .
- Follow Conventional Commit prefixes described in
CONTRIBUTING.md(feat,fix,docs,style,refactor,perf,test,chore). - Keep PR title and description clear.
- Reference related issues when available.
- Ask clarifying questions when requirements are ambiguous or affect public API.
- Preserve backward compatibility unless breaking changes are explicitly requested.
- Destructive changes are prohibited by default. Only perform them when explicitly requested and approved.
- Do not silently change package targets, versions, or CI behavior.
- Prefer deterministic, reproducible steps in instructions and scripts.
A change is considered complete when:
- Requested behavior is implemented.
- Relevant tests are added/updated and pass.
- Formatting/style checks are satisfied.
- Impact and assumptions are clearly summarized.