diff --git a/.agents/skills/dotnet-codestyle/SKILL.md b/.agents/skills/dotnet-codestyle/SKILL.md
index 69efa64..ee8d9a9 100644
--- a/.agents/skills/dotnet-codestyle/SKILL.md
+++ b/.agents/skills/dotnet-codestyle/SKILL.md
@@ -101,130 +101,13 @@ updates, dependency upgrades, benchmarks) on top:
 
 ## Coding standards and conventions
 
-Code snippets below are illustrative examples only, replace namespaces and types to match your
-project.
+Key rules: no `var` (always explicit types), file-scoped namespaces, Allman braces, Nullable
+enabled, modern C# features (primary constructors, pattern matching, collection expressions). Every
+public surface has XML documentation. Private fields use `_camelCase`, static fields `s_camelCase`,
+constants PascalCase. Member ordering follows StyleCop SA1201.
 
-### C# language features
-
-1. **File-scoped namespaces**:
-
-   ```csharp
-   namespace Example.Project.Library;
-   ```
-
-2. **Nullable reference types**: enabled (`<Nullable>enable</Nullable>`), use nullable annotations
-   appropriately, use `required` for mandatory properties.
-3. **Modern C# features**: prefer modern language constructs, primary constructors when
-   appropriate, top-level statements for console apps, pattern matching over traditional checks,
-   collection expressions when types loosely match, extension methods (the classic
-   `this`-parameter form or an `extension(<receiver>) { ... }` block on C# 14+), implicit object
-   creation when the type is apparent, range and index operators.
-4. **Expression-bodied members**: use for applicable methods, properties, accessors, operators,
-   lambdas, local functions.
-5. **`var` keyword**: do NOT use `var`, always use explicit types:
-
-   ```csharp
-   // Correct
-   int count = 42;
-   string name = "test";
-
-   // Incorrect
-   var count = 42;
-   var name = "test";
-   ```
-
-### Naming conventions
-
-1. **Private fields**: underscore prefix with camelCase:
-
-   ```csharp
-   private readonly HttpClient _httpClient;
-   private int _counter;
-   ```
-
-2. **Static fields**: `s_` prefix with camelCase:
-
-   ```csharp
-   private static int s_instanceCount;
-   ```
-
-3. **Constants**: PascalCase:
-
-   ```csharp
-   private const int MaxRetries = 3;
-   ```
-
-### Code structure
-
-1. **Global usings**: use `GlobalUsings.cs` for common namespaces:
-
-   ```csharp
-   global using System;
-   global using System.Net.Http;
-   global using System.Threading.Tasks;
-   global using Microsoft.Extensions.Logging;
-   ```
-
-2. **Usings placement**: outside the namespace, sorted with `System` directives first:
-
-   ```csharp
-   using System.CommandLine;
-   using System.Runtime.CompilerServices;
-   using Example.Project.Library;
-
-   namespace Example.Project.Console;
-   ```
-
-3. **Braces**: Allman style:
-
-   ```csharp
-   public void Method()
-   {
-       if (condition)
-       {
-           // code
-       }
-   }
-   ```
-
-4. **Indentation**: C# files 4 spaces, XML/csproj files 2 spaces, YAML files 2 spaces, JSON files
-   4 spaces.
-5. **Line endings**: not specified here, governed per repo by `.editorconfig` / `.gitattributes`
-   per GOVERNANCE.md's "Line Endings" section.
-6. **`#region`**: do not use regions, prefer logical file/folder/namespace organization.
-7. **Member ordering (StyleCop SA1201)**: const -> static readonly -> static fields -> instance
-   readonly fields -> instance fields -> constructors -> public (events -> properties -> indexers
-   -> methods -> operators) -> non-public in same order -> nested types.
-
-### Comments and documentation
-
-XML documentation is on: `<GenerateDocumentationFile>true</GenerateDocumentationFile>`, and
-missing XML comments for public APIs are suppressed in `.editorconfig`. Every public surface must
-still be documented: a single-line summary, additional details in remarks, documented input
-parameters, return values, exceptions, and crefs.
-
-```csharp
-/// <summary>
-/// Example of a single line summary.
-/// </summary>
-/// <remarks>
-/// Additional important details about usage.
-/// Multiple lines if needed.
-/// </remarks>
-/// <param name="category">
-/// The quote category to request
-/// </param>
-/// <param name="cancellationToken">
-/// A <see cref="System.Threading.CancellationToken"/> that can be used to cancel the request.
-/// </param>
-/// <returns>
-/// A <see cref="string"/> containing the quote text.
-/// </returns>
-/// <exception cref="System.ArgumentException">
-/// Thrown when <paramref name="category"/> is not a supported value.
-/// </exception>
-public async Task<string> GetQuoteOfTheDayAsync(string category, CancellationToken cancellationToken) {}
-```
+For language features, naming, code structure, and XML documentation examples, see
+`references/conventions.md`.
 
 ## Analyzer suppressions (.NET)
 
@@ -312,47 +195,15 @@ The .NET mechanics, narrowest first:
 
 ## Testing conventions
 
-1. **Framework**: xUnit v3 or later (the `xunit.v3` package, never the legacy v2 `xunit` package)
-   with AwesomeAssertions for every assertion. Native xUnit asserts (`Assert.Equal`,
-   `Assert.True`, ...) are not allowed, use the fluent `.Should()` API. Dynamic test skipping
-   (`Assert.Skip`, `Assert.SkipWhen`) is control flow, not an assertion, and stays native:
-
-   ```csharp
-   [Fact]
-   public void MethodName_Scenario_ExpectedBehavior()
-   {
-       // Arrange
-       int expected = 42;
-
-       // Act
-       int actual = GetValue();
-
-       // Assert
-       actual.Should().Be(expected);
-   }
-   ```
-
-2. **Organization**: Arrange-Act-Assert pattern.
-3. **Naming**: descriptive names with underscores.
-4. **Theory tests**: use `[Theory]` with `[InlineData]`.
+xUnit v3 (`xunit.v3`, not the legacy `xunit`) + AwesomeAssertions (`.Should()` API, never native
+asserts). Arrange-Act-Assert pattern, descriptive underscore names, `[Theory]`/`[InlineData]` for
+parameterized tests. See `references/testing.md` for the framework setup template.
 
 ## Project configuration
 
-1. **Target framework**: .NET 10.0 (`<TargetFramework>net10.0</TargetFramework>`).
-2. **AOT compatibility**: `<IsAotCompatible>true</IsAotCompatible>`,
-   `<VerifyReferenceAotCompatibility>true</VerifyReferenceAotCompatibility>`.
-3. **Assembly information**: use semantic versioning, include SourceLink
-   (`<PublishRepositoryUrl>true</PublishRepositoryUrl>`), embed untracked sources
-   (`<EmbedUntrackedSources>true</EmbedUntrackedSources>`).
-4. **Internal visibility**: use `InternalsVisibleTo` for test and benchmark access (adapt the
-   project names to your repo's test/benchmark projects):
-
-   ```xml
-   <ItemGroup>
-     <InternalsVisibleTo Include="YourBenchmarkProject" />
-     <InternalsVisibleTo Include="YourTestProject" />
-   </ItemGroup>
-   ```
+.NET 10.0 target, AOT-compatible (`IsAotCompatible=true`, `VerifyReferenceAotCompatibility=true`),
+SourceLink, embedded untracked sources, `InternalsVisibleTo` for test/benchmark access. See
+`references/project-config.md` for the full property list.
 
 ## Best practices
 
diff --git a/.agents/skills/dotnet-codestyle/references/conventions.md b/.agents/skills/dotnet-codestyle/references/conventions.md
new file mode 100644
index 0000000..5eb4854
--- /dev/null
+++ b/.agents/skills/dotnet-codestyle/references/conventions.md
@@ -0,0 +1,126 @@
+# .NET Coding Standards and Conventions
+
+Code snippets below are illustrative examples only, replace namespaces and types to match your
+project.
+
+## C# language features
+
+1. **File-scoped namespaces**:
+
+   ```csharp
+   namespace Example.Project.Library;
+   ```
+
+2. **Nullable reference types**: enabled (`<Nullable>enable</Nullable>`), use nullable annotations
+   appropriately, use `required` for mandatory properties.
+3. **Modern C# features**: prefer modern language constructs, primary constructors when
+   appropriate, top-level statements for console apps, pattern matching over traditional checks,
+   collection expressions when types loosely match, extension methods (the classic
+   `this`-parameter form or an `extension(<receiver>) { ... }` block on C# 14+), implicit object
+   creation when the type is apparent, range and index operators.
+4. **Expression-bodied members**: use for applicable methods, properties, accessors, operators,
+   lambdas, local functions.
+5. **`var` keyword**: do NOT use `var`, always use explicit types:
+
+   ```csharp
+   // Correct
+   int count = 42;
+   string name = "test";
+
+   // Incorrect
+   var count = 42;
+   var name = "test";
+   ```
+
+## Naming conventions
+
+1. **Private fields**: underscore prefix with camelCase:
+
+   ```csharp
+   private readonly HttpClient _httpClient;
+   private int _counter;
+   ```
+
+2. **Static fields**: `s_` prefix with camelCase:
+
+   ```csharp
+   private static int s_instanceCount;
+   ```
+
+3. **Constants**: PascalCase:
+
+   ```csharp
+   private const int MaxRetries = 3;
+   ```
+
+## Code structure
+
+1. **Global usings**: use `GlobalUsings.cs` for common namespaces:
+
+   ```csharp
+   global using System;
+   global using System.Net.Http;
+   global using System.Threading.Tasks;
+   global using Microsoft.Extensions.Logging;
+   ```
+
+2. **Usings placement**: outside the namespace, sorted with `System` directives first:
+
+   ```csharp
+   using System.CommandLine;
+   using System.Runtime.CompilerServices;
+   using Example.Project.Library;
+
+   namespace Example.Project.Console;
+   ```
+
+3. **Braces**: Allman style:
+
+   ```csharp
+   public void Method()
+   {
+       if (condition)
+       {
+           // code
+       }
+   }
+   ```
+
+4. **Indentation**: C# files 4 spaces, XML/csproj files 2 spaces, YAML files 2 spaces, JSON files
+   4 spaces.
+5. **Line endings**: not specified here, governed per repo by `.editorconfig` / `.gitattributes`
+   per GOVERNANCE.md's "Line Endings" section.
+6. **`#region`**: do not use regions, prefer logical file/folder/namespace organization.
+7. **Member ordering (StyleCop SA1201)**: const -> static readonly -> static fields -> instance
+   readonly fields -> instance fields -> constructors -> public (events -> properties -> indexers
+   -> methods -> operators) -> non-public in same order -> nested types.
+
+## Comments and documentation
+
+XML documentation is on: `<GenerateDocumentationFile>true</GenerateDocumentationFile>`, and
+missing XML comments for public APIs are suppressed in `.editorconfig`. Every public surface must
+still be documented: a single-line summary, additional details in remarks, documented input
+parameters, return values, exceptions, and crefs.
+
+```csharp
+/// <summary>
+/// Example of a single line summary.
+/// </summary>
+/// <remarks>
+/// Additional important details about usage.
+/// Multiple lines if needed.
+/// </remarks>
+/// <param name="category">
+/// The quote category to request
+/// </param>
+/// <param name="cancellationToken">
+/// A <see cref="System.Threading.CancellationToken"/> that can be used to cancel the request.
+/// </param>
+/// <returns>
+/// A <see cref="string"/> containing the quote text.
+/// </returns>
+/// <exception cref="System.ArgumentException">
+/// Thrown when <paramref name="category"/> is not a supported value.
+/// </exception>
+public async Task<string> GetQuoteOfTheDayAsync(string category, CancellationToken cancellationToken) {}
+```
diff --git a/.agents/skills/dotnet-codestyle/references/project-config.md b/.agents/skills/dotnet-codestyle/references/project-config.md
new file mode 100644
index 0000000..8f6e838
--- /dev/null
+++ b/.agents/skills/dotnet-codestyle/references/project-config.md
@@ -0,0 +1,17 @@
+# .NET Project Configuration
+
+1. **Target framework**: .NET 10.0 (`<TargetFramework>net10.0</TargetFramework>`).
+2. **AOT compatibility**: `<IsAotCompatible>true</IsAotCompatible>`,
+   `<VerifyReferenceAotCompatibility>true</VerifyReferenceAotCompatibility>`.
+3. **Assembly information**: use semantic versioning, include SourceLink
+   (`<PublishRepositoryUrl>true</PublishRepositoryUrl>`), embed untracked sources
+   (`<EmbedUntrackedSources>true</EmbedUntrackedSources>`).
+4. **Internal visibility**: use `InternalsVisibleTo` for test and benchmark access (adapt the
+   project names to your repo's test/benchmark projects):
+
+   ```xml
+   <ItemGroup>
+     <InternalsVisibleTo Include="YourBenchmarkProject" />
+     <InternalsVisibleTo Include="YourTestProject" />
+   </ItemGroup>
+   ```
diff --git a/.agents/skills/dotnet-codestyle/references/testing.md b/.agents/skills/dotnet-codestyle/references/testing.md
new file mode 100644
index 0000000..5a84a17
--- /dev/null
+++ b/.agents/skills/dotnet-codestyle/references/testing.md
@@ -0,0 +1,25 @@
+# .NET Testing Conventions
+
+1. **Framework**: xUnit v3 or later (the `xunit.v3` package, never the legacy v2 `xunit` package)
+   with AwesomeAssertions for every assertion. Native xUnit asserts (`Assert.Equal`,
+   `Assert.True`, ...) are not allowed, use the fluent `.Should()` API. Dynamic test skipping
+   (`Assert.Skip`, `Assert.SkipWhen`) is control flow, not an assertion, and stays native:
+
+   ```csharp
+   [Fact]
+   public void MethodName_Scenario_ExpectedBehavior()
+   {
+       // Arrange
+       int expected = 42;
+
+       // Act
+       int actual = GetValue();
+
+       // Assert
+       actual.Should().Be(expected);
+   }
+   ```
+
+2. **Organization**: Arrange-Act-Assert pattern.
+3. **Naming**: descriptive names with underscores.
+4. **Theory tests**: use `[Theory]` with `[InlineData]`.
diff --git a/.agents/skills/git-commit-conventions/SKILL.md b/.agents/skills/git-commit-conventions/SKILL.md
index 3709d31..85e46eb 100644
--- a/.agents/skills/git-commit-conventions/SKILL.md
+++ b/.agents/skills/git-commit-conventions/SKILL.md
@@ -154,28 +154,13 @@ the rewrite looks, a rejected push is recoverable, a force-pushed one is not.
 
 ## History rewrites re-identify only what changed
 
-**A history rewrite includes only the commits that must change, and re-identifies any commit it
-rewrites that is not the agent's own.** Filtering history (`git filter-repo` or an equivalent, for
-example to strip PII) re-signs every commit it touches with the rewriter's own key, while the
-tooling preserves each commit's original `author`/`committer` unless told otherwise. GitHub
-verifies a signature against the commit's `committer` identity, so a signature from the rewriter's
-key over a commit still committed by a bot (`dependabot[bot]`, `github-actions[bot]`) or GitHub's
-own web-flow does not match its committer and lands `unknown_key`/unverified, which a
-require-signed-commits rule then rejects.
-
-Two gates keep committer and signature aligned:
-
-1. **Scope the rewrite to only the commits that must be modified.** By default those are the
-   rewriter's own, whose committer already matches, so a commit that needs no change stays out of
-   the rewrite entirely and its identity and signature are never touched.
-2. **If a commit that must change is not the rewriter's own, set its `committer` to the rewriter's
-   own signing identity before re-signing** (and its `author` too, since a rewrite that alters
-   content should not keep attributing it to the bot). The original bot attribution is deliberately
-   given up as the cost of having to rewrite it.
-
-Never leave a signature over a commit committed by another identity. Verify after any rewrite that
-every rewritten commit is signed and committed under the correct identity
-(`git log --show-signature`).
+**Do not rewrite a commit that does not need to change.** A history rewrite (e.g. `git filter-repo`
+to strip PII) re-signs every touched commit with the rewriter's key. If that commit is still
+committed by a bot (`dependabot[bot]`, `github-actions[bot]`) or GitHub's own web-flow, the
+signature will not match the committer and the require-signed-commits rule rejects it. Scope the
+rewrite to only the commits that must change. Set `committer` (and `author`) to the rewriter's
+identity on any non-own commit that must be modified. Verify with `git log --show-signature` after
+any rewrite. See `references/history-rewrite.md` for the full two-gate rule.
 
 ## Never run destructive git commands without being asked
 
diff --git a/.agents/skills/git-commit-conventions/references/history-rewrite.md b/.agents/skills/git-commit-conventions/references/history-rewrite.md
new file mode 100644
index 0000000..b331a55
--- /dev/null
+++ b/.agents/skills/git-commit-conventions/references/history-rewrite.md
@@ -0,0 +1,24 @@
+# History Rewrites: Re-identification Rules
+
+**A history rewrite includes only the commits that must change, and re-identifies any commit it
+rewrites that is not the agent's own.** Filtering history (`git filter-repo` or an equivalent, for
+example to strip PII) re-signs every commit it touches with the rewriter's own key, while the
+tooling preserves each commit's original `author`/`committer` unless told otherwise. GitHub
+verifies a signature against the commit's `committer` identity, so a signature from the rewriter's
+key over a commit still committed by a bot (`dependabot[bot]`, `github-actions[bot]`) or GitHub's
+own web-flow does not match its committer and lands `unknown_key`/unverified, which a
+require-signed-commits rule then rejects.
+
+Two gates keep committer and signature aligned:
+
+1. **Scope the rewrite to only the commits that must be modified.** By default those are the
+   rewriter's own, whose committer already matches, so a commit that needs no change stays out of
+   the rewrite entirely and its identity and signature are never touched.
+2. **If a commit that must change is not the rewriter's own, set its `committer` to the rewriter's
+   own signing identity before re-signing** (and its `author` too, since a rewrite that alters
+   content should not keep attributing it to the bot). The original bot attribution is deliberately
+   given up as the cost of having to rewrite it.
+
+Never leave a signature over a commit committed by another identity. Verify after any rewrite that
+every rewritten commit is signed and committed under the correct identity
+(`git log --show-signature`).
diff --git a/.agents/skills/python-codestyle/SKILL.md b/.agents/skills/python-codestyle/SKILL.md
index a5a262d..911ae30 100644
--- a/.agents/skills/python-codestyle/SKILL.md
+++ b/.agents/skills/python-codestyle/SKILL.md
@@ -24,66 +24,16 @@ language shares (clean-compile verification as a concept, the suppression-scope
 casing in prose), this Skill is everything specific to a Python project on top of that: the two
 profiles, the toolchain, layout, and the language-level conventions.
 
-## Adapt before propagating
-
-The rules below describe the default Python profile: a package that publishes to PyPI,
-type-checked by pyright in strict mode, dependencies in `[dependency-groups]`. A derived repo
-often differs, and when it does, adapt these fields to match the repo's actual toolchain rather
-than copying verbatim (a verbatim copy that misdescribes the repo is inaccurate and gets rejected
-in review). The axes that commonly vary per repo:
-
-- **Type checker in CI**: pyright strict, mypy in CI with pyright editor-only (Pylance), or both.
-  Whichever runs in CI is the one the clean-compile and the CI gate invoke.
-- **Dependency declaration**: `[dependency-groups]`, or PEP 621 `[project.optional-dependencies]`
-  (dev tools installed with `uv sync --extra <group>`).
-- **Versioning / publishing**: a published package (`_version.py` plus a version source,
-  `uv build`, and a PyPI publish step), or a source-only repo with a static `version` and no
-  publish step (see Versioning below).
-- **Disabled markdownlint rules**: repo-specific, `.markdownlint-cli2.jsonc` at the repo root is
-  the source of truth, not any example rule named here.
-- **VS Code config home**: editor settings/extensions may live in `.vscode/*.json` or the
-  `<Repo>.code-workspace`, while tasks/launch/debug configs can only be external `.vscode/*.json`
-  (they cannot live in the workspace file). The repo's own `tasks.json` sits wherever it keeps it,
-  and the canonical task definitions it is written against are the hub `vscode-tasks-python.json`
-  snippet, which resolves the same way from every repo.
-
 ## Two profiles
 
-A repo's Python is one of two shapes, declared as the `build` or `lint-only` profile and validated
-against the `pyproject.toml` shape. Most of this Skill (uv project, `uv.lock`, `uv run`, src
-layout, pytest coverage) describes the Project shape (the `build` profile). The two differ by
-whether the Python has third-party runtime dependencies, which shows up structurally in
-`pyproject.toml`, so the fleet's audit reads the shape there:
+Read the repo's `pyproject.toml` shape and pick the profile before applying any other rule:
 
-- **Project** (the `build` profile): the Python has third-party runtime dependencies, or is the
-  repo's deliverable. It is a PEP 621 uv project: `[project]` with `dependencies` (dev tools in
-  `[project.optional-dependencies]` or `[dependency-groups]`), a `[build-system]`, and a committed
-  `uv.lock` (pinned LF, per GOVERNANCE.md's "Line Endings" section). CI runs `uv sync --frozen` +
-  `uv run <tool>`, so the lockfile pins tool versions.
-- **Scripts** (the `lint-only` profile): stdlib-only utility scripts embedded in a non-Python repo
-  (e.g. a Python tooling subtree of a `csharp` app). Run the tools with `uvx` (no project install,
-  no lockfile): the `pyproject.toml` carries only tool config (`[tool.ruff]`, `[tool.mypy]`, and
-  an optional `[tool.pyright]` editor block), with no `[project]`, no `[build-system]`, and no
-  `uv.lock` (that metadata would misrepresent it as a shippable package). mypy is the type-check
-  gate (there is no first-party package for pyright strict to anchor on), and a `[tool.pyright]`
-  block in standard mode keeps Pylance quiet in the editor, the same mypy-gate/pyright-editor
-  split the build profile uses. There is no lockfile, and a `uvx <tool>@<ver>` pin in a `run:`
-  step is not something Dependabot tracks, so CI runs `uvx ruff@latest` / `uvx mypy@latest` rather
-  than a manual pin that would silently go stale. The fleet rule is to pin only what Dependabot
-  auto-updates (SHA-pinned actions, package deps) and otherwise run latest, so the VS Code tasks,
-  README, and CI all run the unpinned latest here. `.py` files follow the repo's LF line-ending
-  default (per GOVERNANCE.md's "Line Endings" section). There is no pytest suite, and `unittest` is the runner
-  instead. A script that carries a gate still earns tests, written with the standard library's
-  `unittest` so they run under bare `python3` with nothing installed, as `test_<script>.py` under
-  a `tests/` directory beside the scripts it exercises (`<scripts-dir>/tests/`), kept apart so a
-  test never reads as a tool. Within the scripts directory the name carries the kind: a gate that
-  checks and exits non-zero on a finding takes a `_lint` or `_gate` suffix, and a utility that
-  does work takes none. Any repo carrying Python carries the Python tooling in CI, coverage
-  included, this profile too: `uvx ruff@latest check`, `uvx ruff@latest format --check`,
-  `uvx mypy@latest`, and the unittest suite
-  under `uvx coverage@latest run -m unittest discover -s <scripts-dir>/tests` with
-  `coverage report`, informational with no threshold adopted. A co-present `csharp` type still
-  carries `codecov.yml` for its own tests.
+- **build** (Project): `[project]` + `[build-system]` + committed `uv.lock`. Uses `uv run`, pytest,
+  pyright strict (or mypy where the repo requires it).
+- **lint-only** (Scripts): no `[project]`, no lockfile. Uses `uvx`, unittest, mypy as CI gate.
+
+For the full profile specification and per-repo adaptation axes (type checker, dependency
+declaration, versioning, VS Code config), see `references/profiles.md`.
 
 ## Toolchain
 
@@ -161,105 +111,33 @@ unbuilt code:
 
 ## Code style
 
-### Formatting and linting
+Key rules for every Python task:
 
-- **`ruff format` is authoritative.** Don't argue with the formatter, and if it reformats your
-  code, that's the final form. Configure (line length, target version) in `pyproject.toml`
+- **`ruff format` is authoritative.** Don't argue with the formatter. Configure in `pyproject.toml`
   `[tool.ruff]`, not via inline `# fmt:` directives.
-- **Run `ruff check --fix` before committing.** Most ruff lint rules have safe autofixes, let the
-  tool handle them. The configured rule families are listed under `[tool.ruff.lint]` `select`. Add
-  new rule families project-wide rather than scattering inline `# noqa` markers.
-- **`# noqa` is a last resort.** When you must use one, scope it narrowly (`# noqa: E501`, not
-  bare `# noqa`) and add a short comment on the same line explaining why. False-positive patterns
-  that recur across the codebase belong in `[tool.ruff.lint]` `ignore` or per-file
-  `[tool.ruff.lint.per-file-ignores]`, with a comment. Porting an existing codebase is not a
-  license to add `ignore` / `per-file-ignores` blocks to mute newly surfaced lint. Fix it.
-
-### Comments
-
-- **Inline `#` comments**: keep tight and local. One line is preferred, but multi-line is fine
-  when you need to document a non-obvious implementation constraint, a local trade-off, or
-  coupling that future edits could easily break. Keep that rationale next to the affected block so
-  the reviewer/maintainer sees it at edit-time.
-- **Don't explain what the code does.** Well-named identifiers handle that. Don't reference the
-  current task ("added for X", "used by Y"), which belongs in the PR description.
-
-### Docstrings
-
-- Follow [PEP 257][pep-0257-link]. Focus docstrings primarily on the behavior contract (what
-  callers and tests can rely on), public semantics, and edge-case expectations.
-  Implementation-local rationale belongs in inline `#` comments, not docstrings.
-- A short one-liner is fine for trivial functions and tests with self-documenting names.
-- For non-trivial behavior (non-obvious test scenarios, contracts a test pins, edge cases callers
-  must know about, design trade-offs that are load-bearing for future maintainers), write a
-  one-line summary, blank line, then a details paragraph. Multi-paragraph docstrings are fine when
-  the contract earns it.
-- Design notes belong in the code (docstrings or inline comments). They do NOT belong in
-  `HISTORY.md`, which is end-user release notes, not a design log.
-
-### Type hints
-
-- **All public APIs are typed.** The repo's configured type checker runs on `src/` (pyright strict
-  via `[tool.pyright]` `strict = ["src"]`, or mypy where that is the CI checker), and tests run in
-  the checker's looser/standard mode.
-- **Use modern syntax**: `list[int]` not `List[int]`, `dict[str, X]` not `Dict[str, X]`,
-  `X | None` not `Optional[X]`, `from __future__ import annotations` only when needed for forward
-  references.
-- **Don't add `# type: ignore` to silence pyright errors without a comment** explaining the
-  constraint. If a recurring false positive needs suppression, configure it project-wide in
-  `[tool.pyright]`. A new port doesn't change this, fix freshly surfaced type errors rather than
-  muting them.
-
-### Naming
-
-- `snake_case` for functions, methods, variables, modules, package directories.
-- `PascalCase` for classes, type aliases, type vars, enum members.
-- `UPPER_SNAKE_CASE` for module-level constants.
-- Single leading underscore for module-private, double leading underscore for name-mangled (rare,
-  and usually means rethink the design).
-
-### Imports
-
-- **Let ruff sort imports.** `[tool.ruff.lint]` `select` includes the `I` rule family
-  (isort-equivalent). Don't hand-sort.
-- Standard library first, then third-party, then first-party (the project itself), each block
-  separated by a blank line, which ruff enforces automatically.
-- Avoid wildcard imports (`from x import *`) outside `__init__.py` re-exports.
-
-### Patterns to avoid
-
-- **Don't add backward-compat shims, `# removed` markers, or rename-to-`_` for unused vars**, just
-  delete. Git history is the audit trail.
-- **Don't add error handling for impossible cases.** Trust internal code, and validate only at
-  boundaries (user input, parsed config, external APIs).
-- **Don't use exceptions for expected control flow.** Exceptions are for unexpected states.
-- **Don't suppress errors silently** (`except Exception: pass`). Either handle the specific
-  exception and document why it's safe, or let it propagate.
+- **Run `ruff check --fix` before committing.** The configured rule families are in
+  `[tool.ruff.lint]` `select`. Add new rule families project-wide, not scattered inline `# noqa`.
+- **`# noqa` is a last resort.** Scope it narrowly (`# noqa: E501`) with a comment. Recurring
+  false positives belong in `[tool.ruff.lint]` `ignore` or `per-file-ignores`.
+- **All public APIs are typed.** Use modern syntax (`list[int]`, `X | None`). Don't add
+  `# type: ignore` without an explaining comment.
+- **Don't add backward-compat shims.** Just delete unused code. Git history is the audit trail.
+- **Don't add error handling for impossible cases.** Trust internal code. Validate only at boundaries.
+
+For comments, docstrings, full type-hint rules, naming, imports, and all patterns to avoid, see
+`references/code-style.md`.
 
 ## Tests
 
-- `pytest` with the configuration in `[tool.pytest.ini_options]`. Default invocation:
-  `uv run pytest`.
-- One test file per module under test, named `test_<module>.py`.
-- Test functions named `test_<scenario>_<expected_behavior>`, descriptive and not numbered.
-- Use fixtures (defined in `conftest.py` for shared ones, or per-test for narrowly-scoped) instead
-  of setup/teardown methods.
-- **Avoid mocking when fakes work.** Hand-rolled fakes that implement the protocol you depend on
-  are usually clearer and break less than `unittest.mock` magic.
-- **Test edge cases that the docstring promises**, not implementation details. If the test breaks
-  when you refactor without changing behavior, the test is asserting on an implementation detail.
+`uv run pytest`. One test file per module (`test_<module>.py`), fixtures over setup/teardown,
+fakes over mocks. Test the docstring's contract, not implementation details. See
+`references/testing.md` for the full conventions.
 
 ## Versioning
 
-**Published packages.** `_version.py` ships with `__version__ = "0.0.0"` as a placeholder. Until
-you wire `_version.py` to something that increments (the usual options are `hatch-vcs`, a
-version.json bridge, or manual bumps), no new PyPI versions will land, and publishing with
-`skip-existing: true` keeps a stuck placeholder version from failing the run.
-
-**Source-only repos** (no PyPI publish, with a source-release on dispatch or no release at all) do
-not need `_version.py`: keep a static `version` in `pyproject.toml` `[project]`, or let the
-release pipeline's version source (e.g. NBGV plus `version.json`) own the tag. There is no publish
-step to guard, so `skip-existing` does not apply.
+Published packages use `_version.py` with `__version__ = "0.0.0"` as a placeholder. Wire
+`hatch-vcs` or equivalent to increment, publish with `skip-existing: true`. Source-only repos use
+a static `version` in `[project]` with no `_version.py`. See `references/profiles.md` for details.
 
 ## Linter cleanliness
 
@@ -280,7 +158,6 @@ Before pushing or opening a PR:
 [docs-link]: https://docs.pytest.org/
 [latest-link]: https://hatch.pypa.io/latest/
 [mypy-link]: https://mypy-lang.org/
-[pep-0257-link]: https://peps.python.org/pep-0257/
 [pyright-link]: https://microsoft.github.io/pyright/
 [ruff-link]: https://docs.astral.sh/ruff/
 [uv-link]: https://docs.astral.sh/uv/
diff --git a/.agents/skills/python-codestyle/references/code-style.md b/.agents/skills/python-codestyle/references/code-style.md
new file mode 100644
index 0000000..b7e62b0
--- /dev/null
+++ b/.agents/skills/python-codestyle/references/code-style.md
@@ -0,0 +1,80 @@
+# Python Code Style: Full Reference
+
+## Formatting and linting
+
+- **`ruff format` is authoritative.** Don't argue with the formatter, and if it reformats your
+  code, that's the final form. Configure (line length, target version) in `pyproject.toml`
+  `[tool.ruff]`, not via inline `# fmt:` directives.
+- **Run `ruff check --fix` before committing.** Most ruff lint rules have safe autofixes, let the
+  tool handle them. The configured rule families are listed under `[tool.ruff.lint]` `select`. Add
+  new rule families project-wide rather than scattering inline `# noqa` markers.
+- **`# noqa` is a last resort.** When you must use one, scope it narrowly (`# noqa: E501`, not
+  bare `# noqa`) and add a short comment on the same line explaining why. False-positive patterns
+  that recur across the codebase belong in `[tool.ruff.lint]` `ignore` or per-file
+  `[tool.ruff.lint.per-file-ignores]`, with a comment. Porting an existing codebase is not a
+  license to add `ignore` / `per-file-ignores` blocks to mute newly surfaced lint. Fix it.
+
+## Comments
+
+- **Inline `#` comments**: keep tight and local. One line is preferred, but multi-line is fine
+  when you need to document a non-obvious implementation constraint, a local trade-off, or
+  coupling that future edits could easily break. Keep that rationale next to the affected block so
+  the reviewer/maintainer sees it at edit-time.
+- **Don't explain what the code does.** Well-named identifiers handle that. Don't reference the
+  current task ("added for X", "used by Y"), which belongs in the PR description.
+
+## Docstrings
+
+- Follow [PEP 257][pep-0257-link]. Focus docstrings primarily on the behavior contract (what
+  callers and tests can rely on), public semantics, and edge-case expectations.
+  Implementation-local rationale belongs in inline `#` comments, not docstrings.
+- A short one-liner is fine for trivial functions and tests with self-documenting names.
+- For non-trivial behavior (non-obvious test scenarios, contracts a test pins, edge cases callers
+  must know about, design trade-offs that are load-bearing for future maintainers), write a
+  one-line summary, blank line, then a details paragraph. Multi-paragraph docstrings are fine when
+  the contract earns it.
+- Design notes belong in the code (docstrings or inline comments). They do NOT belong in
+  `HISTORY.md`, which is end-user release notes, not a design log.
+
+## Type hints
+
+- **All public APIs are typed.** The repo's configured type checker runs on `src/` (pyright strict
+  via `[tool.pyright]` `strict = ["src"]`, or mypy where that is the CI checker), and tests run in
+  the checker's looser/standard mode.
+- **Use modern syntax**: `list[int]` not `List[int]`, `dict[str, X]` not `Dict[str, X]`,
+  `X | None` not `Optional[X]`, `from __future__ import annotations` only when needed for forward
+  references.
+- **Don't add `# type: ignore` to silence pyright errors without a comment** explaining the
+  constraint. If a recurring false positive needs suppression, configure it project-wide in
+  `[tool.pyright]`. A new port doesn't change this, fix freshly surfaced type errors rather than
+  muting them.
+
+## Naming
+
+- `snake_case` for functions, methods, variables, modules, package directories.
+- `PascalCase` for classes, type aliases, type vars, enum members.
+- `UPPER_SNAKE_CASE` for module-level constants.
+- Single leading underscore for module-private, double leading underscore for name-mangled (rare,
+  and usually means rethink the design).
+
+## Imports
+
+- **Let ruff sort imports.** `[tool.ruff.lint]` `select` includes the `I` rule family
+  (isort-equivalent). Don't hand-sort.
+- Standard library first, then third-party, then first-party (the project itself), each block
+  separated by a blank line, which ruff enforces automatically.
+- Avoid wildcard imports (`from x import *`) outside `__init__.py` re-exports.
+
+## Patterns to avoid
+
+- **Don't add backward-compat shims, `# removed` markers, or rename-to-`_` for unused vars**, just
+  delete. Git history is the audit trail.
+- **Don't add error handling for impossible cases.** Trust internal code, and validate only at
+  boundaries (user input, parsed config, external APIs).
+- **Don't use exceptions for expected control flow.** Exceptions are for unexpected states.
+- **Don't suppress errors silently** (`except Exception: pass`). Either handle the specific
+  exception and document why it's safe, or let it propagate.
+
+<!-- External -->
+
+[pep-0257-link]: https://peps.python.org/pep-0257/
diff --git a/.agents/skills/python-codestyle/references/profiles.md b/.agents/skills/python-codestyle/references/profiles.md
new file mode 100644
index 0000000..b7eedfb
--- /dev/null
+++ b/.agents/skills/python-codestyle/references/profiles.md
@@ -0,0 +1,74 @@
+# Python Profile Details
+
+## Adapt before propagating
+
+The rules in `SKILL.md` describe the default Python profile: a package that publishes to PyPI,
+type-checked by pyright in strict mode, dependencies in `[dependency-groups]`. A derived repo
+often differs, and when it does, adapt these fields to match the repo's actual toolchain rather
+than copying verbatim (a verbatim copy that misdescribes the repo is inaccurate and gets rejected
+in review). The axes that commonly vary per repo:
+
+- **Type checker in CI**: pyright strict, mypy in CI with pyright editor-only (Pylance), or both.
+  Whichever runs in CI is the one the clean-compile and the CI gate invoke.
+- **Dependency declaration**: `[dependency-groups]`, or PEP 621 `[project.optional-dependencies]`
+  (dev tools installed with `uv sync --extra <group>`).
+- **Versioning / publishing**: a published package (`_version.py` plus a version source,
+  `uv build`, and a PyPI publish step), or a source-only repo with a static `version` and no
+  publish step (see Versioning below).
+- **Disabled markdownlint rules**: repo-specific, `.markdownlint-cli2.jsonc` at the repo root is
+  the source of truth, not any example rule named here.
+- **VS Code config home**: editor settings/extensions may live in `.vscode/*.json` or the
+  `<Repo>.code-workspace`, while tasks/launch/debug configs can only be external `.vscode/*.json`
+  (they cannot live in the workspace file). The repo's own `tasks.json` sits wherever it keeps it,
+  and the canonical task definitions it is written against are the hub `vscode-tasks-python.json`
+  snippet, which resolves the same way from every repo.
+
+## Two profiles: full specification
+
+A repo's Python is one of two shapes, declared as the `build` or `lint-only` profile and validated
+against the `pyproject.toml` shape. Most of the `SKILL.md` rules (uv project, `uv.lock`, `uv run`,
+src layout, pytest coverage) describe the Project shape (the `build` profile). The two differ by
+whether the Python has third-party runtime dependencies, which shows up structurally in
+`pyproject.toml`, so the fleet's audit reads the shape there:
+
+- **Project** (the `build` profile): the Python has third-party runtime dependencies, or is the
+  repo's deliverable. It is a PEP 621 uv project: `[project]` with `dependencies` (dev tools in
+  `[project.optional-dependencies]` or `[dependency-groups]`), a `[build-system]`, and a committed
+  `uv.lock` (pinned LF, per GOVERNANCE.md's "Line Endings" section). CI runs `uv sync --frozen` +
+  `uv run <tool>`, so the lockfile pins tool versions.
+- **Scripts** (the `lint-only` profile): stdlib-only utility scripts embedded in a non-Python repo
+  (e.g. a Python tooling subtree of a `csharp` app). Run the tools with `uvx` (no project install,
+  no lockfile): the `pyproject.toml` carries only tool config (`[tool.ruff]`, `[tool.mypy]`, and
+  an optional `[tool.pyright]` editor block), with no `[project]`, no `[build-system]`, and no
+  `uv.lock` (that metadata would misrepresent it as a shippable package). mypy is the type-check
+  gate (there is no first-party package for pyright strict to anchor on), and a `[tool.pyright]`
+  block in standard mode keeps Pylance quiet in the editor, the same mypy-gate/pyright-editor
+  split the build profile uses. There is no lockfile, and a `uvx <tool>@<ver>` pin in a `run:`
+  step is not something Dependabot tracks, so CI runs `uvx ruff@latest` / `uvx mypy@latest` rather
+  than a manual pin that would silently go stale. The fleet rule is to pin only what Dependabot
+  auto-updates (SHA-pinned actions, package deps) and otherwise run latest, so the VS Code tasks,
+  README, and CI all run the unpinned latest here. `.py` files follow the repo's LF line-ending
+  default (per GOVERNANCE.md's "Line Endings" section). There is no pytest suite, and `unittest` is
+  the runner instead. A script that carries a gate still earns tests, written with the standard
+  library's `unittest` so they run under bare `python3` with nothing installed, as
+  `test_<script>.py` under a `tests/` directory beside the scripts it exercises
+  (`<scripts-dir>/tests/`), kept apart so a test never reads as a tool. Within the scripts
+  directory the name carries the kind: a gate that checks and exits non-zero on a finding takes a
+  `_lint` or `_gate` suffix, and a utility that does work takes none. Any repo carrying Python
+  carries the Python tooling in CI, coverage included, this profile too: `uvx ruff@latest check`,
+  `uvx ruff@latest format --check`, `uvx mypy@latest`, and the unittest suite under
+  `uvx coverage@latest run -m unittest discover -s <scripts-dir>/tests` with `coverage report`,
+  informational with no threshold adopted. A co-present `csharp` type still carries `codecov.yml`
+  for its own tests.
+
+## Versioning
+
+**Published packages.** `_version.py` ships with `__version__ = "0.0.0"` as a placeholder. Until
+you wire `_version.py` to something that increments (the usual options are `hatch-vcs`, a
+version.json bridge, or manual bumps), no new PyPI versions will land, and publishing with
+`skip-existing: true` keeps a stuck placeholder version from failing the run.
+
+**Source-only repos** (no PyPI publish, with a source-release on dispatch or no release at all) do
+not need `_version.py`: keep a static `version` in `pyproject.toml` `[project]`, or let the
+release pipeline's version source (e.g. NBGV plus `version.json`) own the tag. There is no publish
+step to guard, so `skip-existing` does not apply.
diff --git a/.agents/skills/python-codestyle/references/testing.md b/.agents/skills/python-codestyle/references/testing.md
new file mode 100644
index 0000000..c19ff9d
--- /dev/null
+++ b/.agents/skills/python-codestyle/references/testing.md
@@ -0,0 +1,13 @@
+# Python Testing Conventions
+
+Use `pytest` with configuration in `[tool.pytest.ini_options]`. Default invocation:
+`uv run pytest`.
+
+- One test file per module under test, named `test_<module>.py`.
+- Test functions named `test_<scenario>_<expected_behavior>`, descriptive and not numbered.
+- Use fixtures (defined in `conftest.py` for shared ones, or per-test for narrowly-scoped) instead
+  of setup/teardown methods.
+- **Avoid mocking when fakes work.** Hand-rolled fakes that implement the protocol you depend on
+  are usually clearer and break less than `unittest.mock` magic.
+- **Test edge cases that the docstring promises**, not implementation details. If the test breaks
+  when you refactor without changing behavior, the test is asserting on an implementation detail.
diff --git a/.claude-plugin/fleet-skills/.source-digest b/.claude-plugin/fleet-skills/.source-digest
index 4ee31bf..9bd7332 100644
--- a/.claude-plugin/fleet-skills/.source-digest
+++ b/.claude-plugin/fleet-skills/.source-digest
@@ -1 +1 @@
-213fc219bcee8f5f
+f89062080fcd73f6
diff --git a/.claude-plugin/fleet-skills/skills/dotnet-codestyle/SKILL.md b/.claude-plugin/fleet-skills/skills/dotnet-codestyle/SKILL.md
index 69efa64..ee8d9a9 100644
--- a/.claude-plugin/fleet-skills/skills/dotnet-codestyle/SKILL.md
+++ b/.claude-plugin/fleet-skills/skills/dotnet-codestyle/SKILL.md
@@ -101,130 +101,13 @@ updates, dependency upgrades, benchmarks) on top:
 
 ## Coding standards and conventions
 
-Code snippets below are illustrative examples only, replace namespaces and types to match your
-project.
+Key rules: no `var` (always explicit types), file-scoped namespaces, Allman braces, Nullable
+enabled, modern C# features (primary constructors, pattern matching, collection expressions). Every
+public surface has XML documentation. Private fields use `_camelCase`, static fields `s_camelCase`,
+constants PascalCase. Member ordering follows StyleCop SA1201.
 
-### C# language features
-
-1. **File-scoped namespaces**:
-
-   ```csharp
-   namespace Example.Project.Library;
-   ```
-
-2. **Nullable reference types**: enabled (`<Nullable>enable</Nullable>`), use nullable annotations
-   appropriately, use `required` for mandatory properties.
-3. **Modern C# features**: prefer modern language constructs, primary constructors when
-   appropriate, top-level statements for console apps, pattern matching over traditional checks,
-   collection expressions when types loosely match, extension methods (the classic
-   `this`-parameter form or an `extension(<receiver>) { ... }` block on C# 14+), implicit object
-   creation when the type is apparent, range and index operators.
-4. **Expression-bodied members**: use for applicable methods, properties, accessors, operators,
-   lambdas, local functions.
-5. **`var` keyword**: do NOT use `var`, always use explicit types:
-
-   ```csharp
-   // Correct
-   int count = 42;
-   string name = "test";
-
-   // Incorrect
-   var count = 42;
-   var name = "test";
-   ```
-
-### Naming conventions
-
-1. **Private fields**: underscore prefix with camelCase:
-
-   ```csharp
-   private readonly HttpClient _httpClient;
-   private int _counter;
-   ```
-
-2. **Static fields**: `s_` prefix with camelCase:
-
-   ```csharp
-   private static int s_instanceCount;
-   ```
-
-3. **Constants**: PascalCase:
-
-   ```csharp
-   private const int MaxRetries = 3;
-   ```
-
-### Code structure
-
-1. **Global usings**: use `GlobalUsings.cs` for common namespaces:
-
-   ```csharp
-   global using System;
-   global using System.Net.Http;
-   global using System.Threading.Tasks;
-   global using Microsoft.Extensions.Logging;
-   ```
-
-2. **Usings placement**: outside the namespace, sorted with `System` directives first:
-
-   ```csharp
-   using System.CommandLine;
-   using System.Runtime.CompilerServices;
-   using Example.Project.Library;
-
-   namespace Example.Project.Console;
-   ```
-
-3. **Braces**: Allman style:
-
-   ```csharp
-   public void Method()
-   {
-       if (condition)
-       {
-           // code
-       }
-   }
-   ```
-
-4. **Indentation**: C# files 4 spaces, XML/csproj files 2 spaces, YAML files 2 spaces, JSON files
-   4 spaces.
-5. **Line endings**: not specified here, governed per repo by `.editorconfig` / `.gitattributes`
-   per GOVERNANCE.md's "Line Endings" section.
-6. **`#region`**: do not use regions, prefer logical file/folder/namespace organization.
-7. **Member ordering (StyleCop SA1201)**: const -> static readonly -> static fields -> instance
-   readonly fields -> instance fields -> constructors -> public (events -> properties -> indexers
-   -> methods -> operators) -> non-public in same order -> nested types.
-
-### Comments and documentation
-
-XML documentation is on: `<GenerateDocumentationFile>true</GenerateDocumentationFile>`, and
-missing XML comments for public APIs are suppressed in `.editorconfig`. Every public surface must
-still be documented: a single-line summary, additional details in remarks, documented input
-parameters, return values, exceptions, and crefs.
-
-```csharp
-/// <summary>
-/// Example of a single line summary.
-/// </summary>
-/// <remarks>
-/// Additional important details about usage.
-/// Multiple lines if needed.
-/// </remarks>
-/// <param name="category">
-/// The quote category to request
-/// </param>
-/// <param name="cancellationToken">
-/// A <see cref="System.Threading.CancellationToken"/> that can be used to cancel the request.
-/// </param>
-/// <returns>
-/// A <see cref="string"/> containing the quote text.
-/// </returns>
-/// <exception cref="System.ArgumentException">
-/// Thrown when <paramref name="category"/> is not a supported value.
-/// </exception>
-public async Task<string> GetQuoteOfTheDayAsync(string category, CancellationToken cancellationToken) {}
-```
+For language features, naming, code structure, and XML documentation examples, see
+`references/conventions.md`.
 
 ## Analyzer suppressions (.NET)
 
@@ -312,47 +195,15 @@ The .NET mechanics, narrowest first:
 
 ## Testing conventions
 
-1. **Framework**: xUnit v3 or later (the `xunit.v3` package, never the legacy v2 `xunit` package)
-   with AwesomeAssertions for every assertion. Native xUnit asserts (`Assert.Equal`,
-   `Assert.True`, ...) are not allowed, use the fluent `.Should()` API. Dynamic test skipping
-   (`Assert.Skip`, `Assert.SkipWhen`) is control flow, not an assertion, and stays native:
-
-   ```csharp
-   [Fact]
-   public void MethodName_Scenario_ExpectedBehavior()
-   {
-       // Arrange
-       int expected = 42;
-
-       // Act
-       int actual = GetValue();
-
-       // Assert
-       actual.Should().Be(expected);
-   }
-   ```
-
-2. **Organization**: Arrange-Act-Assert pattern.
-3. **Naming**: descriptive names with underscores.
-4. **Theory tests**: use `[Theory]` with `[InlineData]`.
+xUnit v3 (`xunit.v3`, not the legacy `xunit`) + AwesomeAssertions (`.Should()` API, never native
+asserts). Arrange-Act-Assert pattern, descriptive underscore names, `[Theory]`/`[InlineData]` for
+parameterized tests. See `references/testing.md` for the framework setup template.
 
 ## Project configuration
 
-1. **Target framework**: .NET 10.0 (`<TargetFramework>net10.0</TargetFramework>`).
-2. **AOT compatibility**: `<IsAotCompatible>true</IsAotCompatible>`,
-   `<VerifyReferenceAotCompatibility>true</VerifyReferenceAotCompatibility>`.
-3. **Assembly information**: use semantic versioning, include SourceLink
-   (`<PublishRepositoryUrl>true</PublishRepositoryUrl>`), embed untracked sources
-   (`<EmbedUntrackedSources>true</EmbedUntrackedSources>`).
-4. **Internal visibility**: use `InternalsVisibleTo` for test and benchmark access (adapt the
-   project names to your repo's test/benchmark projects):
-
-   ```xml
-   <ItemGroup>
-     <InternalsVisibleTo Include="YourBenchmarkProject" />
-     <InternalsVisibleTo Include="YourTestProject" />
-   </ItemGroup>
-   ```
+.NET 10.0 target, AOT-compatible (`IsAotCompatible=true`, `VerifyReferenceAotCompatibility=true`),
+SourceLink, embedded untracked sources, `InternalsVisibleTo` for test/benchmark access. See
+`references/project-config.md` for the full property list.
 
 ## Best practices
 
diff --git a/.claude-plugin/fleet-skills/skills/dotnet-codestyle/references/conventions.md b/.claude-plugin/fleet-skills/skills/dotnet-codestyle/references/conventions.md
new file mode 100644
index 0000000..5eb4854
--- /dev/null
+++ b/.claude-plugin/fleet-skills/skills/dotnet-codestyle/references/conventions.md
@@ -0,0 +1,126 @@
+# .NET Coding Standards and Conventions
+
+Code snippets below are illustrative examples only, replace namespaces and types to match your
+project.
+
+## C# language features
+
+1. **File-scoped namespaces**:
+
+   ```csharp
+   namespace Example.Project.Library;
+   ```
+
+2. **Nullable reference types**: enabled (`<Nullable>enable</Nullable>`), use nullable annotations
+   appropriately, use `required` for mandatory properties.
+3. **Modern C# features**: prefer modern language constructs, primary constructors when
+   appropriate, top-level statements for console apps, pattern matching over traditional checks,
+   collection expressions when types loosely match, extension methods (the classic
+   `this`-parameter form or an `extension(<receiver>) { ... }` block on C# 14+), implicit object
+   creation when the type is apparent, range and index operators.
+4. **Expression-bodied members**: use for applicable methods, properties, accessors, operators,
+   lambdas, local functions.
+5. **`var` keyword**: do NOT use `var`, always use explicit types:
+
+   ```csharp
+   // Correct
+   int count = 42;
+   string name = "test";
+
+   // Incorrect
+   var count = 42;
+   var name = "test";
+   ```
+
+## Naming conventions
+
+1. **Private fields**: underscore prefix with camelCase:
+
+   ```csharp
+   private readonly HttpClient _httpClient;
+   private int _counter;
+   ```
+
+2. **Static fields**: `s_` prefix with camelCase:
+
+   ```csharp
+   private static int s_instanceCount;
+   ```
+
+3. **Constants**: PascalCase:
+
+   ```csharp
+   private const int MaxRetries = 3;
+   ```
+
+## Code structure
+
+1. **Global usings**: use `GlobalUsings.cs` for common namespaces:
+
+   ```csharp
+   global using System;
+   global using System.Net.Http;
+   global using System.Threading.Tasks;
+   global using Microsoft.Extensions.Logging;
+   ```
+
+2. **Usings placement**: outside the namespace, sorted with `System` directives first:
+
+   ```csharp
+   using System.CommandLine;
+   using System.Runtime.CompilerServices;
+   using Example.Project.Library;
+
+   namespace Example.Project.Console;
+   ```
+
+3. **Braces**: Allman style:
+
+   ```csharp
+   public void Method()
+   {
+       if (condition)
+       {
+           // code
+       }
+   }
+   ```
+
+4. **Indentation**: C# files 4 spaces, XML/csproj files 2 spaces, YAML files 2 spaces, JSON files
+   4 spaces.
+5. **Line endings**: not specified here, governed per repo by `.editorconfig` / `.gitattributes`
+   per GOVERNANCE.md's "Line Endings" section.
+6. **`#region`**: do not use regions, prefer logical file/folder/namespace organization.
+7. **Member ordering (StyleCop SA1201)**: const -> static readonly -> static fields -> instance
+   readonly fields -> instance fields -> constructors -> public (events -> properties -> indexers
+   -> methods -> operators) -> non-public in same order -> nested types.
+
+## Comments and documentation
+
+XML documentation is on: `<GenerateDocumentationFile>true</GenerateDocumentationFile>`, and
+missing XML comments for public APIs are suppressed in `.editorconfig`. Every public surface must
+still be documented: a single-line summary, additional details in remarks, documented input
+parameters, return values, exceptions, and crefs.
+
+```csharp
+/// <summary>
+/// Example of a single line summary.
+/// </summary>
+/// <remarks>
+/// Additional important details about usage.
+/// Multiple lines if needed.
+/// </remarks>
+/// <param name="category">
+/// The quote category to request
+/// </param>
+/// <param name="cancellationToken">
+/// A <see cref="System.Threading.CancellationToken"/> that can be used to cancel the request.
+/// </param>
+/// <returns>
+/// A <see cref="string"/> containing the quote text.
+/// </returns>
+/// <exception cref="System.ArgumentException">
+/// Thrown when <paramref name="category"/> is not a supported value.
+/// </exception>
+public async Task<string> GetQuoteOfTheDayAsync(string category, CancellationToken cancellationToken) {}
+```
diff --git a/.claude-plugin/fleet-skills/skills/dotnet-codestyle/references/project-config.md b/.claude-plugin/fleet-skills/skills/dotnet-codestyle/references/project-config.md
new file mode 100644
index 0000000..8f6e838
--- /dev/null
+++ b/.claude-plugin/fleet-skills/skills/dotnet-codestyle/references/project-config.md
@@ -0,0 +1,17 @@
+# .NET Project Configuration
+
+1. **Target framework**: .NET 10.0 (`<TargetFramework>net10.0</TargetFramework>`).
+2. **AOT compatibility**: `<IsAotCompatible>true</IsAotCompatible>`,
+   `<VerifyReferenceAotCompatibility>true</VerifyReferenceAotCompatibility>`.
+3. **Assembly information**: use semantic versioning, include SourceLink
+   (`<PublishRepositoryUrl>true</PublishRepositoryUrl>`), embed untracked sources
+   (`<EmbedUntrackedSources>true</EmbedUntrackedSources>`).
+4. **Internal visibility**: use `InternalsVisibleTo` for test and benchmark access (adapt the
+   project names to your repo's test/benchmark projects):
+
+   ```xml
+   <ItemGroup>
+     <InternalsVisibleTo Include="YourBenchmarkProject" />
+     <InternalsVisibleTo Include="YourTestProject" />
+   </ItemGroup>
+   ```
diff --git a/.claude-plugin/fleet-skills/skills/dotnet-codestyle/references/testing.md b/.claude-plugin/fleet-skills/skills/dotnet-codestyle/references/testing.md
new file mode 100644
index 0000000..5a84a17
--- /dev/null
+++ b/.claude-plugin/fleet-skills/skills/dotnet-codestyle/references/testing.md
@@ -0,0 +1,25 @@
+# .NET Testing Conventions
+
+1. **Framework**: xUnit v3 or later (the `xunit.v3` package, never the legacy v2 `xunit` package)
+   with AwesomeAssertions for every assertion. Native xUnit asserts (`Assert.Equal`,
+   `Assert.True`, ...) are not allowed, use the fluent `.Should()` API. Dynamic test skipping
+   (`Assert.Skip`, `Assert.SkipWhen`) is control flow, not an assertion, and stays native:
+
+   ```csharp
+   [Fact]
+   public void MethodName_Scenario_ExpectedBehavior()
+   {
+       // Arrange
+       int expected = 42;
+
+       // Act
+       int actual = GetValue();
+
+       // Assert
+       actual.Should().Be(expected);
+   }
+   ```
+
+2. **Organization**: Arrange-Act-Assert pattern.
+3. **Naming**: descriptive names with underscores.
+4. **Theory tests**: use `[Theory]` with `[InlineData]`.
diff --git a/.claude-plugin/fleet-skills/skills/git-commit-conventions/SKILL.md b/.claude-plugin/fleet-skills/skills/git-commit-conventions/SKILL.md
index 3709d31..85e46eb 100644
--- a/.claude-plugin/fleet-skills/skills/git-commit-conventions/SKILL.md
+++ b/.claude-plugin/fleet-skills/skills/git-commit-conventions/SKILL.md
@@ -154,28 +154,13 @@ the rewrite looks, a rejected push is recoverable, a force-pushed one is not.
 
 ## History rewrites re-identify only what changed
 
-**A history rewrite includes only the commits that must change, and re-identifies any commit it
-rewrites that is not the agent's own.** Filtering history (`git filter-repo` or an equivalent, for
-example to strip PII) re-signs every commit it touches with the rewriter's own key, while the
-tooling preserves each commit's original `author`/`committer` unless told otherwise. GitHub
-verifies a signature against the commit's `committer` identity, so a signature from the rewriter's
-key over a commit still committed by a bot (`dependabot[bot]`, `github-actions[bot]`) or GitHub's
-own web-flow does not match its committer and lands `unknown_key`/unverified, which a
-require-signed-commits rule then rejects.
-
-Two gates keep committer and signature aligned:
-
-1. **Scope the rewrite to only the commits that must be modified.** By default those are the
-   rewriter's own, whose committer already matches, so a commit that needs no change stays out of
-   the rewrite entirely and its identity and signature are never touched.
-2. **If a commit that must change is not the rewriter's own, set its `committer` to the rewriter's
-   own signing identity before re-signing** (and its `author` too, since a rewrite that alters
-   content should not keep attributing it to the bot). The original bot attribution is deliberately
-   given up as the cost of having to rewrite it.
-
-Never leave a signature over a commit committed by another identity. Verify after any rewrite that
-every rewritten commit is signed and committed under the correct identity
-(`git log --show-signature`).
+**Do not rewrite a commit that does not need to change.** A history rewrite (e.g. `git filter-repo`
+to strip PII) re-signs every touched commit with the rewriter's key. If that commit is still
+committed by a bot (`dependabot[bot]`, `github-actions[bot]`) or GitHub's own web-flow, the
+signature will not match the committer and the require-signed-commits rule rejects it. Scope the
+rewrite to only the commits that must change. Set `committer` (and `author`) to the rewriter's
+identity on any non-own commit that must be modified. Verify with `git log --show-signature` after
+any rewrite. See `references/history-rewrite.md` for the full two-gate rule.
 
 ## Never run destructive git commands without being asked
 
diff --git a/.claude-plugin/fleet-skills/skills/git-commit-conventions/references/history-rewrite.md b/.claude-plugin/fleet-skills/skills/git-commit-conventions/references/history-rewrite.md
new file mode 100644
index 0000000..b331a55
--- /dev/null
+++ b/.claude-plugin/fleet-skills/skills/git-commit-conventions/references/history-rewrite.md
@@ -0,0 +1,24 @@
+# History Rewrites: Re-identification Rules
+
+**A history rewrite includes only the commits that must change, and re-identifies any commit it
+rewrites that is not the agent's own.** Filtering history (`git filter-repo` or an equivalent, for
+example to strip PII) re-signs every commit it touches with the rewriter's own key, while the
+tooling preserves each commit's original `author`/`committer` unless told otherwise. GitHub
+verifies a signature against the commit's `committer` identity, so a signature from the rewriter's
+key over a commit still committed by a bot (`dependabot[bot]`, `github-actions[bot]`) or GitHub's
+own web-flow does not match its committer and lands `unknown_key`/unverified, which a
+require-signed-commits rule then rejects.
+
+Two gates keep committer and signature aligned:
+
+1. **Scope the rewrite to only the commits that must be modified.** By default those are the
+   rewriter's own, whose committer already matches, so a commit that needs no change stays out of
+   the rewrite entirely and its identity and signature are never touched.
+2. **If a commit that must change is not the rewriter's own, set its `committer` to the rewriter's
+   own signing identity before re-signing** (and its `author` too, since a rewrite that alters
+   content should not keep attributing it to the bot). The original bot attribution is deliberately
+   given up as the cost of having to rewrite it.
+
+Never leave a signature over a commit committed by another identity. Verify after any rewrite that
+every rewritten commit is signed and committed under the correct identity
+(`git log --show-signature`).
diff --git a/.claude-plugin/fleet-skills/skills/python-codestyle/SKILL.md b/.claude-plugin/fleet-skills/skills/python-codestyle/SKILL.md
index a5a262d..911ae30 100644
--- a/.claude-plugin/fleet-skills/skills/python-codestyle/SKILL.md
+++ b/.claude-plugin/fleet-skills/skills/python-codestyle/SKILL.md
@@ -24,66 +24,16 @@ language shares (clean-compile verification as a concept, the suppression-scope
 casing in prose), this Skill is everything specific to a Python project on top of that: the two
 profiles, the toolchain, layout, and the language-level conventions.
 
-## Adapt before propagating
-
-The rules below describe the default Python profile: a package that publishes to PyPI,
-type-checked by pyright in strict mode, dependencies in `[dependency-groups]`. A derived repo
-often differs, and when it does, adapt these fields to match the repo's actual toolchain rather
-than copying verbatim (a verbatim copy that misdescribes the repo is inaccurate and gets rejected
-in review). The axes that commonly vary per repo:
-
-- **Type checker in CI**: pyright strict, mypy in CI with pyright editor-only (Pylance), or both.
-  Whichever runs in CI is the one the clean-compile and the CI gate invoke.
-- **Dependency declaration**: `[dependency-groups]`, or PEP 621 `[project.optional-dependencies]`
-  (dev tools installed with `uv sync --extra <group>`).
-- **Versioning / publishing**: a published package (`_version.py` plus a version source,
-  `uv build`, and a PyPI publish step), or a source-only repo with a static `version` and no
-  publish step (see Versioning below).
-- **Disabled markdownlint rules**: repo-specific, `.markdownlint-cli2.jsonc` at the repo root is
-  the source of truth, not any example rule named here.
-- **VS Code config home**: editor settings/extensions may live in `.vscode/*.json` or the
-  `<Repo>.code-workspace`, while tasks/launch/debug configs can only be external `.vscode/*.json`
-  (they cannot live in the workspace file). The repo's own `tasks.json` sits wherever it keeps it,
-  and the canonical task definitions it is written against are the hub `vscode-tasks-python.json`
-  snippet, which resolves the same way from every repo.
-
 ## Two profiles
 
-A repo's Python is one of two shapes, declared as the `build` or `lint-only` profile and validated
-against the `pyproject.toml` shape. Most of this Skill (uv project, `uv.lock`, `uv run`, src
-layout, pytest coverage) describes the Project shape (the `build` profile). The two differ by
-whether the Python has third-party runtime dependencies, which shows up structurally in
-`pyproject.toml`, so the fleet's audit reads the shape there:
+Read the repo's `pyproject.toml` shape and pick the profile before applying any other rule:
 
-- **Project** (the `build` profile): the Python has third-party runtime dependencies, or is the
-  repo's deliverable. It is a PEP 621 uv project: `[project]` with `dependencies` (dev tools in
-  `[project.optional-dependencies]` or `[dependency-groups]`), a `[build-system]`, and a committed
-  `uv.lock` (pinned LF, per GOVERNANCE.md's "Line Endings" section). CI runs `uv sync --frozen` +
-  `uv run <tool>`, so the lockfile pins tool versions.
-- **Scripts** (the `lint-only` profile): stdlib-only utility scripts embedded in a non-Python repo
-  (e.g. a Python tooling subtree of a `csharp` app). Run the tools with `uvx` (no project install,
-  no lockfile): the `pyproject.toml` carries only tool config (`[tool.ruff]`, `[tool.mypy]`, and
-  an optional `[tool.pyright]` editor block), with no `[project]`, no `[build-system]`, and no
-  `uv.lock` (that metadata would misrepresent it as a shippable package). mypy is the type-check
-  gate (there is no first-party package for pyright strict to anchor on), and a `[tool.pyright]`
-  block in standard mode keeps Pylance quiet in the editor, the same mypy-gate/pyright-editor
-  split the build profile uses. There is no lockfile, and a `uvx <tool>@<ver>` pin in a `run:`
-  step is not something Dependabot tracks, so CI runs `uvx ruff@latest` / `uvx mypy@latest` rather
-  than a manual pin that would silently go stale. The fleet rule is to pin only what Dependabot
-  auto-updates (SHA-pinned actions, package deps) and otherwise run latest, so the VS Code tasks,
-  README, and CI all run the unpinned latest here. `.py` files follow the repo's LF line-ending
-  default (per GOVERNANCE.md's "Line Endings" section). There is no pytest suite, and `unittest` is the runner
-  instead. A script that carries a gate still earns tests, written with the standard library's
-  `unittest` so they run under bare `python3` with nothing installed, as `test_<script>.py` under
-  a `tests/` directory beside the scripts it exercises (`<scripts-dir>/tests/`), kept apart so a
-  test never reads as a tool. Within the scripts directory the name carries the kind: a gate that
-  checks and exits non-zero on a finding takes a `_lint` or `_gate` suffix, and a utility that
-  does work takes none. Any repo carrying Python carries the Python tooling in CI, coverage
-  included, this profile too: `uvx ruff@latest check`, `uvx ruff@latest format --check`,
-  `uvx mypy@latest`, and the unittest suite
-  under `uvx coverage@latest run -m unittest discover -s <scripts-dir>/tests` with
-  `coverage report`, informational with no threshold adopted. A co-present `csharp` type still
-  carries `codecov.yml` for its own tests.
+- **build** (Project): `[project]` + `[build-system]` + committed `uv.lock`. Uses `uv run`, pytest,
+  pyright strict (or mypy where the repo requires it).
+- **lint-only** (Scripts): no `[project]`, no lockfile. Uses `uvx`, unittest, mypy as CI gate.
+
+For the full profile specification and per-repo adaptation axes (type checker, dependency
+declaration, versioning, VS Code config), see `references/profiles.md`.
 
 ## Toolchain
 
@@ -161,105 +111,33 @@ unbuilt code:
 
 ## Code style
 
-### Formatting and linting
+Key rules for every Python task:
 
-- **`ruff format` is authoritative.** Don't argue with the formatter, and if it reformats your
-  code, that's the final form. Configure (line length, target version) in `pyproject.toml`
+- **`ruff format` is authoritative.** Don't argue with the formatter. Configure in `pyproject.toml`
   `[tool.ruff]`, not via inline `# fmt:` directives.
-- **Run `ruff check --fix` before committing.** Most ruff lint rules have safe autofixes, let the
-  tool handle them. The configured rule families are listed under `[tool.ruff.lint]` `select`. Add
-  new rule families project-wide rather than scattering inline `# noqa` markers.
-- **`# noqa` is a last resort.** When you must use one, scope it narrowly (`# noqa: E501`, not
-  bare `# noqa`) and add a short comment on the same line explaining why. False-positive patterns
-  that recur across the codebase belong in `[tool.ruff.lint]` `ignore` or per-file
-  `[tool.ruff.lint.per-file-ignores]`, with a comment. Porting an existing codebase is not a
-  license to add `ignore` / `per-file-ignores` blocks to mute newly surfaced lint. Fix it.
-
-### Comments
-
-- **Inline `#` comments**: keep tight and local. One line is preferred, but multi-line is fine
-  when you need to document a non-obvious implementation constraint, a local trade-off, or
-  coupling that future edits could easily break. Keep that rationale next to the affected block so
-  the reviewer/maintainer sees it at edit-time.
-- **Don't explain what the code does.** Well-named identifiers handle that. Don't reference the
-  current task ("added for X", "used by Y"), which belongs in the PR description.
-
-### Docstrings
-
-- Follow [PEP 257][pep-0257-link]. Focus docstrings primarily on the behavior contract (what
-  callers and tests can rely on), public semantics, and edge-case expectations.
-  Implementation-local rationale belongs in inline `#` comments, not docstrings.
-- A short one-liner is fine for trivial functions and tests with self-documenting names.
-- For non-trivial behavior (non-obvious test scenarios, contracts a test pins, edge cases callers
-  must know about, design trade-offs that are load-bearing for future maintainers), write a
-  one-line summary, blank line, then a details paragraph. Multi-paragraph docstrings are fine when
-  the contract earns it.
-- Design notes belong in the code (docstrings or inline comments). They do NOT belong in
-  `HISTORY.md`, which is end-user release notes, not a design log.
-
-### Type hints
-
-- **All public APIs are typed.** The repo's configured type checker runs on `src/` (pyright strict
-  via `[tool.pyright]` `strict = ["src"]`, or mypy where that is the CI checker), and tests run in
-  the checker's looser/standard mode.
-- **Use modern syntax**: `list[int]` not `List[int]`, `dict[str, X]` not `Dict[str, X]`,
-  `X | None` not `Optional[X]`, `from __future__ import annotations` only when needed for forward
-  references.
-- **Don't add `# type: ignore` to silence pyright errors without a comment** explaining the
-  constraint. If a recurring false positive needs suppression, configure it project-wide in
-  `[tool.pyright]`. A new port doesn't change this, fix freshly surfaced type errors rather than
-  muting them.
-
-### Naming
-
-- `snake_case` for functions, methods, variables, modules, package directories.
-- `PascalCase` for classes, type aliases, type vars, enum members.
-- `UPPER_SNAKE_CASE` for module-level constants.
-- Single leading underscore for module-private, double leading underscore for name-mangled (rare,
-  and usually means rethink the design).
-
-### Imports
-
-- **Let ruff sort imports.** `[tool.ruff.lint]` `select` includes the `I` rule family
-  (isort-equivalent). Don't hand-sort.
-- Standard library first, then third-party, then first-party (the project itself), each block
-  separated by a blank line, which ruff enforces automatically.
-- Avoid wildcard imports (`from x import *`) outside `__init__.py` re-exports.
-
-### Patterns to avoid
-
-- **Don't add backward-compat shims, `# removed` markers, or rename-to-`_` for unused vars**, just
-  delete. Git history is the audit trail.
-- **Don't add error handling for impossible cases.** Trust internal code, and validate only at
-  boundaries (user input, parsed config, external APIs).
-- **Don't use exceptions for expected control flow.** Exceptions are for unexpected states.
-- **Don't suppress errors silently** (`except Exception: pass`). Either handle the specific
-  exception and document why it's safe, or let it propagate.
+- **Run `ruff check --fix` before committing.** The configured rule families are in
+  `[tool.ruff.lint]` `select`. Add new rule families project-wide, not scattered inline `# noqa`.
+- **`# noqa` is a last resort.** Scope it narrowly (`# noqa: E501`) with a comment. Recurring
+  false positives belong in `[tool.ruff.lint]` `ignore` or `per-file-ignores`.
+- **All public APIs are typed.** Use modern syntax (`list[int]`, `X | None`). Don't add
+  `# type: ignore` without an explaining comment.
+- **Don't add backward-compat shims.** Just delete unused code. Git history is the audit trail.
+- **Don't add error handling for impossible cases.** Trust internal code. Validate only at boundaries.
+
+For comments, docstrings, full type-hint rules, naming, imports, and all patterns to avoid, see
+`references/code-style.md`.
 
 ## Tests
 
-- `pytest` with the configuration in `[tool.pytest.ini_options]`. Default invocation:
-  `uv run pytest`.
-- One test file per module under test, named `test_<module>.py`.
-- Test functions named `test_<scenario>_<expected_behavior>`, descriptive and not numbered.
-- Use fixtures (defined in `conftest.py` for shared ones, or per-test for narrowly-scoped) instead
-  of setup/teardown methods.
-- **Avoid mocking when fakes work.** Hand-rolled fakes that implement the protocol you depend on
-  are usually clearer and break less than `unittest.mock` magic.
-- **Test edge cases that the docstring promises**, not implementation details. If the test breaks
-  when you refactor without changing behavior, the test is asserting on an implementation detail.
+`uv run pytest`. One test file per module (`test_<module>.py`), fixtures over setup/teardown,
+fakes over mocks. Test the docstring's contract, not implementation details. See
+`references/testing.md` for the full conventions.
 
 ## Versioning
 
-**Published packages.** `_version.py` ships with `__version__ = "0.0.0"` as a placeholder. Until
-you wire `_version.py` to something that increments (the usual options are `hatch-vcs`, a
-version.json bridge, or manual bumps), no new PyPI versions will land, and publishing with
-`skip-existing: true` keeps a stuck placeholder version from failing the run.
-
-**Source-only repos** (no PyPI publish, with a source-release on dispatch or no release at all) do
-not need `_version.py`: keep a static `version` in `pyproject.toml` `[project]`, or let the
-release pipeline's version source (e.g. NBGV plus `version.json`) own the tag. There is no publish
-step to guard, so `skip-existing` does not apply.
+Published packages use `_version.py` with `__version__ = "0.0.0"` as a placeholder. Wire
+`hatch-vcs` or equivalent to increment, publish with `skip-existing: true`. Source-only repos use
+a static `version` in `[project]` with no `_version.py`. See `references/profiles.md` for details.
 
 ## Linter cleanliness
 
@@ -280,7 +158,6 @@ Before pushing or opening a PR:
 [docs-link]: https://docs.pytest.org/
 [latest-link]: https://hatch.pypa.io/latest/
 [mypy-link]: https://mypy-lang.org/
-[pep-0257-link]: https://peps.python.org/pep-0257/
 [pyright-link]: https://microsoft.github.io/pyright/
 [ruff-link]: https://docs.astral.sh/ruff/
 [uv-link]: https://docs.astral.sh/uv/
diff --git a/.claude-plugin/fleet-skills/skills/python-codestyle/references/code-style.md b/.claude-plugin/fleet-skills/skills/python-codestyle/references/code-style.md
new file mode 100644
index 0000000..b7e62b0
--- /dev/null
+++ b/.claude-plugin/fleet-skills/skills/python-codestyle/references/code-style.md
@@ -0,0 +1,80 @@
+# Python Code Style: Full Reference
+
+## Formatting and linting
+
+- **`ruff format` is authoritative.** Don't argue with the formatter, and if it reformats your
+  code, that's the final form. Configure (line length, target version) in `pyproject.toml`
+  `[tool.ruff]`, not via inline `# fmt:` directives.
+- **Run `ruff check --fix` before committing.** Most ruff lint rules have safe autofixes, let the
+  tool handle them. The configured rule families are listed under `[tool.ruff.lint]` `select`. Add
+  new rule families project-wide rather than scattering inline `# noqa` markers.
+- **`# noqa` is a last resort.** When you must use one, scope it narrowly (`# noqa: E501`, not
+  bare `# noqa`) and add a short comment on the same line explaining why. False-positive patterns
+  that recur across the codebase belong in `[tool.ruff.lint]` `ignore` or per-file
+  `[tool.ruff.lint.per-file-ignores]`, with a comment. Porting an existing codebase is not a
+  license to add `ignore` / `per-file-ignores` blocks to mute newly surfaced lint. Fix it.
+
+## Comments
+
+- **Inline `#` comments**: keep tight and local. One line is preferred, but multi-line is fine
+  when you need to document a non-obvious implementation constraint, a local trade-off, or
+  coupling that future edits could easily break. Keep that rationale next to the affected block so
+  the reviewer/maintainer sees it at edit-time.
+- **Don't explain what the code does.** Well-named identifiers handle that. Don't reference the
+  current task ("added for X", "used by Y"), which belongs in the PR description.
+
+## Docstrings
+
+- Follow [PEP 257][pep-0257-link]. Focus docstrings primarily on the behavior contract (what
+  callers and tests can rely on), public semantics, and edge-case expectations.
+  Implementation-local rationale belongs in inline `#` comments, not docstrings.
+- A short one-liner is fine for trivial functions and tests with self-documenting names.
+- For non-trivial behavior (non-obvious test scenarios, contracts a test pins, edge cases callers
+  must know about, design trade-offs that are load-bearing for future maintainers), write a
+  one-line summary, blank line, then a details paragraph. Multi-paragraph docstrings are fine when
+  the contract earns it.
+- Design notes belong in the code (docstrings or inline comments). They do NOT belong in
+  `HISTORY.md`, which is end-user release notes, not a design log.
+
+## Type hints
+
+- **All public APIs are typed.** The repo's configured type checker runs on `src/` (pyright strict
+  via `[tool.pyright]` `strict = ["src"]`, or mypy where that is the CI checker), and tests run in
+  the checker's looser/standard mode.
+- **Use modern syntax**: `list[int]` not `List[int]`, `dict[str, X]` not `Dict[str, X]`,
+  `X | None` not `Optional[X]`, `from __future__ import annotations` only when needed for forward
+  references.
+- **Don't add `# type: ignore` to silence pyright errors without a comment** explaining the
+  constraint. If a recurring false positive needs suppression, configure it project-wide in
+  `[tool.pyright]`. A new port doesn't change this, fix freshly surfaced type errors rather than
+  muting them.
+
+## Naming
+
+- `snake_case` for functions, methods, variables, modules, package directories.
+- `PascalCase` for classes, type aliases, type vars, enum members.
+- `UPPER_SNAKE_CASE` for module-level constants.
+- Single leading underscore for module-private, double leading underscore for name-mangled (rare,
+  and usually means rethink the design).
+
+## Imports
+
+- **Let ruff sort imports.** `[tool.ruff.lint]` `select` includes the `I` rule family
+  (isort-equivalent). Don't hand-sort.
+- Standard library first, then third-party, then first-party (the project itself), each block
+  separated by a blank line, which ruff enforces automatically.
+- Avoid wildcard imports (`from x import *`) outside `__init__.py` re-exports.
+
+## Patterns to avoid
+
+- **Don't add backward-compat shims, `# removed` markers, or rename-to-`_` for unused vars**, just
+  delete. Git history is the audit trail.
+- **Don't add error handling for impossible cases.** Trust internal code, and validate only at
+  boundaries (user input, parsed config, external APIs).
+- **Don't use exceptions for expected control flow.** Exceptions are for unexpected states.
+- **Don't suppress errors silently** (`except Exception: pass`). Either handle the specific
+  exception and document why it's safe, or let it propagate.
+
+<!-- External -->
+
+[pep-0257-link]: https://peps.python.org/pep-0257/
diff --git a/.claude-plugin/fleet-skills/skills/python-codestyle/references/profiles.md b/.claude-plugin/fleet-skills/skills/python-codestyle/references/profiles.md
new file mode 100644
index 0000000..b7eedfb
--- /dev/null
+++ b/.claude-plugin/fleet-skills/skills/python-codestyle/references/profiles.md
@@ -0,0 +1,74 @@
+# Python Profile Details
+
+## Adapt before propagating
+
+The rules in `SKILL.md` describe the default Python profile: a package that publishes to PyPI,
+type-checked by pyright in strict mode, dependencies in `[dependency-groups]`. A derived repo
+often differs, and when it does, adapt these fields to match the repo's actual toolchain rather
+than copying verbatim (a verbatim copy that misdescribes the repo is inaccurate and gets rejected
+in review). The axes that commonly vary per repo:
+
+- **Type checker in CI**: pyright strict, mypy in CI with pyright editor-only (Pylance), or both.
+  Whichever runs in CI is the one the clean-compile and the CI gate invoke.
+- **Dependency declaration**: `[dependency-groups]`, or PEP 621 `[project.optional-dependencies]`
+  (dev tools installed with `uv sync --extra <group>`).
+- **Versioning / publishing**: a published package (`_version.py` plus a version source,
+  `uv build`, and a PyPI publish step), or a source-only repo with a static `version` and no
+  publish step (see Versioning below).
+- **Disabled markdownlint rules**: repo-specific, `.markdownlint-cli2.jsonc` at the repo root is
+  the source of truth, not any example rule named here.
+- **VS Code config home**: editor settings/extensions may live in `.vscode/*.json` or the
+  `<Repo>.code-workspace`, while tasks/launch/debug configs can only be external `.vscode/*.json`
+  (they cannot live in the workspace file). The repo's own `tasks.json` sits wherever it keeps it,
+  and the canonical task definitions it is written against are the hub `vscode-tasks-python.json`
+  snippet, which resolves the same way from every repo.
+
+## Two profiles: full specification
+
+A repo's Python is one of two shapes, declared as the `build` or `lint-only` profile and validated
+against the `pyproject.toml` shape. Most of the `SKILL.md` rules (uv project, `uv.lock`, `uv run`,
+src layout, pytest coverage) describe the Project shape (the `build` profile). The two differ by
+whether the Python has third-party runtime dependencies, which shows up structurally in
+`pyproject.toml`, so the fleet's audit reads the shape there:
+
+- **Project** (the `build` profile): the Python has third-party runtime dependencies, or is the
+  repo's deliverable. It is a PEP 621 uv project: `[project]` with `dependencies` (dev tools in
+  `[project.optional-dependencies]` or `[dependency-groups]`), a `[build-system]`, and a committed
+  `uv.lock` (pinned LF, per GOVERNANCE.md's "Line Endings" section). CI runs `uv sync --frozen` +
+  `uv run <tool>`, so the lockfile pins tool versions.
+- **Scripts** (the `lint-only` profile): stdlib-only utility scripts embedded in a non-Python repo
+  (e.g. a Python tooling subtree of a `csharp` app). Run the tools with `uvx` (no project install,
+  no lockfile): the `pyproject.toml` carries only tool config (`[tool.ruff]`, `[tool.mypy]`, and
+  an optional `[tool.pyright]` editor block), with no `[project]`, no `[build-system]`, and no
+  `uv.lock` (that metadata would misrepresent it as a shippable package). mypy is the type-check
+  gate (there is no first-party package for pyright strict to anchor on), and a `[tool.pyright]`
+  block in standard mode keeps Pylance quiet in the editor, the same mypy-gate/pyright-editor
+  split the build profile uses. There is no lockfile, and a `uvx <tool>@<ver>` pin in a `run:`
+  step is not something Dependabot tracks, so CI runs `uvx ruff@latest` / `uvx mypy@latest` rather
+  than a manual pin that would silently go stale. The fleet rule is to pin only what Dependabot
+  auto-updates (SHA-pinned actions, package deps) and otherwise run latest, so the VS Code tasks,
+  README, and CI all run the unpinned latest here. `.py` files follow the repo's LF line-ending
+  default (per GOVERNANCE.md's "Line Endings" section). There is no pytest suite, and `unittest` is
+  the runner instead. A script that carries a gate still earns tests, written with the standard
+  library's `unittest` so they run under bare `python3` with nothing installed, as
+  `test_<script>.py` under a `tests/` directory beside the scripts it exercises
+  (`<scripts-dir>/tests/`), kept apart so a test never reads as a tool. Within the scripts
+  directory the name carries the kind: a gate that checks and exits non-zero on a finding takes a
+  `_lint` or `_gate` suffix, and a utility that does work takes none. Any repo carrying Python
+  carries the Python tooling in CI, coverage included, this profile too: `uvx ruff@latest check`,
+  `uvx ruff@latest format --check`, `uvx mypy@latest`, and the unittest suite under
+  `uvx coverage@latest run -m unittest discover -s <scripts-dir>/tests` with `coverage report`,
+  informational with no threshold adopted. A co-present `csharp` type still carries `codecov.yml`
+  for its own tests.
+
+## Versioning
+
+**Published packages.** `_version.py` ships with `__version__ = "0.0.0"` as a placeholder. Until
+you wire `_version.py` to something that increments (the usual options are `hatch-vcs`, a
+version.json bridge, or manual bumps), no new PyPI versions will land, and publishing with
+`skip-existing: true` keeps a stuck placeholder version from failing the run.
+
+**Source-only repos** (no PyPI publish, with a source-release on dispatch or no release at all) do
+not need `_version.py`: keep a static `version` in `pyproject.toml` `[project]`, or let the
+release pipeline's version source (e.g. NBGV plus `version.json`) own the tag. There is no publish
+step to guard, so `skip-existing` does not apply.
diff --git a/.claude-plugin/fleet-skills/skills/python-codestyle/references/testing.md b/.claude-plugin/fleet-skills/skills/python-codestyle/references/testing.md
new file mode 100644
index 0000000..c19ff9d
--- /dev/null
+++ b/.claude-plugin/fleet-skills/skills/python-codestyle/references/testing.md
@@ -0,0 +1,13 @@
+# Python Testing Conventions
+
+Use `pytest` with configuration in `[tool.pytest.ini_options]`. Default invocation:
+`uv run pytest`.
+
+- One test file per module under test, named `test_<module>.py`.
+- Test functions named `test_<scenario>_<expected_behavior>`, descriptive and not numbered.
+- Use fixtures (defined in `conftest.py` for shared ones, or per-test for narrowly-scoped) instead
+  of setup/teardown methods.
+- **Avoid mocking when fakes work.** Hand-rolled fakes that implement the protocol you depend on
+  are usually clearer and break less than `unittest.mock` magic.
+- **Test edge cases that the docstring promises**, not implementation details. If the test breaks
+  when you refactor without changing behavior, the test is asserting on an implementation detail.