# Dotnet Library Change

> Use this skill when changing Dapper-FluentMap production code, public contracts, project files, PackageIds, package metadata, dependencies, or related tests. Do not use for pure CI/release work or behavior-preserving refactoring as the primary task.

- Skill: `rodri-oliveira-dev/dotnet-library-change` (Agent Skill)
- Install (CLI): `npx skillmds@latest add rodri-oliveira-dev/dotnet-library-change`
- Raw SKILL.md: https://api.skillmd.com/api/skills/rodri-oliveira-dev/dotnet-library-change/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity, DevOps & Infra
- License: MIT
- Author: rodri-oliveira-dev (https://skillmd.com/u/rodri-oliveira-dev)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/rodri-oliveira-dev/dotnet-library-change

---


# Purpose

Guide small, safe changes to this public multi-package .NET library while preserving build, tests, packaging, and public compatibility.

# When To Use

- Changes under `src/**`.
- Behavior changes requiring tests under `test/**`.
- Changes to `.csproj`, targets, dependencies, public types/members, XML docs, or package metadata.
- Any task that may affect package identity, assembly identity, namespace, dependency ranges, trimming/AOT annotations, analyzers, generators, or consumer compatibility.

# When Not To Use

- Behavior-preserving refactoring is the main task: use `dotnet-refactoring-engineer`.
- Workflows, release, NuGet publishing, or recovery are the main task: use `ci-release-governance`.
- Reviewing an existing PR/diff is the task: use `dotnet-pr-review`.
- The task changes only agent guidance or documentation with no library behavior impact.

# Process

1. Read root `AGENTS.md` and the files directly related to the requested change.
2. Identify the affected package(s): `Dapper.FluentMap`, `Dapper.FluentMap.Dommel`, `FluentMap.DependencyInjection`, `FluentMap.Analyzers`, or `FluentMap.Generators`.
3. Determine whether the change affects public API, source/binary/behavior compatibility, target frameworks, dependency ranges, Dapper/Dommel integration, global state/cache, package output, or documentation.
4. Preserve independent identities: project name, path, assembly name, namespace, and NuGet `PackageId` are not interchangeable.
5. Implement the smallest coherent change using existing project patterns.
6. Add or update tests for observable behavior changes; use regression tests for bug fixes.
7. Update consumer documentation and changelog only when the public contract or documented behavior changes.
8. For dependency, target, PackageId, metadata, or pack output changes, combine with `ci-release-governance`.
9. Run targeted validation first, then broader solution or package validation when risk requires it.
10. Review the full diff for unrelated modernization, formatting churn, project metadata drift, or weakened validation.

# Repository Baseline

- Public packages currently target `netstandard2.0`.
- The shared package version base is `FluentMapPackageVersionPrefix` in `Directory.Build.props`, with an explicit `Version` override in release workflows.
- Package IDs currently include:
  - `Dapper.FluentMap`
  - `Dapper.FluentMap.Dommel`
  - `FluentMap.DependencyInjection`
  - `FluentMap.Analyzers`
  - `FluentMap.Generators`
- Dependency versions are declared where the current project files declare them; this repository does not currently use Central Package Management.
- `Dapper.FluentMap.slnx` is preferred for current SDK validation; `Dapper.FluentMap.sln` remains a compatibility fallback.

# Validation

Use the commands from `AGENTS.md` that match the risk. As a starting point:

```bash
dotnet restore ./Dapper.FluentMap.slnx
dotnet build ./Dapper.FluentMap.slnx --configuration Release --no-restore
dotnet test ./Dapper.FluentMap.slnx --configuration Release --no-build
```

When package output, metadata, dependency ranges, targets, or release compatibility are affected, also run pack validation using the actual `eng` scripts documented in `AGENTS.md`.

# Restrictions

- Do not change `PackageId`, targets, dependency ranges, authors, license, URLs, Source Link/provenance, or package readme/icon behavior without explicit scope.
- Do not add package-management systems, lock-file policy, source generators, analyzers, nullable, NativeAOT/trimming claims, or SDK upgrades as incidental work.
- Do not make internals public just for tests.
- Do not reduce warnings, tests, analyzers, audit, or package validation to get a green run.
- Do not publish packages, create tags, or trigger releases unless explicitly requested.

# Quality Bar

A good library change resolves the requested behavior with a focused diff, preserves unrelated contracts, tests the relevant observable behavior, and keeps build/test/pack expectations consistent with the repository baseline.