Package Workflow

---
name: package-workflow
description: Validate .NET package surfaces for F# and C# libraries with project metadata, dotnet pack, local package smoke checks, semantic versioning, and release-boundary guidance.
license: Apache-2.0
compatibility: Designed for Codex and compatible Agent Skills clients working with NuGet package-oriented .NET SDK projects in F#, C#, or mixed-language solutions.
metadata:
  owner: gaelic-ghost
  repo: socket
  category: dotnet-packaging
allowed-tools: Read Bash(rg:*) Bash(git:*) Bash(dotnet:*)
---

# .NET Package Workflow

## Purpose

Validate a .NET library package before release or publication.

The practical job is to make package metadata explicit, build and test the library, run `dotnet pack`, inspect the generated package, and keep publishing as an explicit release step rather than an accidental side effect.

## When To Use

- Use this skill when a .NET library is intended to become a NuGet package.
- Use this skill when package metadata, versioning, or release notes are changed.
- Use this skill when adding package validation to F#, C#, or mixed solutions.
- Use this skill before package publication, but do not publish unless the user asks for that release step.

## Source Check

Use repo-local .NET files, checked-out dependency sources, Dash MCP or Dash HTTP for installed .NET docsets, and then official Microsoft documentation when Dash/local coverage is missing or stale:

- [`dotnet pack` documentation](https://learn.microsoft.com/dotnet/core/tools/dotnet-pack)
- [`dotnet build` documentation](https://learn.microsoft.com/dotnet/core/tools/dotnet-build)
- [`dotnet restore` documentation](https://learn.microsoft.com/dotnet/core/tools/dotnet-restore)
- [NuGet package creation guidance](https://learn.microsoft.com/nuget/create-packages/creating-a-package-dotnet-cli)
- [NuGet package versioning](https://learn.microsoft.com/nuget/concepts/package-versioning)

Translate documentation into the specific package, project file, and release decision in front of you.

## Inspection Workflow

1. Identify package-bearing projects:
   - `.fsproj`
   - `.csproj`
   - `Directory.Build.props`
   - `Directory.Packages.props`
   - package metadata fields
2. Confirm the intended package boundary:
   - one package per public library project
   - no accidental app project packages
   - no hidden machine-local references
3. Check metadata:
   - `PackageId`
   - `Version` or repository-owned version source
   - `Authors`
   - `Description`
   - `PackageTags`
   - `RepositoryUrl`
   - `PackageLicenseExpression` or license file policy
   - README and release notes if the repo ships them
4. Run validation:
   - `dotnet restore`
   - `dotnet build --configuration Release`
   - `dotnet test`
   - `dotnet pack --configuration Release --no-build`
5. Inspect generated package output.

## F# Package Notes

For F# packages:

- check `.fsproj` compile order before packaging
- keep public modules and types intentional
- avoid exposing implementation-only records or unions as accidental public API
- add C#-friendly API shapes only when there is a real C# consumer or package promise

## C# Package Notes

For C# packages:

- keep nullable reference type behavior explicit
- respect analyzer and warnings-as-errors settings
- avoid publishing broad interfaces or service types that only exist for test setup
- document public async contracts clearly

## Local Smoke Checks

When package behavior matters, create a temporary consumer outside the package source tree or in an ignored scratch path.

The smoke check should prove:

- the package can be restored from a local output directory
- the public API can be referenced by a fresh project
- F# and C# consumers work when the package promises both

Do not commit scratch consumers unless the repo intentionally keeps package integration tests.

## Output Shape

Return:

1. `Package boundary`: which project or projects produce packages.
2. `Metadata`: fields changed or verified.
3. `Validation`: exact restore, build, test, and pack commands.
4. `Artifacts`: package output paths.
5. `Consumer check`: skipped, passed, failed, or not applicable.
6. `Release boundary`: whether publication is still pending and what explicit release step would be needed.

## Guardrails

- Do not publish packages unless the user explicitly asks or the repo-local release workflow requires it.
- Do not pack app projects accidentally.
- Do not commit package metadata that points at machine-local paths.
- Do not use `--no-build` unless a successful Release build already ran in the same validation flow.
- Do not treat package creation as proof that public API design is good; inspect the API boundary too.