From eae019f4874e0ddc05d8fafe0c8f40659a2f66a7 Mon Sep 17 00:00:00 2001
From: darthsharp <48331467+darthsharp@users.noreply.github.com>
Date: Thu, 27 Aug 2026 18:54:11 +0200
Subject: [PATCH 1/2] Remove unused references, scripts, and markdown
 documentation across multiple skills

- Deleted unused `auth.md`, `azure-devops-markdown-guidance.md`, `concurrency-control.md`, `configuration.md`, `considerations.md`, and related markdown files across `.claude` and `.github/skills`.
- Removed `collect-diff.sh` script from multiple locations.
- Cleaned up deprecated `.github/copilot-instructions.md` and `csharp.instructions.md`.
---
 .claude/agents/dotnet-developer.md            |  27 --
 .../skills/convert-plaintext-to-md/SKILL.md   |  33 --
 .../azure-devops-markdown-guidance.md         | 173 --------
 .../references/considerations.md              |  40 --
 .../references/examples.md                    | 221 -----------
 .../references/github-basic-formatting.md     | 153 -------
 .../references/markdown-extended-syntax.md    | 133 -------
 .../references/parameters.md                  | 103 -----
 .claude/skills/create-readme/SKILL.md         |  17 -
 .../references/github-admonition-syntax.md    |  60 ---
 .../references/run-on-output-readme.md        | 146 -------
 .../serverless-chat-langchainjs-readme.md     | 280 -------------
 .../serverless-recipes-javascript-readme.md   | 162 --------
 .../create-readme/references/smoke-readme.md  | 366 -----------------
 .claude/skills/dotnet-aspnet/SKILL.md         |  46 ---
 .../skills/dotnet-aspnet/references/auth.md   |  26 --
 .../references/error-handling.md              |  44 ---
 .../dotnet-aspnet/references/middleware.md    |  38 --
 .../references/model-binding-validation.md    |  71 ----
 .../references/openapi-and-cross-cutting.md   | 100 -----
 .../references/project-and-endpoints.md       |  92 -----
 .claude/skills/dotnet-dev/SKILL.md            | 312 ---------------
 .../skills/dotnet-dev/references/REFERENCE.md | 209 ----------
 .claude/skills/dotnet-ef-core/SKILL.md        | 107 -----
 .../references/concurrency-control.md         |  52 ---
 .claude/skills/dotnet-fundamentals/SKILL.md   |  41 --
 .../references/configuration.md               |  79 ----
 .../references/dependency-injection.md        |  81 ----
 .../references/modern-patterns.md             |  87 ----
 .../references/options-pattern.md             |  89 -----
 .claude/skills/dotnet-inspect/SKILL.md        | 235 -----------
 .claude/skills/dotnet-nuget-manager/SKILL.md  |  86 ----
 .claude/skills/dotnet-reviewer/SKILL.md       | 138 -------
 .../references/report-format.md               |  78 ----
 .../review-checklist-architecture.md          |  37 --
 .../review-checklist-code-quality.md          |  57 ---
 .../references/review-checklist-net10.md      |  30 --
 .../review-checklist-performance.md           |  44 ---
 .../references/review-checklist-security.md   |  61 ---
 .../references/severity-taxonomy.md           |  52 ---
 .../dotnet-reviewer/scripts/collect-diff.sh   | 110 ------
 .../scripts/detect-dotnet-version.sh          | 119 ------
 .../dotnet-reviewer/scripts/run-checks.sh     | 103 -----
 .claude/skills/dotnet-sdk-builder/SKILL.md    | 134 -------
 .../references/di-patterns.md                 | 186 ---------
 .../references/http-client-patterns.md        | 254 ------------
 .../references/project-setup.md               | 123 ------
 .claude/skills/dotnet-tester/SKILL.md         | 140 -------
 .claude/skills/dotnet-xmldocs/SKILL.md        |  41 --
 .../references/member-documentation-rules.md  |  41 --
 .claude/skills/dotnet/SKILL.md                |  46 ---
 .github/agents/dotnet-developer.md            |  27 --
 .github/copilot-instructions.md               | 109 -----
 .github/instructions/csharp.instructions.md   |  89 -----
 .github/skills/boost-prompt/SKILL.md          |  18 -
 .github/skills/code-review/SKILL.md           |  48 ---
 .../skills/convert-plaintext-to-md/SKILL.md   |  33 --
 .../azure-devops-markdown-guidance.md         | 173 --------
 .../references/considerations.md              |  40 --
 .../references/examples.md                    | 221 -----------
 .../references/github-basic-formatting.md     | 153 -------
 .../references/markdown-extended-syntax.md    | 133 -------
 .../references/parameters.md                  | 103 -----
 .github/skills/create-readme/SKILL.md         |  17 -
 .../references/github-admonition-syntax.md    |  60 ---
 .../references/run-on-output-readme.md        | 146 -------
 .../serverless-chat-langchainjs-readme.md     | 280 -------------
 .../serverless-recipes-javascript-readme.md   | 162 --------
 .../create-readme/references/smoke-readme.md  | 366 -----------------
 .github/skills/csharp-docs/SKILL.md           |  28 --
 .../references/member-documentation-rules.md  |  41 --
 .github/skills/dotnet-aspnet/SKILL.md         | 372 ------------------
 .github/skills/dotnet-inspect/SKILL.md        | 229 -----------
 .github/skills/dotnet-reviewer/SKILL.md       | 134 -------
 .../references/report-format.md               |  78 ----
 .../review-checklist-architecture.md          |  40 --
 .../review-checklist-code-quality.md          |  62 ---
 .../references/review-checklist-net10.md      |  35 --
 .../review-checklist-performance.md           |  49 ---
 .../references/review-checklist-security.md   |  61 ---
 .../references/severity-taxonomy.md           |  52 ---
 .../dotnet-reviewer/scripts/collect-diff.sh   | 110 ------
 .../scripts/detect-dotnet-version.sh          | 119 ------
 .../dotnet-reviewer/scripts/run-checks.sh     | 103 -----
 .github/skills/dotnet-sdk-builder/SKILL.md    | 129 ------
 .../references/di-patterns.md                 | 186 ---------
 .../references/http-client-patterns.md        | 254 ------------
 .../references/project-setup.md               | 121 ------
 .github/skills/dotnet-tester/SKILL.md         | 121 ------
 .github/skills/ef-core/SKILL.md               |  91 -----
 .../ef-core/references/concurrency-control.md |  52 ---
 .github/skills/nuget-manager/SKILL.md         |  70 ----
 .github/skills/refactoring/SKILL.md           |  22 --
 .github/workflows/sync-ai-config.yml          |  44 ---
 .junie/guidelines.md                          | 212 ----------
 .serena/project.yml                           |  93 ++---
 96 files changed, 40 insertions(+), 10549 deletions(-)
 delete mode 100644 .claude/agents/dotnet-developer.md
 delete mode 100644 .claude/skills/convert-plaintext-to-md/SKILL.md
 delete mode 100644 .claude/skills/convert-plaintext-to-md/references/azure-devops-markdown-guidance.md
 delete mode 100644 .claude/skills/convert-plaintext-to-md/references/considerations.md
 delete mode 100644 .claude/skills/convert-plaintext-to-md/references/examples.md
 delete mode 100644 .claude/skills/convert-plaintext-to-md/references/github-basic-formatting.md
 delete mode 100644 .claude/skills/convert-plaintext-to-md/references/markdown-extended-syntax.md
 delete mode 100644 .claude/skills/convert-plaintext-to-md/references/parameters.md
 delete mode 100644 .claude/skills/create-readme/SKILL.md
 delete mode 100644 .claude/skills/create-readme/references/github-admonition-syntax.md
 delete mode 100644 .claude/skills/create-readme/references/run-on-output-readme.md
 delete mode 100644 .claude/skills/create-readme/references/serverless-chat-langchainjs-readme.md
 delete mode 100644 .claude/skills/create-readme/references/serverless-recipes-javascript-readme.md
 delete mode 100644 .claude/skills/create-readme/references/smoke-readme.md
 delete mode 100644 .claude/skills/dotnet-aspnet/SKILL.md
 delete mode 100644 .claude/skills/dotnet-aspnet/references/auth.md
 delete mode 100644 .claude/skills/dotnet-aspnet/references/error-handling.md
 delete mode 100644 .claude/skills/dotnet-aspnet/references/middleware.md
 delete mode 100644 .claude/skills/dotnet-aspnet/references/model-binding-validation.md
 delete mode 100644 .claude/skills/dotnet-aspnet/references/openapi-and-cross-cutting.md
 delete mode 100644 .claude/skills/dotnet-aspnet/references/project-and-endpoints.md
 delete mode 100644 .claude/skills/dotnet-dev/SKILL.md
 delete mode 100644 .claude/skills/dotnet-dev/references/REFERENCE.md
 delete mode 100644 .claude/skills/dotnet-ef-core/SKILL.md
 delete mode 100644 .claude/skills/dotnet-ef-core/references/concurrency-control.md
 delete mode 100644 .claude/skills/dotnet-fundamentals/SKILL.md
 delete mode 100644 .claude/skills/dotnet-fundamentals/references/configuration.md
 delete mode 100644 .claude/skills/dotnet-fundamentals/references/dependency-injection.md
 delete mode 100644 .claude/skills/dotnet-fundamentals/references/modern-patterns.md
 delete mode 100644 .claude/skills/dotnet-fundamentals/references/options-pattern.md
 delete mode 100644 .claude/skills/dotnet-inspect/SKILL.md
 delete mode 100644 .claude/skills/dotnet-nuget-manager/SKILL.md
 delete mode 100644 .claude/skills/dotnet-reviewer/SKILL.md
 delete mode 100644 .claude/skills/dotnet-reviewer/references/report-format.md
 delete mode 100644 .claude/skills/dotnet-reviewer/references/review-checklist-architecture.md
 delete mode 100644 .claude/skills/dotnet-reviewer/references/review-checklist-code-quality.md
 delete mode 100644 .claude/skills/dotnet-reviewer/references/review-checklist-net10.md
 delete mode 100644 .claude/skills/dotnet-reviewer/references/review-checklist-performance.md
 delete mode 100644 .claude/skills/dotnet-reviewer/references/review-checklist-security.md
 delete mode 100644 .claude/skills/dotnet-reviewer/references/severity-taxonomy.md
 delete mode 100644 .claude/skills/dotnet-reviewer/scripts/collect-diff.sh
 delete mode 100644 .claude/skills/dotnet-reviewer/scripts/detect-dotnet-version.sh
 delete mode 100644 .claude/skills/dotnet-reviewer/scripts/run-checks.sh
 delete mode 100644 .claude/skills/dotnet-sdk-builder/SKILL.md
 delete mode 100644 .claude/skills/dotnet-sdk-builder/references/di-patterns.md
 delete mode 100644 .claude/skills/dotnet-sdk-builder/references/http-client-patterns.md
 delete mode 100644 .claude/skills/dotnet-sdk-builder/references/project-setup.md
 delete mode 100644 .claude/skills/dotnet-tester/SKILL.md
 delete mode 100644 .claude/skills/dotnet-xmldocs/SKILL.md
 delete mode 100644 .claude/skills/dotnet-xmldocs/references/member-documentation-rules.md
 delete mode 100644 .claude/skills/dotnet/SKILL.md
 delete mode 100644 .github/agents/dotnet-developer.md
 delete mode 100644 .github/copilot-instructions.md
 delete mode 100644 .github/instructions/csharp.instructions.md
 delete mode 100644 .github/skills/boost-prompt/SKILL.md
 delete mode 100644 .github/skills/code-review/SKILL.md
 delete mode 100644 .github/skills/convert-plaintext-to-md/SKILL.md
 delete mode 100644 .github/skills/convert-plaintext-to-md/references/azure-devops-markdown-guidance.md
 delete mode 100644 .github/skills/convert-plaintext-to-md/references/considerations.md
 delete mode 100644 .github/skills/convert-plaintext-to-md/references/examples.md
 delete mode 100644 .github/skills/convert-plaintext-to-md/references/github-basic-formatting.md
 delete mode 100644 .github/skills/convert-plaintext-to-md/references/markdown-extended-syntax.md
 delete mode 100644 .github/skills/convert-plaintext-to-md/references/parameters.md
 delete mode 100644 .github/skills/create-readme/SKILL.md
 delete mode 100644 .github/skills/create-readme/references/github-admonition-syntax.md
 delete mode 100644 .github/skills/create-readme/references/run-on-output-readme.md
 delete mode 100644 .github/skills/create-readme/references/serverless-chat-langchainjs-readme.md
 delete mode 100644 .github/skills/create-readme/references/serverless-recipes-javascript-readme.md
 delete mode 100644 .github/skills/create-readme/references/smoke-readme.md
 delete mode 100644 .github/skills/csharp-docs/SKILL.md
 delete mode 100644 .github/skills/csharp-docs/references/member-documentation-rules.md
 delete mode 100644 .github/skills/dotnet-aspnet/SKILL.md
 delete mode 100644 .github/skills/dotnet-inspect/SKILL.md
 delete mode 100644 .github/skills/dotnet-reviewer/SKILL.md
 delete mode 100644 .github/skills/dotnet-reviewer/references/report-format.md
 delete mode 100644 .github/skills/dotnet-reviewer/references/review-checklist-architecture.md
 delete mode 100644 .github/skills/dotnet-reviewer/references/review-checklist-code-quality.md
 delete mode 100644 .github/skills/dotnet-reviewer/references/review-checklist-net10.md
 delete mode 100644 .github/skills/dotnet-reviewer/references/review-checklist-performance.md
 delete mode 100644 .github/skills/dotnet-reviewer/references/review-checklist-security.md
 delete mode 100644 .github/skills/dotnet-reviewer/references/severity-taxonomy.md
 delete mode 100644 .github/skills/dotnet-reviewer/scripts/collect-diff.sh
 delete mode 100644 .github/skills/dotnet-reviewer/scripts/detect-dotnet-version.sh
 delete mode 100644 .github/skills/dotnet-reviewer/scripts/run-checks.sh
 delete mode 100644 .github/skills/dotnet-sdk-builder/SKILL.md
 delete mode 100644 .github/skills/dotnet-sdk-builder/references/di-patterns.md
 delete mode 100644 .github/skills/dotnet-sdk-builder/references/http-client-patterns.md
 delete mode 100644 .github/skills/dotnet-sdk-builder/references/project-setup.md
 delete mode 100644 .github/skills/dotnet-tester/SKILL.md
 delete mode 100644 .github/skills/ef-core/SKILL.md
 delete mode 100644 .github/skills/ef-core/references/concurrency-control.md
 delete mode 100644 .github/skills/nuget-manager/SKILL.md
 delete mode 100644 .github/skills/refactoring/SKILL.md
 delete mode 100644 .github/workflows/sync-ai-config.yml
 delete mode 100644 .junie/guidelines.md

diff --git a/.claude/agents/dotnet-developer.md b/.claude/agents/dotnet-developer.md
deleted file mode 100644
index fe21deea..00000000
--- a/.claude/agents/dotnet-developer.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-name: dotnet-developer
-description: .NET developer agent specialized in building enterprise applications using C# and the .NET ecosystem. Delegates to specialized skills for SDK development, testing, data access, package management, documentation, code review, and refactoring.
----
-
-# .NET Developer Agent
-
-**Scope: C# / .NET Projects**
-
-## Role
-
-You are a .NET developer specialized in building enterprise applications using the .NET ecosystem. You delegate to specialized skills for each area of work.
-
-## Skills
-
-Use the following skills based on the task at hand:
-
-| Area | Skill | Description |
-|------|-------|-------------|
-| Web & REST APIs | `dotnet-aspnet` | ASP.NET Core controllers, minimal APIs, middleware, auth, and API conventions |
-| SDK & Library Development | `dotnet-sdk-builder` | Generate .NET SDK libraries with DI support, typed HTTP clients, and Options pattern |
-| Testing | `dotnet-tester` | Write and execute unit tests using xUnit, FakeItEasy, and AwesomeAssertions |
-| Data Access | `dotnet-ef-core` | Entity Framework Core best practices, DbContext design, migrations, and queries |
-| Package Management | `dotnet-nuget-manager` | Add, remove, and update NuGet packages via dotnet CLI |
-| Documentation | `dotnet-xmldocs` | C# XML documentation comments following Microsoft standards |
-| Code Review | `code-review` | Structured code reviews covering quality, security, and performance |
-| Refactoring | `refactoring` | Improve code structure and maintainability without changing behavior |
diff --git a/.claude/skills/convert-plaintext-to-md/SKILL.md b/.claude/skills/convert-plaintext-to-md/SKILL.md
deleted file mode 100644
index e92d220c..00000000
--- a/.claude/skills/convert-plaintext-to-md/SKILL.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-name: convert-plaintext-to-md
-description: Converts plain text or legacy documentation files to properly formatted Markdown. Use when asked to convert, migrate, or reformat a plaintext file to .md format. Supports reference-guided conversion, formatting options (headers, code blocks, indentation), and finalization/cleanup of existing .md files.
----
-
-# Convert Plaintext Documentation to Markdown
-
-## Conversion Methods
-
-You can perform conversions using one of three approaches:
-
-1. **From explicit instructions** — Follow specific conversion instructions provided with the request.
-2. **From documented options** — If a documented option/procedure is passed, follow those established conversion rules.
-3. **From reference file** — Use another markdown file (that was previously converted from text format) as a template and guide for converting similar documents.
-
-When using a reference file, apply the same formatting patterns, structure, and conventions — while adapting to the specific content of the file being converted.
-
-## Workflow
-
-1. Determine the input file and check whether a `.md` counterpart already exists (see [parameters.md](./references/parameters.md))
-2. Identify which conversion method applies
-3. Apply the requested parameters and options (see [parameters.md](./references/parameters.md))
-4. Follow pattern recognition and content preservation rules (see [considerations.md](./references/considerations.md))
-5. If `finalize` is passed, clean up formatting after conversion
-
-## References
-
-- [Parameters and Options](./references/parameters.md) — Full parameter reference, options (`--header`, `--pattern`, `--stop`), predefined instructions
-- [Usage Examples](./references/examples.md) — Worked examples: basic conversion, guide-based, finalize, inline regex pattern
-- [Conversion Considerations](./references/considerations.md) — Pattern recognition, conversion goals, markdown style references
-
-> [!IMPORTANT]
-> Do not change the data content unless the prompt instructions clearly and without a doubt specify to do so.
diff --git a/.claude/skills/convert-plaintext-to-md/references/azure-devops-markdown-guidance.md b/.claude/skills/convert-plaintext-to-md/references/azure-devops-markdown-guidance.md
deleted file mode 100644
index 59631614..00000000
--- a/.claude/skills/convert-plaintext-to-md/references/azure-devops-markdown-guidance.md
+++ /dev/null
@@ -1,173 +0,0 @@
-# Azure DevOps Markdown Guidance
-
-This reference describes Markdown syntax supported by Azure DevOps features including Wiki pages, README files, dashboards, and pull requests.
-
-## Supported Features
-
-| Markdown type | Definition of Done | Widget | Pull Requests | README | Wiki |
-|---|---|---|---|---|---|
-| Headings | Yes | Yes | Yes | Yes | Yes |
-| Paragraphs/line breaks | Yes | Yes | Yes | Yes | Yes |
-| Blockquotes | Yes | Yes | Yes | Yes | Yes |
-| Horizontal rules | Yes | Yes | Yes | Yes | Yes |
-| Emphasis (bold, italic) | Yes | Yes | Yes | Yes | Yes |
-| Tables | No | Yes | Yes | Yes | Yes |
-| Lists (ordered, unordered) | Yes | Yes | Yes | Yes | Yes |
-| Links | Yes | Yes | Yes | Yes | Yes |
-| Images | No | Yes | Yes | Yes | Yes |
-| Code highlighting | No | Yes | Yes | Yes | Yes |
-| Math notation | No | No | Yes | Yes | Yes |
-| Checklists/task lists | No | No | Yes | Yes | Yes |
-| Mermaid diagrams | No | No | No | No | Yes |
-
-> **Note:** Markdown in Azure DevOps doesn't support JavaScript or iframes.
-
-## Headings
-
-```markdown
-# Heading 1
-## Heading 2
-### Heading 3
-#### Heading 4
-##### Heading 5
-###### Heading 6
-```
-
-## Paragraphs and Line Breaks
-
-Use a blank line for new paragraphs. Use two spaces at line end or `<br/>` for line breaks within a paragraph.
-
-## Blockquotes
-
-```markdown
-> Single blockquote
->> Nested blockquote
-```
-
-## Horizontal Rules
-
-Use three or more hyphens, asterisks, or underscores on a line by themselves.
-
-## Emphasis
-
-```markdown
-*Italic* or _Italic_
-**Bold** or __Bold__
-***Bold italic***
-~~Strikethrough~~
-```
-
-## Code Highlighting
-
-**Inline:** Use single backticks `` `code` ``
-
-**Block:** Use triple backticks with optional language identifier:
-
-````markdown
-```javascript
-const x = 1;
-```
-````
-
-Supported languages include: ActionScript, Apex, Bash, C, C#, C++, CSS, Dart, Go, Groovy, Haskell, HTML, Java, JavaScript, JSON, Kotlin, Lua, Markdown, Objective-C, Perl, PHP, PowerShell, Python, R, Ruby, Rust, Scala, Shell, SQL, Swift, TypeScript, XML, YAML, and more.
-
-## Tables
-
-```markdown
-| Header 1 | Header 2 |
-|----------|----------|
-| Cell 1   | Cell 2   |
-```
-
-Alignment with colons: `:---` (left), `:---:` (center), `---:` (right).
-
-## Lists
-
-**Ordered:**
-
-```markdown
-1. First item
-2. Second item
-```
-
-**Unordered:**
-
-```markdown
-- Item 1
-- Item 2
-```
-
-**Nested:** Indent with spaces.
-
-## Links
-
-```markdown
-[Link text](URL)
-[Link text](URL "Title")
-```
-
-**Anchor links:** Link to headings within the same page using `#section-name`.
-
-## Images
-
-```markdown
-![Alt text](image-url)
-![Alt text](image-url =WIDTHxHEIGHT)
-```
-
-Azure DevOps supports image resizing with `=WIDTHxHEIGHT` syntax.
-
-## Checklists / Task Lists
-
-```markdown
-- [ ] Incomplete task
-- [x] Completed task
-```
-
-## Mathematical Notation
-
-**Inline:** `$` delimiters: `$e^{i\pi} = -1$`
-
-**Block:** `$$` delimiters:
-
-```markdown
-$$
-\sum_{i=1}^{n} x_i
-$$
-```
-
-Uses KaTeX for rendering.
-
-## Mermaid Diagrams (Wiki only)
-
-````markdown
-```mermaid
-graph TD;
-    A-->B;
-    B-->C;
-```
-````
-
-Supports: flowcharts, sequence diagrams, Gantt charts, and more.
-
-## Collapsible Sections
-
-```html
-<details>
-  <summary>Click to expand</summary>
-
-  Content here (leave blank line after summary tag).
-</details>
-```
-
-## Emoji
-
-Use standard emoji shortcodes: `:smile:`, `:thumbsup:`, etc.
-
-## Special Characters
-
-Escape special Markdown characters with backslash: `\*`, `\#`, `\[`, etc.
-
-## HTML Tags
-
-Supported HTML tags in Wiki include: `<div>`, `<span>`, `<img>`, `<br>`, `<table>`, `<tr>`, `<td>`, `<th>`, `<strong>`, `<em>`, `<code>`, `<pre>`, `<blockquote>`, `<ul>`, `<ol>`, `<li>`, `<h1>`-`<h6>`, `<hr>`, `<p>`, `<a>`, `<details>`, `<summary>`, `<video>`, `<audio>`.
diff --git a/.claude/skills/convert-plaintext-to-md/references/considerations.md b/.claude/skills/convert-plaintext-to-md/references/considerations.md
deleted file mode 100644
index 5e053ed3..00000000
--- a/.claude/skills/convert-plaintext-to-md/references/considerations.md
+++ /dev/null
@@ -1,40 +0,0 @@
-# Conversion Considerations
-
-## Pattern Recognition
-
-When converting plaintext, pay attention to:
-
-- **Line indentation** — determines nesting level for lists and code blocks
-- **Indented code blocks** — lines indented with 4+ spaces relative to context
-- **Fenced code blocks** — detect language from context and add language identifier
-- **Section separators** — lines like `===`, `---`, `***` map to horizontal rules or heading levels
-
-### Do Not Stop on Process-Related Keywords
-
-When converting documentation, do **not** halt the conversion when the text documents procedures that use shell commands or function calls. These are content to be preserved, not instructions to execute:
-
-- `exit` / `exit()`
-- `kill` / `killall`
-- `quit` / `quit()`
-- `sleep` / `sleep()`
-- Similar commands, functions, or procedures
-
----
-
-## Conversion Goals
-
-- Preserve all technical content accurately — do **not** change data unless prompt instructions clearly specify to do so
-- Maintain proper markdown syntax and formatting
-- Ensure headers, lists, code blocks, and other elements are correctly structured
-- Keep the document readable and well-organized
-- Assemble a unified set of instructions using all parameters and options provided
-
----
-
-## Markdown References
-
-When in doubt, consult these resources for markdown best practices:
-
-- [GitHub Basic Writing and Formatting Syntax](./github-basic-formatting.md)
-- [Markdown Extended Syntax](./markdown-extended-syntax.md)
-- [Azure DevOps Markdown Guidance](./azure-devops-markdown-guidance.md)
diff --git a/.claude/skills/convert-plaintext-to-md/references/examples.md b/.claude/skills/convert-plaintext-to-md/references/examples.md
deleted file mode 100644
index d92bbc8f..00000000
--- a/.claude/skills/convert-plaintext-to-md/references/examples.md
+++ /dev/null
@@ -1,221 +0,0 @@
-# Usage Examples
-
-## Basic Conversion
-
-**User**
-
-```bash
-/convert-plaintext-to-md #file
-```
-
-**Agent**
-
-```
-I see there is no corresponding `file.md`. Let me copy the plaintext document:
-
-    ```bash
-    cp file file.md
-    ```
-
-Now I'll apply markdown best practices to convert the plaintext documentation to a markdown document.
-```
-
----
-
-## Guide-Based Conversion
-
-Uses a previously converted markdown file as a formatting reference.
-
-**User**
-
-```bash
-/convert-plaintext-to-md #file.md --guide #CODE.md
-```
-
-**Agent**
-
-```
-I see that both the file and CODE markdown files have corresponding plaintext documentation. Let me
-check CODE and compare it to CODE.md, and identify patterns to help with conversion.
-
-    CODE
-    ```text
-    Title
-
-    Text in opening.
-
-    1. Section
-      1.1 Section Item
-
-    =============================================
-
-    1. Section
-      1.1
-      Full details of section item.
-    ```
-
-And looking at CODE.md:
-
-    CODE.md
-    ```markdown
-    # Title
-
-    Text in opening.
-
-    ### [Section](#1-section)
-
-    - [1.1](#11) Section Item but Only Numbers in Sub-heading
-
-    ***
-
-    ## 1. Section
-
-    ### 1.1
-
-    Full details of section item.
-    ```
-
-I see file.md exists and matches the text in file.
-
-I'll convert file.md similarly. Let's look at the file text documentation:
-
-    file
-    ```text
-    Title
-
-    1. Command
-      1.10.0 Options
-
-    ---------------------------------------------
-
-    Command
-      1.10.0
-      Info on the commands' options.
-    ```
-
-OK, after analyzing the guide file, I've updated file.md to:
-
-    file.md
-    ```markdown
-    # Title
-
-    ### [1. Command](#command)
-    - [1.10.0](#1100-option-with-text-subheading) Option With Text Subheading
-
-    ***
-
-    ## Command
-
-    ### 1.10.0 Option With Text Subheading
-    Info on the commands' options.
-    ```
-```
-
----
-
-## Finalize / Polish
-
-Natural language variations like "polish", "clean up", or "finalize" all trigger the `finalize` behavior.
-
-**User**
-
-```bash
-/convert-plaintext-to-md #file.md polish the converted markdown file
-```
-
-**Agent**
-
-```
-I'll finalize file.md. I see the current converted markdown file has:
-
-    ```markdown
-    # Title
-
-    Some paragraph with space character at start of line. This <html> should be escaped.
-
-    -  Some list item with extra space character.
-    -  Nested list but only one nesting space character, and extra space after dash.
-      if (a == 1) {
-        return "Indented code block without enough space characters.";
-      } else {
-        return "Passing `finalize` or similar should resolve this.";
-      }
-
-    But when `python` is used, syntax will be like:
-    ```
-
-    ```
-    import math
-    radius = float(input("This is clearly python, but let's do math."))
-    area = math.pi * radius**2
-    circumference = 2 * math.pi * radius
-    print(f"Area: {area:.2f}, Circumference: {circumference:.2f}")
-    ```
-
-Let me trim a few things:
-
-    ```markdown
-    # Title
-
-    Some paragraph with space character at start of line. This \<html\> should be escaped.
-
-    - Some list item with extra space character.
-      - Nested list but only one space character.
-
-        if (a == 1) {
-          return "Indented code block without enough space characters.";
-        } else {
-          return "Passing `finalize` or similar should resolve this.";
-        }
-
-    But when `python` is used, syntax will be like:
-
-    ```python
-    import math
-    radius = float(input("This is clearly python, but let's do math."))
-    area = math.pi * radius**2
-    circumference = 2 * math.pi * radius
-    print(f"Area: {area:.2f}, Circumference: {circumference:.2f}")
-    ```
-```
-
----
-
-## Inline Pattern with Shorthand Regex
-
-**User**
-
-```bash
-/convert-plaintext-to-md #BUGS --p "regex()=> ^ {1,}([0-9]+\.[0-9]+\.[0-9]+) to ^### $1"
-```
-
-**Agent**
-
-```
-I see that there is no `BUGS.md` file. Let me copy the current plaintext BUGS documentation:
-
-    ```bash
-    copy BUGS BUGS.md
-    ```
-
-Now I'll update the copied file BUGS.md, converting it to proper markdown.
-Let me read the current contents:
-
-    ```markdown
-    1 Section
-      1.1 Section Item
-      1.2 Section Item
-      ...
-      1.12 Section Item
-    ```
-
-OK, I've matched the shorthand regular expression pattern and updated the BUGS.md to:
-
-    ```markdown
-    1 Section
-    ### 1.1 Section Item
-    ### 1.2 Section Item
-    ### ...
-    ### 1.12 Section Item
-    ```
-```
diff --git a/.claude/skills/convert-plaintext-to-md/references/github-basic-formatting.md b/.claude/skills/convert-plaintext-to-md/references/github-basic-formatting.md
deleted file mode 100644
index efaa03b1..00000000
--- a/.claude/skills/convert-plaintext-to-md/references/github-basic-formatting.md
+++ /dev/null
@@ -1,153 +0,0 @@
-# GitHub Basic Writing and Formatting Syntax Reference
-
-## Headings
-
-Create hierarchy using 1-6 hash symbols. GitHub automatically generates a table of contents when you use multiple headings.
-
-```markdown
-# First-level heading
-## Second-level heading
-### Third-level heading
-```
-
-## Text Styling
-
-| Style | Syntax | Example |
-|-------|--------|---------|
-| Bold | `** **` or `__ __` | `**bold text**` |
-| Italic | `* *` or `_ _` | `*italicized text*` |
-| Strikethrough | `~~ ~~` | `~~mistaken text~~` |
-| Bold & italic | `** **` and `_ _` | `**_extremely_ important**` |
-| Subscript | `<sub> </sub>` | `<sub>subscript</sub>` |
-| Superscript | `<sup> </sup>` | `<sup>superscript</sup>` |
-| Underline | `<ins> </ins>` | `<ins>underlined</ins>` |
-
-## Quoting Text
-
-Use `>` to create block quotes:
-
-```markdown
-> Text that is a quote
-```
-
-## Code Formatting
-
-**Inline code:** Use single backticks for code within sentences:
-
-```markdown
-Use `git status` to list changes.
-```
-
-**Code blocks:** Use triple backticks for standalone code:
-
-````markdown
-```
-git status
-git add
-git commit
-```
-````
-
-## Color Support
-
-Display colors using supported models within backticks:
-
-- Hex: `` `#0969DA` ``
-- RGB: `` `rgb(9, 105, 218)` ``
-- HSL: `` `hsl(212, 92%, 45%)` ``
-
-## Links
-
-Wrap link text in brackets and URL in parentheses:
-
-```markdown
-[Link text](https://example.com)
-```
-
-**Section links:** Link directly to any heading using its anchor.
-
-**Relative links:** Use paths relative to current file:
-
-```markdown
-[Contribution guidelines](docs/CONTRIBUTING.md)
-```
-
-## Images
-
-Include images using exclamation mark, alt text in brackets, and URL in parentheses:
-
-```markdown
-![Alt text](image-url.png)
-```
-
-The `<picture>` HTML element is supported for theme-adaptive images.
-
-## Lists
-
-**Unordered lists:** Use `-`, `*`, or `+`
-
-**Ordered lists:** Use numbers followed by periods
-
-**Nested lists:** Indent items under parent items using spaces or tabs
-
-## Task Lists
-
-Create checkboxes with `[ ]` for incomplete and `[x]` for complete tasks:
-
-```markdown
-- [x] Completed task
-- [ ] Incomplete task
-```
-
-## Mentions & References
-
-- **Mention people/teams:** `@username` or `@organization/team-name`
-- **Reference issues:** `#` followed by issue number or title
-
-## Emojis
-
-Use `:EMOJICODE:` format: `:+1:`, `:shipit:`
-
-## Paragraphs & Line Breaks
-
-Create paragraphs by leaving blank lines between text. For line breaks:
-
-- Two trailing spaces at line end
-- Backslash `\` at line end
-- HTML `<br/>`
-
-## Footnotes
-
-```markdown
-Here is a footnote[^1].
-
-[^1]: Footnote content here.
-```
-
-Footnotes render at document bottom regardless of placement.
-
-## Alerts
-
-Five alert types emphasize critical information:
-
-```markdown
-> [!NOTE]
-> Essential information users should know.
-
-> [!TIP]
-> Helpful advice for better outcomes.
-
-> [!IMPORTANT]
-> Key information for success.
-
-> [!WARNING]
-> Urgent information requiring immediate attention.
-
-> [!CAUTION]
-> Warns about risks and negative outcomes.
-```
-
-## Special Features
-
-- **HTML comments:** `<!-- Hidden content -->`
-- **Escape formatting:** Backslash before markdown characters: `\*not italicized\*`
diff --git a/.claude/skills/convert-plaintext-to-md/references/markdown-extended-syntax.md b/.claude/skills/convert-plaintext-to-md/references/markdown-extended-syntax.md
deleted file mode 100644
index bbc1ab0d..00000000
--- a/.claude/skills/convert-plaintext-to-md/references/markdown-extended-syntax.md
+++ /dev/null
@@ -1,133 +0,0 @@
-# Markdown Extended Syntax Reference
-
-The extended syntax builds upon basic Markdown by adding advanced features. Not all Markdown applications support extended syntax — check your application's documentation to confirm compatibility.
-
-## Tables
-
-Create tables using pipes (`|`) and hyphens (`---`):
-
-```markdown
-| Syntax      | Description |
-| ----------- | ----------- |
-| Header      | Title       |
-| Paragraph   | Text        |
-```
-
-### Alignment
-
-Add colons to align columns:
-
-- Left: `:---`
-- Center: `:---:`
-- Right: `---:`
-
-### Formatting in Tables
-
-Supported: links, code (backticks only), emphasis.
-Not supported: headings, blockquotes, lists, horizontal rules, images.
-
-### Escaping Pipes
-
-Use HTML entity `&#124;` to display pipe characters.
-
-## Fenced Code Blocks
-
-Use triple backticks or tildes without indentation:
-
-````markdown
-```json
-{
-  "example": "value"
-}
-```
-````
-
-Specify language after opening backticks for syntax highlighting.
-
-## Footnotes
-
-```markdown
-Text here.[^1]
-
-[^1]: This is the footnote.
-```
-
-## Heading IDs
-
-Add custom IDs to headings:
-
-```markdown
-### Heading {#custom-id}
-```
-
-Link to IDs with `[Link text](#custom-id)`.
-
-## Definition Lists
-
-```markdown
-Term
-: Definition of the term.
-```
-
-## Strikethrough
-
-Use double tildes:
-
-```markdown
-~~Strikethrough text~~
-```
-
-## Task Lists
-
-```markdown
-- [x] Completed task
-- [ ] Incomplete task
-```
-
-## Emoji
-
-### Direct Copy-Paste
-
-Paste emoji directly from sources like Emojipedia.
-
-### Shortcodes
-
-```markdown
-Gone camping! :tent: Be back soon.
-```
-
-## Highlight
-
-```markdown
-==Important words==
-```
-
-Or use HTML: `<mark>text</mark>`
-
-## Subscript
-
-```markdown
-H~2~O
-```
-
-Or HTML: `H<sub>2</sub>O`
-
-## Superscript
-
-```markdown
-X^2^
-```
-
-Or HTML: `X<sup>2</sup>`
-
-## Automatic URL Linking
-
-Most processors auto-link URLs. Disable by wrapping in backticks:
-
-```markdown
-`http://www.example.com`
-```
-
----
-
-> **Note:** Support varies significantly across applications. Always test extended syntax features in your specific Markdown processor.
diff --git a/.claude/skills/convert-plaintext-to-md/references/parameters.md b/.claude/skills/convert-plaintext-to-md/references/parameters.md
deleted file mode 100644
index 3bda9e86..00000000
--- a/.claude/skills/convert-plaintext-to-md/references/parameters.md
+++ /dev/null
@@ -1,103 +0,0 @@
-# Parameters and Options Reference
-
-## Command Syntax
-
-```bash
-/convert-plaintext-to-md <#file:{{file}}> [finalize] [guide #file:{{reference-file}}] [instructions] [platform={{name}}] [options] [pre=<name>]
-```
-
-When parameters and options are unclear, use `#tool:fetch` to retrieve the URLs in the [Markdown References](./considerations.md#markdown-references) section.
-
----
-
-## Parameters
-
-### `#file:{{file}}` _(required)_
-
-The plain or generic text documentation file to convert to markdown.
-
-- If a corresponding `{{file}}.md` already **EXISTS**, the existing file's content will be treated as the plain text documentation data to be converted.
-- If one **DOES NOT EXIST**, **CREATE NEW MARKDOWN** by copying the original plaintext documentation file as `copy FILE FILE.md` in the same directory as the plain text documentation file.
-
-### `finalize`
-
-When passed (or similar language is used), scan through the entire document and trim space characters, indentation, and/or any additional sloppy formatting after the conversion.
-
-### `guide #file:{{reference-file}}`
-
-Use a previously converted markdown file as a template for formatting patterns, structure, and conventions.
-
-### `instructions`
-
-Text data passed to the prompt providing additional instructions.
-
-### `platform={{name}}`
-
-Specify the target platform for markdown rendering to ensure compatibility:
-
-| Platform | Description |
-|---|---|
-| **GitHub** _(default)_ | GitHub-flavored markdown (GFM) with tables, task lists, strikethrough, and alerts |
-| **StackOverflow** | CommonMark with StackOverflow-specific extensions |
-| **VS Code** | Optimized for VS Code's markdown preview renderer |
-| **GitLab** | GitLab-flavored markdown with platform-specific features |
-| **CommonMark** | Standard CommonMark specification |
-
----
-
-## Options
-
-### `--header [1-4]`
-
-Add markdown header tags to the document.
-
-- **`[1-4]`** — Specifies the header level to add (`#` through `####`)
-- **`#selection`** — Data used to:
-  - Identify sections where updates should be applied
-  - Serve as a guide for applying headers to other sections or the entire document
-- **Auto-apply** (if none provided) — Add headers based on content structure
-
-### `-p, --pattern`
-
-Follow an existing pattern from:
-
-- **`#selection`** — A selected pattern to follow when updating the file or a portion of it
-  - **IMPORTANT**: DO NOT only edit the selection when passed to `{{[-p, --pattern]}}`
-  - **NOTE**: The selection is **NOT** the **WORKING RANGE**
-  - Identify pattern(s) from the selection
-  - **Stopping Points**:
-    - If `{{[-s, --stop]}} eof` is passed or no clear endpoint is specified, convert to end of file
-    - If `-s [0-9]+` is passed, convert to the line number specified in the regex `[0-9]+`
-- **Prompt instructions** — Instructional data passed with the prompt
-- **Auto-detect** (if none provided) — Identify existing patterns in the file by:
-  - Analyzing where patterns occur
-  - Identifying data that does not match the pattern
-  - Applying patterns from one section to corresponding sections where the pattern is missing
-
-### `-s, --stop <[0-9]+ | eof>`
-
-- **`[0-9]+`** — Line number to stop the current markdown conversion at
-- **`eof`** — If passed, or any other text clearly indicating end of file, convert to end of file
-
----
-
-## Predefined Instructions
-
-If any of the predefined instructions are passed as an argument, expand and use them as **ADDITIONAL** input for the prompt instructions. If only the predefined instruction is passed and no additional input, use it as the sole instruction for the current prompt.
-
-**Syntax:**
-
-```bash
-/convert-plaintext-to-md pre=<name>
-```
-
-### Available Predefined Instructions
-
-| Name | Description |
-|---|---|
-| `rm-head-digits` | Remove any prepending numbers from the headers when updating or converting the plaintext to markdown. |
-| `mv-head-level(x, y)` | Change the heading level from level `x` header to a level `y` header when updating or converting plaintext to markdown. |
-| `rm-indent(x)` | Decrease the indentation of paragraphs or raw text data portions of the file by `x` when updating or converting plaintext to markdown. |
-
-> [!NOTE]
-> If there is no matching predefined instruction, disregard the `pre=name` for the current prompt.
diff --git a/.claude/skills/create-readme/SKILL.md b/.claude/skills/create-readme/SKILL.md
deleted file mode 100644
index acff6c89..00000000
--- a/.claude/skills/create-readme/SKILL.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-name: create-readme
-description: Creates a comprehensive, professional README.md for a project. Use when a project has no README, when the existing README is outdated, or when asked to generate project documentation. Follows OSS conventions with GFM formatting, project logo detection, and concise writing style.
----
-
-## Workflow
-
-1. Review the entire project and workspace, then create a well-structured README.md.
-2. Take inspiration from these readme files for structure, tone, and content:
-   - [serverless-chat-langchainjs](./references/serverless-chat-langchainjs-readme.md)
-   - [serverless-recipes-javascript](./references/serverless-recipes-javascript-readme.md)
-   - [run-on-output](./references/run-on-output-readme.md)
-   - [smoke](./references/smoke-readme.md)
-3. Do not overuse emojis, and keep the readme concise and to the point.
-4. Do not include sections like "LICENSE", "CONTRIBUTING", "CHANGELOG", etc. There are dedicated files for those sections.
-5. Use GFM (GitHub Flavored Markdown) for formatting, and GitHub admonition syntax (see [reference](./references/github-admonition-syntax.md)) where appropriate.
-6. If you find a logo or icon for the project, use it in the readme's header.
diff --git a/.claude/skills/create-readme/references/github-admonition-syntax.md b/.claude/skills/create-readme/references/github-admonition-syntax.md
deleted file mode 100644
index 324df13d..00000000
--- a/.claude/skills/create-readme/references/github-admonition-syntax.md
+++ /dev/null
@@ -1,60 +0,0 @@
-# GitHub Markdown Alerts (Admonition Syntax)
-
-GitHub supports a markdown extension for creating highlighted alert blocks using blockquote syntax. This feature helps emphasize critical information in documentation with distinctive colors and icons.
-
-## Syntax
-
-The basic syntax uses blockquote markers (`>`) with a bracket notation:
-
-```markdown
-> [!TYPE]
-> Your alert content here
-```
-
-## Supported Alert Types
-
-### NOTE
-
-```markdown
-> [!NOTE]
-> Highlights information users should consider, even when skimming.
-```
-
-### TIP
-
-```markdown
-> [!TIP]
-> Optional information to help users be more successful.
-```
-
-### IMPORTANT
-
-```markdown
-> [!IMPORTANT]
-> Crucial information necessary for users to succeed.
-```
-
-### WARNING
-
-```markdown
-> [!WARNING]
-> Critical content demanding immediate attention due to potential risks.
-```
-
-### CAUTION
-
-```markdown
-> [!CAUTION]
-> Negative potential consequences of an action.
-```
-
-## Key Features
-
-- A line break must follow the alert type marker
-- Alerts render as `div` elements with semantic styling rather than blockquote elements
-- Works in READMEs, Markdown files, wikis, issues, pull requests, and discussions
-- Each alert type uses distinct visual styling (colors and icons) for clarity
-
-## Source
-
-Originally discussed at: https://github.com/orgs/community/discussions/16925
diff --git a/.claude/skills/create-readme/references/run-on-output-readme.md b/.claude/skills/create-readme/references/run-on-output-readme.md
deleted file mode 100644
index 971734d4..00000000
--- a/.claude/skills/create-readme/references/run-on-output-readme.md
+++ /dev/null
@@ -1,146 +0,0 @@
-<div align="center">
-  <img src="icon.png" width="96" alt="run-on-output logo">
-  
-  # run-on-output
-  *Execute tasks when CLI output patterns are detected*
-  
-  [![Build Status](https://img.shields.io/github/actions/workflow/status/sinedied/run-on-output/ci.yml?style=flat-square)](https://github.com/sinedied/run-on-output/actions)
-  [![npm version](https://img.shields.io/npm/v/run-on-output?style=flat-square)](https://www.npmjs.com/package/run-on-output)
-  [![Node.js](https://img.shields.io/badge/Node.js->=20-3c873a?style=flat-square)](https://nodejs.org)
-  [![XO code style](https://shields.io/badge/code_style-5ed9c7?logo=xo&labelColor=gray&style=flat-square)](https://github.com/xojs/xo)
-  [![License](https://img.shields.io/badge/License-MIT-blue?style=flat-square)](LICENSE)
-
-  ⭐ If you like this project, star it on GitHub!
-
-  [Features](#features) • [Installation](#installation) • [Usage](#usage) • [Examples](#examples)
-
-</div>
-
-
-A lightweight Node.js CLI tool that monitors command output in real-time and triggers actions when specific patterns are found. Perfect for automation workflows, development environments, and CI/CD pipelines.
-
-## Features
-
-- 🎯 **Pattern Matching** - Monitor stdout/stderr for regex patterns or plain strings
-- ⚡ **Real-time Monitoring** - Output is forwarded in real-time while monitoring  
-- 🔧 **Flexible Actions** - Display messages or execute commands when patterns match
-- 📝 **Multiple Patterns** - Wait for multiple patterns before triggering actions
-- 🚀 **Zero Dependencies** - Built with Node.js built-in modules only
-
-## Installation
-
-```bash
-npm install -g run-on-output
-```
-
-Or use without installing:
-
-```bash
-npx run-on-output [options] <command> [args...]
-```
-
-## Usage
-
-### Basic Examples
-
-**Display a message when server starts:**
-```bash
-run-on-output -s "Server started" -m "🚀 Server is ready" npm start
-```
-
-**Execute a health check when server is listening:**
-```bash
-run-on-output -p "listening on port \\d+" -r "curl http://localhost:3000/health" node server.js
-```
-
-**Monitor development environment startup:**
-```bash
-run-on-output -s "webpack compiled,server ready" -m "✅ Development environment ready" npm run dev
-```
-
-**Multiple actions - show message and open browser:**
-```bash
-run-on-output -s "ready" -m "Server is up" -r "open http://localhost:3000" npm start
-```
-
-**Run npm script when server is ready:**
-```bash
-run-on-output -s "Server running" -n "test" node server.js
-```
-
-> [!TIP]
-> You can use the short alias `roo` instead of `run-on-output` for faster typing:
-> ```bash
-> roo -s "Server started" -m "🚀 Server is ready" npm start
-> ```
-
-### Command Line Options
-
-```
-run-on-output [OPTIONS] <command> [args...]
-
-OPTIONS:
-  -p, --patterns <patterns>    Comma-separated list of regex patterns to watch for
-  -s, --strings <strings>      Comma-separated list of plain strings to watch for
-  -r, --run <command>          Command to execute after all patterns are found
-  -n, --npm <script>           npm script to run after all patterns are found
-  -m, --message <text>         Message to display after all patterns are found
-  -h, --help                   Show this help message
-
-REQUIREMENTS:
-  - Either --patterns or --strings must be specified (but not both)
-  - At least one of --run, --npm, or --message must be specified
-```
-
-### Pattern Types
-
-**Plain Strings (`-s, --strings`)**
-- Matches exact text (case-insensitive)
-- Easier to use for simple text matching
-- Example: `-s "Server started,Database connected"`
-
-**Regex Patterns (`-p, --patterns`)**
-- Use regular expressions for complex matching
-- Supports all JavaScript regex features
-- Example: `-p "listening on port \\d+,ready in \\d+ms"`
-
-## Examples
-
-**Development Workflow**
-```bash
-# Wait for both webpack and server, then open browser
-run-on-output -s "webpack compiled,Local:" -r "open http://localhost:3000" npm run dev
-
-# Monitor test runner and show completion message
-run-on-output -s "Tests completed" -m "✅ All tests passed" npm test
-```
-
-**CI/CD Pipeline**
-```bash
-# Wait for deployment completion and run smoke tests
-run-on-output -p "deployment.*complete" -r "./scripts/smoke-test.sh" deploy.sh
-
-# Monitor build process and trigger notifications
-run-on-output -s "Build successful" -r "slack-notify '#dev' 'Build completed'" npm run build
-```
-
-**Docker & Containers**
-```bash
-# Wait for container health check and run integration tests
-run-on-output -s "healthy" -r "npm run test:integration" docker-compose up
-
-# Monitor database initialization
-run-on-output -p "database.*ready" -m "📁 Database initialized" ./start-db.sh
-```
-
-**API Development**
-```bash
-# Wait for API server and run endpoint tests
-run-on-output -p "server.*listening.*port" -r "npm run test:api" node api.js
-
-# Monitor microservices startup and run deployment script
-run-on-output -s "auth-service ready,user-service ready" -n "deploy" ./start-services.sh
-
-# Combine message, command and npm script
-run-on-output -s "Database connected" -m "🎉 Ready for testing" -n "test:integration" npm start
-```
diff --git a/.claude/skills/create-readme/references/serverless-chat-langchainjs-readme.md b/.claude/skills/create-readme/references/serverless-chat-langchainjs-readme.md
deleted file mode 100644
index b36fbba7..00000000
--- a/.claude/skills/create-readme/references/serverless-chat-langchainjs-readme.md
+++ /dev/null
@@ -1,280 +0,0 @@
-<!-- prettier-ignore -->
-<div align="center">
-
-<img src="./packages/webapp/public/favicon.png" alt="" align="center" height="64" />
-
-# Serverless AI Chat with RAG using LangChain.js
-
-[![Open project in GitHub Codespaces](https://img.shields.io/badge/Codespaces-Open-blue?style=flat-square&logo=github)](https://codespaces.new/Azure-Samples/serverless-chat-langchainjs?hide_repo_select=true&ref=main&quickstart=true)
-[![Join Azure AI Foundry Discord](https://img.shields.io/badge/Discord-Azure_AI_Community-blue?style=flat-square&logo=discord&color=5865f2&logoColor=fff)](https://aka.ms/foundry/discord)
-[![Official Learn documentation](https://img.shields.io/badge/Documentation-00a3ee?style=flat-square)](https://learn.microsoft.com/azure/developer/javascript/ai/get-started-app-chat-template-langchainjs)
-[![Watch to learn about RAG and this sample on YouTube](https://img.shields.io/badge/YouTube-d95652.svg?style=flat-square&logo=youtube)](https://www.youtube.com/watch?v=xkFOmx5yxIA&list=PLlrxD0HtieHi5ZpsHULPLxm839IrhmeDk&index=4)
-[![dev.to blog post walkthrough](https://img.shields.io/badge/Blog%20post-black?style=flat-square&logo=dev.to)](https://dev.to/azure/build-a-serverless-chatgpt-with-rag-using-langchainjs-3487)
-<br>
-[![Build Status](https://img.shields.io/github/actions/workflow/status/Azure-Samples/serverless-chat-langchainjs/build-test.yaml?style=flat-square&label=Build)](https://github.com/Azure-Samples/serverless-chat-langchainjs/actions)
-![Node version](https://img.shields.io/badge/Node.js->=20-3c873a?style=flat-square)
-[![Ollama + Llama3.1](https://img.shields.io/badge/Ollama-Llama3.1-ff7000?style=flat-square)](https://ollama.com/library/llama3.1)
-[![TypeScript](https://img.shields.io/badge/TypeScript-blue?style=flat-square&logo=typescript&logoColor=white)](https://www.typescriptlang.org)
-[![License](https://img.shields.io/badge/License-MIT-yellow?style=flat-square)](LICENSE)
-
-:star: If you like this sample, star it on GitHub — it helps a lot!
-
-[Overview](#overview) • [Get started](#getting-started) • [Run the sample](#run-the-sample) • [Resources](#resources) • [FAQ](#faq) • [Troubleshooting](#troubleshooting)
-
-![Animation showing the chat app in action](./docs/images/demo.gif)
-
-</div>
-
-This sample shows how to build a serverless AI chat experience with Retrieval-Augmented Generation using [LangChain.js](https://js.langchain.com/) and Azure. The application is hosted on [Azure Static Web Apps](https://learn.microsoft.com/azure/static-web-apps/overview) and [Azure Functions](https://learn.microsoft.com/azure/azure-functions/functions-overview?pivots=programming-language-javascript), with [Azure Cosmos DB for NoSQL](https://learn.microsoft.com/azure/cosmos-db/nosql/vector-) as the vector database. You can use it as a starting point for building more complex AI applications.
-
-> [!TIP]
-> You can test this application locally without any cost using [Ollama](https://ollama.com/). Follow the instructions in the [Local Development](#local-development) section to get started.
-
-## Overview
-
-Building AI applications can be complex and time-consuming, but using LangChain.js and Azure serverless technologies allows to greatly simplify the process. This application is a chatbot that uses a set of enterprise documents to generate responses to user queries.
-
-We provide sample data to make this sample ready to try, but feel free to replace it with your own. We use a fictitious company called _Contoso Real Estate_, and the experience allows its customers to ask support questions about the usage of its products. The sample data includes a set of documents that describes its terms of service, privacy policy and a support guide.
-
-<div align="center">
-  <img src="./docs/images/architecture.drawio.png" alt="Application architecture" width="640px" />
-</div>
-
-This application is made from multiple components:
-
-- A web app made with a single chat web component built with [Lit](https://lit.dev) and hosted on [Azure Static Web Apps](https://learn.microsoft.com/azure/static-web-apps/overview). The code is located in the `packages/webapp` folder.
-
-- A serverless API built with [Azure Functions](https://learn.microsoft.com/azure/azure-functions/functions-overview?pivots=programming-language-javascript) and using [LangChain.js](https://js.langchain.com/) to ingest the documents and generate responses to the user chat queries. The code is located in the `packages/api` folder.
-
-- A database to store chat sessions and the text extracted from the documents and the vectors generated by LangChain.js, using [Azure Cosmos DB for NoSQL](https://learn.microsoft.com/azure/cosmos-db/nosql/).
-
-- A file storage to store the source documents, using [Azure Blob Storage](https://learn.microsoft.com/azure/storage/blobs/storage-blobs-introduction).
-
-We use the [HTTP protocol for AI chat apps](https://aka.ms/chatprotocol) to communicate between the web app and the API.
-
-## Features
-
-- **Serverless Architecture**: Utilizes Azure Functions and Azure Static Web Apps for a fully serverless deployment.
-- **Retrieval-Augmented Generation (RAG)**: Combines the power of Azure Cosmos DB and LangChain.js to provide relevant and accurate responses.
-- **Chat Sessions History**: Maintains a personal chat history for each user, allowing them to revisit previous conversations.
-- **Scalable and Cost-Effective**: Leverages Azure's serverless offerings to provide a scalable and cost-effective solution.
-- **Local Development**: Supports local development using Ollama for testing without any cloud costs.
-
-## Getting started
-
-There are multiple ways to get started with this project.
-
-The quickest way is to use [GitHub Codespaces](#use-github-codespaces) that provides a preconfigured environment for you. Alternatively, you can [set up your local environment](#use-your-local-environment) following the instructions below.
-
-> [!IMPORTANT]
-> If you want to run this sample entirely locally using Ollama, you have to follow the instructions in the [local environment](#use-your-local-environment) section.
-
-### Use your local environment
-
-You need to install following tools to work on your local machine:
-
-- [Node.js LTS](https://nodejs.org/download/)
-- [Azure Developer CLI](https://aka.ms/azure-dev/install)
-- [Git](https://git-scm.com/downloads)
-- [PowerShell 7+](https://github.com/powershell/powershell) _(for Windows users only)_
-  - **Important**: Ensure you can run `pwsh.exe` from a PowerShell command. If this fails, you likely need to upgrade PowerShell.
-  - Instead of Powershell, you can also use Git Bash or WSL to run the Azure Developer CLI commands.
-- [Azure Functions Core Tools](https://learn.microsoft.com/azure/azure-functions/functions-run-local?tabs=macos%2Cisolated-process%2Cnode-v4%2Cpython-v2%2Chttp-trigger%2Ccontainer-apps&pivots=programming-language-javascript) _(should be installed automatically with NPM, only install manually if the API fails to start)_
-
-Then you can get the project code:
-
-1. [**Fork**](https://github.com/Azure-Samples/serverless-chat-langchainjs/fork) the project to create your own copy of this repository.
-2. On your forked repository, select the **Code** button, then the **Local** tab, and copy the URL of your forked repository.
-
-<div align="center">
-  <img src="./docs/images/clone-url.png" alt="Screenshot showing how to copy the repository URL" width="400px" />
-</div>
-3. Open a terminal and run this command to clone the repo: <code> git clone &lt;your-repo-url&gt; </code>
-
-### Use GitHub Codespaces
-
-You can run this project directly in your browser by using GitHub Codespaces, which will open a web-based VS Code:
-
-[![Open in GitHub Codespaces](https://img.shields.io/static/v1?style=for-the-badge&label=GitHub+Codespaces&message=Open&color=blue&logo=github)](https://codespaces.new/Azure-Samples/serverless-chat-langchainjs?hide_repo_select=true&ref&quickstart=true)
-
-### Use a VSCode dev container
-
-A similar option to Codespaces is VS Code Dev Containers, that will open the project in your local VS Code instance using the [Dev Containers extension](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers).
-
-You will also need to have [Docker](https://www.docker.com/products/docker-desktop) installed on your machine to run the container.
-
-[![Open in Dev Containers](https://img.shields.io/static/v1?style=for-the-badge&label=Dev%20Containers&message=Open&color=blue&logo=visualstudiocode)](https://vscode.dev/redirect?url=vscode://ms-vscode-remote.remote-containers/cloneInVolume?url=https://github.com/Azure-Samples/serverless-chat-langchainjs)
-
-## Run the sample
-
-There are multiple ways to run this sample: locally using Ollama or Azure OpenAI models, or by deploying it to Azure.
-
-### Deploy the sample to Azure
-
-#### Azure prerequisites
-
-- **Azure account**. If you're new to Azure, [get an Azure account for free](https://azure.microsoft.com/free) to get free Azure credits to get started. If you're a student, you can also get free credits with [Azure for Students](https://aka.ms/azureforstudents).
-- **Azure subscription with access enabled for the Azure OpenAI service**. You can request access with [this form](https://aka.ms/oaiapply).
-- **Azure account permissions**:
-  - Your Azure account must have `Microsoft.Authorization/roleAssignments/write` permissions, such as [Role Based Access Control Administrator](https://learn.microsoft.com/azure/role-based-access-control/built-in-roles#role-based-access-control-administrator-preview), [User Access Administrator](https://learn.microsoft.com/azure/role-based-access-control/built-in-roles#user-access-administrator), or [Owner](https://learn.microsoft.com/azure/role-based-access-control/built-in-roles#owner). If you don't have subscription-level permissions, you must be granted [RBAC](https://learn.microsoft.com/azure/role-based-access-control/built-in-roles#role-based-access-control-administrator-preview) for an existing resource group and [deploy to that existing group](docs/deploy_existing.md#resource-group).
-  - Your Azure account also needs `Microsoft.Resources/deployments/write` permissions on the subscription level.
-
-#### Cost estimation
-
-See the [cost estimation](./docs/cost.md) details for running this sample on Azure.
-
-#### Deploy the sample
-
-1. Open a terminal and navigate to the root of the project.
-2. Authenticate with Azure by running `azd auth login`.
-3. Run `azd up` to deploy the application to Azure. This will provision Azure resources, deploy this sample, and build the search index based on the files found in the `./data` folder.
-   - You will be prompted to select a base location for the resources. If you're unsure of which location to choose, select `eastus2`.
-   - By default, the OpenAI resource will be deployed to `eastus2`. You can set a different location with `azd env set AZURE_OPENAI_RESOURCE_GROUP_LOCATION <location>`. Currently only a short list of locations is accepted. That location list is based on the [OpenAI model availability table](https://learn.microsoft.com/azure/ai-services/openai/concepts/models#standard-deployment-model-availability) and may become outdated as availability changes.
-
-The deployment process will take a few minutes. Once it's done, you'll see the URL of the web app in the terminal.
-
-<div align="center">
-  <img src="./docs/images/azd-up.png" alt="Screenshot of the azd up command result" width="600px" />
-</div>
-
-You can now open the web app in your browser and start chatting with the bot.
-
-##### Enhance security
-
-When deploying the sample in an enterprise context, you may want to enforce tighter security restrictions to protect your data and resources. See the [enhance security](./docs/enhance-security.md) guide for more information.
-
-#### Enable CI/CD
-
-If you want to enable Continuous Deployment for your forked repository, you need to configure the Azure pipeline first:
-
-1. Open a terminal at the root of your forked project.
-2. Authenticate with Azure by running `azd auth login`.
-3. Run `azd pipeline config` to configure the required secrets and variables for connecting to Azure from GitHub Actions.
-   - This command will set up the necessary Azure service principal and configure GitHub repository secrets.
-   - Follow the prompts to complete the configuration.
-
-Once configured, the GitHub Actions workflow will automatically deploy your application to Azure whenever you push changes to the main branch.
-
-#### Clean up
-
-To clean up all the Azure resources created by this sample:
-
-1. Run `azd down --purge`
-2. When asked if you are sure you want to continue, enter `y`
-
-The resource group and all the resources will be deleted.
-
-### Run the sample locally with Ollama
-
-If you have a machine with enough resources, you can run this sample entirely locally without using any cloud resources. To do that, you first have to install [Ollama](https://ollama.com) and then run the following commands to download the models on your machine:
-
-```bash
-ollama pull llama3.1:latest
-ollama pull nomic-embed-text:latest
-```
-
-> [!NOTE]
-> The `llama3.1` model with download a few gigabytes of data, so it can take some time depending on your internet connection.
-
-After that you have to install the NPM dependencies:
-
-```bash
-npm install
-```
-
-Then you can start the application by running the following command which will start the web app and the API locally:
-
-```bash
-npm start
-```
-
-Then, open a new terminal running concurrently and run the following command to upload the PDF documents from the `/data` folder to the API:
-
-```bash
-npm run upload:docs
-```
-
-This only has to be done once, unless you want to add more documents.
-
-You can now open the URL `http://localhost:8000` in your browser to start chatting with the bot.
-
-> [!NOTE]
-> While local models usually works well enough to answer the questions, sometimes they may not be able to follow perfectly the advanced formatting instructions for the citations and follow-up questions. This is expected, and a limitation of using smaller local models.
-
-### Run the sample locally with Azure OpenAI models
-
-First you need to provision the Azure resources needed to run the sample. Follow the instructions in the [Deploy the sample to Azure](#deploy-the-sample-to-azure) section to deploy the sample to Azure, then you'll be able to run the sample locally using the deployed Azure resources.
-
-Once your deployment is complete, you should see a `.env` file in the `packages/api` folder. This file contains the environment variables needed to run the application using Azure resources.
-
-To run the sample, you can then use the same commands as for the Ollama setup. This will start the web app and the API locally:
-
-```bash
-npm start
-```
-
-Open the URL `http://localhost:8000` in your browser to start chatting with the bot.
-
-Note that the documents are uploaded automatically when deploying the sample to Azure with `azd up`.
-
-> [!TIP]
-> You can switch back to using Ollama models by simply deleting the `packages/api/.env` file and starting the application again. To regenerate the `.env` file, you can run `azd env get-values > packages/api/.env`.
-
-## Resources
-
-Here are some resources to learn more about the technologies used in this sample:
-
-- [LangChain.js documentation](https://js.langchain.com)
-- [Generative AI with JavaScript](https://github.com/microsoft/generative-ai-with-javascript)
-- [Generative AI For Beginners](https://github.com/microsoft/generative-ai-for-beginners)
-- [Azure OpenAI Service](https://learn.microsoft.com/azure/ai-services/openai/overview)
-- [Azure Cosmos DB for NoSQL](https://learn.microsoft.com/azure/cosmos-db/nosql/)
-- [Ask YouTube: LangChain.js + Azure Quickstart sample](https://github.com/Azure-Samples/langchainjs-quickstart-demo)
-- [Chat + Enterprise data with Azure OpenAI and Azure AI Search](https://github.com/Azure-Samples/azure-search-openai-javascript)
-- [Revolutionize your Enterprise Data with Chat: Next-gen Apps w/ Azure OpenAI and AI Search](https://aka.ms/entgptsearchblog)
-
-You can also find [more Azure AI samples here](https://github.com/Azure-Samples/azureai-samples).
-
-## FAQ
-
-You can find answers to frequently asked questions in the [FAQ](./docs/faq.md).
-
-## Troubleshooting
-
-If you have any issue when running or deploying this sample, please check the [troubleshooting guide](./docs/troubleshooting.md). If you can't find a solution to your problem, please [open an issue](https://github.com/Azure-Samples/serverless-chat-langchainjs/issues) in this repository.
-
-## Guidance
-
-For more detailed guidance on how to use this sample, please refer to the [tutorial](./docs/tutorial/01-introduction.md).
-
-## Getting Help
-
-If you get stuck or have any questions about building AI apps, join:
-
-[![Azure AI Foundry Discord](https://img.shields.io/badge/Discord-Azure_AI_Foundry_Community_Discord-blue?style=for-the-badge&logo=discord&color=5865f2&logoColor=fff)](https://aka.ms/foundry/discord)
-
-If you have product feedback or errors while building visit:
-
-[![Azure AI Foundry Developer Forum](https://img.shields.io/badge/GitHub-Azure_AI_Foundry_Developer_Forum-blue?style=for-the-badge&logo=github&color=000000&logoColor=fff)](https://aka.ms/foundry/forum)
-
-## Contributing
-
-This project welcomes contributions and suggestions. Most contributions require you to agree to a
-Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us
-the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.
-
-When you submit a pull request, a CLA bot will automatically determine whether you need to provide
-a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions
-provided by the bot. You will only need to do this once across all repos using our CLA.
-
-This project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/).
-For more information see the [Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/) or
-contact [opencode@microsoft.com](mailto:opencode@microsoft.com) with any additional questions or comments.
-
-## Trademarks
-
-This project may contain trademarks or logos for projects, products, or services. Authorized use of Microsoft
-trademarks or logos is subject to and must follow
-[Microsoft's Trademark & Brand Guidelines](https://www.microsoft.com/en-us/legal/intellectualproperty/trademarks/usage/general).
-Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship.
-Any use of third-party trademarks or logos are subject to those third-party's policies.
diff --git a/.claude/skills/create-readme/references/serverless-recipes-javascript-readme.md b/.claude/skills/create-readme/references/serverless-recipes-javascript-readme.md
deleted file mode 100644
index d361fd69..00000000
--- a/.claude/skills/create-readme/references/serverless-recipes-javascript-readme.md
+++ /dev/null
@@ -1,162 +0,0 @@
-<!-- prettier-ignore -->
-<div align="center">
-
-<img src="./docs/images/icon.png" alt="" align="center" height="96" />
-
-# Serverless Recipes for JavaScript/TypeScript
-
-[![Open project in GitHub Codespaces](https://img.shields.io/badge/Codespaces-Open-blue?style=flat-square&logo=github)](https://codespaces.new/Azure-Samples/serverless-recipes-javascript?hide_repo_select=true&ref=main&quickstart=true)
-[![Join Azure AI Foundry Discord](https://img.shields.io/badge/Discord-Azure_AI_Community-blue?style=flat-square&logo=discord&color=5865f2&logoColor=fff)](https://aka.ms/foundry/discord)
-[![Build Status](https://img.shields.io/github/actions/workflow/status/Azure-Samples/serverless-recipes-javascript/build-test.yaml?style=flat-square&label=Build)](https://github.com/Azure-Samples/serverless-recipes-javascript/actions)
-![Node version](https://img.shields.io/badge/Node.js->=20-3c873a?style=flat-square)
-[![TypeScript](https://img.shields.io/badge/TypeScript-blue?style=flat-square&logo=typescript&logoColor=white)](https://www.typescriptlang.org)
-[![License](https://img.shields.io/badge/License-MIT-yellow?style=flat-square)](LICENSE)
-
-⭐ If you like this project, star it on GitHub — it helps a lot!
-
-[Get started](#getting-started) • [Run the samples](#run-the-samples) • [Samples list](#samples-list) • [Resources](#resources) • [Troubleshooting](#troubleshooting)
-
-</div>
-
-This repository is a collection of code examples demonstrating how to build serverless applications using TypeScript and Azure. Each recipe is a standalone sample that demonstrates how to build a specific feature or use a specific technology. You can use these samples as a starting point for your own projects or to learn more about serverless development with Azure.
-
-> [!NOTE]
-> **What's Serverless?**<br>
-> Serverless computing allows you to build and run applications without managing infrastructure. You can focus on your code and let the cloud provider handle the rest. Azure provides a wide range of serverless services, including [Azure Functions](https://learn.microsoft.com/azure/azure-functions/functions-overview?pivots=programming-language-javascript), [Azure Static Web Apps]([Azure Static Web Apps](https://learn.microsoft.com/azure/static-web-apps/overview), [Azure Cosmos DB](https://learn.microsoft.com/azure/cosmos-db/nosql/), and more.
-
-## Why serverless?
-
-Let's say you're a developer for the Contoso Solutions company, and you've been tasked to build new applications with a fast turnaround time, startup style. You need to build these apps quickly with a low initial budget, and you don't want to worry about managing servers, scaling, or infrastructure. **You want to focus on writing code and delivering value to your users.**
-
-*This is exactly where serverless is a great fit!*
-
-While walking through this collection of ready-to-use code examples, you'll learn how to solve common problems and build applications using many of the serverless technologies available on Azure. The best part? You only need to pay attention to the code and the business logic, all samples are ready to deploy and run in your Azure account.
-
-## Prerequisites
-- **Azure account**. If you're new to Azure, [get an Azure account for free](https://azure.microsoft.com/free) to get free Azure credits to get started. If you're a student, you can also get free credits with [Azure for Students](https://aka.ms/azureforstudents).
-- **GitHub account**. If you don't have one, you can [create a free GitHub account](https://github.com/signup). You can optionally use [GitHub Copilot Free](https://github.com/features/copilot) to help you write code and ship your application even faster.
-
-## Getting started
-
-There are multiple ways to get started with this project.
-
-The quickest way is to use [GitHub Codespaces](#use-github-codespaces) that provides a preconfigured environment for you. Alternatively, you can [set up your local environment](#use-your-local-environment) following the instructions below.
-
-<details open>
-<summary><h3>Use GitHub Codespaces</h3></summary>
-
-You can run this project directly in your browser by using GitHub Codespaces, which will open a web-based VS Code:
-
-[![Open in GitHub Codespaces](https://img.shields.io/static/v1?style=flat-square&label=GitHub+Codespaces&message=Open&color=blue&logo=github)](https://codespaces.new/Azure-Samples/serverless-recipes-javascript?hide_repo_select=true&ref&quickstart=true)
-
-</details>
-
-<details>
-<summary><h3>Use a VSCode dev container</h3></summary>
-
-A similar option to Codespaces is VS Code Dev Containers, that will open the project in your local VS Code instance using the [Dev Containers extension](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers).
-
-You will also need to have [Docker](https://www.docker.com/get-started/) installed on your machine to run the container.
-
-[![Open in Dev Containers](https://img.shields.io/static/v1?style=flat-square&label=Dev%20Containers&message=Open&color=blue&logo=visualstudiocode)](https://vscode.dev/redirect?url=vscode://ms-vscode-remote.remote-containers/cloneInVolume?url=https://github.com/Azure-Samples/serverless-recipes-javascript)
-
-</details>
-
-<details>
-<summary><h3>Use your local environment</h3></summary>
-
-You need to install following tools to work on your local machine:
-
-- [Node.js LTS](https://nodejs.org/en/download)
-- [Azure Developer CLI](https://aka.ms/azure-dev/install)
-- [Git](https://git-scm.com/downloads)
-- [PowerShell 7+](https://github.com/powershell/powershell) _(for Windows users only)_
-  - **Important**: Ensure you can run `pwsh.exe` from a PowerShell command. If this fails, you likely need to upgrade PowerShell.
-  - Instead of Powershell, you can also use Git Bash or WSL to run the Azure Developer CLI commands.
-- [Azure Functions Core Tools](https://learn.microsoft.com/azure/azure-functions/functions-run-local?tabs=macos%2Cisolated-process%2Cnode-v4%2Cpython-v2%2Chttp-trigger%2Ccontainer-apps&pivots=programming-language-javascript) _(should be installed automatically with NPM, only install manually if the API fails to start)_
-
-Then you can get the project code:
-
-1. [**Fork**](https://github.com/Azure-Samples/serverless-recipes-javascript/fork) the project to create your own copy of this repository.
-2. On your forked repository, select the **Code** button, then the **Local** tab, and copy the URL of your forked repository.
-
-   ![Screenshot showing how to copy the repository URL](./docs/images/clone-url.png)
-3. Open a terminal and run this command to clone the repo: `git clone <your-repo-url>`
-
-</details>
-
-## Run the samples
-
-After setting up your environment, you can deploy and run any of the samples. Each sample is a standalone project that you can run independently. Follows these steps to run a sample:
-
-```bash
-# Open the sample directory
-cd samples/<sample-name>
-
-# Install dependencies
-npm install
-
-# Deploy the sample to Azure
-azd auth login
-azd up
-```
-
-Once the initial deployment is completed, you can also run the sample locally with `npm start`.
-You can check the `README.md` file in each sample directory for more specific instructions.
-
-## Samples list
-
-<!-- #begin-samples -->
-
-| | Sample | Deployment Time | Video | Blog |
-| --- |:--- | --- | --- | --- |
-| <img src="./samples/openai-extension-embeddings/docs/images/icon.png" width="32px"/> | [Azure Functions OpenAI extension - embeddings](./samples/openai-extension-embeddings) | 5min | - | - |
-| <img src="./samples/openai-extension-textcompletion/docs/images/icon.png" width="32px"/> | [Azure Functions OpenAI extension - text completion](./samples/openai-extension-textcompletion) | 5min | - | - |
-
-<!-- #end-samples -->
-
-## Resources
-
-Here are some additional resources to learn more about the technologies used:
-
-- [Serverless Node.js with Azure Functions](https://learn.microsoft.com/azure/developer/javascript/how-to/develop-serverless-apps?tabs=v4-ts) (Microsoft Learn)
-- [Azure Cosmos DB for NoSQL](https://learn.microsoft.com/azure/cosmos-db/nosql/) (Microsoft Learn)
-- [Azure OpenAI Service](https://learn.microsoft.com/azure/ai-services/openai/overview) (Microsoft Learn)
-- [Generative AI with JavaScript](https://github.com/microsoft/generative-ai-with-javascript) (GitHub)
-- [Serverless AI Chat with RAG using LangChain.js](https://github.com/Azure-Samples/serverless-chat-langchainjs) (GitHub)
-
-## Troubleshooting
-
-If you have any issue when running or deploying the samples, please check the [troubleshooting guide](./docs/troubleshooting.md). If you can't find a solution to your problem, please [open an issue](https://github.com/Azure-Samples/serverless-recipes-javascript/issues) in this repository.
-
-## Getting Help
-
-If you get stuck or have any questions about building AI apps, join:
-
-[![Azure AI Foundry Discord](https://img.shields.io/badge/Discord-Azure_AI_Foundry_Community_Discord-blue?style=for-the-badge&logo=discord&color=5865f2&logoColor=fff)](https://aka.ms/foundry/discord)
-
-If you have product feedback or errors while building visit:
-
-[![Azure AI Foundry Developer Forum](https://img.shields.io/badge/GitHub-Azure_AI_Foundry_Developer_Forum-blue?style=for-the-badge&logo=github&color=000000&logoColor=fff)](https://aka.ms/foundry/forum)
-
-## Contributing
-
-This project welcomes contributions and suggestions. Most contributions require you to agree to a
-Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us
-the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.
-
-When you submit a pull request, a CLA bot will automatically determine whether you need to provide
-a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions
-provided by the bot. You will only need to do this once across all repos using our CLA.
-
-This project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/).
-For more information see the [Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/) or
-contact [opencode@microsoft.com](mailto:opencode@microsoft.com) with any additional questions or comments.
-
-## Trademarks
-
-This project may contain trademarks or logos for projects, products, or services. Authorized use of Microsoft
-trademarks or logos is subject to and must follow
-[Microsoft's Trademark & Brand Guidelines](https://www.microsoft.com/en-us/legal/intellectualproperty/trademarks/usage/general).
-Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship.
-Any use of third-party trademarks or logos are subject to those third-party's policies.
diff --git a/.claude/skills/create-readme/references/smoke-readme.md b/.claude/skills/create-readme/references/smoke-readme.md
deleted file mode 100644
index fd2fc808..00000000
--- a/.claude/skills/create-readme/references/smoke-readme.md
+++ /dev/null
@@ -1,366 +0,0 @@
-# :dash: smoke
-
-[![NPM version](https://img.shields.io/npm/v/smoke.svg)](https://www.npmjs.com/package/smoke)
-[![Build Status](https://github.com/sinedied/smoke/workflows/build/badge.svg)](https://github.com/sinedied/smoke/actions)
-![Node version](https://img.shields.io/node/v/smoke.svg)
-[![XO code style](https://img.shields.io/badge/code_style-XO-5ed9c7.svg)](https://github.com/sindresorhus/xo)
-[![License](https://img.shields.io/badge/license-MIT-blue.svg)](LICENSE)
-
-> Simple yet powerful file-based mock server with recording abilities
-
-![demo](https://user-images.githubusercontent.com/593151/49312821-9f2cc680-f4e5-11e8-900a-117120c38422.gif)
-
-Just drop a bunch of (JSON) files in a folder and you're ready to go!
-
-### Basic mock example
-1. Start the server: `smoke`
-2. Create a file named `get_api#hello.json`:
-    ```json
-    {
-      "message": "hello world!"
-    }
-    ```
-3. Test the mock: `curl http://localhost:3000/api/hello`
-
-### Features
-
-**Smoke** is a file-based, convention over configuration mock server that can fill your API mocking needs without any
-complex setup. Yet, it supports many advanced features and dynamic mocks for almost any situation:
-
-- Generate mocks quickly by recording responses from an existing server
-- Use folders and file names to describe API routes and REST methods
-- Use templates to generate responses based on input queries and route parameters
-- Add / edit / remove mocks without restarting the server
-- Generate mocks with JavaScript for more complex responses
-- Define different mock sets to simulate various scenarii (errors...), with fallback
-- Customize headers and status code if needed, automatically detect content-type if not specified
-- Add custom middlewares to modify requests/responses
-- Mock only specific requests and proxy the rest to an existing server
-- Supports CORS (cross-origin resource-sharing)
-
-## Installation
-
-```bash
-npm install -g smoke
-```
-
-## Usage
-
-See [some example mocks](test/mocks) to quickly get a grasp of the syntax and possibilities.
-
-CLI usage is quite straightforward you can just run `smoke` unless you want to add some options:
-```
-Usage: smoke [<mocks_folder>] [options]
-
-Base options:
-  -p, --port <num>                  Server port           [default: 3000]
-  -h, --host <host>                 Server host           [default: "localhost"]
-  -s, --set <name>                  Mocks set to use      [default: none]
-  -n, --not-found <glob>            Mocks for 404 errors  [default: "404.*"]
-  -i, --ignore <glob>               Files to ignore       [default: none]
-  -k, --hooks <file>                Middleware hooks      [default: none]
-  -x, --proxy <host>                Fallback proxy if no mock found
-  -o, --allow-cors [all|<hosts>]    Enable CORS requests  [default: none]
-  --https                           Enable secure request serving with HTTPS [default: false]
-  -l, --logs                        Enable server logs
-  -v, --version                     Show version
-  --help                            Show help
-
-Mock recording:
-  -r, --record <host>               Proxy & record requests if no mock found
-  -c, --collection <file>           Save to single file mock collection
-  -d, --depth <N>                   Folder depth for mocks  [default: 1]
-  -a, --save-headers                Save response headers
-  -q, --save-query                  Save query parameters
-```
-
-### File naming
-
-**General format:** `methods_api#route#@routeParam$queryParam=value.__set.extension`
-
-The path and file name of the mock is used to determinate:
-
-#### Supported HTTP methods
-Optionally prefix your file by the HTTP method supported followed by an underscore (for example `get_`).
-You can specify multiple methods at once using a `+` to separate them (for example `post+put_`);
-If no method is specified, the mock will be used for any HTTP method.
-
-#### Server route and named route parameters
-Use any combination of folders or hash-separated components to specify the server route.
-
-For example `api/example/get_hello.json` is equivalent to `get_api#example#hello.json` and will respond to
-`GET api/example/hello` requests.
-
-Additionaly, any route component can be defined as a route parameter by prefixing the name with `@`, for example
-`api#resource#@id.json` will match `GET api/resource/1` and expose `1` as the value for the `id` parameter that can be
-used in dynamic mocks (templates or JavaScript).
-
-#### Query parameters
-You can further discriminate mocks by adding query parameters to match after defining the route, using a `$` (instead
-of the regular `?`) like you would specify them in a request.
-
-For example `get_api#hello$who=john.json` will match the request `api/get_hello?who=john.json`.
-
-Multiple query parameters to match can be added with `&`, for example `get_api#hello$who=john&greet=hi.json`.
-Any specified query parameter in the file name must be matched (in any order) by the request, but the opposite is not
-needed.
-
-Note that special characters must be URL-encoded, for example use `get_api#hello$who=john%20doe.json` to set the
-parameter `who` with the value `john doe`.
-
-> Tip: If you need to URL-encode a string, just run `node -p "encodeURIComponent('some string')"` in a terminal.
-
-#### Content type
-The file extension will determine the content type of the response if it's not already specified in a
-[custom header](#custom-status-and-headers).
-
-Files with no extension will use the default MIME type `application/octet-stream`.
-
-You can have multiple mocks with the same API route and different file extensions, the server will then use the best
-mock depending of the [`Accept` header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept) of the
-request.
-
-#### Mock set
-You can optionally specify a mock set before the file extension by using a `__set-name` suffix after the file name.
-
-For example `get_api#hello__error.json` will only be used if you start the server with the `error` set enabled:
-`smoke --set error`.
-
-If you do not specify a mock set on your file name, it will be considered as the default mock for the specified route
-and will be used as a fallback if no mock with this set matched.
-
-#### Templates
-If you add an underscore `_` after the file extension, the mock will be processed as a template before being sent to
-the client. Templates works only on text-based formats.
-
-For example `get_hello.html_` or `get_hello.json_` will be treated as templates. 
-
-Every template can use an implicit context object that have these properties defined:
-- `method`: the HTTP method of the request (ex: `'GET'`, `'POST'`)
-- `query`: map with query parameters that were part of the request URL. For example, matched URL
-  `http://server/hello?who=world` will result in the query value: `{ who: 'world' }`.
-- `params`: map containing matched route parameters. For example the mock `resource#@id.json_` with the matched URL
-  `http://server/resource/123` will result in the params value: `{ id: '123' }`.
-- `headers`: map containing request headers
-- `body`: the request body. JSON bodies are automatically parsed.
-- `files`: if the request includes `multipart/form-data`, this will be the array of uploaded files (see
-  [multer documentation](https://github.com/expressjs/multer) for more details)
-
-##### Template syntax
-
-- `{{ }}` interpolates data in place
-
-  For example, create **get_hello.txt_** with this:
-  ```
-  Hello {{query.name}}!
-  ```
-
-  Then `curl "http://localhost:3000/hello?name=John"` returns `Hello John!`
-
-- `{{{ }}}` escapes HTML special chars from interpolated string
-
-  For example, create **get_hello.html_** with this:
-  ```html
-  <h1>Hello {{{query.name}}}!</h1>
-  ```
-
-  Then `curl "http://localhost:3000/hello?name=%3CJack%26Jones%3E"` returns:
-  ```html
-  <h1>Hello &lt;Jack&amp;Jones&gt;!</h1>
-  ```
-
-- `<{ }>` evaluates JavaScript to generate data
-
-  For example, create **get_hello.html_** with this:
-  ```html
-  Hello to:
-  <ul>
-    <{ query.name.forEach(name => { }><li>{{name}}</li><{ }); }>
-  </ul>
-  ```
-
-  Then `curl "http://localhost:3000/hello?name=Jack&name=Jones"` returns:
-  ```html
-  Hello to:
-  <ul>
-    <li>Jack</li><li>Jones</li>
-  </ul>
-  ```
-
-### Custom status and headers
-
-By default all mocks responses are sent with a status code `200` (OK), or `204` (No content) if a mock file is empty.
-
-You can customize the response status and (optionally) headers with JSON and [JavaScript](#javascript-mocks) files,
-using this syntax:
-```js
-{
-  "statusCode": 400,
-  "body": {
-    "error": "Bad request"
-  },
-  // headers can be omitted, only use if you want to customize them
-  "headers": {
-    "Content-Type": "text/plain"
-  } 
-}
-```
-
-You can also use non-string content type if you encode the content as a base64 string in the `body` property and add
-the property `"buffer": true` to the mock:
-```js
-{
-  "statusCode": 200,
-  "body": "U21va2Ugcm9ja3Mh",
-  "buffer": true,
-  "headers": {
-    "Content-Type": "application/octet-stream"
-  } 
-}
-```
-
-### Mock formats
-
-Any file format is supported for mocks, and the file extension will be used to determine the response content type.
-Files with no extension will use the default MIME type `application/octet-stream`.
-
-Text formats (for example `.json`, `.html`, `.txt`...) can be processed as [templates](#templates) by adding an
-underscore to the file extension.
-
-Note that JSON files and templates must use `UTF-8` encoding.
-
-#### JavaScript mocks
-
-In addition, you can define dynamic mocks using JavaScript by using the `.js` extension, that will be loaded as a regular
-Node.js module.
-
-In that case, your JS module is expected to export a function that take an input data object with the
-[same properties](#templates) as for templates and must returns the response body or an
-[object](#custom-status-and-headers) containing the status code, headers and body.
-
-Example:
-```js
-export default (data) => `{ "data": "Your user agent is: ${data.headers['user-agent']}" }`;
-```
-
-Note that by default, JS mocks use `application/json` for the response content type. If you want to use another type,
-you must set the `Content-Type` header yourself, for example:
-```js
-export default data => ({
-  statusCode: 200,
-  headers: {
-    'Content-Type': 'text/plain'
-  },
-  body: `Your user agent is: ${data.headers['user-agent']}`
-});
-```
-
-### Fallback proxy
-
-If you want to override responses of an existing server, you can use the `--proxy <host>` option. This will proxy
-every request for which a mock does not exist to the specified host.
-
-This can also be useful for mocking yet-to-be-implemented APIs and keep using real implemented APIs.
-
-### Mock recording
-
-To quickly create a mock set of an existing server (to allow working offline for example), you can use the
-`--record <host>` option. This will proxy every request for which a mock does not exist to the specified host, and
-record the resulting response as a mock file.
-
-You can change the maximum folder depth for mock files created this way using the `--depth` option.
-
-The recorded mock set can also be changed using the `--set` option.
-
-Instead of recoring separate mock files, you can also record to a
-[single file mock collection](#single-file-mock-collection) using the `--collection <file>` option. 
-
-Note that by default response headers and request query parameters are not saved. To change this behavior, you can
-use the `--save-headers` and `--save-query` options.
-
-### Middleware hooks
-
-For more advanced usages, you can hook on any standard
-[Express middleware](https://expressjs.com/en/guide/writing-middleware.html) to modify the request and/or the response
-returned by the server.
-
-To hook on your own middlewares, use the `--hooks` to specify a JavaScript module with exports setup like this:
-```js
-export const before = []; // middlewares to be executed before the request is processed
-export const after = [];  // middlewares to be executed after the request has been processed
-```
-
-Middlewares executed before the request is processed can be used to bypass regular mock response, for example to
-randomly simulate a server failure with an early error 500 response.
-
-On the other hand, middlewares executed after the request have been processed can be used to augment or modify the
-response, for example by adding header or changing the response status. You can also access and modify the response
-body by using the special `res.body` property.
-
-Remember that once you have used `.send()`, `.sendStatus` or `.json()` in a middleware the response cannot be altered
-anymore, that's why you should use the `res.body` property instead if you plan to alter the response later on.
-
-See some [example hooks](test/hooks.js).
-
-## Enabling CORS
-
-Smoke offers support to requests originating from a different origin. However, by default, this would be disabled.
-
-To enable CORS, pass the hosts that you want to allow to `-o` or `--allow-cors` arguments.
-
-**Accepted Values**
-- `all` - Allow requests from `*`
-- `<hosts>` - You could also pass a comma-separated list of hosts that you want to allow requests from something like `'http://localhost:3000,http://example.com'`
-
-### Single file mock collection
-
-You can regroup multiple mocks in a special single file with the extension `.mocks.js`, using this format:
-```js
-export default {
-  '<file_name>': '<file_content>' // can be a string, an object (custom response) or a function (JavaScript mock)
-};
-```
-See this [example mock collection](test/mocks/collection.mocks.js) to get an idea of all possibilities.
-
-The format of file name is the same as for individual mock files, and will be used to match the request using the same
-rules. As for the mock content, the format is also the same as what you would put in single file mock. If a request
-matches both a mock file and a mock within a collection with the same specificity, the mock file will always be used
-over the collection.
-
-As the format is the same, you can convert a bunch of files to a single file mock collection and conversely.
-To convert separate mock files to a collection:
-```sh
-smoke-conv <glob> <output_file>  // Will create <output_file>.mocks.js from all mocks found
-```
-
-To convert a mock collection to separate files:
-```sh
-smoke-conv <file> <output_folder>  // Will extract separate mocks into <output_folder>
-```
-
-Note that only text-based file content will be inserted directly, other file content will be converted to a base64
-string.
-
-:warning: There is a limitation regarding JavaScript mocks: only the exported function will be converted for a given
-mock, meaning that if you have non-exported functions, variables or imports they will be lost during the conversion.
-
-## Migration from v1/v2/v3 to v4
-
-If you are migrating from a previous version of Smoke, you need to be aware that the default module format has changed: earlier version used CommonJS modules, while v4 uses ES modules by default.
-
-But don't worry! You don't have to regenerate or updates all your mock files, Smoke will still support the CommonJS format for backward compatibility, though you need to rename all your `*.js` mocks, collections and hooks files to use the `.cjs` extension instead of `.js`.
-
-If you prefer to migrate your existing mock files to the new ES module format, you can do so by updating the export syntax to use `export default` instead of `module.exports` in mock files and collections, and `export` the `before` and `after` hooks constant separately in hooks fles.
-
-> [!NOTE]
-> If you try to record new mocks into an existing collection in CommonJS format, the result will be saved into a new collection in ES modules format.
-
-## Other mock servers
-
-If you cannot find what you need here, you might want to check out one of these other Node.js mock servers:
-
-- [JSON Server](https://github.com/typicode/json-server)
-- [mockserver](https://github.com/namshi/mockserver)
-- [node-mock-server](https://github.com/smollweide/node-mock-server)
-- [node-easymock](https://github.com/CyberAgent/node-easymock)
-- [mockserver-node](https://github.com/jamesdbloom/mockserver-node)
diff --git a/.claude/skills/dotnet-aspnet/SKILL.md b/.claude/skills/dotnet-aspnet/SKILL.md
deleted file mode 100644
index b3ba2125..00000000
--- a/.claude/skills/dotnet-aspnet/SKILL.md
+++ /dev/null
@@ -1,46 +0,0 @@
----
-name: dotnet-aspnet
-description: Applies ASP.NET Core best practices for building Web and REST APIs. Use when creating controllers, minimal APIs, configuring middleware, routing, model binding, validation, authentication, authorization, error handling with ProblemDetails, OpenAPI/Swagger, health checks, CORS, rate limiting, or structuring an ASP.NET Core project. For DI, Options pattern, and configuration that apply to any .NET host, use dotnet-fundamentals.
----
-
-# ASP.NET Core Web API Best Practices
-
-## When to Use
-
-- Creating new controllers, minimal API endpoints, or feature folders in an ASP.NET Core project
-- Configuring the middleware pipeline, routing, or model binding
-- Adding authentication, authorization policies, or `[Authorize]`-based access control
-- Implementing error handling with `ProblemDetails` (RFC 9457) or `IExceptionHandler`
-- Wiring up OpenAPI/Swagger, health checks, CORS, rate limiting, output caching, or response compression
-- Reviewing or restructuring an existing ASP.NET Core project to align with best practices
-
-This skill covers the **HTTP / web layer only**. For dependency injection, Options pattern, and configuration that apply to any .NET host, see [`dotnet-fundamentals`](../dotnet-fundamentals/SKILL.md).
-
-## Core Principles
-
-- Use feature folders, not layer folders. Keep `Program.cs` lean — extract registrations into extension methods.
-- Always use `[ApiController]` on MVC controllers; prefer `TypedResults` in minimal APIs.
-- Accept `CancellationToken` on every async endpoint.
-- Map domain exceptions to ProblemDetails — never leak internal exception messages.
-- Middleware order matters: exception handler → status code pages → HSTS/HTTPS → CORS → auth → rate limiter → endpoints.
-
-## Reference Index
-
-Detailed patterns and code samples live in `references/`:
-
-- **[project-and-endpoints.md](references/project-and-endpoints.md)** — Project structure, Controllers vs Minimal APIs, routing, API conventions, response types (`TypedResults`, `[ProducesResponseType]`)
-- **[model-binding-validation.md](references/model-binding-validation.md)** — Binding sources (`[FromBody]`, `[FromRoute]`, etc.), Data Annotations, FluentValidation, `ValidationProblemDetails`
-- **[middleware.md](references/middleware.md)** — Pipeline order, custom middleware with primary constructors
-- **[auth.md](references/auth.md)** — JWT Bearer, authorization policies, `IAuthorizationHandler`, `RequireAuthorization`
-- **[error-handling.md](references/error-handling.md)** — ProblemDetails, `IExceptionHandler` (.NET 8+), `UseStatusCodePages`
-- **[openapi-and-cross-cutting.md](references/openapi-and-cross-cutting.md)** — OpenAPI/Swagger, XML doc generation, health checks (liveness/readiness), CORS, rate limiting, output caching, response compression
-
-## Related Skills
-
-- **[dotnet-fundamentals](../dotnet-fundamentals/SKILL.md)** — Foundation: DI, Options pattern, configuration, modern C# idioms used by every endpoint and service in this skill
-- **[dotnet-ef-core](../dotnet-ef-core/SKILL.md)** — Data access with Entity Framework Core
-- **[dotnet-tester](../dotnet-tester/SKILL.md)** — Unit and integration testing for endpoints
-- **[dotnet-xmldocs](../dotnet-xmldocs/SKILL.md)** — XML documentation comments (feed OpenAPI)
-- **[dotnet-nuget-manager](../dotnet-nuget-manager/SKILL.md)** — Invoked for adding health-check, resilience, and middleware packages
-- **[dotnet-sdk-builder](../dotnet-sdk-builder/SKILL.md)** — Generates typed HTTP clients for consuming these APIs
-- **[dotnet-reviewer](../dotnet-reviewer/SKILL.md)** — Reviews ASP.NET Core code for security, performance, and architecture issues
diff --git a/.claude/skills/dotnet-aspnet/references/auth.md b/.claude/skills/dotnet-aspnet/references/auth.md
deleted file mode 100644
index 52f26414..00000000
--- a/.claude/skills/dotnet-aspnet/references/auth.md
+++ /dev/null
@@ -1,26 +0,0 @@
-# Authentication & Authorization
-
-## JWT Bearer Authentication
-
-```csharp
-builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
-    .AddJwtBearer(options =>
-    {
-        options.Authority = builder.Configuration["Auth:Authority"];
-        options.Audience = builder.Configuration["Auth:Audience"];
-    });
-```
-
-## Authorization Policies
-
-```csharp
-builder.Services.AddAuthorizationBuilder()
-    .AddPolicy("AdminOnly", policy => policy.RequireRole("Admin"))
-    .AddPolicy("CanEditOrder", policy =>
-        policy.Requirements.Add(new OrderOwnerRequirement()));
-```
-
-- Use policy-based authorization over role checks in attributes
-- Apply `[Authorize]` at controller level, `[AllowAnonymous]` for exceptions
-- Implement `IAuthorizationHandler` for resource-based authorization
-- For minimal APIs use `.RequireAuthorization("PolicyName")`
diff --git a/.claude/skills/dotnet-aspnet/references/error-handling.md b/.claude/skills/dotnet-aspnet/references/error-handling.md
deleted file mode 100644
index 09282b57..00000000
--- a/.claude/skills/dotnet-aspnet/references/error-handling.md
+++ /dev/null
@@ -1,44 +0,0 @@
-# Error Handling
-
-## ProblemDetails (RFC 9457)
-
-```csharp
-builder.Services.AddProblemDetails(options =>
-{
-    options.CustomizeProblemDetails = ctx =>
-    {
-        ctx.ProblemDetails.Extensions["traceId"] = ctx.HttpContext.TraceIdentifier;
-    };
-});
-```
-
-## Global Exception Handling (.NET 8+)
-
-```csharp
-public class GlobalExceptionHandler(ILogger<GlobalExceptionHandler> logger) : IExceptionHandler
-{
-    public async ValueTask<bool> TryHandleAsync(
-        HttpContext context, Exception exception, CancellationToken ct)
-    {
-        logger.LogError(exception, "Unhandled exception");
-
-        var problem = new ProblemDetails
-        {
-            Status = StatusCodes.Status500InternalServerError,
-            Title = "An error occurred",
-            Type = "https://httpstatuses.com/500"
-        };
-
-        context.Response.StatusCode = problem.Status.Value;
-        await context.Response.WriteAsJsonAsync(problem, ct);
-        return true;
-    }
-}
-
-builder.Services.AddExceptionHandler<GlobalExceptionHandler>();
-```
-
-- Use `IExceptionHandler` (.NET 8+) instead of custom exception middleware
-- Map domain exceptions to appropriate HTTP status codes
-- Never expose internal exception details in production responses
-- Use `app.UseStatusCodePages()` for consistent responses on empty status codes (404, 405, etc.)
diff --git a/.claude/skills/dotnet-aspnet/references/middleware.md b/.claude/skills/dotnet-aspnet/references/middleware.md
deleted file mode 100644
index 9940ff34..00000000
--- a/.claude/skills/dotnet-aspnet/references/middleware.md
+++ /dev/null
@@ -1,38 +0,0 @@
-# Middleware Pipeline
-
-Order matters — register middleware in the correct sequence:
-
-```csharp
-app.UseExceptionHandler();
-app.UseStatusCodePages();
-app.UseHsts();
-app.UseHttpsRedirection();
-app.UseCors();
-app.UseAuthentication();
-app.UseAuthorization();
-app.UseRateLimiter();
-app.UseOutputCache();
-app.MapControllers();
-```
-
-## Custom Middleware
-
-```csharp
-public class RequestTimingMiddleware(RequestDelegate next)
-{
-    public async Task InvokeAsync(HttpContext context)
-    {
-        var sw = Stopwatch.StartNew();
-        context.Response.OnStarting(() =>
-        {
-            context.Response.Headers["X-Response-Time-Ms"] = sw.ElapsedMilliseconds.ToString();
-            return Task.CompletedTask;
-        });
-        await next(context);
-    }
-}
-```
-
-- Use primary constructors for middleware
-- Inject scoped services via `InvokeAsync` parameters, not the constructor
-- Keep middleware focused — one concern per middleware
diff --git a/.claude/skills/dotnet-aspnet/references/model-binding-validation.md b/.claude/skills/dotnet-aspnet/references/model-binding-validation.md
deleted file mode 100644
index 1023f6d2..00000000
--- a/.claude/skills/dotnet-aspnet/references/model-binding-validation.md
+++ /dev/null
@@ -1,71 +0,0 @@
-# Model Binding & Validation
-
-ASP.NET Core-specific concerns around mapping HTTP requests onto typed arguments and validating them.
-
-## Binding Sources
-
-- Use binding source attributes explicitly: `[FromBody]`, `[FromQuery]`, `[FromRoute]`, `[FromHeader]`, `[FromForm]`, `[FromServices]`.
-- With `[ApiController]`, the framework infers binding sources: complex types default to `[FromBody]`, simple types to `[FromRoute]` / `[FromQuery]`.
-- For minimal APIs, binding is determined by parameter type and route template; use the attributes when inference is ambiguous.
-
-```csharp
-[HttpPost]
-public IActionResult Create(
-    [FromBody] CreateOrderRequest body,
-    [FromHeader(Name = "X-Tenant-Id")] string tenantId,
-    CancellationToken ct)
-{
-    // ...
-}
-```
-
-## Data Annotation Validation
-
-```csharp
-public record CreateOrderRequest(
-    [Required] string CustomerId,
-    [Required, MinLength(1)] List<OrderItemRequest> Items);
-```
-
-- With `[ApiController]`, validation failures automatically produce a `400 Bad Request` with a `ValidationProblemDetails` body.
-- Combine with `[StringLength]`, `[Range]`, `[RegularExpression]`, `[EmailAddress]` for richer constraints.
-
-## FluentValidation
-
-For validation logic that exceeds attribute capabilities (cross-field rules, async lookups), use FluentValidation:
-
-```csharp
-public class CreateOrderRequestValidator : AbstractValidator<CreateOrderRequest>
-{
-    public CreateOrderRequestValidator()
-    {
-        RuleFor(x => x.CustomerId).NotEmpty().Length(5, 50);
-        RuleFor(x => x.Items).NotEmpty();
-        RuleForEach(x => x.Items).SetValidator(new OrderItemRequestValidator());
-    }
-}
-
-builder.Services.AddValidatorsFromAssemblyContaining<CreateOrderRequestValidator>();
-```
-
-Wire validators into the pipeline via an `IEndpointFilter` (minimal APIs) or a custom MVC filter that runs `IValidator<T>` and returns `ValidationProblemDetails` on failure.
-
-## ProblemDetails for Validation Errors
-
-`[ApiController]` returns `ValidationProblemDetails` (RFC 9457 extension) automatically. For minimal APIs, return it explicitly:
-
-```csharp
-app.MapPost("/orders", async (CreateOrderRequest req, IValidator<CreateOrderRequest> validator, CancellationToken ct) =>
-{
-    var result = await validator.ValidateAsync(req, ct);
-    if (!result.IsValid)
-        return Results.ValidationProblem(result.ToDictionary());
-
-    // proceed
-    return Results.Created(...);
-});
-```
-
----
-
-**For DI lifetimes, the Options pattern, and configuration (`appsettings.json`, User Secrets, environment variables): see the [`dotnet-fundamentals`](../../dotnet-fundamentals/SKILL.md) skill.**
diff --git a/.claude/skills/dotnet-aspnet/references/openapi-and-cross-cutting.md b/.claude/skills/dotnet-aspnet/references/openapi-and-cross-cutting.md
deleted file mode 100644
index 374a6ef2..00000000
--- a/.claude/skills/dotnet-aspnet/references/openapi-and-cross-cutting.md
+++ /dev/null
@@ -1,100 +0,0 @@
-# OpenAPI, Health Checks & Cross-Cutting Concerns
-
-## OpenAPI / Swagger
-
-- Use the built-in OpenAPI support (.NET 9+) or Swashbuckle/NSwag for earlier versions:
-
-```csharp
-builder.Services.AddOpenApi();
-// ...
-app.MapOpenApi();
-```
-
-- Enable XML comments in `.csproj` for automatic documentation:
-  ```xml
-  <PropertyGroup>
-    <GenerateDocumentationFile>true</GenerateDocumentationFile>
-    <NoWarn>$(NoWarn);1591</NoWarn>
-  </PropertyGroup>
-  ```
-- Use `[Tags]`, `[EndpointSummary]`, `[EndpointDescription]` for metadata
-- Use `WithName()` and `WithTags()` on minimal API endpoints
-- Use the `dotnet-xmldocs` skill for writing XML documentation comments
-
-## Health Checks
-
-```csharp
-builder.Services.AddHealthChecks()
-    .AddCheck("self", () => HealthCheckResult.Healthy())
-    .AddNpgSql(connectionString, name: "database")
-    .AddRedis(redisConnectionString, name: "cache");
-
-app.MapHealthChecks("/health", new HealthCheckOptions
-{
-    ResponseWriter = UIResponseWriter.WriteHealthCheckUIResponse
-});
-
-app.MapHealthChecks("/health/ready", new HealthCheckOptions
-{
-    Predicate = check => check.Tags.Contains("ready")
-});
-```
-
-- Separate liveness (`/health`) and readiness (`/health/ready`) endpoints
-- Tag health checks for selective filtering
-- Use NuGet packages `AspNetCore.HealthChecks.*` for common dependencies
-- Use the `dotnet-nuget-manager` skill for adding health check packages
-
-## CORS
-
-```csharp
-builder.Services.AddCors(options =>
-{
-    options.AddPolicy("AllowFrontend", policy =>
-        policy.WithOrigins("https://app.example.com")
-              .AllowAnyHeader()
-              .AllowAnyMethod()
-              .AllowCredentials());
-});
-
-app.UseCors("AllowFrontend");
-```
-
-## Rate Limiting (.NET 7+)
-
-```csharp
-builder.Services.AddRateLimiter(options =>
-{
-    options.AddFixedWindowLimiter("api", limiter =>
-    {
-        limiter.PermitLimit = 100;
-        limiter.Window = TimeSpan.FromMinutes(1);
-    });
-    options.RejectionStatusCode = StatusCodes.Status429TooManyRequests;
-});
-
-app.UseRateLimiter();
-```
-
-- Apply per-endpoint with `[EnableRateLimiting("api")]` or `.RequireRateLimiting("api")`
-
-## Output Caching (.NET 7+)
-
-```csharp
-builder.Services.AddOutputCache(options =>
-{
-    options.AddBasePolicy(builder => builder.Expire(TimeSpan.FromMinutes(5)));
-    options.AddPolicy("NoCache", builder => builder.NoCache());
-});
-```
-
-## Response Compression
-
-```csharp
-builder.Services.AddResponseCompression(options =>
-{
-    options.EnableForHttps = true;
-    options.Providers.Add<BrotliCompressionProvider>();
-    options.Providers.Add<GzipCompressionProvider>();
-});
-```
diff --git a/.claude/skills/dotnet-aspnet/references/project-and-endpoints.md b/.claude/skills/dotnet-aspnet/references/project-and-endpoints.md
deleted file mode 100644
index 61649e98..00000000
--- a/.claude/skills/dotnet-aspnet/references/project-and-endpoints.md
+++ /dev/null
@@ -1,92 +0,0 @@
-# Project Structure & Endpoints
-
-## Project Structure
-
-- Organize code by feature/domain, not by layer (avoid generic `Controllers/`, `Services/`, `Models/` folders)
-- Use `Program.cs` as the composition root — register services, configure middleware pipeline
-- Keep `Program.cs` lean by extracting registration into extension methods (e.g., `AddApplicationServices()`, `AddAuthenticationServices()`)
-- Use feature folders:
-  ```
-  Features/
-    Orders/
-      OrdersController.cs
-      CreateOrderRequest.cs
-      OrderResponse.cs
-      OrderService.cs
-    Products/
-      ...
-  ```
-
-## Controllers vs Minimal APIs
-
-### Controllers
-
-Use controllers for larger APIs with shared conventions, filters, and complex routing:
-
-```csharp
-[ApiController]
-[Route("api/[controller]")]
-public class OrdersController(IOrderService orderService) : ControllerBase
-{
-    [HttpGet("{id:guid}")]
-    [ProducesResponseType<OrderResponse>(StatusCodes.Status200OK)]
-    [ProducesResponseType(StatusCodes.Status404NotFound)]
-    public async Task<IActionResult> GetById(Guid id, CancellationToken ct)
-    {
-        var order = await orderService.GetByIdAsync(id, ct);
-        return order is null ? NotFound() : Ok(order);
-    }
-}
-```
-
-- Always use `[ApiController]` attribute — enables automatic model validation, binding source inference, and ProblemDetails responses
-- Use primary constructor injection for dependencies
-- Return `IActionResult` or `ActionResult<T>` for endpoints with multiple response types
-- Accept `CancellationToken` on all async endpoints
-
-### Minimal APIs
-
-Use minimal APIs for simple endpoints, microservices, or when startup performance matters:
-
-```csharp
-var group = app.MapGroup("/api/orders")
-    .WithTags("Orders")
-    .RequireAuthorization();
-
-group.MapGet("/{id:guid}", async (Guid id, IOrderService service, CancellationToken ct) =>
-{
-    var order = await service.GetByIdAsync(id, ct);
-    return order is null ? Results.NotFound() : Results.Ok(order);
-})
-.WithName("GetOrderById")
-.Produces<OrderResponse>()
-.ProducesProblem(StatusCodes.Status404NotFound);
-```
-
-- Use `MapGroup()` to share route prefixes, filters, and metadata
-- Use `TypedResults` instead of `Results` for compile-time response type verification
-- Add `.WithName()` for OpenAPI operation IDs and link generation
-- Use endpoint filters for cross-cutting concerns
-
-## Routing & Endpoints
-
-- Use attribute routing on controllers (`[Route]`, `[HttpGet]`, etc.)
-- Apply route constraints: `{id:guid}`, `{page:int:min(1)}`, `{slug:regex(^[a-z-]+$)}`
-- Use API versioning via URL segment (`/api/v1/orders`) or header-based versioning with `Asp.Versioning.Http`
-- Keep route templates consistent — plural nouns for resources (`/api/orders`, not `/api/order`)
-- Use `LinkGenerator` for generating URLs to named endpoints
-
-## API Conventions & Response Types
-
-- Annotate endpoints with `[ProducesResponseType]` for OpenAPI documentation
-- Use `[Consumes]` and `[Produces]` for content type negotiation
-- Return consistent response envelopes or use ProblemDetails for errors
-- Use `TypedResults` in minimal APIs for compile-time response verification:
-
-```csharp
-group.MapPost("/", async (CreateOrderRequest req, IOrderService service, CancellationToken ct) =>
-{
-    var id = await service.CreateAsync(req, ct);
-    return TypedResults.Created($"/api/orders/{id}", new { id });
-});
-```
diff --git a/.claude/skills/dotnet-dev/SKILL.md b/.claude/skills/dotnet-dev/SKILL.md
deleted file mode 100644
index db23ff43..00000000
--- a/.claude/skills/dotnet-dev/SKILL.md
+++ /dev/null
@@ -1,312 +0,0 @@
----
-name: dotnet-dev
-description: >
-  Use when asked to implement, extend, or change a feature, user story,
-  requirement, or bug fix in a .NET / C# project — any task that produces or
-  modifies C# production code, tests, or documentation. Use when a .NET change
-  request arrives, before writing any code.
----
-
-# dotnet-dev — Comprehensive C# Requirement Implementation
-
-A strict, gated workflow for implementing requirements end-to-end in .NET / C#.
-Every phase ends in a confirmation gate; every applicable `dotnet-*` skill is a
-mandatory binding. The workflow exists to survive exactly the conditions —
-deadlines, "trivial" framing, "skip the ceremony" — under which it is most
-tempting to abandon.
-
-## Core Principle
-
-**Violating the letter of this workflow is violating its spirit.** The phases,
-gates, point-by-point clarification, and skill bindings are not ceremony to be
-proportioned to task size. They are the work. A one-line endpoint runs the same
-workflow as a subsystem — at speed, never collapsed.
-
-## CRITICAL RULES (read before every phase)
-
-1. **NO COMMITS.** Never run `git commit`, `git add -A`/`.`, branch, tag, or
-   push. The user commits manually. If asked to commit, skip it and say so.
-
-2. **URGENCY AND TRIVIALITY WAIVE NOTHING.** "It's trivial", "I'm in a hurry",
-   "demo in 30 minutes", "skip the clarification dance", "no need for the full
-   process", "just bang it out", "one pass is fine" are NOT permission to skip a
-   phase, a gate, a clarification point, or a skill binding. Acknowledge the
-   deadline, then run the workflow **at speed** — do not shrink it. The only
-   lawful way to reduce a binding's work is an objective `n/a` (see below);
-   user preference, pressure, and perceived size are never valid `n/a` reasons.
-   An explicit, informed user waiver is a different thing from pressure — see
-   *Waiver vs. `n/a` vs. silent skip*.
-
-3. **EVERY PHASE ENDS IN A CONFIRMATION GATE.** At the end of each phase you
-   MUST present a summary and STOP. Do not start the next phase until the user
-   explicitly confirms. **Batching is a violation** — you may not present
-   multiple phases at once, "pre-run" the next phase, or ask for one combined
-   confirmation at the end. One phase → one summary → one wait.
-
-4. **`dotnet-*` SKILLS ARE MANDATORY BINDINGS.** When a binding applies, you
-   MUST invoke that skill via the `Skill` tool, in this conversation, for this
-   task, **before** producing the corresponding artifact. Listing it,
-   paraphrasing it, "knowing it already", or having invoked it for a previous
-   task does NOT count. Invocation must shape the artifact, not certify it
-   afterward.
-
-## Phase Flow
-
-```
-Phase 1: Requirement Review              → GATE
-Phase 2: Clarification (8 points)        → GATE
-Phase 3: Task Breakdown                  → GATE
-Phase 4: Implementation + App Smoke-Check ◄──┐  → GATE
-Phase 5: Code Review (dotnet-reviewer)       │
-   └─ rework needed? ───────────────────────►┘
-   └─ all good → GATE
-Phase 6: Final Summary
-```
-
-## Skill Map — Mandatory Bindings
-
-| Binding | Skill | Applies in | When |
-|---|---|---|---|
-| Core C# / DI / Options / config / modern C# idioms | `dotnet-fundamentals` | Phase 4 | always, for production code |
-| ASP.NET Core (controllers, minimal APIs, middleware, auth, ProblemDetails, OpenAPI) | `dotnet-aspnet` | Phase 4 | when ASP.NET Core is touched |
-| EF Core (DbContext, entities, LINQ, migrations) | `dotnet-ef-core` | Phase 4 | when EF Core is touched |
-| SDK / typed HTTP client generation | `dotnet-sdk-builder` | Phase 4 | when building a typed SDK / client |
-| External / platform / NuGet API surface lookup | `dotnet-inspect` | Phase 1, 4 | when an external/platform API is involved |
-| Tests | `dotnet-tester` | Phase 4 | always, when code is written or changed |
-| XML documentation | `dotnet-xmldocs` | Phase 4 | for any public API addition/change |
-| NuGet packages | `dotnet-nuget-manager` | Phase 4 | any package add/remove/version change |
-| Code review | `dotnet-reviewer` | Phase 5 | always |
-| Router (tie-breaker) | `dotnet` | any | when the right sub-skill is not obvious |
-
-**Correct names matter:** `dotnet-ef-core` and `dotnet-nuget-manager` (not
-`ef-core` / `nuget-manager`). A binding is fulfilled only when its skill has
-fired via the `Skill` tool for this task. A binding applies whether you do the
-work yourself or dispatch a sub-agent — self-execution never waives it, and a
-sub-agent's invocation never waives the main agent's own follow-up edits.
-
-**Tooling:** for code navigation/exploration follow the project + global rules
-(Serena first, then tokensave; built-in/`Explore` agents only in the documented
-carve-outs). Do NOT use `Explore` agents for code research when tokensave is
-available.
-
----
-
-## Phase 1 — Requirement Review
-
-1. Read the requirement. Extract explicit AND implicit acceptance criteria.
-2. **Find gaps, contradictions, and open questions** — list them explicitly. A
-   review that surfaces no gaps on an ambiguous requirement is a failure; if the
-   requirement truly is unambiguous, say so explicitly rather than skipping.
-3. Analyze scope: affected `*.csproj`, components, files; existing tests/docs.
-4. Read `CLAUDE.md`, `AGENTS.md`, `.editorconfig`, `Directory.Build.props`,
-   `Directory.Packages.props` and follow the conventions found.
-5. Invoke `dotnet-inspect` if any external/platform API surface must be verified.
-6. **Determine the preliminary Skill Map** for this task and show it as a table.
-
-**GATE 1 — STOP.** Present: requirement restated, acceptance criteria,
-gaps/contradictions/open questions, affected scope, and the preliminary Skill
-Map table. Wait for confirmation.
-
-## Phase 2 — Clarification (8 points, one round-trip per point)
-
-Clarify the following **one point at a time** — present point _N_, propose a
-concrete default/assumption, ask the open question, and **wait for the user's
-answer before moving to point _N+1_.** You may NOT batch points into one
-message, NOR skip a point silently. A point that objectively does not apply is
-presented with `n/a — <code-referenced reason>` and still acknowledged.
-
-| # | Item | Must clarify |
-|---|---|---|
-| 1 | Project & folder structure | Target `*.csproj`, namespace, folder layout, new projects yes/no |
-| 2 | Architecture & layering | Layers (controller/service/repo or vertical slice), DI lifetimes, public vs internal surface |
-| 3 | Naming conventions | Type/method/file/namespace names, suffixes (`Service`, `Handler`, `Options`, `Async`), test naming |
-| 4 | Public API / contracts | DTO shape, request/response, ProblemDetails, versioning, OpenAPI annotations |
-| 5 | Errors & edge cases | Exception strategy, Result vs throws, validation style, logging granularity |
-| 6 | Test strategy | Unit and/or integration, mock boundaries, naming, fakes vs real dependencies, coverage expectation |
-| 7 | Persistence / EF Core | Entity shape, migrations yes/no, owned types, indexes, query style (LINQ vs spec) |
-| 8 | Dependencies / NuGet | Allowed/forbidden packages, Central Package Management versions |
-
-**GATE 2 — STOP.** Present: every clarified decision (all 8 points) and the
-**finalized** Skill Map (updated from the answers — e.g. points 7/8 confirm
-`dotnet-ef-core` / `dotnet-nuget-manager`). Wait for confirmation.
-
-## Phase 3 — Task Breakdown
-
-1. Break the requirement into discrete implementation tasks.
-2. Each task covers **production code + tests + documentation**.
-3. **Each task publishes a Skill-prerequisite checklist** (from the Skill Map):
-
-   ```
-   Task #N: <subject>
-     Skill prerequisites:
-       [ ] dotnet-fundamentals
-       [ ] dotnet-aspnet
-       [ ] dotnet-tester
-       [ ] dotnet-xmldocs
-   ```
-
-4. Define dependencies and which tasks may run in parallel via sub-agents.
-
-**GATE 3 — STOP.** Present the task list with per-task checklists, dependency
-order, and parallelization. Wait for confirmation.
-
-## Phase 4 — Implementation + App Smoke-Check
-
-For each task (or parallel group):
-
-1. **Step 0 — invoke every required `dotnet-*` skill for this task** before any
-   `Write`/`Edit`/code-producing `Bash`. One `Skill(...)` call per binding, no
-   collapsing. Re-invoke per task; previous-task invocations do not carry over.
-   Then follow each skill's workflow when producing its artifact.
-2. Implement production code (`dotnet-fundamentals` + stack skill), tests
-   (`dotnet-tester`), XML docs (`dotnet-xmldocs`), package changes
-   (`dotnet-nuget-manager`).
-3. Run `dotnet build` and the test suite. Fix failures.
-4. **App Smoke-Check** — if a runnable application exists, start it and verify
-   it actually runs:
-   - **Applies when** the solution has an executable project (`OutputType=Exe`,
-     ASP.NET Core Web/API, Worker Service). **`n/a` only when** the solution is
-     library-only (no executable project) — state that as the reason.
-   - Start the app **in the background** (a server does not exit on its own),
-     check startup logs / health endpoint / a representative request, then shut
-     it down cleanly. Never block on a foreground long-running process.
-
-**GATE 4 — STOP.** Present implemented tasks, build/test result, and the
-App-Smoke-Check outcome (or its `n/a` reason). Wait for confirmation.
-
-## Phase 5 — Code Review
-
-1. Launch a code-review **sub-agent** that uses `dotnet-reviewer`. Invoke
-   `dotnet-reviewer` via the `Skill` tool in the main conversation **and** pass
-   it to the sub-agent prompt. Inline self-review does NOT satisfy this phase —
-   `dotnet-reviewer` produces a severity-tagged Markdown report under
-   `docs/reviews/`.
-2. Evaluate findings:
-   - **Rework needed** → create new tasks (each with its own Skill checklist)
-     and return to **Phase 4**. After fixing, re-run Phase 5 (rework loop).
-   - **All good** → proceed.
-
-**GATE 5 — STOP.** Present the review findings, the report path, and your
-rework/no-rework decision. Wait for confirmation.
-
-## Phase 6 — Final Summary
-
-1. Files created/modified; what was implemented and why.
-2. Tests added/updated; documentation changes; package changes.
-3. Decisions/trade-offs; anything the user should verify before committing.
-4. **Skill-Invocation Log** (mandatory audit trail — see below).
-5. Reminder: *the user commits; this workflow creates no commits.*
-
----
-
-## `n/a` Criteria — Strict
-
-A binding or clarification point may be `n/a` **only** when an objective
-technical fact makes the work empty for this task. Valid reasons cite the
-codebase, never the user:
-
-- ✅ `n/a — task touches no public API members (internal sealed class)` — `dotnet-xmldocs`
-- ✅ `n/a — no NuGet package added/removed/version-changed` — `dotnet-nuget-manager`
-- ✅ `n/a — solution is library-only, no executable project` — App Smoke-Check
-- ✅ `n/a — scanned changed files; no DbContext/IQueryable/migration` — `dotnet-ef-core`
-- ❌ NOT valid: `n/a — user said no tests`
-- ❌ NOT valid: `n/a — too small / trivial / one-liner / just a lambda`
-- ❌ NOT valid: `n/a — single ToListAsync, doesn't need the skill`
-- ❌ NOT valid: `n/a — no test project exists` (creating it is part of the task)
-- ❌ NOT valid: `n/a — demo, no time`
-
-If you cannot phrase the reason as "no `<artifact>` exists in this task because
-`<code-referenced fact>`", it is NOT `n/a` — invoke the skill and do the work.
-
-**No avoidance-driven `n/a`.** You may not reshape the implementation to escape
-a binding — e.g. hand-rolling code to dodge `dotnet-nuget-manager`, inlining a
-public member to dodge `dotnet-xmldocs`, or collapsing a service into private
-code to dodge `dotnet-tester`. The binding follows the natural shape of the
-work, not a shape chosen to minimise bindings.
-
-## Waiver vs. `n/a` vs. silent skip
-
-Three distinct cases — keep them apart. Conflating them is how the workflow
-silently collapses.
-
-- **Implicit pressure** — "it's trivial", "I'm in a hurry", "demo in 30
-  minutes", "skip the ceremony", "this is how we work here", "nobody runs all
-  this". **Waives NOTHING.** Acknowledge it and run the full workflow at speed.
-  These are exactly the conditions the workflow exists to survive (CRITICAL
-  RULE 2). Treat them as no-ops on scope.
-
-- **Explicit, informed user waiver** — the user, *after being told what the step
-  protects and what gap skipping it creates*, directly says "skip phase X / the
-  gates / the clarification / the tests / the review." This **may be honored**
-  (your global rule: explicit user instructions take precedence), but only on
-  these terms:
-  1. **State the cost first.** Name what the skipped step would have caught
-     before you skip it. No silent compliance.
-  2. **Record it as a waiver, never as `n/a`.** A waiver means "the user chose
-     to skip this"; `n/a` means "the work is objectively empty." Stamping `n/a`
-     on a waived step makes the audit trail lie about *why* it was skipped.
-     Log it as: `waived — explicit user instruction (<who>, <when>); not a
-     technical n/a; gap: <what is now uncovered>`.
-  3. **Some steps still run regardless.** Invoking the relevant `dotnet-*`
-     skills before writing code costs the user nothing and keeps the code
-     matching repo conventions — keep them even under a waiver.
-
-- **Objective `n/a`** — the work is empty for a code-referenced reason (see
-  `n/a` Criteria). This is the only state that requires no user sign-off.
-
-**The line:** vague urgency is not a waiver. A waiver is the user explicitly
-electing to skip a *named* step after hearing its cost. When in doubt, ask the
-user to confirm the waiver explicitly — do not infer one from pressure.
-
-## Artifact-Substance Bar
-
-Invoking a skill is necessary but not sufficient — the artifact must reflect it:
-
-- A test that asserts nothing about the change (`Assert.True(true)`, a smoke
-  test with no behavioral assertion) does not satisfy `dotnet-tester`.
-- Empty `<summary />` or name-echoing docs do not satisfy `dotnet-xmldocs`.
-- Hand-editing `<PackageReference>` after "invoking" `dotnet-nuget-manager` does
-  not satisfy it — use the `dotnet` CLI as the skill prescribes.
-- A "review" with no `docs/reviews/` report does not satisfy `dotnet-reviewer`.
-
-If an artifact misses the bar, the binding is `[!]`, not `[x]`.
-
-## Skill-Invocation Log (Phase 6)
-
-Reproduce each task's checklist, every entry resolved with evidence:
-
-- `[x] <skill> — invoked at <evidence>` — a verifiable ordered turn (e.g.
-  "before Write of `UsersController.cs`"). "Considered"/"applied" is not
-  evidence. Invocation AFTER the artifact is `[!]`, not `[x]`.
-- `[n/a] <skill> — did not apply (<code-referenced reason>)`.
-- `[!] <skill> — NOT invoked` — a violation. `[!]` is **not a shipping path**:
-  name it, mark the task INCOMPLETE, STOP, and offer to re-enter Phase 4 to run
-  the missing skill's workflow on the artifact. Phase 6 does not complete while
-  any `[!]` is present.
-
-## Red Flags — STOP and run the workflow
-
-| Rationalization | Reality |
-|---|---|
-| "It's trivial / one endpoint — phases & gates are overkill" | Size does not scale the workflow. Run all phases at speed. Gate after each. |
-| "Demo in 30 min / I'm in a hurry — one pass, no gates" | Urgency waives nothing (CRITICAL RULE 2). Acknowledge the deadline, keep the gates. |
-| "Lead waived the clarification dance" | The 8 points are mandatory, one round-trip each. User waiver is not a valid skip. |
-| "Ambiguities aren't blocking — I'll state assumptions instead of asking" | Stating assumptions ≠ clarifying. Present each point and wait for the answer. |
-| "I'll batch all phases / ask one combined confirmation" | Batching is a gate violation. One phase → one summary → one wait. |
-| "This is a single ToListAsync — `dotnet-ef-core` isn't needed" | Touching EF Core triggers the binding regardless of LINQ simplicity. Invoke it. |
-| "Not a public library API, so skip `dotnet-xmldocs`" | `n/a` only for objectively internal members. Public additions/changes go through it. |
-| "User said no tests" | User preference is not a valid `n/a`. Either an objective code-referenced `n/a` exists or `dotnet-tester` is required; if the user insists, name it as a violation and let them decide. |
-| "I'll self-review the diff inline instead of `dotnet-reviewer`" | Phase 5 requires the `dotnet-reviewer` sub-agent + `docs/reviews/` report. Inline self-review does not satisfy it. |
-| "I'll hand-roll it to avoid adding a package" | Avoidance-driven `n/a` is forbidden. The binding follows the natural shape of the work. |
-| "The owner told me to skip it — I'll mark those steps `n/a`" | A waiver is not an `n/a`. Honor an explicit informed waiver if given, but record it as `waived — user instruction`, never `n/a`, never silently. See *Waiver vs. `n/a`*. |
-| "They pushed back / 'nobody does this here' — the workflow is waived" | Pushback, urgency, and social proof are not waivers. Only an explicit, informed skip of a *named* step counts. Vague urgency waives nothing — run at speed. |
-| "I already know C# / the skill — invoking is ceremony" | Skills encode project conventions and modern idioms. Knowing ≠ invoking. Invoke it. |
-| "The skill was invoked last task" | Invocations do not carry over. Re-invoke per task. |
-| "The sub-agent invoked it — covers my own edits" | It does not. Re-invoke before your own follow-up Write/Edit. |
-| "I'll log the `Skill(...)` call even though I ran it after the Write" | Evidence must be a real ordered turn. After-the-fact is `[!]`, not `[x]`. |
-| "No executable project, but I'll skip the App-Smoke-Check check anyway" | Decide it explicitly: run it, or mark `n/a — library-only`. Don't drop it silently. |
-
----
-
-For detailed per-phase guidance, see
-[references/REFERENCE.md](references/REFERENCE.md).
diff --git a/.claude/skills/dotnet-dev/references/REFERENCE.md b/.claude/skills/dotnet-dev/references/REFERENCE.md
deleted file mode 100644
index 4cd3787d..00000000
--- a/.claude/skills/dotnet-dev/references/REFERENCE.md
+++ /dev/null
@@ -1,209 +0,0 @@
-# dotnet-dev — Detailed Reference
-
-In-depth guidance per phase. Assumes a .NET / C# project. The Skill Map and the
-CRITICAL RULES in `SKILL.md` are authoritative; this document expands the *how*.
-
----
-
-## Phase 1 — Requirement Review (Detail)
-
-### Goal
-Understand the requirement fully before any code is written, and surface every
-gap before they become rework.
-
-### Steps
-1. **Read the requirement** (issue, story, ticket, message). Identify the core
-   objective and expected outcome.
-2. **Acceptance criteria** — explicit (stated) and implicit (existing tests must
-   still pass, API contracts honored, public additions need XML docs, existing
-   conventions respected).
-3. **Gaps / contradictions / open questions** — write them down. Watch for:
-   - Scope boundaries (what is in / out).
-   - Error-handling behavior (`ProblemDetails`? typed exceptions? Result?).
-   - Backward compatibility (API surface, EF Core migrations).
-   - Target-framework / performance constraints.
-   - Contradictions between the request and existing code/conventions.
-4. **Codebase analysis** — affected `*.csproj`, host type (ASP.NET Core, Worker,
-   Console, MAUI), data layer (EF Core), cross-cutting (DI, Options, Serilog).
-   Locate existing tests (`*.Tests`) and docs. Read `Directory.Build.props`,
-   `Directory.Packages.props`, `.editorconfig`, `nuget.config`. Use Serena /
-   tokensave per project + global tooling rules — not `Explore` agents when
-   tokensave is available.
-5. **`dotnet-inspect`** — invoke whenever an external/platform/NuGet API surface
-   must be verified (types, members, version diffs, extension methods).
-6. **Preliminary Skill Map** — from the requirement, list which bindings the
-   work will touch. It is *preliminary*: persistence (point 7) and dependencies
-   (point 8) are confirmed in Phase 2 and may add `dotnet-ef-core` /
-   `dotnet-nuget-manager`.
-
-### GATE 1 output
-Requirement restated in your words · acceptance criteria · gaps/contradictions/
-open questions · affected scope · preliminary Skill Map table. **Wait.**
-
----
-
-## Phase 2 — Clarification (Detail)
-
-### Goal
-Resolve the 8 standard implementation dimensions, one at a time, so nothing is
-silently assumed.
-
-### Protocol
-- **One point per message.** Present point _N_: a concrete proposed default,
-  then the open question. Wait for the answer before point _N+1_.
-- **No batching, no skipping.** A point that objectively does not apply is shown
-  with `n/a — <code-referenced reason>` and still acknowledged before moving on.
-- Pre-filling a sensible default is encouraged — it lets the user reply "ok"
-  fast — but the default never replaces the round-trip.
-
-### The 8 points (expanded prompts)
-1. **Project & folder structure** — which `*.csproj`, namespace, folder layout;
-   new projects yes/no.
-2. **Architecture & layering** — controller/service/repo vs vertical slice; DI
-   lifetimes (singleton/scoped/transient); public vs internal surface.
-3. **Naming conventions** — type/method/file/namespace names; suffixes
-   (`Service`, `Handler`, `Options`, `Async`); test naming pattern.
-4. **Public API / contracts** — DTO shape, request/response, `ProblemDetails`,
-   versioning, OpenAPI annotations.
-5. **Errors & edge cases** — exception strategy, Result vs throws, validation
-   style, logging granularity.
-6. **Test strategy** — unit and/or integration, mock boundaries, naming, fakes
-   vs real dependencies, coverage expectation.
-7. **Persistence / EF Core** — entity shape, migrations yes/no, owned types,
-   indexes, query style (LINQ vs spec). Confirms `dotnet-ef-core`.
-8. **Dependencies / NuGet** — allowed/forbidden packages, Central Package
-   Management versions. Confirms `dotnet-nuget-manager`.
-
-### GATE 2 output
-All 8 clarified decisions · the **finalized** Skill Map. **Wait.**
-
----
-
-## Phase 3 — Task Breakdown (Detail)
-
-### Goal
-A trackable plan of discrete tasks, each self-contained.
-
-### Steps
-- Break into the smallest reasonable tasks; descriptive IDs; enough detail to
-  execute without re-reading the plan.
-- Each task addresses **production code + tests + documentation**.
-- Each task publishes its **Skill-prerequisite checklist** from the Skill Map.
-- Dependencies — common .NET order: entities → EF Core config/migrations →
-  repositories/services → controllers/endpoints; DTOs before consumers; package
-  changes before code using them.
-- Parallelization — group independent tasks for sub-agents; do not parallelize
-  migration/schema work with other EF Core work.
-
-### GATE 3 output
-Task list with per-task checklists · dependency order · parallel groups. **Wait.**
-
----
-
-## Phase 4 — Implementation + App Smoke-Check (Detail)
-
-### Step 0 — Skill invocation (per task)
-Before any `Write`/`Edit`/code-producing `Bash` for the task, invoke each
-required binding once via the `Skill` tool. A task touching code + tests + docs
-is at least three calls (`dotnet-fundamentals` + `dotnet-tester` +
-`dotnet-xmldocs`) plus stack skills and `dotnet-nuget-manager` if packages
-change. Wait for each skill's content; follow its workflow when producing the
-artifact. Sub-agent dispatch is in addition to Step 0, not a substitute — pass
-the skills explicitly to the sub-agent (sub-agents are stateless).
-
-### Production code
-`dotnet-fundamentals` always; plus `dotnet-aspnet` (web), `dotnet-ef-core` (EF),
-`dotnet-sdk-builder` (typed SDK/HTTP client), `dotnet-inspect` (verify external
-API). Apply project conventions: `Ensure.*` guards, primary constructors,
-nullable reference types, `CancellationToken` propagation, `.ConfigureAwait(false)`
-in library code (not in tests), never `.Result`/`.Wait()`/`.GetAwaiter().GetResult()`.
-
-### Tests
-`dotnet-tester` always when code is written/changed — xUnit + FakeItEasy +
-AwesomeAssertions, plus its second-agent missing-case pass. Cover new/changed
-behavior and the edge cases from Phase 1.
-
-### Documentation
-`dotnet-xmldocs` for every public API addition/change.
-
-### Build & dependencies
-`dotnet-nuget-manager` for any package add/remove/version change (enforces the
-`dotnet` CLI and `Directory.Packages.props`). Then `dotnet build` + `dotnet test`;
-fix failures before the gate.
-
-### App Smoke-Check
-- **Applies** when an executable project exists (`OutputType=Exe`, ASP.NET Core
-  Web/API, Worker Service). **`n/a`** only when library-only.
-- Start in the **background** (servers do not self-exit). Verify startup logs /
-  health endpoint / one representative request. Shut down cleanly. Never block
-  on a foreground long-running process.
-
-### GATE 4 output
-Implemented tasks · build/test result · App-Smoke-Check outcome (or `n/a`
-reason). **Wait.**
-
----
-
-## Phase 5 — Code Review (Detail)
-
-### Steps
-- Launch a code-review **sub-agent** instructed to invoke `dotnet-reviewer`;
-  also invoke `dotnet-reviewer` in the main conversation. The skill reviews
-  working-tree or branch-vs-`main` changes and writes a severity-tagged Markdown
-  report under `docs/reviews/`.
-- Review covers: correctness/completeness vs requirement, test coverage, doc
-  accuracy, code quality/bugs/security, .NET idioms, convention consistency.
-
-### Evaluate findings
-- **No / minor issues** → fix directly (still invoking the required skills
-  before edits), then gate.
-- **Significant issues** → new tasks (each with its Skill checklist) → return to
-  Phase 4 → re-run Phase 5. If the same issue recurs after 2 cycles, consult the
-  user.
-
-### GATE 5 output
-Findings · report path · rework/no-rework decision. **Wait.**
-
----
-
-## Phase 6 — Final Summary (Detail)
-
-1. **Requirement** restated briefly.
-2. **Files** created/modified.
-3. **Implementation details** and key design decisions.
-4. **Tests** added/updated and what they cover.
-5. **Documentation** changes (XML docs, READMEs).
-6. **Package changes** (cross-reference `Directory.Packages.props`).
-7. **Decisions / trade-offs.**
-8. **Review notes** — key `dotnet-reviewer` points + report link.
-9. **Things to check** before committing.
-10. **Skill-Invocation Log** — every task's checklist resolved to `[x]`/`[n/a]`/
-    `[!]` with evidence (see `SKILL.md`). Mandatory even when all bindings were
-    correct — it is the audit trail.
-
-End with: *All changes are ready for your review. Commit them yourself when
-satisfied — this workflow creates no commits.*
-
----
-
-## General Guidelines
-
-### Sub-agents
-- Provide complete context (stateless). Pass the relevant `dotnet-*` skills in
-  the prompt. Use a build/test runner for `dotnet build`/`dotnet test`. Prefer
-  small focused tasks; launch independent tasks in parallel.
-- For code research, follow the project + global tooling rules (Serena →
-  tokensave → built-in; no `Explore` agents when tokensave is available).
-
-### Git
-- NEVER `git commit`, `git add -A`/`.`, branch, tag, or push. Read-only git
-  (`diff`/`status`/`log`) is fine. Stage by name only when explicitly asked;
-  refuse secret-like files (`.env`, `credentials.json`, `*.pem`).
-- If a commit is requested, skip it: *"Committing is your responsibility."*
-
-### Project conventions
-- Honor `CLAUDE.md`, `AGENTS.md`, `.github/copilot-instructions.md`,
-  `.editorconfig`, `Directory.Build.props`, `Directory.Packages.props`.
-- `Ensure.NotNull(...)` / `Ensure.IsNotNullOrEmpty(...)` /
-  `Ensure.IsNotNullOrWhitespace(...)` from `CreativeCoders.Core` for argument
-  guards in libraries.
diff --git a/.claude/skills/dotnet-ef-core/SKILL.md b/.claude/skills/dotnet-ef-core/SKILL.md
deleted file mode 100644
index 10ba55d5..00000000
--- a/.claude/skills/dotnet-ef-core/SKILL.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-name: dotnet-ef-core
-description: Applies Entity Framework Core best practices for .NET projects. Use when designing DbContext, creating entities or relationships, writing LINQ queries, managing migrations, implementing repository patterns, or troubleshooting N+1 queries and performance issues with EF Core.
----
-
-# Entity Framework Core Best Practices
-
-## When to Use
-
-- Designing or restructuring a `DbContext`, entities, or relationships
-- Writing LINQ queries against EF Core, or troubleshooting N+1 / performance issues
-- Creating, naming, or reviewing EF Core migrations
-- Implementing concurrency control, repository patterns, or change tracking strategies
-- Setting up EF Core tests with SQLite in-memory or Testcontainers
-
-## Data Context Design
-
-- Keep DbContext classes focused and cohesive
-- Use constructor injection for configuration options
-- Override OnModelCreating for fluent API configuration
-- Separate entity configurations using IEntityTypeConfiguration
-- Consider using DbContextFactory pattern for console apps or tests
-
-## Entity Design
-
-- Use meaningful primary keys (consider natural vs surrogate keys)
-- Implement proper relationships (one-to-one, one-to-many, many-to-many)
-- Use data annotations or fluent API for constraints and validations
-- Implement appropriate navigational properties
-- Consider using owned entity types for value objects
-
-## Performance
-
-- Use AsNoTracking() for read-only queries
-- Implement pagination for large result sets with Skip() and Take()
-- Use Include() to eager load related entities when needed
-- Consider projection (Select) to retrieve only required fields
-- Use compiled queries for frequently executed queries
-- Avoid N+1 query problems by properly including related data
-
-## Migrations
-
-- Create small, focused migrations
-- Name migrations descriptively
-- Verify migration SQL scripts before applying to production
-- Consider using migration bundles for deployment
-- Add data seeding through migrations when appropriate
-
-## Querying
-
-- Use IQueryable judiciously and understand when queries execute
-- Prefer strongly-typed LINQ queries over raw SQL
-- Use appropriate query operators (Where, OrderBy, GroupBy)
-- Consider database functions for complex operations
-- Implement specifications pattern for reusable queries
-
-## Change Tracking & Saving
-
-- Use appropriate change tracking strategies
-- Batch your SaveChanges() calls
-- Implement concurrency control for multi-user scenarios (see below)
-- Consider using transactions for multiple operations
-- Use appropriate DbContext lifetimes (scoped for web apps)
-
-### Concurrency Control
-
-See [concurrency-control.md](./references/concurrency-control.md) for `[Timestamp]`, `[ConcurrencyCheck]`, fluent API configuration, and `DbUpdateConcurrencyException` handling patterns.
-
-## Security
-
-- Use parameterized queries to prevent SQL injection
-- Implement appropriate data access permissions
-- Be careful with raw SQL queries
-- Consider data encryption for sensitive information
-- Use migrations to manage database user permissions
-
-## Testing
-
-- Avoid the EF Core In-Memory provider for tests — it does not enforce constraints, referential integrity, or transactions, so tests can pass while real database behavior fails
-- Use **SQLite in-memory mode** for lightweight unit and integration tests that need realistic SQL semantics:
-  ```csharp
-  var connection = new SqliteConnection("DataSource=:memory:");
-  connection.Open();
-  var options = new DbContextOptionsBuilder<AppDbContext>()
-      .UseSqlite(connection)
-      .Options;
-  ```
-- Use **Testcontainers** for integration tests that must match production database behavior (e.g., PostgreSQL, SQL Server):
-  ```csharp
-  var container = new PostgreSqlBuilder().Build();
-  await container.StartAsync();
-  var options = new DbContextOptionsBuilder<AppDbContext>()
-      .UseNpgsql(container.GetConnectionString())
-      .Options;
-  ```
-- Mock DbContext and DbSet only for pure unit tests that do not execute queries
-- Test migrations in isolated environments
-- Consider snapshot testing for model changes
-- Use the `dotnet-tester` skill for generating unit and integration tests after schema changes
-
-## Related Skills
-
-- **[dotnet-fundamentals](../dotnet-fundamentals/SKILL.md)** — DI lifetimes for `DbContext`, Options pattern for connection strings, modern C# idioms used in entity types
-- **[dotnet-tester](../dotnet-tester/SKILL.md)** — Generates DbContext-backed unit and integration tests (SQLite in-memory, Testcontainers)
-- **[dotnet-aspnet](../dotnet-aspnet/SKILL.md)** — Wires EF Core into ASP.NET Core via DI (scoped DbContext lifetimes)
-- **[dotnet-reviewer](../dotnet-reviewer/SKILL.md)** — Reviews EF Core data-access code for performance and security issues
-- **[dotnet-nuget-manager](../dotnet-nuget-manager/SKILL.md)** — Adds EF Core providers, Testcontainers, and SQLite packages
diff --git a/.claude/skills/dotnet-ef-core/references/concurrency-control.md b/.claude/skills/dotnet-ef-core/references/concurrency-control.md
deleted file mode 100644
index 57200980..00000000
--- a/.claude/skills/dotnet-ef-core/references/concurrency-control.md
+++ /dev/null
@@ -1,52 +0,0 @@
-# Concurrency Control
-
-Use `[Timestamp]` for automatic row-version concurrency (SQL Server / PostgreSQL with `rowversion` or `xmin`):
-
-```csharp
-public class Order
-{
-    public int Id { get; set; }
-    public string Status { get; set; } = string.Empty;
-
-    [Timestamp]
-    public byte[] RowVersion { get; set; } = [];
-}
-```
-
-Use `[ConcurrencyCheck]` to protect individual properties without a row version column:
-
-```csharp
-public class Product
-{
-    public int Id { get; set; }
-
-    [ConcurrencyCheck]
-    public decimal Price { get; set; }
-}
-```
-
-Or configure via fluent API:
-
-```csharp
-modelBuilder.Entity<Order>()
-    .Property(o => o.RowVersion)
-    .IsRowVersion();
-
-modelBuilder.Entity<Product>()
-    .Property(p => p.Price)
-    .IsConcurrencyToken();
-```
-
-Catch `DbUpdateConcurrencyException` at the call site and implement a retry or conflict-resolution strategy:
-
-```csharp
-try
-{
-    await context.SaveChangesAsync();
-}
-catch (DbUpdateConcurrencyException ex)
-{
-    // Reload the entity and resolve the conflict, or inform the user
-    await ex.Entries.Single().ReloadAsync();
-}
-```
diff --git a/.claude/skills/dotnet-fundamentals/SKILL.md b/.claude/skills/dotnet-fundamentals/SKILL.md
deleted file mode 100644
index 3a643cd3..00000000
--- a/.claude/skills/dotnet-fundamentals/SKILL.md
+++ /dev/null
@@ -1,41 +0,0 @@
----
-name: dotnet-fundamentals
-description: Applies modern .NET fundamentals — dependency injection, Options pattern, configuration, and modern C# idioms. Use when registering services in any .NET host (ASP.NET Core, Worker Service, Console, MAUI), binding configuration with IOptions<T>, choosing DI lifetimes, configuring appsettings.json / User Secrets / environment variables, or applying primary constructors, required properties, nullable reference types, and CancellationToken propagation.
----
-
-# Modern .NET Fundamentals
-
-## When to Use
-
-- Working with .NET/C# Code
-- Registering services in any `IServiceCollection` (ASP.NET Core, Worker Service, Console app, MAUI, library DI extension methods)
-- Choosing a DI lifetime (Transient, Scoped, Singleton) or registering keyed services (.NET 8+)
-- Binding configuration sections to a strongly-typed Options class
-- Setting up `appsettings.json`, environment-specific overrides, User Secrets, or environment variables
-- Adopting primary constructors, `required` properties, nullable reference types, or `CancellationToken` propagation in new code
-
-## Core Principles
-
-- This skill is **technology-agnostic across .NET hosts**. ASP.NET Core, EF Core, and SDK builders all sit on top of these fundamentals.
-- **Interface-first registration** — register services via their abstraction (`AddScoped<IFoo, Foo>()`), not the concrete type. Enables substitution and testing.
-- **No service locator** — never inject `IServiceProvider` into business logic. Constructor-inject the dependencies you actually need.
-- **Options over constructor parameters for configuration** — bind config sections to `IOptions<T>`, do not pass raw `IConfiguration` values around.
-- **Fail fast** — use `ValidateDataAnnotations().ValidateOnStart()` so misconfiguration surfaces at startup, not at first use.
-- **Immutable configuration** — Options classes use `required` properties and `init`-only setters.
-- **Cancellation flows everywhere** — every async method takes a `CancellationToken` with default as its last parameter and forwards it.
-
-## Reference Index
-
-- **[dependency-injection.md](references/dependency-injection.md)** — `IServiceCollection` registration, lifetimes, keyed services, interface-based registration, anti-service-locator
-- **[options-pattern.md](references/options-pattern.md)** — `IOptions<T>` vs `IOptionsMonitor<T>` vs `IOptionsSnapshot<T>`, `BindConfiguration`, `ValidateDataAnnotations`, `ValidateOnStart`
-- **[configuration.md](references/configuration.md)** — `appsettings.json` and environment overrides, User Secrets, environment variables, production secret stores
-- **[modern-patterns.md](references/modern-patterns.md)** — primary constructors, `required` / `init`-only properties, nullable reference types, `CancellationToken` propagation
-
-## Related Skills
-
-- **dotnet-aspnet** — Builds the HTTP layer (controllers, minimal APIs, middleware, routing, auth, ProblemDetails) on an ASP.NET Core host
-- **dotnet-sdk-builder** — Generates .NET SDK / client libraries (DI extension methods, typed HTTP clients, typed Options, typed exceptions)
-- **dotnet-ef-core** — Entity Framework Core data access (DbContext, entities, LINQ, migrations); registered via DI and configured via Options
-- **dotnet-reviewer** — Structured .NET code review producing a severity-tagged Markdown report
-- **dotnet-tester** — Writes and runs C#/.NET unit tests (xUnit, FakeItEasy, AwesomeAssertions) and identifies missing test cases
-- **dotnet-nuget-manager** — Use whenever NuGet packages are added, removed, or updated in a project (dotnet CLI, central version management, version verification)
diff --git a/.claude/skills/dotnet-fundamentals/references/configuration.md b/.claude/skills/dotnet-fundamentals/references/configuration.md
deleted file mode 100644
index 8a4c529f..00000000
--- a/.claude/skills/dotnet-fundamentals/references/configuration.md
+++ /dev/null
@@ -1,79 +0,0 @@
-# Configuration
-
-Configuration in .NET is layered — later sources override earlier ones. The default `HostApplicationBuilder` order is:
-
-1. `appsettings.json`
-2. `appsettings.{Environment}.json` (e.g. `appsettings.Development.json`)
-3. User Secrets (Development only)
-4. Environment variables
-5. Command-line arguments
-
-The first source that supplies a key wins for that key; sources don't merge sections deeply, they override per leaf value.
-
-## `appsettings.json`
-
-Use for defaults that ship with the application:
-
-```json
-{
-  "Smtp": {
-    "Host": "smtp.example.com",
-    "Port": 587
-  },
-  "Logging": {
-    "LogLevel": {
-      "Default": "Information"
-    }
-  }
-}
-```
-
-Use `appsettings.{Environment}.json` for environment-specific overrides:
-
-```json
-// appsettings.Development.json
-{
-  "Smtp": { "Host": "localhost" }
-}
-```
-
-The active environment is set via `DOTNET_ENVIRONMENT` (generic host) or `ASPNETCORE_ENVIRONMENT` (ASP.NET Core).
-
-## User Secrets
-
-For local development secrets, never commit them. Initialize once per project:
-
-```bash
-dotnet user-secrets init
-dotnet user-secrets set "Smtp:Password" "dev-password"
-```
-
-User Secrets are stored outside the project directory (in `~/.microsoft/usersecrets/<UserSecretsId>/secrets.json`) and are only loaded in the Development environment.
-
-## Environment Variables
-
-Use for production secrets and container/Kubernetes deployments. Nested keys use `__` (double underscore) as separator:
-
-```bash
-export Smtp__Host=smtp.prod.example.com
-export Smtp__Password=$(cat /run/secrets/smtp-password)
-```
-
-The `__` separator is portable (works on Linux, macOS, Windows). `:` is also accepted but is not valid in environment variable names on Linux.
-
-## Production Secret Stores
-
-For production, integrate a real secret store rather than environment variables when secrets need rotation, auditing, or RBAC:
-
-- **Azure Key Vault** — `AddAzureKeyVault(...)` from `Azure.Extensions.AspNetCore.Configuration.Secrets`
-- **AWS Secrets Manager** — via `AWSSDK.Extensions.NETCore.Setup`
-- **HashiCorp Vault** — via `VaultSharp` plus a custom configuration provider
-
-These plug into the same `IConfiguration` pipeline, so consuming code keeps using `IOptions<T>` — only the registration in `Program.cs` differs.
-
-## Anti-Patterns
-
-- **Hard-coded secrets** — never commit a real password, API key, or connection string to source control. Local defaults should point at obviously-fake values.
-- **`IConfiguration` injected into business logic** — bind to a typed Options class instead. Business logic should never know about configuration providers.
-- **`config["Foo:Bar"]` indexing across the codebase** — magic strings + no validation. Bind once, inject `IOptions<T>`.
-- **Per-environment code branching** — if behavior differs between Development and Production, model it as configuration, not as `if (env.IsDevelopment())` branches scattered through services.
diff --git a/.claude/skills/dotnet-fundamentals/references/dependency-injection.md b/.claude/skills/dotnet-fundamentals/references/dependency-injection.md
deleted file mode 100644
index 330f0b8f..00000000
--- a/.claude/skills/dotnet-fundamentals/references/dependency-injection.md
+++ /dev/null
@@ -1,81 +0,0 @@
-# Dependency Injection
-
-## Registration
-
-Register services on the host's `IServiceCollection`. The same API applies to ASP.NET Core (`builder.Services`), Worker Services, Console apps using `HostApplicationBuilder`, and library extension methods (`public static IServiceCollection AddMyFeature(this IServiceCollection services)`).
-
-```csharp
-services.AddScoped<IOrderService, OrderService>();
-services.AddSingleton<IClock, SystemClock>();
-services.AddTransient<IEmailFormatter, EmailFormatter>();
-```
-
-- Register services in `Program.cs` or via extension methods (`AddApplicationServices()`, `AddPersistence()`, etc.) to keep `Program.cs` lean.
-- Prefer interface-based registration for testability — register against the abstraction, not the concrete type.
-
-## Lifetimes
-
-- **Transient** — Stateless, lightweight services. New instance per resolution.
-- **Scoped** — One instance per logical operation (per HTTP request in ASP.NET Core, per `IServiceScope` in worker scenarios). Typical for `DbContext`, unit-of-work, and per-request caches.
-- **Singleton** — Thread-safe shared state (caches, configuration providers, expensive-to-build clients). Must be safe for concurrent use.
-
-Lifetime mismatches (e.g. a Singleton capturing a Scoped service) are a common bug — `ValidateScopes` and `ValidateOnBuild` catch this at startup.
-
-```csharp
-var host = Host.CreateApplicationBuilder()
-    .ConfigureContainer<IServiceCollection>((ctx, services) =>
-    {
-        // Register here
-    })
-    .Build();
-```
-
-For ASP.NET Core, scope validation is on by default in Development. For other hosts, enable it explicitly via `ServiceProviderOptions`.
-
-## Keyed Services (.NET 8+)
-
-Use keyed services when multiple implementations of the same interface need to coexist and be selected by key:
-
-```csharp
-services.AddKeyedScoped<IPaymentGateway, StripeGateway>("stripe");
-services.AddKeyedScoped<IPaymentGateway, PayPalGateway>("paypal");
-
-public class CheckoutHandler(
-    [FromKeyedServices("stripe")] IPaymentGateway stripe,
-    [FromKeyedServices("paypal")] IPaymentGateway paypal)
-{
-    // ...
-}
-```
-
-## Anti-Patterns
-
-- **Service locator** — Do not inject `IServiceProvider` into business logic and resolve dependencies at runtime. Constructor-inject the specific dependencies you need.
-- **Capturing scoped services in singletons** — A singleton holding a reference to a scoped service leaks the scoped instance and causes use-after-dispose bugs. Use `IServiceScopeFactory` to create a fresh scope when needed.
-- **Concrete-type registration when an interface exists** — Registering `services.AddScoped<OrderService>()` instead of `services.AddScoped<IOrderService, OrderService>()` defeats substitution and testing.
-- **Static state / singletons outside DI** — All cross-cutting state goes through DI. No `public static` mutable state.
-
-## Library Extension Method Pattern
-
-When shipping a NuGet library that registers services for consumers, expose a single extension method:
-
-```csharp
-public static class MyFeatureServiceCollectionExtensions
-{
-    public static IServiceCollection AddMyFeature(
-        this IServiceCollection services,
-        Action<MyFeatureOptions>? configure = null)
-    {
-        services.AddOptions<MyFeatureOptions>()
-            .BindConfiguration(MyFeatureOptions.SectionName)
-            .ValidateDataAnnotations()
-            .ValidateOnStart();
-
-        if (configure is not null)
-            services.Configure(configure);
-
-        services.AddScoped<IMyFeatureService, MyFeatureService>();
-        return services;
-    }
-}
-```
diff --git a/.claude/skills/dotnet-fundamentals/references/modern-patterns.md b/.claude/skills/dotnet-fundamentals/references/modern-patterns.md
deleted file mode 100644
index c8f3e043..00000000
--- a/.claude/skills/dotnet-fundamentals/references/modern-patterns.md
+++ /dev/null
@@ -1,87 +0,0 @@
-# Modern C# / .NET Patterns
-
-Conventions for code written against current .NET. Use these consistently in new code; match existing project style if it predates these features.
-
-## Primary Constructors (C# 12)
-
-- For middleware, inject scoped services via `InvokeAsync` parameters, not the primary constructor.
-
-## `required` Properties + `init`-Only Setters
-
-Force callers to supply mandatory values at object initialization; prevent mutation afterward.
-
-```csharp
-public record CreateOrderRequest
-{
-    public required string CustomerId { get; init; }
-    public required IReadOnlyList<OrderItem> Items { get; init; }
-    public string? Notes { get; init; }
-}
-
-var req = new CreateOrderRequest
-{
-    CustomerId = "C-123",
-    Items = items,
-};
-```
-
-- Combine with `record` for value-semantics DTOs.
-- `required` runs at compile time — the compiler refuses initialization expressions that omit a required member.
-- Use `init` (not `set`) for immutable-after-construction shape.
-
-## Nullable Reference Types
-
-Enable project-wide in the `.csproj`:
-
-```xml
-<Nullable>enable</Nullable>
-```
-
-- Declare a reference type as nullable explicitly: `string?` means "may be null", `string` means "guaranteed non-null".
-- Treat nullable warnings as errors (`<TreatWarningsAsErrors>true</TreatWarningsAsErrors>`) in new projects.
-- For legacy code being migrated, use `<Nullable>annotations</Nullable>` first (annotations only, no warnings) to add types incrementally, then flip to `enable`.
-- Use the null-forgiving `!` operator only at provable-non-null boundaries (post-validation, after `ArgumentNullException.ThrowIfNull`). Do not sprinkle it to silence warnings.
-
-## `CancellationToken` Propagation
-
-Every async method takes a `CancellationToken` as its **last** parameter and forwards it to every async call it makes.
-
-```csharp
-public async Task<Order?> GetByIdAsync(Guid id, CancellationToken ct = default)
-{
-    var dto = await _db.Orders
-        .AsNoTracking()
-        .FirstOrDefaultAsync(o => o.Id == id, ct);
-    return dto is null ? null : await _mapper.MapAsync(dto, ct);
-}
-```
-
-- Parameter is named `ct` or `cancellationToken` consistently within a codebase.
-- Default to `default` only for entry points that have no caller-supplied token (e.g. CLI `Main`); library code should require the caller to pass one.
-- In ASP.NET Core, `HttpContext.RequestAborted` is automatically bound to action parameters of type `CancellationToken`.
-- Never swallow `OperationCanceledException` — let it bubble. The host treats it as expected cancellation.
-
-## File-Scoped Namespaces (C# 10)
-
-```csharp
-namespace MyCompany.MyProduct.Orders;
-
-public class OrderService { /* ... */ }
-```
-
-Default for all new files. Removes one level of indentation across the file.
-
-## `global using` Directives
-
-Centralize common imports in `GlobalUsings.cs`:
-
-```csharp
-global using System;
-global using System.Collections.Generic;
-global using System.Threading;
-global using System.Threading.Tasks;
-global using Microsoft.Extensions.DependencyInjection;
-global using Microsoft.Extensions.Options;
-```
-
-Use the SDK-provided `<ImplicitUsings>enable</ImplicitUsings>` for the default set; add project-specific globals via explicit `global using` declarations.
diff --git a/.claude/skills/dotnet-fundamentals/references/options-pattern.md b/.claude/skills/dotnet-fundamentals/references/options-pattern.md
deleted file mode 100644
index 74256cc1..00000000
--- a/.claude/skills/dotnet-fundamentals/references/options-pattern.md
+++ /dev/null
@@ -1,89 +0,0 @@
-# Options Pattern
-
-Bind configuration sections to strongly-typed classes via `Microsoft.Extensions.Options`. Validate at startup, inject by interface (`IOptions<T>` / `IOptionsMonitor<T>` / `IOptionsSnapshot<T>`).
-
-## Defining an Options Class
-
-```csharp
-public class SmtpOptions
-{
-    public const string SectionName = "Smtp";
-
-    public required string Host { get; init; }
-    public int Port { get; init; } = 587;
-    public required string Username { get; init; }
-    public required string Password { get; init; }
-}
-```
-
-- Declare `SectionName` as a `const string` on the class so consumers and tests can refer to it without magic strings.
-- Use `required` properties for values without sane defaults — binding fails clearly if a required value is missing.
-- Use `init`-only setters to keep options immutable after binding.
-
-## Registration
-
-```csharp
-services.AddOptions<SmtpOptions>()
-    .BindConfiguration(SmtpOptions.SectionName)
-    .ValidateDataAnnotations()
-    .ValidateOnStart();
-```
-
-- `BindConfiguration("Smtp")` binds the section automatically and re-binds when configuration reloads.
-- `ValidateDataAnnotations()` runs `[Required]`, `[Range]`, etc. on the options class.
-- `ValidateOnStart()` runs validation at host startup — misconfiguration surfaces immediately instead of at first use.
-
-For complex validation, implement `IValidateOptions<T>`:
-
-```csharp
-public class SmtpOptionsValidator : IValidateOptions<SmtpOptions>
-{
-    public ValidateOptionsResult Validate(string? name, SmtpOptions options)
-    {
-        if (options.Port is < 1 or > 65535)
-            return ValidateOptionsResult.Fail("Port must be 1-65535");
-        return ValidateOptionsResult.Success;
-    }
-}
-
-services.AddSingleton<IValidateOptions<SmtpOptions>, SmtpOptionsValidator>();
-```
-
-## Consuming Options
-
-| Interface | Lifetime | When to use |
-|---|---|---|
-| `IOptions<T>` | Singleton | Static configuration that does not change after startup. Cheapest. |
-| `IOptionsSnapshot<T>` | Scoped (ASP.NET Core only) | Per-request rebinding — picks up changes for each new request. |
-| `IOptionsMonitor<T>` | Singleton with change notifications | Long-lived components (background services, HTTP clients) that need to react to reloads via `OnChange`. |
-
-```csharp
-public class EmailSender(IOptions<SmtpOptions> options)
-{
-    private readonly SmtpOptions _smtp = options.Value;
-    // ...
-}
-
-public class ReloadableEmailSender(IOptionsMonitor<SmtpOptions> monitor)
-{
-    public ReloadableEmailSender(IOptionsMonitor<SmtpOptions> monitor)
-    {
-        monitor.OnChange(opts => RebuildClient(opts));
-    }
-}
-```
-
-## Named Options
-
-When the same options shape exists multiple times (e.g. multiple SMTP backends):
-
-```csharp
-services.Configure<SmtpOptions>("Primary", config.GetSection("Smtp:Primary"));
-services.Configure<SmtpOptions>("Fallback", config.GetSection("Smtp:Fallback"));
-
-public class Mailer(IOptionsMonitor<SmtpOptions> monitor)
-{
-    private readonly SmtpOptions _primary = monitor.Get("Primary");
-    private readonly SmtpOptions _fallback = monitor.Get("Fallback");
-}
-```
diff --git a/.claude/skills/dotnet-inspect/SKILL.md b/.claude/skills/dotnet-inspect/SKILL.md
deleted file mode 100644
index 699076c9..00000000
--- a/.claude/skills/dotnet-inspect/SKILL.md
+++ /dev/null
@@ -1,235 +0,0 @@
----
-name: dotnet-inspect
-description: Query .NET APIs across NuGet packages, platform libraries, and local files. Search for types, list API surfaces, compare and diff versions, find extension methods and implementors. Use whenever you need to answer questions about .NET library contents.
----
-
-# dotnet-inspect
-
-Query .NET library APIs — the same commands work across NuGet packages, platform libraries (System.*, Microsoft.AspNetCore.*), and local .dll/.nupkg files.
-
-## Quick Decision Tree
-
-- **Code broken?** → `diff --package Foo@old..new` first, then `member`
-- **What's new in a .NET preview?** → `diff --platform System.Runtime@P2..P3 --additive` per framework library
-- **What types exist?** → `type --package Foo` (discover types in a package or library)
-- **What members does a type have?** → `member Type --package Foo` (compact table by default)
-- **What does a type look like?** → `type Type --package Foo` (tree view for single type)
-- **What are the method signatures?** → `member Type --package Foo -m Method` (full signatures + docs)
-- **What is the source/IL?** → `member Type --package Foo -m Method:1 -v:d` (Source, Lowered C#, IL)
-- **Where is the source code?** → `source Type --package Foo` (SourceLink URLs), `source Type -m Member` (with line numbers)
-- **Want raw source content?** → `source Type --package Foo --cat` (fetches and prints source files)
-- **What constructors exist?** → `member 'Type<T>' --package Foo -m .ctor` (use `<T>` not `<>`)
-- **How many overloads?** → `member Type --package Foo --show-index` (shows `Name:N` indices)
-- **What does this package depend on?** → `depends --package Foo`
-- **What does this type inherit?** → `depends 'INumber<TSelf>'`
-- **Want a dependency diagram?** → `depends --mermaid` (standalone) or `depends --markdown --mermaid` (embedded)
-- **What metadata fields exist?** → `-S Section --fields "PDB*"` (structured query, no DSL)
-- **What version is available?** → `Foo --version` (cache-first), `Foo --latest-version` (always NuGet), `Foo --versions` (list all)
-
-## When to Use This Skill
-
-- **"What types are in this package?"** — `type` discovers types, `find` searches by pattern
-- **"What members does this type have?"** — `member` for methods/properties/events (docs on by default)
-- **"What changed between versions?"** — `diff` classifies breaking/additive changes
-- **"What new APIs shipped in this preview?"** — `diff --platform System.Runtime@prev..current --additive` per framework library
-- **"This code uses an old API — fix it"** — `diff` the old..new version, then `member` to see the new API
-- **"What extends this type?"** — `extensions` finds extension methods/properties (`--reachable` for transitive)
-- **"What implements this interface?"** — `implements` finds concrete types
-- **"What does this type depend on?"** — `depends` walks type hierarchy, package deps, or library refs
-- **"Show dependencies as a diagram"** — `depends --mermaid` for standalone mermaid, `--markdown --mermaid` for embedded
-- **"Where is the source code?"** — `source` returns SourceLink URLs; add member name for line numbers
-- **"What version/metadata does this have?"** — `package` and `library` inspect metadata
-- **"What version is available?"** — `Foo --version` (fast, cache-first — like `docker run`)
-- **"What's the latest on NuGet?"** — `Foo --latest-version` (always queries NuGet — like `docker pull`)
-- **"What versions exist?"** — `Foo --versions` (list all published versions)
-- **"What TFMs are available?"** — `package Foo --tfms`, then `type --package Foo --tfm net8.0`
-- **"Where is the source code?"** — `source` returns SourceLink URLs; add member name for line numbers
-- **"Show me the actual source?"** — `source Type --package Foo --cat` fetches and prints source file contents
-- **"Show me something cool"** — `demo` runs curated showcase queries
-
-## Key Patterns
-
-Default output is **markdown** — headings, tables, and field lists that render well in terminals, editors, and LLM contexts. No flags needed:
-
-```bash
-dnx dotnet-inspect -y -- member JsonSerializer --package System.Text.Json    # scan members
-dnx dotnet-inspect -y -- type --package System.Text.Json                     # scan types
-dnx dotnet-inspect -y -- diff --package System.CommandLine@2.0.0-beta4.22272.1..2.0.3  # triage changes
-```
-
-Default format is **markdown** — no flags needed. Optional formats: **oneline** (`--oneline`), **plaintext** (`--plaintext`), **json** (`--json`), **mermaid** (`--mermaid`). Verbosity (`-v:q/m/n/d`) controls which sections are included; formatter controls how they render. They compose freely — except `--oneline` and `-v` cannot be combined.
-
-```bash
-dnx dotnet-inspect -y -- member JsonSerializer --package System.Text.Json -v:d  # detailed (source/IL)
-dnx dotnet-inspect -y -- System.Text.Json -v:n --plaintext                      # all local sections, plaintext
-dnx dotnet-inspect -y -- type --package System.Text.Json --oneline              # compact columnar output
-dnx dotnet-inspect -y -- depends Stream --mermaid                               # standalone mermaid diagram
-dnx dotnet-inspect -y -- depends Stream --markdown --mermaid                    # mermaid embedded in markdown
-```
-
-Use `diff` first when fixing broken code — triage changes, then drill into specifics:
-
-```bash
-dnx dotnet-inspect -y -- diff --package System.CommandLine@2.0.0-beta4.22272.1..2.0.3  # what changed?
-dnx dotnet-inspect -y -- member Command --package System.CommandLine@2.0.3               # new API surface
-```
-
-## Platform Diffs & Release Notes
-
-For framework libraries (System.*, Microsoft.AspNetCore.*), use `--platform` instead of `--package`. This is the primary workflow for .NET release notes — diff each framework library between preview versions:
-
-```bash
-dnx dotnet-inspect -y -- diff --platform System.Runtime@P2..P3 --additive        # what's new?
-dnx dotnet-inspect -y -- diff --platform System.Net.Http@P2..P3 --additive       # per-library
-dnx dotnet-inspect -y -- diff --platform System.Text.Json@9.0.0..10.0.0          # across major versions
-```
-
-**Multi-library packages:** `diff --package` works across all libraries in a package (e.g., `Microsoft.Azure.SignalR` with multiple DLLs). For framework ref packages like `Microsoft.NETCore.App.Ref`, prefer `--platform` per-library since it resolves from installed packs.
-
-**Nightly/preview packages from custom feeds:** The `--source` flag works for version listing but not package downloads. Pre-populate the NuGet cache instead:
-
-```bash
-# Pre-populate cache (fails with NU1213 but downloads the package)
-dotnet add package Microsoft.NETCore.App.Ref --version <version> --source <feed-url>
-# Then use normally — resolves from NuGet cache
-dnx dotnet-inspect -y -- diff --platform System.Runtime@P2..P3 --additive
-```
-
-## Version Resolution (Docker-style)
-
-Version queries use Docker-like semantics: cached packages are served in under 15ms, network calls cost 1–4 seconds. Three flags, three behaviors:
-
-| Flag | Behavior | Network | Like Docker... |
-| ---- | -------- | ------- | -------------- |
-| `--version` (bare) | **Local** — returns the version from local cache | Only on cache miss | `docker run nginx` |
-| `--latest-version` | **Remote** — queries nuget.org for the absolute latest | Always | `docker pull nginx` |
-| `--versions` | **Remote** — returns every published version | Always | `docker image ls --all` |
-
-`--version` and bare-name inspection share the same cache. If `Foo --version` returns `2.0.3`, then `Foo` (or `package Foo`) will inspect that same `2.0.3` — no surprises, no extra network call. This is the fast path for most tasks.
-
-`--latest-version` and `--versions` always query nuget.org, so they reflect the latest published state. Use `--latest-version` when you need to confirm the newest version, e.g., before a dependency upgrade.
-
-```bash
-dnx dotnet-inspect -y -- Foo --version           # what's in the cache? (fast, local)
-dnx dotnet-inspect -y -- Foo --latest-version     # what's on nuget.org? (always network)
-dnx dotnet-inspect -y -- Foo --versions           # list all published versions
-dnx dotnet-inspect -y -- Foo --versions 5         # list latest 5 versions
-dnx dotnet-inspect -y -- Foo --versions --preview # include prerelease versions
-```
-
-The same flags work on the `package` subcommand:
-
-```bash
-dnx dotnet-inspect -y -- package Foo --version           # same local cache check
-dnx dotnet-inspect -y -- package Foo --latest-version     # always queries nuget.org
-dnx dotnet-inspect -y -- package Foo --versions           # list all versions
-```
-
-Version pinning with `@version` syntax:
-
-```bash
-dnx dotnet-inspect -y -- Foo@2.0.3                # pinned — no network if cached
-dnx dotnet-inspect -y -- Foo@latest               # always checks nuget.org
-dnx dotnet-inspect -y -- Foo                      # prefer cache, refresh on TTL expiry
-```
-
-**Use `--version` (not `--latest-version`) as the default.** It's fast and returns the same version that bare-name commands will use. Only reach for `--latest-version` when you need the absolute latest from nuget.org.
-
-## Structured Queries (like Go templates, without a DSL)
-
-Discover the schema, then select and project — no template language needed:
-
-```bash
-dnx dotnet-inspect -y -- System.Text.Json -D                          # list sections
-dnx dotnet-inspect -y -- System.Text.Json -D --effective              # sections with data (dry run)
-dnx dotnet-inspect -y -- library System.Text.Json -D --tree           # full schema tree
-dnx dotnet-inspect -y -- System.Text.Json -S Symbols                  # render one section
-dnx dotnet-inspect -y -- System.Text.Json -S Symbols --fields "PDB*"  # project specific fields
-dnx dotnet-inspect -y -- type System.Text.Json --columns Kind,Type    # project specific columns
-```
-
-## Mermaid Diagrams
-
-The `depends` command supports `--mermaid` for Mermaid diagram output. Two modes:
-
-| Flags | Output | Use case |
-| ----- | ------ | -------- |
-| `--mermaid` | Standalone mermaid (`graph TD`) | Pipe to `mmdc`, embed in tooling |
-| `--markdown --mermaid` | Mermaid fenced blocks inside markdown | Render in GitHub, VS Code, docs |
-
-```bash
-dnx dotnet-inspect -y -- depends Stream --mermaid                               # type hierarchy as mermaid
-dnx dotnet-inspect -y -- depends Stream --markdown --mermaid                    # embedded in markdown
-dnx dotnet-inspect -y -- depends --library System.Text.Json --mermaid           # assembly reference graph
-dnx dotnet-inspect -y -- depends --package Markout --mermaid                    # package dependency graph
-```
-
-## Search Scope
-
-Search commands (`find`, `extensions`, `implements`, `depends`) use scope flags:
-
-- **(no flags)** — all platform frameworks (runtime, aspnetcore, netstandard)
-- **`--platform`** — all platform frameworks
-- **`--extensions`** — curated Microsoft.Extensions.* packages
-- **`--aspnetcore`** — curated Microsoft.AspNetCore.* packages
-- **`--package Foo`** — specific NuGet package (combinable with scope flags)
-
-`type`, `member`, `library`, `diff` accept `--platform <name>` as a string for a specific platform library.
-
-## Command Reference
-
-| Command | Purpose |
-| ------- | ------- |
-| `type` | **Discover types** — terse output, no docs, use `--shape` for hierarchy |
-| `member` | **Inspect members** — docs on by default, supports dotted syntax (`-m Type.Member`) |
-| `find` | Search for types by glob or fuzzy match across any scope |
-| `diff` | Compare API surfaces between versions — breaking/additive classification |
-| `extensions` | Find extension methods/properties for a type (`--reachable` for transitive) |
-| `implements` | Find types implementing an interface or extending a base class |
-| `depends` | Walk dependency graphs upward — type hierarchy, package deps, or library refs |
-| `package` | Package metadata, files, versions, dependencies, `search` for NuGet discovery |
-| `library` | Library metadata, symbols, references, SourceLink audit |
-| `source` | **SourceLink URLs** — type-level or member-level (with line numbers), `--cat` to fetch content, `--verify` to check URLs |
-| `demo` | Run curated showcase queries — list, invoke, or feeling-lucky |
-
-## Filtering and Limiting
-
-```bash
-dnx dotnet-inspect -y -- type System.Text.Json -k enum               # filter by kind (type and member commands)
-dnx dotnet-inspect -y -- type System.Text.Json -t "*Converter*"      # glob filter on type names
-dnx dotnet-inspect -y -- member System.Text.Json JsonDocument -m Parse  # filter by member name
-dnx dotnet-inspect -y -- type System.Text.Json -5                    # first 5 lines (like head -5)
-dnx dotnet-inspect -y -- type System.Text.Json --tail 10             # last 10 lines (like tail -10)
-```
-
-**Do not pipe output through `head`, `tail`, or `Select-Object`.** Use built-in `--head` / `--tail`:
-
-- **`-n N`, `--head N`, or `-N`** — first N lines (like `head`). Keeps headers, truncates cleanly.
-- **`--tail N`** — last N lines (like `tail`). Buffers output, emits only the final N lines.
-- **`-m N`** (numeric) — item limit (members per kind section).
-- **`-k Kind`** — filter by kind: `class/struct/interface/enum/delegate` (type) or `method/property/field/event/constructor` (type single-type view, member).
-- **`-S Section`** — show only a specific section (glob-capable).
-
-## Key Syntax
-
-- **Generic types** need quotes: `'Option<T>'`, `'IEnumerable<T>'`
-- **Use `<T>` not `<>`** for generic types — `"Option<>"` resolves to the abstract base, `'Option<T>'` resolves to the concrete generic with constructors
-- **`type` uses `-t`** for type filtering, **`member` uses `-m`** for member filtering (not `--filter`)
-- **Dotted syntax** for `member`: `-m JsonSerializer.Deserialize` or `-m System.Text.Json.JsonSerializer.Deserialize`
-- **Diff ranges** use `..`: `--package System.Text.Json@9.0.0..10.0.0`
-- **Derived types** only show their own members — query the base type too
-
-## Installation
-
-Use `dnx` (like `npx`). Always use `-y` and `--` to prevent interactive prompts:
-
-```bash
-dnx dotnet-inspect -y -- <command>
-```
-
-## Related Skills
-
-- **[dotnet-reviewer](../dotnet-reviewer/SKILL.md)** — Uses dotnet-inspect to investigate API surface and version diffs during reviews
-- **[dotnet-sdk-builder](../dotnet-sdk-builder/SKILL.md)** — Queries types and members of existing libraries when generating SDK wrappers
-- **[dotnet-nuget-manager](../dotnet-nuget-manager/SKILL.md)** — Inspects packages before upgrading or replacing them
-- **[dotnet-aspnet](../dotnet-aspnet/SKILL.md)** — Discovers ASP.NET Core APIs across versions when migrating or adopting new features
diff --git a/.claude/skills/dotnet-nuget-manager/SKILL.md b/.claude/skills/dotnet-nuget-manager/SKILL.md
deleted file mode 100644
index df2960c3..00000000
--- a/.claude/skills/dotnet-nuget-manager/SKILL.md
+++ /dev/null
@@ -1,86 +0,0 @@
----
-name: dotnet-nuget-manager
-description: Manages NuGet packages in .NET projects and solutions. Use when adding, removing, or updating NuGet package references or versions. Enforces dotnet CLI for package operations, supports Directory.Packages.props central version management, and provides version verification workflows. Handles dotnet add/remove package, dotnet list package --outdated, and dotnet restore.
----
-
-# NuGet Manager
-
-## When to Use
-
-- Adding, removing, or updating NuGet packages in a .NET project or solution
-- Listing outdated packages and planning version bumps
-- Verifying a specific package version exists before bumping it
-- Working in a solution that uses `Directory.Packages.props` central version management
-
-## Prerequisites
-
-- .NET SDK installed (typically .NET 8.0 SDK or later, or a version compatible with the target solution).
-- `dotnet` CLI available on your `PATH`.
-- `jq` (JSON processor) — Linux/macOS; OR
-- PowerShell (`pwsh`) — Windows/cross-platform; required for version verification using `dotnet package search`.
-
-## Core Rules
-
-1.  **NEVER** directly edit `.csproj`, `.props`, or `Directory.Packages.props` files to **add** or **remove** packages. Always use `dotnet add package` and `dotnet remove package` commands.
-2.  **DIRECT EDITING** is ONLY permitted for **changing versions** of existing packages.
-3.  **VERSION UPDATES** must follow the mandatory workflow:
-    - Verify the target version exists on NuGet.
-    - Determine if versions are managed per-project (`.csproj`) or centrally (`Directory.Packages.props`).
-    - Update the version string in the appropriate file.
-    - Immediately run `dotnet restore` to verify compatibility.
-
-## Workflows
-
-### Adding a Package
-Use `dotnet add [<PROJECT>] package <PACKAGE_NAME> [--version <VERSION>]`.
-Example: `dotnet add src/MyProject/MyProject.csproj package Newtonsoft.Json`
-
-### Removing a Package
-Use `dotnet remove [<PROJECT>] package <PACKAGE_NAME>`.
-Example: `dotnet remove src/MyProject/MyProject.csproj package Newtonsoft.Json`
-
-### Updating Package Versions
-When updating a version, follow these steps:
-
-1.  **Verify Version Existence**:
-    Check if the version exists using the `dotnet package search` command with exact match and JSON formatting. 
-    Using `jq`:
-    `dotnet package search <PACKAGE_NAME> --exact-match --format json | jq -e '.searchResult[].packages[] | select(.version == "<VERSION>")'`
-    Using PowerShell:
-    `(dotnet package search <PACKAGE_NAME> --exact-match --format json | ConvertFrom-Json).searchResult.packages | Where-Object { $_.version -eq "<VERSION>" }`
-    
-2.  **Determine Version Management**:
-    - Search for `Directory.Packages.props` in the solution root. If present, versions should be managed there via `<PackageVersion Include="Package.Name" Version="1.2.3" />`.
-    - If absent, check individual `.csproj` files for `<PackageReference Include="Package.Name" Version="1.2.3" />`.
-
-3.  **Apply Changes**:
-    Modify the identified file with the new version string.
-
-4.  **Verify Stability**:
-    Run `dotnet restore` on the project or solution. If errors occur, revert the change and investigate.
-
-### Listing Outdated Packages
-
-Use `dotnet list package --outdated` to find packages with newer versions available.
-
-**Per project:**
-```bash
-dotnet list src/MyProject/MyProject.csproj package --outdated
-```
-
-**Entire solution:**
-```bash
-dotnet list package --outdated
-```
-
-The output shows the current version, the latest resolved version, and the latest available version for each package. Use this as the basis for deciding which packages to update, then follow the **Updating Package Versions** workflow for each.
-
-## Related Skills
-
-- **[dotnet-fundamentals](../dotnet-fundamentals/SKILL.md)** — Used when adding `Microsoft.Extensions.*` packages for DI, Options, and Configuration
-- **[dotnet-aspnet](../dotnet-aspnet/SKILL.md)** — Invokes this skill for health-check, resilience, and middleware packages
-- **[dotnet-sdk-builder](../dotnet-sdk-builder/SKILL.md)** — Invokes this skill in Step 7 to add SDK runtime dependencies
-- **[dotnet-reviewer](../dotnet-reviewer/SKILL.md)** — Used when a review surfaces outdated or vulnerable packages
-- **[dotnet-inspect](../dotnet-inspect/SKILL.md)** — Inspect package APIs before upgrading or replacing them
-- **[dotnet-ef-core](../dotnet-ef-core/SKILL.md)** — Adds EF Core providers, Testcontainers, and SQLite packages
-
diff --git a/.claude/skills/dotnet-reviewer/SKILL.md b/.claude/skills/dotnet-reviewer/SKILL.md
deleted file mode 100644
index 63d6f97a..00000000
--- a/.claude/skills/dotnet-reviewer/SKILL.md
+++ /dev/null
@@ -1,138 +0,0 @@
----
-name: dotnet-reviewer
-description: Performs structured code reviews on .NET 10+ projects. Reviews either uncommitted working-tree changes or committed changes on the current feature branch (vs. main). Produces a Markdown report under docs/reviews/ with severity-tagged findings ([Critical|Major|Minor|Suggestion|Nitpick][Security|Performance|Architecture|Code-Quality|Tests|.NET-Idioms]) and fix suggestions. Must NOT activate on generic "review my code" requests; other-language reviewers must not be hijacked.
----
-
-# dotnet-reviewer
-
-Structured code review for .NET 10+ projects.
-
-## When to Use This Skill
-
-A Code review for a .NET 10+ project is needed.
-The user may add language preferences (e.g., "in German") — apply that to the report only. The skill itself remains in English.
-
-## Prerequisites
-
-- `git` repo with `main` branch (for branch mode).
-- `dotnet ≥ 10` SDK if any of build/format/test will run.
-- `bash` 3.2+ available (macOS default works).
-- `python3` available (used by scripts for safe JSON encoding).
-
-## Workflow
-
-Follow these steps in order.
-
-### Step 1 — Interactive prompt
-
-Ask the user three things:
-
-1. **Mode:** `uncommitted` (working-tree vs HEAD, includes staged/unstaged/untracked) or `branch` (current branch vs `main`).
-2. **Tools:** for each of `build`, `format`, `test` — yes or no. Default no for all three.
-3. **Report language:** default English. If they want another language, capture it.
-
-Validate inputs against the whitelist. Re-prompt on invalid input.
-
-### Step 2 — Detect .NET version
-
-Run `scripts/detect-dotnet-version.sh --repo-root <repo>`.
-
-- Exit 0: parse JSON `{sdk, target_frameworks, project_files}`. Pick the highest `net<N>.0` from `target_frameworks` to drive checklist selection.
-- Exit 4 (SDK < 10 or none): abort. Tell the user "this skill targets .NET 10+; detected `<X>`."
-- Exit 5 (malformed): show offending file. Ask the user whether to proceed without version-awareness. If yes, fall back to general checklists only.
-- Exit 2 (not a directory) or 1 (usage): bug — report and abort.
-
-### Step 3 — Collect diff
-
-Run `scripts/collect-diff.sh --repo-root <repo> --mode <mode> --baseline main`.
-
-- Exit 0 with `files == 0`: report "no changes to review" and exit.
-- Exit 0 with `files > 0`: continue.
-- Exit 2: not a git repo — abort.
-- Exit 3 (branch mode, missing `main`): abort, tell user.
-
-### Step 4 — Large-diff strategy gate
-
-If `loc > 2000` OR `files > 50`, ask the user to choose:
-
-- **(B) Review everything** — note token cost in report header.
-- **(C) Prioritize** — review files matching `*Service.cs`, `*Controller.cs`, files without sibling `*.Tests/*Tests.cs` first; summarize the rest.
-- **(D) Chunk file-by-file** — review each file independently; group findings by file.
-
-If C is chosen but no files match the priority heuristics, fall back to D and note the fallback transparently in the report.
-
-### Step 5 — Run requested tool checks
-
-For each tool the user selected, invoke `scripts/run-checks.sh --repo-root <repo>` with the appropriate flag(s). Parse JSON.
-
-If a tool isn't installed, the script reports the failure inside the JSON — log "X not available, skipping" and continue. Don't abort.
-
-### Step 6 — Review
-
-Walk the diff against:
-1. The version-specific checklist (`references/review-checklist-net<N>.md`).
-2. `references/review-checklist-security.md`.
-3. `references/review-checklist-performance.md`.
-4. `references/review-checklist-architecture.md`.
-5. `references/review-checklist-code-quality.md`.
-
-Fold tool findings into the issue list using the severity mapping defined in `references/severity-taxonomy.md`:
-- `dotnet build` errors → Critical
-- `dotnet build` warnings → Minor
-- `dotnet test` failures → Critical
-- `dotnet format` violations → Suggestion
-
-Each finding MUST include a fix suggestion as a code block (`csharp` fenced) — no auto-patching.
-
-### Step 7 — Render report
-
-Generate the report following `references/report-format.md` exactly:
-- Title + metadata block
-- Detailed Executive Summary (counts, top-3 risks, LOC, scope)
-- Findings ordered by severity desc, then file path asc
-- Tool Output Appendix
-
-### Step 8 — Write report
-
-Path: `docs/reviews/YYYY-MM-DD-<branch>-<mode>.md`. Branch name is sanitized (replace `/` with `-`).
-
-If the path exists, append `-2`, `-3`, … until unique. Create `docs/reviews/` if missing. **Never auto-commit. Never overwrite.**
-
-Output to chat: the file path and a one-line summary (e.g., `"Wrote review with 2 Critical, 5 Major findings to docs/reviews/…"`).
-
-## Output Contract
-
-- Single Markdown file under `docs/reviews/`.
-- Format strictly per `references/report-format.md`.
-- Severity and area tags from `references/severity-taxonomy.md`.
-
-## Resource Index
-
-- `scripts/detect-dotnet-version.sh` — SDK / target framework detection
-- `scripts/collect-diff.sh` — diff collection with exclusions
-- `scripts/run-checks.sh` — optional dotnet build/format/test
-- `references/severity-taxonomy.md`
-- `references/report-format.md`
-- `references/review-checklist-net10.md`
-- `references/review-checklist-security.md`
-- `references/review-checklist-performance.md`
-- `references/review-checklist-architecture.md`
-- `references/review-checklist-code-quality.md`
-
-## Things This Skill Never Does
-
-- Auto-patches or auto-commits the report.
-- Bypasses git hooks (`--no-verify`, `--no-gpg-sign`).
-- Runs destructive operations as "fixes" (no `git reset`, no deletions).
-- Includes secrets in logs or the report.
-- Reviews .NET versions below 10 — aborts with a clear message.
-
-## Related Skills
-
-- **[dotnet-fundamentals](../dotnet-fundamentals/SKILL.md)** — Review findings reference DI lifetime, Options, and configuration best practices
-- **[dotnet-xmldocs](../dotnet-xmldocs/SKILL.md)** — Code-quality checklist references XML documentation conventions
-- **[dotnet-tester](../dotnet-tester/SKILL.md)** — Test-quality findings reference this skill's expectations
-- **[dotnet-ef-core](../dotnet-ef-core/SKILL.md)** — EF Core findings reference these data-access best practices
-- **[dotnet-aspnet](../dotnet-aspnet/SKILL.md)** — ASP.NET Core findings reference this skill's conventions
-- **[dotnet-nuget-manager](../dotnet-nuget-manager/SKILL.md)** — Surfaced outdated/vulnerable packages are addressed via this skill
-- **[dotnet-inspect](../dotnet-inspect/SKILL.md)** — Used to investigate API surface and version diffs during review
diff --git a/.claude/skills/dotnet-reviewer/references/report-format.md b/.claude/skills/dotnet-reviewer/references/report-format.md
deleted file mode 100644
index 301d3e9b..00000000
--- a/.claude/skills/dotnet-reviewer/references/report-format.md
+++ /dev/null
@@ -1,78 +0,0 @@
-# Report Format
-
-The reviewer writes one Markdown file to `docs/reviews/YYYY-MM-DD-<branch>-<mode>.md`.
-Never overwrite — append `-2`, `-3`, … on collision. Never auto-commit.
-
-## Required Sections
-
-1. Title + metadata block
-2. Executive Summary (detailed)
-3. Findings, ordered by severity desc, then by file path
-4. Tool Output Appendix (if any tool ran)
-
-## Skeleton
-
-```markdown
-# .NET Code Review — <branch> (<mode>)
-
-**Date:** YYYY-MM-DD
-**Mode:** uncommitted | branch (vs. main)
-**Detected SDK:** 10.0.x
-**Target Framework(s):** net10.0, …
-**Tools run:** build=Y/N · format=Y/N · test=Y/N
-**Exclusions:** .gitignore, *.min.js, wwwroot/lib/**
-**Review strategy:** full | prioritized | chunked
-**Diff size:** <files> files, <loc> changed LOC
-
-## Executive Summary
-
-| Severity | Count |
-|---|---|
-| Critical | N |
-| Major | N |
-| Minor | N |
-| Suggestion | N |
-| Nitpick | N |
-
-**Top risks:**
-1. <one line>
-2. <one line>
-3. <one line>
-
-**Overall:** <1–2 sentence assessment>
-
-## Findings
-
-### [Critical][Security] src/Api/UserController.cs:42
-<one-line description>
-
-<recommendation paragraph>
-
-```csharp
-// fix suggestion
-```
-
-### [Major][Performance] src/Data/Repo.cs:88
-…
-
-## Tool Output Appendix
-
-### dotnet build
-- 0 errors, 2 warnings (see findings above for warnings folded in).
-
-### dotnet test
-- 12 passed, 0 failed (duration: 4s).
-
-### dotnet format
-- Skipped.
-```
-
-## Rules
-
-- **Every finding MUST include a fix suggestion** as a code block. If the fix is structural (no single-snippet rewrite), describe the steps in prose and provide the most-affected snippet.
-- Do not paste raw diff content. Reference `path:line` instead.
-- File paths are repo-relative.
-- Group findings by severity desc, ties broken by file path asc.
-- Tool warnings/errors that are already covered by a hand-written finding should not be duplicated in the appendix — note "folded into findings".
-- If strategy `chunked` was used, group findings under `## Findings — <file>` subsections.
-- If strategy `prioritized` was used, list deferred files at the end as `## Files Not Reviewed in Detail`.
diff --git a/.claude/skills/dotnet-reviewer/references/review-checklist-architecture.md b/.claude/skills/dotnet-reviewer/references/review-checklist-architecture.md
deleted file mode 100644
index 773733ba..00000000
--- a/.claude/skills/dotnet-reviewer/references/review-checklist-architecture.md
+++ /dev/null
@@ -1,37 +0,0 @@
-# Review Checklist — Architecture
-
-## Layering
-
-- Domain references no infrastructure (no EF Core attributes on domain entities; no `HttpClient` in domain).
-- Application layer orchestrates — does not reach into UI/infrastructure types directly.
-- Controllers / minimal-API handlers stay thin: parse, dispatch to application service, map result.
-- Infrastructure adapters implement domain/application interfaces, not the other way around.
-
-## Dependency Direction
-
-- Outer rings depend on inner rings. Flag any inner-ring file with a `using` of an outer-ring namespace.
-- Solution structure should make this provable; if it doesn't (single project, mixed namespaces), call it out.
-
-## SOLID
-
-- **SRP:** classes that change for multiple reasons. Public surface that mixes orchestration with persistence.
-- **OCP:** strategy patterns where `if (type == X) … else if (type == Y) …` is repeated across files.
-- **LSP:** subclass that throws `NotSupportedException` on a base member.
-- **ISP:** "fat" interfaces with one consumer per method. Split or use mark-only interfaces.
-- **DIP:** new-ing dependencies inside a class instead of injecting (except for value objects).
-
-## Dependency Injection
-
-See the `dotnet-aspnet` skill (Dependency Injection + Configuration sections) for lifetime rules and the Options pattern. Reviewer-specific hook: flag DI changes that capture a `Scoped` service inside a `Singleton`, call `BuildServiceProvider()` during composition, or register `IOptions<T>` without `ValidateOnStart()`.
-
-## Pattern Consistency
-
-- New code matches the existing project pattern. If this file uses CQRS handlers and you added a controller method that bypasses them, flag it.
-- Naming consistency: `XxxService` vs. `XxxRepository` vs. `XxxHandler` — pick one and stay consistent within a bounded context.
-- New pattern introductions (e.g., switching from MediatR to direct calls) need an architectural rationale; flag if introduced silently.
-
-## Module Boundaries
-
-- Each project (.csproj) has a clear purpose. Flag projects whose name and contents have drifted.
-- Public API of a project is intentional — `internal` over `public` unless cross-project consumption is required.
-- `InternalsVisibleTo` only for tests; flag if used to share types with non-test projects.
diff --git a/.claude/skills/dotnet-reviewer/references/review-checklist-code-quality.md b/.claude/skills/dotnet-reviewer/references/review-checklist-code-quality.md
deleted file mode 100644
index ada47793..00000000
--- a/.claude/skills/dotnet-reviewer/references/review-checklist-code-quality.md
+++ /dev/null
@@ -1,57 +0,0 @@
-# Review Checklist — Code Quality
-
-## Naming
-
-- Methods are verbs. Properties are nouns. Async methods end in `Async`.
-- No Hungarian notation (`strName`, `iCount`).
-- Booleans read as questions: `IsValid`, `HasItems`, `CanRetry`.
-- Acronyms: `Url`, `Id`, `Api` (PascalCase per .NET conventions, not `URL`/`ID`/`API`).
-- Type parameters: `T`, or `TKey`/`TValue` — descriptive when more than one.
-
-## Nullability
-
-- `<Nullable>enable</Nullable>` is on (project-level check).
-- No `!` (null-forgiving operator) without a comment explaining why.
-- No `#nullable disable` regions in new code.
-- API surface honors nullability annotations — methods returning `T?` actually return null in some path.
-
-## Complexity
-
-- Methods over ~30 lines or with 4+ levels of nesting deserve a closer look.
-- A `switch` with more than ~7 arms over the same value usually wants polymorphism or a lookup table.
-- Boolean parameters often hide two methods — flag and suggest splitting.
-
-## Exception Handling
-
-- Catch the specific exception type, not `Exception`. `catch (Exception)` requires justification.
-- Never swallow exceptions silently. Logging counts only if the log line carries enough context to diagnose.
-- Don't use exceptions for control flow.
-- Wrap third-party exceptions at the boundary; do not leak them into domain code.
-
-## IDisposable / IAsyncDisposable
-
-- `using` (or `using` declarations) for every `IDisposable` you create.
-- `IDisposable` types as fields require the owning class to also be disposable.
-- `IAsyncDisposable` consumed with `await using`, not `using`.
-
-## Dead Code
-
-- Unused `using` directives → format check should catch; flag if format check is off.
-- Unreachable code (`return` followed by statements).
-- Unused private members. Public unused members may be API for a consumer — leave alone unless clearly orphaned.
-
-## Comments and Docs
-
-- Public API has XML docs, especially for libraries. See the `dotnet-xmldocs` skill for the tag conventions (`<summary>`, `<param>`, `<returns>`, `<exception>`, etc.).
-- Comments explain *why*, not *what*. Flag comments that restate the code.
-- TODOs without a ticket reference are a smell; flag.
-
-## Tests (cross-cutting)
-
-See the `dotnet-tester` skill for AAA layout, `Method_Condition_Expected` naming, mocking conventions, and edge-case coverage. Reviewer-specific hook: flag any new public behavior that ships without at least one test, and any test body containing conditional logic (`if`/`for`).
-
-## Logging
-
-- Structured logging (named placeholders), not string concatenation.
-- Log level matches consequence: `Error` for exceptions reaching the boundary, `Warning` for recoverable degraded paths, `Information` for state transitions, `Debug` for detail.
-- No PII in logs (email, user names, full request bodies) without a redaction strategy.
diff --git a/.claude/skills/dotnet-reviewer/references/review-checklist-net10.md b/.claude/skills/dotnet-reviewer/references/review-checklist-net10.md
deleted file mode 100644
index 8c67a22e..00000000
--- a/.claude/skills/dotnet-reviewer/references/review-checklist-net10.md
+++ /dev/null
@@ -1,30 +0,0 @@
-# Review Checklist — .NET 10
-
-Apply when `detect-dotnet-version.sh` reports `target_frameworks` containing `net10.0`.
-
-## Language Idioms
-
-- **Primary constructors** — prefer over redundant private fields when the parameter is used directly. Flag: legacy `ctor + private readonly field` pattern in new code.
-- **Collection expressions** — `[1, 2, 3]` over `new[] { 1, 2, 3 }` and `new List<int> { 1, 2, 3 }`. Flag: verbose collection initialization.
-- **Required members** — `required` modifier replaces hand-rolled validation in constructors. Flag: throws in constructor for missing init-only properties.
-- **`field` keyword** — auto-property backing-field access (preview in 9, stable in 10). Flag: unnecessary backing field declarations.
-- **Pattern matching** — list patterns, relational patterns. Flag: chained `if (x.Length > 0 && x[0] == …)`.
-- **`init` and `required` together** — for immutable POCOs.
-
-## API Idioms
-
-- `System.Threading.Lock` (new lock type) over `object`-based `lock` for new code.
-- `Random.Shared` for non-cryptographic randomness — never `new Random()` in hot path.
-- `TimeProvider` for testable time — flag direct `DateTime.UtcNow` in code that should be testable.
-- `JsonSerializerContext` (source-gen) over reflection-based `JsonSerializer` on hot paths.
-
-## Project Configuration
-
-- `<Nullable>enable</Nullable>` MUST be on. Flag projects without it.
-- `<TreatWarningsAsErrors>true</TreatWarningsAsErrors>` recommended for libraries.
-- `<LangVersion>` should not be pinned below the SDK's default unless a comment explains why.
-- `ImplicitUsings` enabled — flag stale top-of-file using directives that are already implicit.
-
-## Non-version-specific checks
-
-For language- and runtime-neutral pitfalls (`.Result`/`.Wait()`, `async void`, allocation hot spots, etc.) see `review-checklist-performance.md` and `review-checklist-code-quality.md`. This file covers only what is specific to .NET 10.
diff --git a/.claude/skills/dotnet-reviewer/references/review-checklist-performance.md b/.claude/skills/dotnet-reviewer/references/review-checklist-performance.md
deleted file mode 100644
index 15f5030b..00000000
--- a/.claude/skills/dotnet-reviewer/references/review-checklist-performance.md
+++ /dev/null
@@ -1,44 +0,0 @@
-# Review Checklist — Performance
-
-## async/await
-
-- No `.Result`, `.Wait()`, `GetAwaiter().GetResult()` in async code paths.
-- `async void` only on event handlers.
-- `Task.Run` not used to "fake async" over CPU-bound work that already runs on a worker thread (e.g., inside an existing async pipeline).
-- `ConfigureAwait(false)` on library code (not application code in modern ASP.NET).
-- `ValueTask` for hot paths that frequently complete synchronously; do not consume `ValueTask` more than once.
-- `IAsyncEnumerable<T>` for streaming; flag `List<T>` accumulation when callers can stream.
-
-## Allocations
-
-- `string` concatenation in loops → `StringBuilder` or `string.Create`.
-- `string.Format` with hot-path frequency → interpolated handlers.
-- LINQ `ToList()` / `ToArray()` immediately followed by another enumeration — extra allocation for nothing.
-- `params object[]` on hot paths — allocates per call. Use overloads.
-- Closures capturing `this` in hot lambdas — flag if measurably hot.
-- Boxing: `int` → `object`, generic constraints missing.
-
-## Span / Memory
-
-- Parsing/slicing strings: `ReadOnlySpan<char>` over `Substring`.
-- File / network buffers: `Memory<byte>` / `IBufferWriter<byte>` over `byte[]`.
-- `stackalloc` for small fixed buffers in hot paths (with bounds check).
-
-## EF Core
-
-See the `dotnet-ef-core` skill (Performance section) for the full list of EF Core performance pitfalls. Reviewer-specific hook: flag any new query against a `DbContext` that is missing `.AsNoTracking()` on a read-only path, that calls `.ToList()` before a filter, or that uses `foreach` to iterate parent entities while issuing per-row child queries (N+1).
-
-## Hot-Path Heuristics
-
-A method is "hot" if any of:
-- It's on a request path of an HTTP server.
-- It's inside a `for` / `while` over a user-sized collection.
-- It's called from `Hosted` / `BackgroundService` loops.
-- A comment or naming suggests perf-sensitive use ("inner loop", "hot", "fast path").
-
-## Concurrency
-
-- Shared mutable state without synchronization (lock, `Interlocked`, immutable patterns).
-- `ConcurrentDictionary` misuse — `GetOrAdd` with allocating factory called on every hit.
-- `SemaphoreSlim` not awaited in `using` / `try/finally`.
-- `Task.WhenAll` with thousands of tasks → bound concurrency (`Parallel.ForEachAsync` with `MaxDegreeOfParallelism`).
diff --git a/.claude/skills/dotnet-reviewer/references/review-checklist-security.md b/.claude/skills/dotnet-reviewer/references/review-checklist-security.md
deleted file mode 100644
index adc6d248..00000000
--- a/.claude/skills/dotnet-reviewer/references/review-checklist-security.md
+++ /dev/null
@@ -1,61 +0,0 @@
-# Review Checklist — Security
-
-## Input Validation
-
-- All public-API entry points (controllers, minimal-API handlers, gRPC, message handlers) validate input.
-- DTOs use `[Required]`, `[Range]`, `[StringLength]`, or FluentValidation rules. Flag DTOs without any validation.
-- Reject untrusted input before it reaches the data layer. No ad-hoc string parsing in business logic.
-
-## Injection
-
-- **SQL:** parameterized queries via EF Core LINQ, `FromSqlInterpolated`, or `DbCommand` with parameters. Flag: `FromSqlRaw` with interpolation, raw `SqlCommand` with concatenation.
-- **Command/Process:** `Process.Start` with user-controlled args — flag any concatenation; require `ProcessStartInfo` with `ArgumentList`.
-- **LDAP/XPath:** sanitized filter construction.
-- **Path traversal:** `Path.Combine` does not protect — validate that the resolved absolute path is under the intended root.
-
-## Authentication / Authorization
-
-- `[Authorize]` (or equivalent) on every non-anonymous endpoint. Flag controllers without `[Authorize]` at class level when most actions need auth.
-- Role/policy checks match the intent (no `[Authorize(Roles = "Admin")]` for user-scoped data; use resource-based authorization).
-- No "fallback to anonymous" branches in middleware.
-
-## Secrets and Credentials
-
-- No secrets in source: API keys, connection strings with passwords, JWT keys.
-- `appsettings.*.json` with secrets must be `.gitignore`-d; production uses a secret manager.
-- Logs do not include `request.Headers`, `Request.Body`, or full URLs containing tokens.
-- `HttpClient` does not blindly trust certs (`ServerCertificateCustomValidationCallback` should not return `true`).
-
-## Deserialization & Serialization
-
-- `JsonSerializer` does not deserialize untrusted JSON to `object` or `dynamic`.
-- `BinaryFormatter` is forbidden — flag any usage.
-- XML deserialization disables DTD processing (`XmlReaderSettings.DtdProcessing = Prohibit`).
-
-## Cryptography
-
-- No `MD5` or `SHA1` for security purposes. Use `SHA256+`.
-- No `RandomNumberGenerator.Create()` followed by predictable seeding — use `RandomNumberGenerator.GetBytes()`.
-- AES with `CipherMode.ECB` is forbidden. Prefer authenticated modes (`AesGcm`).
-- No hard-coded IVs or keys.
-
-## Web App Specific
-
-- CSRF protection on state-changing endpoints (cookie auth + non-GET).
-- Anti-forgery tokens for forms.
-- CORS is restrictive — `AllowAnyOrigin` only on read-only public endpoints.
-- HSTS, secure cookies, `SameSite=Lax` minimum.
-- Output encoding — Razor auto-encodes; `Html.Raw` is a code smell that needs justification.
-
-## OWASP Mapping
-
-When reporting, reference the OWASP Top 10 category in parentheses:
-- A01 Broken Access Control
-- A02 Cryptographic Failures
-- A03 Injection
-- A04 Insecure Design
-- A05 Security Misconfiguration
-- A07 Identification & Auth Failures
-- A08 Software & Data Integrity Failures
-- A09 Security Logging Failures
-- A10 SSRF
diff --git a/.claude/skills/dotnet-reviewer/references/severity-taxonomy.md b/.claude/skills/dotnet-reviewer/references/severity-taxonomy.md
deleted file mode 100644
index 9aa92c7d..00000000
--- a/.claude/skills/dotnet-reviewer/references/severity-taxonomy.md
+++ /dev/null
@@ -1,52 +0,0 @@
-# Severity Taxonomy and Area Tags
-
-Every finding is tagged `[Severity][Area]` followed by `path:line`.
-
-## Severity Levels
-
-| Severity | When to use | Examples |
-|---|---|---|
-| **Critical** | Ship-blocker. Production correctness, security, data loss, or a failing test. | SQL injection, unhandled `null` deref on hot path, failing test, build error. |
-| **Major** | Will hurt users or maintainers but not a ship-blocker. | Missing input validation on a public API, race condition under load, broken contract with caller. |
-| **Minor** | Real issue, low impact, deserves a fix in this PR. | Build warning, sloppy exception handling, missing log context, dead code. |
-| **Suggestion** | Improvement worth considering. Author can accept or reject. | Refactor opportunity, alternative idiom, better naming, format violation. |
-| **Nitpick** | Cosmetic. Author should ignore unless trivial. | Whitespace, comment phrasing, minor style preference. |
-
-## Area Tags
-
-Pick the **dominant** concern. If two apply, pick the higher-severity area.
-
-| Tag | Scope |
-|---|---|
-| `Security` | Authn/authz, input validation, secrets, injection, deserialization, crypto, OWASP. |
-| `Performance` | Allocations, async/await misuse, EF query shape, hot-path heuristics, Span/Memory. |
-| `Architecture` | Layer/dependency direction, SOLID, DI misuse, pattern consistency, coupling. |
-| `Code-Quality` | Naming, complexity, nullability, IDisposable, dead code, exception strategy. |
-| `Tests` | Missing coverage, flaky tests, weak assertions, test maintenance smell. |
-| `.NET-Idioms` | Version-specific idioms (Primary Ctors, Collection Expressions, Required Members, …). |
-
-## Mapping from Tool Outputs
-
-| Tool finding | Severity | Area |
-|---|---|---|
-| `dotnet build` error | Critical | Code-Quality (or context-driven) |
-| `dotnet build` warning | Minor | Code-Quality |
-| `dotnet test` failure | Critical | Tests |
-| `dotnet format` violation | Suggestion | Code-Quality |
-
-## Examples
-
-```
-[Critical][Security] src/Api/UserController.cs:42
-User input is concatenated directly into a SQL string.
-
-Use parameterized queries via `FromSqlInterpolated` or EF Core's LINQ.
-
-```csharp
-// before
-var users = ctx.Users.FromSqlRaw($"SELECT * FROM Users WHERE Name = '{name}'");
-
-// after
-var users = ctx.Users.FromSqlInterpolated($"SELECT * FROM Users WHERE Name = {name}");
-```
-```
diff --git a/.claude/skills/dotnet-reviewer/scripts/collect-diff.sh b/.claude/skills/dotnet-reviewer/scripts/collect-diff.sh
deleted file mode 100644
index 75ecc028..00000000
--- a/.claude/skills/dotnet-reviewer/scripts/collect-diff.sh
+++ /dev/null
@@ -1,110 +0,0 @@
-#!/usr/bin/env bash
-# collect-diff.sh — collect a unified diff in uncommitted or branch mode.
-# Output JSON: {loc, files, file_list, diff}
-# Exit codes: 0 ok (incl. empty diff), 1 usage, 2 not git, 3 baseline missing.
-
-set -u
-
-usage() {
-  cat <<EOF
-collect-diff.sh — collect a unified diff with exclusions applied
-
-Usage:
-  collect-diff.sh --repo-root <path> --mode uncommitted|branch [--baseline main]
-  collect-diff.sh --help
-
-Exclusions:
-  - .gitignore (implicit via git diff)
-  - *.min.js
-  - wwwroot/lib/**
-
-Exit codes:
-  0  success (empty diff is success)
-  1  usage error
-  2  not a git repository
-  3  baseline branch not found (branch mode only)
-EOF
-}
-
-REPO_ROOT="" MODE="" BASELINE="main"
-while [[ $# -gt 0 ]]; do
-  case "$1" in
-    --repo-root) REPO_ROOT=${2:-}; shift 2 ;;
-    --mode)      MODE=${2:-};      shift 2 ;;
-    --baseline)  BASELINE=${2:-};  shift 2 ;;
-    --help|-h)   usage; exit 0 ;;
-    *) echo "unknown arg: $1" >&2; usage >&2; exit 1 ;;
-  esac
-done
-
-[[ -n "$REPO_ROOT" && -n "$MODE" ]] || { usage >&2; exit 1; }
-case "$MODE" in uncommitted|branch) ;; *) echo "invalid --mode: $MODE" >&2; exit 1 ;; esac
-[[ -d "$REPO_ROOT/.git" ]] || { echo "not a git repository: $REPO_ROOT" >&2; exit 2; }
-
-cd "$REPO_ROOT"
-
-if [[ "$MODE" == "branch" ]]; then
-  if ! git rev-parse --verify --quiet "$BASELINE" -- >/dev/null; then
-    echo "baseline branch not found: $BASELINE" >&2
-    exit 3
-  fi
-fi
-
-# Guard: uncommitted mode against an empty repo (no HEAD yet) — abort cleanly.
-if [[ "$MODE" == "uncommitted" ]] && ! git rev-parse --verify --quiet HEAD -- >/dev/null; then
-  echo "repository has no commits yet (HEAD missing)" >&2
-  exit 3
-fi
-
-# pathspec exclusions on top of .gitignore
-EXCLUDES=(
-  ':(exclude)*.min.js'
-  ':(exclude,glob)wwwroot/lib/**'
-)
-
-if [[ "$MODE" == "uncommitted" ]]; then
-  # working-tree changes vs HEAD (staged + unstaged + untracked)
-  diff_payload=$(git diff HEAD --no-renames -- . "${EXCLUDES[@]}")
-  # Append untracked files as added-from-empty diffs
-  while IFS= read -r f; do
-    [[ -z "$f" ]] && continue
-    diff_payload+=$'\n'$(git diff --no-index --no-renames /dev/null "$f" 2>/dev/null || true)
-  done < <(git ls-files --others --exclude-standard -- . "${EXCLUDES[@]}")
-else
-  diff_payload=$(git diff "$BASELINE"...HEAD --no-renames -- . "${EXCLUDES[@]}")
-fi
-
-# Count files & LOC from the diff
-files=0
-loc=0
-file_list=()
-while IFS= read -r line; do
-  case "$line" in
-    "+++ b/"*) f=${line#+++ b/}; [[ "$f" != "/dev/null" ]] && { file_list+=("$f"); files=$((files+1)); } ;;
-    "+"*|"-"*)
-      [[ "$line" == "+++ "* || "$line" == "--- "* ]] || loc=$((loc+1))
-      ;;
-  esac
-done <<< "$diff_payload"
-
-# emit JSON (escape diff payload for JSON string)
-json_escape() {
-  printf '%s' "$1" | python3 -c 'import json,sys; print(json.dumps(sys.stdin.read()), end="")'
-}
-
-list_json() {
-  local first=1
-  printf '['
-  for v in "$@"; do
-    [[ $first -eq 0 ]] && printf ','
-    first=0
-    printf '"%s"' "${v//\"/\\\"}"
-  done
-  printf ']'
-}
-
-diff_json=$(json_escape "$diff_payload")
-fl_json=$(list_json ${file_list[@]+"${file_list[@]}"})
-
-printf '{"loc":%d,"files":%d,"file_list":%s,"diff":%s}\n' \
-  "$loc" "$files" "$fl_json" "$diff_json"
diff --git a/.claude/skills/dotnet-reviewer/scripts/detect-dotnet-version.sh b/.claude/skills/dotnet-reviewer/scripts/detect-dotnet-version.sh
deleted file mode 100644
index abc16df1..00000000
--- a/.claude/skills/dotnet-reviewer/scripts/detect-dotnet-version.sh
+++ /dev/null
@@ -1,119 +0,0 @@
-#!/usr/bin/env bash
-# detect-dotnet-version.sh — Detect .NET SDK and target frameworks in a repo.
-# Outputs JSON: {sdk, target_frameworks[], project_files[]}
-# Exit codes: 0 ok, 1 usage, 4 SDK<10, 5 malformed project file.
-
-set -u
-
-usage() {
-  cat <<EOF
-detect-dotnet-version.sh — detect .NET SDK and target frameworks
-
-Usage: detect-dotnet-version.sh --repo-root <path>
-       detect-dotnet-version.sh --help
-
-Exit codes:
-  0  success
-  1  usage error
-  4  SDK below 10 or no .NET version detected
-  5  malformed global.json or *.csproj
-EOF
-}
-
-REPO_ROOT=""
-while [[ $# -gt 0 ]]; do
-  case "$1" in
-    --repo-root) REPO_ROOT=${2:-}; shift 2 ;;
-    --help|-h)   usage; exit 0 ;;
-    *) echo "unknown arg: $1" >&2; usage >&2; exit 1 ;;
-  esac
-done
-
-[[ -n "$REPO_ROOT" ]] || { echo "missing --repo-root" >&2; usage >&2; exit 1; }
-[[ -d "$REPO_ROOT" ]] || { echo "not a directory: $REPO_ROOT" >&2; exit 1; }
-
-# --- parse global.json (optional) ---
-SDK="unknown"
-if [[ -f "$REPO_ROOT/global.json" ]]; then
-  SDK=$(grep -oE '"version"[[:space:]]*:[[:space:]]*"[^"]+"' "$REPO_ROOT/global.json" \
-        | head -n1 | sed -E 's/.*"version"[[:space:]]*:[[:space:]]*"([^"]+)".*/\1/')
-  if [[ -z "$SDK" ]]; then
-    echo "malformed global.json: $REPO_ROOT/global.json" >&2
-    exit 5
-  fi
-  sdk_major=${SDK%%.*}
-  if [[ "$sdk_major" =~ ^[0-9]+$ ]] && [[ "$sdk_major" -lt 10 ]]; then
-    echo "global.json pins SDK $SDK; this skill targets .NET 10+" >&2
-    exit 4
-  fi
-fi
-
-# --- find all *.csproj and extract <TargetFramework(s)> ---
-project_files_json="[]"
-tfms_json="[]"
-# bash 3.2 compatible: read into array via while loop
-projects=()
-while IFS= read -r line; do
-  projects+=("$line")
-done < <(find "$REPO_ROOT" -type f -name '*.csproj' -not -path '*/bin/*' -not -path '*/obj/*' 2>/dev/null | sort)
-
-if [[ ${#projects[@]} -eq 0 ]]; then
-  echo "no *.csproj found under $REPO_ROOT" >&2
-  exit 4
-fi
-
-all_tfms=()
-rel_paths=()
-
-for p in "${projects[@]}"; do
-  rel=${p#"$REPO_ROOT/"}
-  rel_paths+=("$rel")
-  # crude check for malformed XML: must contain </Project>
-  if ! grep -q '</Project>' "$p"; then
-    echo "malformed csproj: $p" >&2
-    exit 5
-  fi
-  # extract single or plural element
-  tfm_line=$(grep -oE '<TargetFramework[s]?>[^<]+</TargetFramework[s]?>' "$p" | head -n1 || true)
-  if [[ -z "$tfm_line" ]]; then
-    echo "no TargetFramework in: $p" >&2
-    exit 5
-  fi
-  tfm_value=$(printf '%s' "$tfm_line" | sed -E 's|<TargetFrameworks?>([^<]+)</TargetFrameworks?>|\1|')
-  IFS=';' read -r -a parts <<<"$tfm_value"
-  for t in "${parts[@]}"; do
-    [[ -n "$t" ]] && all_tfms+=("$t")
-  done
-done
-
-# --- enforce .NET 10+ ---
-ok=0
-for t in "${all_tfms[@]}"; do
-  if [[ "$t" =~ ^net([0-9]+)\.[0-9]+$ ]]; then
-    major=${BASH_REMATCH[1]}
-    if [[ $major -ge 10 ]]; then ok=1; break; fi
-  fi
-done
-
-if [[ $ok -eq 0 ]]; then
-  echo "no target framework >= net10.0 detected; found: ${all_tfms[*]}" >&2
-  exit 4
-fi
-
-# --- emit JSON (manual, jq-free) ---
-json_array() {
-  local first=1
-  printf '['
-  for v in "$@"; do
-    [[ $first -eq 0 ]] && printf ','
-    first=0
-    printf '"%s"' "${v//\"/\\\"}"
-  done
-  printf ']'
-}
-
-tfms_json=$(json_array "${all_tfms[@]}")
-project_files_json=$(json_array "${rel_paths[@]}")
-
-printf '{"sdk":"%s","target_frameworks":%s,"project_files":%s}\n' \
-  "$SDK" "$tfms_json" "$project_files_json"
diff --git a/.claude/skills/dotnet-reviewer/scripts/run-checks.sh b/.claude/skills/dotnet-reviewer/scripts/run-checks.sh
deleted file mode 100644
index df5fbea9..00000000
--- a/.claude/skills/dotnet-reviewer/scripts/run-checks.sh
+++ /dev/null
@@ -1,103 +0,0 @@
-#!/usr/bin/env bash
-# run-checks.sh — run optional dotnet build|format|test, emit structured JSON.
-# Output JSON: {build:{ok,warnings[],errors[]}|null, format:{ok,violations[]}|null, test:{ok,failed[],duration}|null}
-# Always exits 0 (tool failures are reported in JSON, not via exit code) unless usage error.
-# DOTNET_BIN env overrides `dotnet` (used by tests).
-
-set -u
-
-usage() {
-  cat <<EOF
-run-checks.sh — run dotnet build/format/test and emit structured JSON
-
-Usage:
-  run-checks.sh --repo-root <path> [--build] [--format] [--test]
-  run-checks.sh --help
-
-Each requested check runs independently; failures are reported in JSON, not via exit code.
-Set DOTNET_BIN to override the dotnet binary path (used by tests).
-EOF
-}
-
-REPO_ROOT=""; DO_BUILD=0; DO_FORMAT=0; DO_TEST=0
-while [[ $# -gt 0 ]]; do
-  case "$1" in
-    --repo-root) REPO_ROOT=${2:-}; shift 2 ;;
-    --build)  DO_BUILD=1; shift ;;
-    --format) DO_FORMAT=1; shift ;;
-    --test)   DO_TEST=1; shift ;;
-    --help|-h) usage; exit 0 ;;
-    *) echo "unknown arg: $1" >&2; usage >&2; exit 1 ;;
-  esac
-done
-
-[[ -n "$REPO_ROOT" && -d "$REPO_ROOT" ]] || { usage >&2; exit 1; }
-
-DOTNET=${DOTNET_BIN:-dotnet}
-
-run_dotnet() {
-  # captures stdout+stderr into the named variable, returns the exit code
-  local _out_var=$1; shift
-  local _tmp; _tmp=$(mktemp)
-  local _rc=0
-  # shellcheck disable=SC2086
-  ( cd "$REPO_ROOT" && $DOTNET "$@" ) >"$_tmp" 2>&1 || _rc=$?
-  printf -v "$_out_var" '%s' "$(cat "$_tmp")"
-  rm -f "$_tmp"
-  return "$_rc"
-}
-
-json_string() {
-  python3 -c 'import json,sys; print(json.dumps(sys.stdin.read()), end="")' <<<"$1"
-}
-
-json_string_array() {
-  local first=1
-  printf '['
-  while IFS= read -r line; do
-    [[ -z "$line" ]] && continue
-    [[ $first -eq 0 ]] && printf ','
-    first=0
-    printf '%s' "$(json_string "$line")"
-  done <<<"$1"
-  printf ']'
-}
-
-BUILD_JSON="null"
-if [[ $DO_BUILD -eq 1 ]]; then
-  out=""
-  run_dotnet out build --nologo --verbosity minimal || true
-  warnings=$(grep -E ': warning [A-Z]+[0-9]+' <<<"$out" || true)
-  errors=$(grep -E ': error [A-Z]+[0-9]+' <<<"$out" || true)
-  ok="true"; [[ -n "$errors" ]] && ok="false"
-  BUILD_JSON=$(printf '{"ok":%s,"warnings":%s,"errors":%s}' \
-    "$ok" \
-    "$(json_string_array "$warnings")" \
-    "$(json_string_array "$errors")")
-fi
-
-FORMAT_JSON="null"
-if [[ $DO_FORMAT -eq 1 ]]; then
-  out=""
-  rc=0
-  run_dotnet out format --verify-no-changes --no-restore || rc=$?
-  violations=$(grep -E '\([0-9]+,[0-9]+\)' <<<"$out" || true)
-  ok="true"; [[ $rc -ne 0 ]] && ok="false"
-  FORMAT_JSON=$(printf '{"ok":%s,"violations":%s}' \
-    "$ok" "$(json_string_array "$violations")")
-fi
-
-TEST_JSON="null"
-if [[ $DO_TEST -eq 1 ]]; then
-  out=""
-  rc=0
-  start=$(date +%s)
-  run_dotnet out test --nologo --verbosity minimal || rc=$?
-  end=$(date +%s)
-  failed=$(grep -E '^Failed:' <<<"$out" || true)
-  ok="true"; [[ $rc -ne 0 ]] && ok="false"
-  TEST_JSON=$(printf '{"ok":%s,"failed":%s,"duration":%d}' \
-    "$ok" "$(json_string_array "$failed")" "$((end - start))")
-fi
-
-printf '{"build":%s,"format":%s,"test":%s}\n' "$BUILD_JSON" "$FORMAT_JSON" "$TEST_JSON"
diff --git a/.claude/skills/dotnet-sdk-builder/SKILL.md b/.claude/skills/dotnet-sdk-builder/SKILL.md
deleted file mode 100644
index fafbf4dc..00000000
--- a/.claude/skills/dotnet-sdk-builder/SKILL.md
+++ /dev/null
@@ -1,134 +0,0 @@
----
-name: dotnet-sdk-builder
-description: Generates complete .NET SDK libraries with DI support, interfaces, typed HTTP clients, Options pattern, and typed exceptions. Use when asked to create a .NET SDK, build a .NET client library, wrap a REST API in C#, or generate a typed HTTP client. Invokes dotnet-xmldocs for XML documentation and dotnet-tester for tests.
----
-
-# .NET SDK Library Builder
-
-Generate complete, production-ready .NET SDK libraries from existing C# classes or API documentation. The output follows Microsoft's library design guidelines with full DI support, testability via interfaces, and idiomatic C# patterns.
-
-## When to Use
-
-- Building a new .NET SDK or client library from existing C# classes, OpenAPI/Swagger specs, or REST API docs
-- Wrapping a REST API in a typed C# client with DI registration (`AddXxx(...)`)
-- Generating typed HTTP clients with `IHttpClientFactory`, Options pattern, and typed exceptions
-- Producing libraries that follow Microsoft's library design guidelines (interface-first, no static state)
-
-## Workflow Overview
-
-Follow these steps in order. See the reference files for detailed guidance on each phase.
-
-### Step 1: Analyze Input
-
-Determine what the input is:
-
-- **Existing C# classes**: Read and understand the public API surface, method signatures, and responsibilities.
-- **Documentation** (OpenAPI, Swagger JSON/YAML, Markdown): Parse endpoints, request/response models, authentication, and error responses.
-
-### Step 2: Determine .NET Version
-
-1. Find all `.csproj` files in the solution.
-2. Extract the `<TargetFramework>` (or `<TargetFrameworks>`) value.
-3. If all projects use the same version → use that version.
-4. If versions differ → ask the user which version to target.
-5. Enable nullable reference types based on version:
-   - New project: add `<Nullable>enable</Nullable>` to `.csproj`.
-   - Existing project with nullable disabled: add `#pragma warning disable CS8600` / `#nullable enable` per source file, not globally.
-
-### Step 3: Determine Target Project
-
-1. If the user specified a project → use it.
-2. If no project specified → scan the solution for existing library projects (`.csproj` with no `Sdk="Microsoft.NET.Sdk.Web"` and no executable output).
-3. If a candidate project is found → **ask the user** before adding files to it.
-4. If no suitable project exists → create a new class library project. See [project-setup.md](references/project-setup.md) for conventions.
-
-### Step 4: Derive Names
-
-Derive the service/client name from the input:
-
-| Input | Derived Name Example |
-|---|---|
-| `GitHubService` class | `GitHub` → `IGitHubClient`, `GitHubClient`, `AddGitHub(...)` |
-| `PaymentsApi` class | `Payments` → `IPaymentsClient`, `PaymentsClient`, `AddPayments(...)` |
-| OpenAPI `title: Stripe API` | `Stripe` → `IStripeClient`, `StripeClient`, `AddStripe(...)` |
-
-If the name cannot be derived with confidence → ask the user.
-
-### Step 5: Ask About Resilience
-
-Before generating HTTP client code, ask:
-
-> "Should resilience policies (retry, circuit breaker) be added to the HTTP client using `Microsoft.Extensions.Http.Resilience`?"
-
-If yes → add the Polly-based resilience pipeline. See [http-client-patterns.md](references/http-client-patterns.md#resilience).
-
-### Step 6: Ask About Existing Types Used as Arguments or Return Values
-
-When wrapping existing C# classes, identify all types that appear directly as method parameters or return values in the wrapped API (e.g. classes, records, enums from the source assembly).
-
-For each such type, ask the user **once** (grouped into a single question):
-
-> "The following types from the source are used directly as parameters or return values:
-> - `OrderRequest` (argument of `PlaceOrder`)
-> - `ProductDto` (return value of `GetProduct`)
-> - ...
->
-> Should these types be passed through as-is (reused from the source), or should new equivalents be generated in the SDK library?"
-
-**Options and consequences:**
-
-| Choice | When to recommend | What to generate |
-|---|---|---|
-| **Pass through** | Source types are already in a shared/public assembly that consumers will reference | No new model code; use source types directly in the interface and implementation |
-| **Generate new types** | Source types are internal, in a non-distributable assembly, or consumers should not depend on the source project | New model classes/records in `Models/`; add mapping logic between source and SDK types in the implementation |
-
-If the user chooses to generate new types, apply the same conventions as for response DTOs (see [http-client-patterns.md](references/http-client-patterns.md)). Add a private mapping method or a `XxxMapper` internal class to the implementation to convert between the source type and the SDK type.
-
-### Step 7: Generate Library Code
-
-Generate all components. See [di-patterns.md](references/di-patterns.md) and [http-client-patterns.md](references/http-client-patterns.md) for full patterns.
-
-**Required components:**
-
-| Component | Description |
-|---|---|
-| `IXxxClient` interface | Public contract for DI and testing |
-| `XxxClient` implementation | Concrete HTTP client using `IHttpClientFactory` |
-| `XxxOptions` class | Configuration via Options pattern |
-| `XxxServiceCollectionExtensions` | `AddXxx(...)` extension method |
-| `XxxException` (+ subtypes) | Typed exceptions with diagnostic properties |
-| Model classes | Request/response DTOs |
-
-**Required NuGet packages:** `Microsoft.Extensions.Http`, `Microsoft.Extensions.Options`, `Microsoft.Extensions.DependencyInjection.Abstractions` — plus `Microsoft.Extensions.Http.Resilience` if Step 5 selected resilience. Use the `dotnet-nuget-manager` skill to add them; do not edit `.csproj` directly.
-
-### Step 8: Document the Code
-
-After generating all source files, invoke the `dotnet-xmldocs` skill to add XML documentation comments to all public types and members.
-
-### Step 9: Write Tests
-
-After documentation is complete, invoke the `dotnet-tester` skill to generate unit and integration tests for the library.
-
-## Key Design Principles
-
-- **Interface-first**: Every public service class must have a corresponding interface.
-- **Options pattern**: Configuration always via `IOptions<XxxOptions>`, never constructor parameters for config values.
-- **IHttpClientFactory**: Never inject `HttpClient` directly; always use the named/typed factory pattern.
-- **Typed exceptions**: HTTP errors become typed exceptions with status code, reason, and response body properties.
-- **Nullable**: Follow the project's nullable settings (see Step 2).
-- **No static state**: All state via DI; no singleton anti-patterns.
-
-## Additional Resources
-
-- **[di-patterns.md](references/di-patterns.md)** — DI registration, Options pattern, extension method patterns
-- **[http-client-patterns.md](references/http-client-patterns.md)** — IHttpClientFactory, typed clients, resilience, typed exceptions
-- **[project-setup.md](references/project-setup.md)** — New project structure, folder layout, `.csproj` conventions
-
-## Related Skills
-
-- **[dotnet-fundamentals](../dotnet-fundamentals/SKILL.md)** — Provides the DI, Options, and configuration patterns this skill emits in generated SDKs
-- **[dotnet-xmldocs](../dotnet-xmldocs/SKILL.md)** — Invoked in Step 8 to document generated SDKs with XML comments
-- **[dotnet-tester](../dotnet-tester/SKILL.md)** — Invoked in Step 9 to generate unit and integration tests
-- **[dotnet-nuget-manager](../dotnet-nuget-manager/SKILL.md)** — Invoked in Step 7 to add SDK runtime dependencies
-- **[dotnet-inspect](../dotnet-inspect/SKILL.md)** — Queries existing libraries when generating SDK wrappers
-- **[dotnet-aspnet](../dotnet-aspnet/SKILL.md)** — Generates typed HTTP clients for consuming ASP.NET Core APIs
diff --git a/.claude/skills/dotnet-sdk-builder/references/di-patterns.md b/.claude/skills/dotnet-sdk-builder/references/di-patterns.md
deleted file mode 100644
index c6ed0c1c..00000000
--- a/.claude/skills/dotnet-sdk-builder/references/di-patterns.md
+++ /dev/null
@@ -1,186 +0,0 @@
-# DI Patterns for .NET SDK Libraries
-
-## Service Registration Extension Method
-
-The entry point for consumers is a single `AddXxx(...)` extension method on `IServiceCollection`.
-
-### Basic Pattern (no options)
-
-```csharp
-public static class GitHubServiceCollectionExtensions
-{
-    public static IHttpClientBuilder AddGitHub(
-        this IServiceCollection services,
-        Action<GitHubOptions> configureOptions)
-    {
-        services.Configure(configureOptions);
-
-        return services
-            .AddHttpClient<IGitHubClient, GitHubClient>()
-            .ConfigureHttpClient((sp, client) =>
-            {
-                var options = sp.GetRequiredService<IOptions<GitHubOptions>>().Value;
-                client.BaseAddress = new Uri(options.BaseUrl);
-                client.DefaultRequestHeaders.Add("User-Agent", options.UserAgent);
-            });
-    }
-}
-```
-
-### Pattern with IConfiguration Section
-
-```csharp
-public static IHttpClientBuilder AddGitHub(
-    this IServiceCollection services,
-    IConfiguration configuration,
-    string sectionName = "GitHub")
-{
-    services.Configure<GitHubOptions>(configuration.GetSection(sectionName));
-
-    return services
-        .AddHttpClient<IGitHubClient, GitHubClient>()
-        .ConfigureHttpClient((sp, client) =>
-        {
-            var options = sp.GetRequiredService<IOptions<GitHubOptions>>().Value;
-            client.BaseAddress = new Uri(options.BaseUrl);
-        });
-}
-```
-
-### Pattern Supporting Both Overloads
-
-Expose both so consumers can use either approach:
-
-```csharp
-public static class GitHubServiceCollectionExtensions
-{
-    public static IHttpClientBuilder AddGitHub(
-        this IServiceCollection services,
-        Action<GitHubOptions> configureOptions)
-    {
-        ArgumentNullException.ThrowIfNull(services);
-        ArgumentNullException.ThrowIfNull(configureOptions);
-
-        services.Configure(configureOptions);
-        return services.AddGitHubCore();
-    }
-
-    public static IHttpClientBuilder AddGitHub(
-        this IServiceCollection services,
-        IConfiguration configuration,
-        string sectionName = "GitHub")
-    {
-        ArgumentNullException.ThrowIfNull(services);
-        ArgumentNullException.ThrowIfNull(configuration);
-
-        services.Configure<GitHubOptions>(configuration.GetSection(sectionName));
-        return services.AddGitHubCore();
-    }
-
-    private static IHttpClientBuilder AddGitHubCore(this IServiceCollection services)
-    {
-        return services
-            .AddHttpClient<IGitHubClient, GitHubClient>()
-            .ConfigureHttpClient((sp, client) =>
-            {
-                var options = sp.GetRequiredService<IOptions<GitHubOptions>>().Value;
-                client.BaseAddress = new Uri(options.BaseUrl);
-            });
-    }
-}
-```
-
-## Options Class
-
-```csharp
-/// <summary>Options for configuring the GitHub client.</summary>
-public sealed class GitHubOptions
-{
-    /// <summary>The base URL of the GitHub API. Defaults to https://api.github.com/.</summary>
-    public string BaseUrl { get; set; } = "https://api.github.com/";
-
-    /// <summary>The personal access token used for authentication.</summary>
-    public string? AccessToken { get; set; }
-
-    /// <summary>The User-Agent header value sent with every request.</summary>
-    public string UserAgent { get; set; } = "GitHubSdk/1.0";
-
-    /// <summary>Request timeout. Defaults to 30 seconds.</summary>
-    public TimeSpan Timeout { get; set; } = TimeSpan.FromSeconds(30);
-}
-```
-
-**Rules:**
-- Use `sealed` — options classes are never subclassed.
-- Provide sensible defaults for all non-secret properties.
-- Nullable (`string?`) for optional secrets/tokens.
-- No validation logic in the class itself; use `IValidateOptions<T>` if needed.
-
-## Options Validation (Optional but Recommended)
-
-```csharp
-internal sealed class GitHubOptionsValidator : IValidateOptions<GitHubOptions>
-{
-    public ValidateOptionsResult Validate(string? name, GitHubOptions options)
-    {
-        if (string.IsNullOrWhiteSpace(options.BaseUrl))
-            return ValidateOptionsResult.Fail($"{nameof(GitHubOptions.BaseUrl)} must not be empty.");
-
-        if (!Uri.TryCreate(options.BaseUrl, UriKind.Absolute, out _))
-            return ValidateOptionsResult.Fail($"{nameof(GitHubOptions.BaseUrl)} must be a valid absolute URI.");
-
-        return ValidateOptionsResult.Success;
-    }
-}
-```
-
-Register alongside options:
-
-```csharp
-services.AddSingleton<IValidateOptions<GitHubOptions>, GitHubOptionsValidator>();
-```
-
-## Interface Pattern
-
-```csharp
-/// <summary>Provides access to the GitHub REST API.</summary>
-public interface IGitHubClient
-{
-    /// <summary>Gets a repository by owner and name.</summary>
-    Task<Repository> GetRepositoryAsync(string owner, string repo, CancellationToken cancellationToken = default);
-
-    /// <summary>Lists public repositories for a user.</summary>
-    Task<IReadOnlyList<Repository>> ListRepositoriesAsync(string username, CancellationToken cancellationToken = default);
-}
-```
-
-**Rules:**
-- Every method returns `Task<T>` or `Task`.
-- Always include `CancellationToken cancellationToken = default` as the last parameter.
-- Interface lives in the same namespace as the implementation; no separate `Abstractions` sub-namespace unless the library is large.
-
-## Namespace Conventions
-
-```
-MyCompany.GitHub          ← root namespace
-MyCompany.GitHub.Models   ← DTOs, request/response models
-MyCompany.GitHub.Http     ← internal HTTP helpers (if needed)
-```
-
-Keep namespaces shallow. Avoid deep hierarchies for small/medium libraries.
-
-## Consumer Registration Example
-
-What the consumer writes in `Program.cs` or `Startup.cs`:
-
-```csharp
-// Action-based
-builder.Services.AddGitHub(options =>
-{
-    options.AccessToken = builder.Configuration["GitHub:AccessToken"];
-    options.UserAgent = "MyApp/1.0";
-});
-
-// Configuration-section-based
-builder.Services.AddGitHub(builder.Configuration);
-```
diff --git a/.claude/skills/dotnet-sdk-builder/references/http-client-patterns.md b/.claude/skills/dotnet-sdk-builder/references/http-client-patterns.md
deleted file mode 100644
index 80d847a0..00000000
--- a/.claude/skills/dotnet-sdk-builder/references/http-client-patterns.md
+++ /dev/null
@@ -1,254 +0,0 @@
-# HTTP Client Patterns for .NET SDK Libraries
-
-## Typed HTTP Client Implementation
-
-Always implement clients as typed HTTP clients registered via `AddHttpClient<TClient, TInterface>()`.
-
-```csharp
-internal sealed class GitHubClient : IGitHubClient
-{
-    private readonly HttpClient _httpClient;
-    private readonly IOptions<GitHubOptions> _options;
-    private readonly JsonSerializerOptions _jsonOptions;
-
-    public GitHubClient(HttpClient httpClient, IOptions<GitHubOptions> options)
-    {
-        _httpClient = httpClient;
-        _options = options;
-        _jsonOptions = new JsonSerializerOptions
-        {
-            PropertyNamingPolicy = JsonNamingPolicy.SnakeCaseLower,
-            DefaultIgnoreCondition = JsonIgnoreCondition.WhenWritingNull,
-        };
-    }
-
-    public async Task<Repository> GetRepositoryAsync(
-        string owner,
-        string repo,
-        CancellationToken cancellationToken = default)
-    {
-        ArgumentException.ThrowIfNullOrWhiteSpace(owner);
-        ArgumentException.ThrowIfNullOrWhiteSpace(repo);
-
-        var response = await _httpClient
-            .GetAsync($"repos/{owner}/{repo}", cancellationToken)
-            .ConfigureAwait(false);
-
-        await EnsureSuccessAsync(response, cancellationToken).ConfigureAwait(false);
-
-        return await response.Content
-            .ReadFromJsonAsync<Repository>(_jsonOptions, cancellationToken)
-            .ConfigureAwait(false)
-            ?? throw new GitHubException("Unexpected null response body.");
-    }
-
-    private static async Task EnsureSuccessAsync(
-        HttpResponseMessage response,
-        CancellationToken cancellationToken)
-    {
-        if (response.IsSuccessStatusCode)
-            return;
-
-        var body = await response.Content
-            .ReadAsStringAsync(cancellationToken)
-            .ConfigureAwait(false);
-
-        throw response.StatusCode switch
-        {
-            HttpStatusCode.Unauthorized => new GitHubAuthenticationException(response.StatusCode, body),
-            HttpStatusCode.NotFound     => new GitHubNotFoundException(response.StatusCode, body),
-            HttpStatusCode.TooManyRequests => new GitHubRateLimitException(response.StatusCode, body),
-            _ => new GitHubException(response.StatusCode, body),
-        };
-    }
-}
-```
-
-**Rules:**
-- Mark the class `internal sealed` — consumers use the interface.
-- Inject `HttpClient` (configured by `IHttpClientFactory`) and `IOptions<T>`.
-- Use `ConfigureAwait(false)` on all awaits.
-- Validate parameters with `ArgumentException.ThrowIfNullOrWhiteSpace` (.NET 7+) or `ArgumentNullException.ThrowIfNull`.
-- All error mapping goes through a single `EnsureSuccessAsync` helper.
-
-## Authentication Header Configuration
-
-Configure auth in the `ConfigureHttpClient` delegate inside the extension method — not inside the client class:
-
-```csharp
-.ConfigureHttpClient((sp, client) =>
-{
-    var options = sp.GetRequiredService<IOptions<GitHubOptions>>().Value;
-    client.BaseAddress = new Uri(options.BaseUrl);
-    client.Timeout = options.Timeout;
-
-    if (!string.IsNullOrWhiteSpace(options.AccessToken))
-        client.DefaultRequestHeaders.Authorization =
-            new AuthenticationHeaderValue("Bearer", options.AccessToken);
-});
-```
-
-For APIs that use API key headers:
-
-```csharp
-if (!string.IsNullOrWhiteSpace(options.ApiKey))
-    client.DefaultRequestHeaders.Add("X-Api-Key", options.ApiKey);
-```
-
-## Typed Exceptions
-
-### Base Exception
-
-```csharp
-/// <summary>The exception thrown when the GitHub API returns an error response.</summary>
-public class GitHubException : Exception
-{
-    /// <summary>The HTTP status code returned by the API.</summary>
-    public HttpStatusCode? StatusCode { get; }
-
-    /// <summary>The raw response body returned by the API, if available.</summary>
-    public string? ResponseBody { get; }
-
-    public GitHubException(string message)
-        : base(message) { }
-
-    public GitHubException(HttpStatusCode statusCode, string? responseBody = null)
-        : base($"GitHub API returned {(int)statusCode} {statusCode}.")
-    {
-        StatusCode = statusCode;
-        ResponseBody = responseBody;
-    }
-
-    public GitHubException(HttpStatusCode statusCode, string? responseBody, Exception inner)
-        : base($"GitHub API returned {(int)statusCode} {statusCode}.", inner)
-    {
-        StatusCode = statusCode;
-        ResponseBody = responseBody;
-    }
-}
-```
-
-### Specific Exception Types
-
-Create one subclass per distinct error scenario:
-
-```csharp
-/// <summary>Thrown when the GitHub API returns 401 Unauthorized.</summary>
-public sealed class GitHubAuthenticationException : GitHubException
-{
-    public GitHubAuthenticationException(HttpStatusCode statusCode, string? responseBody = null)
-        : base(statusCode, responseBody) { }
-}
-
-/// <summary>Thrown when the requested resource does not exist (404).</summary>
-public sealed class GitHubNotFoundException : GitHubException
-{
-    public GitHubNotFoundException(HttpStatusCode statusCode, string? responseBody = null)
-        : base(statusCode, responseBody) { }
-}
-
-/// <summary>Thrown when the GitHub API rate limit has been exceeded (429).</summary>
-public sealed class GitHubRateLimitException : GitHubException
-{
-    /// <summary>The UTC time at which the rate limit resets, if provided by the API.</summary>
-    public DateTimeOffset? ResetAt { get; init; }
-
-    public GitHubRateLimitException(HttpStatusCode statusCode, string? responseBody = null)
-        : base(statusCode, responseBody) { }
-}
-```
-
-**Rules:**
-- Base exception is `public class` (unsealed) — callers can catch the base type.
-- Subtypes are `public sealed class`.
-- Always include `StatusCode` and `ResponseBody` on the base type.
-- Add domain-specific properties to subtypes (e.g., `ResetAt` for rate limit).
-
-## Resilience (Polly via Microsoft.Extensions.Http.Resilience) {#resilience}
-
-Only add if the user confirms resilience is desired.
-
-```xml
-<PackageReference Include="Microsoft.Extensions.Http.Resilience" Version="*" />
-```
-
-```csharp
-private static IHttpClientBuilder AddGitHubCore(this IServiceCollection services)
-{
-    return services
-        .AddHttpClient<IGitHubClient, GitHubClient>()
-        .ConfigureHttpClient((sp, client) =>
-        {
-            var options = sp.GetRequiredService<IOptions<GitHubOptions>>().Value;
-            client.BaseAddress = new Uri(options.BaseUrl);
-        })
-        .AddStandardResilienceHandler(options =>
-        {
-            // Optional: customize defaults
-            options.Retry.MaxRetryAttempts = 3;
-            options.CircuitBreaker.SamplingDuration = TimeSpan.FromSeconds(30);
-        });
-}
-```
-
-`AddStandardResilienceHandler()` configures retry (with exponential backoff), circuit breaker, and timeout by default. Customize only when the defaults are insufficient.
-
-## JSON Serialization
-
-Use `System.Text.Json` (built-in). Configure a shared `JsonSerializerOptions` instance — do not create new instances per call:
-
-```csharp
-private static readonly JsonSerializerOptions JsonOptions = new()
-{
-    PropertyNamingPolicy = JsonNamingPolicy.SnakeCaseLower,  // for snake_case APIs
-    DefaultIgnoreCondition = JsonIgnoreCondition.WhenWritingNull,
-    NumberHandling = JsonNumberHandling.AllowReadingFromString,
-};
-```
-
-For APIs that use camelCase (most REST APIs): use `JsonNamingPolicy.CamelCase`.
-For APIs that use PascalCase: omit `PropertyNamingPolicy`.
-
-## Request/Response Models (DTOs)
-
-```csharp
-/// <summary>Represents a GitHub repository.</summary>
-public sealed class Repository
-{
-    /// <summary>The unique identifier of the repository.</summary>
-    public long Id { get; init; }
-
-    /// <summary>The name of the repository.</summary>
-    public string Name { get; init; } = string.Empty;
-
-    /// <summary>The full qualified name including owner (e.g., "owner/repo").</summary>
-    public string FullName { get; init; } = string.Empty;
-
-    /// <summary>Indicates whether the repository is private.</summary>
-    public bool Private { get; init; }
-
-    /// <summary>The URL of the repository on GitHub.</summary>
-    public string HtmlUrl { get; init; } = string.Empty;
-}
-```
-
-**Rules:**
-- Use `init` setters for immutable DTOs.
-- Initialize string properties to `string.Empty` to avoid nulls.
-- Use `sealed` for response models.
-- Use `JsonPropertyName` attribute only when the JSON key differs from the C# name AND a naming policy cannot handle it.
-
-## Pagination Pattern (if needed)
-
-For paginated APIs, return `IAsyncEnumerable<T>`:
-
-```csharp
-public interface IGitHubClient
-{
-    IAsyncEnumerable<Repository> GetAllRepositoriesAsync(
-        string username,
-        CancellationToken cancellationToken = default);
-}
-```
-
-Implementation uses `yield return` with async page fetching.
diff --git a/.claude/skills/dotnet-sdk-builder/references/project-setup.md b/.claude/skills/dotnet-sdk-builder/references/project-setup.md
deleted file mode 100644
index db141d3e..00000000
--- a/.claude/skills/dotnet-sdk-builder/references/project-setup.md
+++ /dev/null
@@ -1,123 +0,0 @@
-# New Project Setup for .NET SDK Libraries
-
-## When to Create a New Project
-
-Create a new class library project when:
-- No suitable existing project is found in the solution.
-- The user explicitly requests a new project.
-- Adding to an existing project would create an inappropriate coupling (e.g., adding an HTTP client library to a web API project).
-
-Always ask the user for confirmation before creating a new project if not explicitly instructed.
-
-## Project File Template
-
-```xml
-<Project Sdk="Microsoft.NET.Sdk">
-
-  <PropertyGroup>
-    <TargetFramework>net9.0</TargetFramework>
-    <Nullable>enable</Nullable>
-    <ImplicitUsings>enable</ImplicitUsings>
-    <LangVersion>latest</LangVersion>
-    <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
-    <GenerateDocumentationFile>true</GenerateDocumentationFile>
-    <NoWarn>$(NoWarn);CS1591</NoWarn>
-  </PropertyGroup>
-
-  <ItemGroup>
-    <PackageReference Include="Microsoft.Extensions.Http" Version="*" />
-    <PackageReference Include="Microsoft.Extensions.Options" Version="*" />
-    <PackageReference Include="Microsoft.Extensions.DependencyInjection.Abstractions" Version="*" />
-  </ItemGroup>
-
-</Project>
-```
-
-**Key settings:**
-- `<Nullable>enable</Nullable>` — always for new projects when .NET version supports it.
-- `<GenerateDocumentationFile>true</GenerateDocumentationFile>` — required for XML doc generation.
-- `<NoWarn>CS1591</NoWarn>` — suppress "missing XML comment" warnings during development; remove after `dotnet-xmldocs` skill adds all docs.
-- `<TreatWarningsAsErrors>true</TreatWarningsAsErrors>` — enforces code quality.
-- `<LangVersion>latest</LangVersion>` — enables the latest C# features for the target framework.
-
-Replace `net9.0` with the .NET version determined in Step 2 of the workflow.
-
-## Folder Structure
-
-```
-MyCompany.GitHub/
-├── MyCompany.GitHub.csproj
-├── GitHubServiceCollectionExtensions.cs   ← DI registration
-├── GitHubOptions.cs                        ← Options class
-├── IGitHubClient.cs                        ← Public interface
-├── GitHubClient.cs                         ← Internal implementation
-├── Exceptions/
-│   ├── GitHubException.cs                  ← Base exception
-│   ├── GitHubAuthenticationException.cs
-│   ├── GitHubNotFoundException.cs
-│   └── GitHubRateLimitException.cs
-└── Models/
-    ├── Repository.cs
-    ├── User.cs
-    └── ...
-```
-
-**Rules:**
-- Root of the project: extension method, options, interface, implementation.
-- `Exceptions/` folder: all exception types.
-- `Models/` folder: all DTOs (request/response models).
-- No `Services/` or `Abstractions/` sub-folders for small libraries — keep it flat.
-- For larger libraries with multiple API areas, group by area: `Repositories/`, `Users/`, etc.
-
-> This layout applies to **library** projects. Web/API applications should organize by feature/domain instead — see the `dotnet-aspnet` skill.
-
-## Naming Conventions
-
-| Artifact | Pattern | Example |
-|---|---|---|
-| Project | `Company.ServiceName` | `Acme.Stripe` |
-| Namespace | Match project name | `Acme.Stripe` |
-| Models namespace | `Company.ServiceName.Models` | `Acme.Stripe.Models` |
-| Interface | `IXxxClient` | `IStripeClient` |
-| Implementation | `XxxClient` | `StripeClient` |
-| Options | `XxxOptions` | `StripeOptions` |
-| Extension class | `XxxServiceCollectionExtensions` | `StripeServiceCollectionExtensions` |
-| Extension method | `AddXxx` | `AddStripe` |
-| Base exception | `XxxException` | `StripeException` |
-
-## Adding to Solution
-
-After creating the `.csproj`, add it to the solution:
-
-```bash
-dotnet sln add path/to/MyCompany.GitHub/MyCompany.GitHub.csproj
-```
-
-## Nullable in Existing Projects
-
-When adding files to an existing project that has `<Nullable>disable</Nullable>` or no nullable setting:
-
-Add at the top of each new source file:
-
-```csharp
-#nullable enable
-```
-
-Do **not** change the `.csproj` setting — this would affect all existing files in the project.
-
-## Global Usings (Optional)
-
-For .NET 6+, a `GlobalUsings.cs` file reduces boilerplate in every source file:
-
-```csharp
-global using System.Net;
-global using System.Net.Http;
-global using System.Net.Http.Json;
-global using System.Text.Json;
-global using System.Text.Json.Serialization;
-global using Microsoft.Extensions.DependencyInjection;
-global using Microsoft.Extensions.Http;
-global using Microsoft.Extensions.Options;
-```
-
-Create this file only when the project has more than ~5 source files that all use these namespaces.
diff --git a/.claude/skills/dotnet-tester/SKILL.md b/.claude/skills/dotnet-tester/SKILL.md
deleted file mode 100644
index 12775ff9..00000000
--- a/.claude/skills/dotnet-tester/SKILL.md
+++ /dev/null
@@ -1,140 +0,0 @@
----
-name: dotnet-tester
-description: Writes, executes, and completes unit tests for C#/.NET code using xUnit, FakeItEasy, and AwesomeAssertions. Uses a second agent to identify missing test cases. Use when asked to create .NET tests or improve test coverage.
----
-
-# .NET Tester
-
-Write comprehensive unit tests for the specified code. Follow a multi-step process with automatic identification of missing test cases.
-
-## When to Use
-
-- User asks to create unit tests, add tests, or improve test coverage for C#/.NET code
-- New C#/.NET production code lacks tests and needs them
-- An existing test suite is missing edge cases or error-path coverage
-- Working in a C# project that uses xUnit, FakeItEasy, AwesomeAssertions/FluentAssertions, NUnit, MSTest, or Moq
-
-Do **not** use this skill for non-.NET test code, or for integration tests that primarily exercise external systems without unit-level concerns.
-
-## Conventions
-
-- **Test Framework**: xUnit
-- **Mocking**: FakeItEasy
-- **Assertions**: AwesomeAssertions (a fork of FluentAssertions with identical API — use `Should()` as usual)
-- **Structure**: Each test method has Arrange/Act/Assert blocks, marked with comments
-- **Language**: English for code, comments, and test names
-- **Style**: The stack above is the default. If the project already uses a different stack (NUnit, MSTest, Moq, FluentAssertions, …), match the existing convention instead of switching.
-
-## Phase 1: Write Tests
-
-1. **Analyze code**: Read the code to be tested and understand:
-  - Public API (methods, properties)
-  - Dependencies (what needs to be mocked?)
-  - Different code paths (if/else, switch, exceptions)
-  - Edge Cases (null, empty collections, boundary values)
-
-2. **Identify test project**: Find the appropriate test project by looking for `*.Tests.csproj` files or `*Tests/` directories in the solution. Fall back to scanning for any project whose name ends in `.Tests` or `.Test`. Orient yourself to the existing project structure before adding files.
-
-3. **Create tests**: Write tests following this pattern:
-
-```csharp
-public class MyClassTests
-{
-    [Fact]
-    public void MethodName_Scenario_ExpectedBehavior()
-    {
-        // Arrange
-        var dependency = A.Fake<IDependency>();
-        A.CallTo(() => dependency.DoSomething()).Returns(expectedValue);
-        var sut = new MyClass(dependency);
-
-        // Act
-        var result = sut.MethodUnderTest(input);
-
-        // Assert
-        result.Should().Be(expectedValue);
-    }
-
-    [Theory]
-    [InlineData("input1", "expected1")]
-    [InlineData("input2", "expected2")]
-    public void MethodName_WithVariousInputs_ReturnsExpected(string input, string expected)
-    {
-        // Arrange
-        var sut = new MyClass();
-
-        // Act
-        var result = sut.MethodUnderTest(input);
-
-        // Assert
-        result.Should().Be(expected);
-    }
-}
-```
-
-4. **Cover test categories**:
-  - Happy Path (normal success case)
-  - Error handling (exceptions, invalid inputs)
-  - Null/empty inputs
-  - Boundary values (boundary conditions)
-  - Dependency behavior (mocks, different return values)
-
-## Phase 2: Execute Tests
-
-1. Run `dotnet test` in the relevant test project
-2. Analyze the results:
-  - On **failures**: Identify the cause and fix the test or test setup
-  - On **success**: Continue to Phase 3
-3. Repeat until all tests are green. Don't fakely pass tests. If a test is too complex to set up, consider if it should be refactored or if the code under test should be made more testable.
-
-## Phase 3: Identify Missing Test Cases
-
-Start a **separate agent** that reads the production code and written tests, then returns a prioritized list of missing cases:
-
-- **Edge Cases**: Null, empty strings/collections, boundary/maximum values
-- **Error Paths**: Exceptions, timeouts, dependency errors
-- **Boundary Conditions**: Off-by-one, integer overflow
-- **Interactions**: Call order, multiple/concurrent calls
-- **State Transitions**: Different initial states
-
-Format: `[HIGH/MEDIUM/LOW] MethodName - Scenario: Description`
-
-## Phase 4: Add Missing Tests
-
-1. Implement the identified missing tests (prioritized: HIGH → MEDIUM → LOW)
-2. Run `dotnet test` again
-3. Fix any errors
-4. Ensure all tests are green
-
-## Output Format
-
-At the end, provide a summary:
-
-```
-### Test Result
-
-**Phase 1**: X tests written
-**Phase 2**: All tests green ✅
-**Phase 3**: Y missing cases identified (Z High, W Medium, V Low)
-**Phase 4**: Y additional tests implemented, all green ✅
-
-**Total**: X + Y tests, all passed
-```
-
-## Important Notes
-
-- Do **not write tests for trivial getters/setters** without logic
-- Do **not write tests to check if properties are initialized correctly after construction**
-- Do **not mock value types** or simple DTOs – create real instances
-- Test **behavior**, not implementation details
-- Use **descriptive test names** in the format `MethodName_Scenario_ExpectedBehavior`
-- For `[Theory]` tests: Use `[InlineData]` for simple types, `[MemberData]` for complex objects
-- Use `A.CallTo(...).MustHaveHappened()` sparingly – only when the call is the expected behavior
-
-## Related Skills
-
-- **[dotnet-fundamentals](../dotnet-fundamentals/SKILL.md)** — Test DI-registered services using `IServiceCollection` overrides
-- **[dotnet-ef-core](../dotnet-ef-core/SKILL.md)** — DbContext-backed unit and integration tests (SQLite in-memory, Testcontainers)
-- **[dotnet-reviewer](../dotnet-reviewer/SKILL.md)** — Test-quality checks during code review
-- **[dotnet-sdk-builder](../dotnet-sdk-builder/SKILL.md)** — Invoked by it in Step 9 to generate tests for new SDK libraries
-- **[dotnet-aspnet](../dotnet-aspnet/SKILL.md)** — Unit and integration tests for ASP.NET Core endpoints
diff --git a/.claude/skills/dotnet-xmldocs/SKILL.md b/.claude/skills/dotnet-xmldocs/SKILL.md
deleted file mode 100644
index b688596b..00000000
--- a/.claude/skills/dotnet-xmldocs/SKILL.md
+++ /dev/null
@@ -1,41 +0,0 @@
----
-name: dotnet-xmldocs
-description: Adds and reviews C# XML documentation comments following Microsoft's documentation standards. Use when writing or reviewing C# code that includes public APIs, complex logic, or when documentation is missing or insufficient. Covers <summary>, <param>, <returns>, <exception>, <remarks>, and all standard XML doc tags.
----
-
-# C# Documentation Best Practices
-
-## When to Use
-
-- Writing or reviewing XML documentation comments (`///`) on C# types and members
-- Adding documentation to public APIs of a new or existing C# library
-- Reviewing missing, insufficient, or non-Microsoft-style XML docs in C# code
-- Generating documentation that feeds OpenAPI/Swagger output or NuGet symbols
-
-## General Guidelines
-
-- Public members should be documented with XML comments.
-- It is encouraged to document internal members as well, especially if they are complex or not self-explanatory.
-
-## Guidance for all APIs
-
-- Use `<summary>` to provide a brief, one sentence, description of what the type or member does. Start the summary with a present-tense, third-person verb.
-- Use `<remarks>` for additional information, which can include implementation details, usage notes, or any other relevant context.
-- Use `<see langword>` for language-specific keywords like `null`, `true`, `false`, `int`, `bool`, etc.
-- Use `<c>` for inline code snippets.
-- Use `<example>` for usage examples on how to use the member.
-  - Use `<code>` for code blocks. `<code>` tags should be placed within an `<example>` tag. Add the language of the code example using the `language` attribute, for example, `<code language="csharp">`.
-- Use `<see cref>` to reference other types or members inline (in a sentence).
-- Use `<seealso>` for standalone (not in a sentence) references to other types or members in the "See also" section of the online docs.
-- Use `<inheritdoc/>` to inherit documentation from base classes or interfaces.
-  - Unless there is major behavior change, in which case you should document the differences.
-
-## Member-Specific Rules
-
-See [member-documentation-rules.md](./references/member-documentation-rules.md) for detailed wording conventions for methods (`<param>`, `<returns>`), constructors, properties (`<value>`, Gets/Sets patterns), and exceptions (`<exception cref>`).
-
-## Related Skills
-
-- **[dotnet-aspnet](../dotnet-aspnet/SKILL.md)** — XML docs feed OpenAPI/Swagger output
-- **[dotnet-sdk-builder](../dotnet-sdk-builder/SKILL.md)** — Invokes this skill in Step 8 to document generated SDKs
-- **[dotnet-reviewer](../dotnet-reviewer/SKILL.md)** — Code-quality checklist references these conventions for public-API docs
diff --git a/.claude/skills/dotnet-xmldocs/references/member-documentation-rules.md b/.claude/skills/dotnet-xmldocs/references/member-documentation-rules.md
deleted file mode 100644
index 8f58133f..00000000
--- a/.claude/skills/dotnet-xmldocs/references/member-documentation-rules.md
+++ /dev/null
@@ -1,41 +0,0 @@
-# Member-Specific Documentation Rules
-
-## Methods
-
-- Use `<param>` to describe method parameters.
-  - The description should be a noun phrase that doesn't specify the data type.
-  - Begin with an introductory article.
-  - If the parameter is a flag enum, start the description with "A bitwise combination of the enumeration values that specifies...".
-  - If the parameter is a non-flag enum, start the description with "One of the enumeration values that specifies...".
-  - If the parameter is a Boolean, the wording should be of the form "`<see langword="true" />` to ...; otherwise, `<see langword="false" />`.".
-  - If the parameter is an "out" parameter, the wording should be of the form "When this method returns, contains .... This parameter is treated as uninitialized.".
-- Use `<paramref>` to reference parameter names in documentation.
-- Use `<typeparam>` to describe type parameters in generic types or methods.
-- Use `<typeparamref>` to reference type parameters in documentation.
-- Use `<returns>` to describe what the method returns.
-  - The description should be a noun phrase that doesn't specify the data type.
-  - Begin with an introductory article.
-  - If the return type is Boolean, the wording should be of the form "`<see langword="true" />` if ...; otherwise, `<see langword="false" />`.".
-
-## Constructors
-
-- The summary wording should be "Initializes a new instance of the <Class> class [or struct].".
-
-## Properties
-
-- The `<summary>` should start with:
-  - "Gets or sets..." for a read-write property.
-  - "Gets..." for a read-only property.
-  - "Gets [or sets] a value that indicates whether..." for properties that return a Boolean value.
-- Use `<value>` to describe the value of the property.
-  - The description should be a noun phrase that doesn't specify the data type.
-  - If the property has a default value, add it in a separate sentence, for example, "The default is `<see langword="false" />`".
-  - If the value type is Boolean, the wording should be of the form "`<see langword="true" />` if ...; otherwise, `<see langword="false" />`. The default is ...".
-
-## Exceptions
-
-- Use `<exception cref>` to document exceptions thrown by constructors, properties, indexers, methods, operators, and events.
-- Document all exceptions thrown directly by the member.
-- For exceptions thrown by nested members, document only the exceptions users are most likely to encounter.
-- The description of the exception describes the condition under which it's thrown.
-  - Omit "Thrown if ..." or "If ..." at the beginning of the sentence. Just state the condition directly, for example "An error occurred when accessing a Message Queuing API."
diff --git a/.claude/skills/dotnet/SKILL.md b/.claude/skills/dotnet/SKILL.md
deleted file mode 100644
index 6766638a..00000000
--- a/.claude/skills/dotnet/SKILL.md
+++ /dev/null
@@ -1,46 +0,0 @@
----
-name: dotnet
-description: Entry point and router for .NET and C# work — directs you to the right specialized .NET skill. Use when a request mentions .NET or C# in general but the specific tool is not obvious, or to get an overview of the available .NET skills. Routes to knowledge skills (dotnet-fundamentals, dotnet-aspnet, dotnet-ef-core, dotnet-xmldocs) and workflow skills (dotnet-sdk-builder, dotnet-tester, dotnet-reviewer, dotnet-inspect, dotnet-nuget-manager). When the matching skill is already clear, invoke that skill directly instead.
----
-
-# .NET / C# Skill Router
-
-Signpost to the specialized .NET skills. This skill holds no best-practice knowledge
-of its own — it maps a request to the appropriate specialized skill.
-
-## When to Use
-
-- A task concerns .NET or C#, but it is unclear which specialized skill applies.
-- You need an overview of the available .NET skills and their responsibilities.
-
-When the matching skill is already clear, load it directly — the router is only
-orientation, not an intermediate step.
-
-## Routing
-
-### Knowledge skills (best practices, `references/` only)
-
-| Concern | Skill |
-|---------|-------|
-| Dependency Injection, Options pattern, Configuration, modern C# idioms (for any .NET host) | `dotnet-fundamentals` |
-| ASP.NET Core Web/REST APIs: controllers, Minimal APIs, middleware, routing, model binding, validation, auth, ProblemDetails, OpenAPI, health checks, CORS, rate limiting | `dotnet-aspnet` |
-| Entity Framework Core: DbContext, entities/relationships, LINQ, migrations, repository patterns, N+1/performance | `dotnet-ef-core` |
-| C# XML doc comments (`<summary>`, `<param>`, `<returns>`, …) | `dotnet-xmldocs` |
-
-### Workflow skills (active tools, scripts, agents)
-
-| Concern | Skill |
-|---------|-------|
-| Generate a .NET SDK / client library / typed HTTP client | `dotnet-sdk-builder` |
-| Write/run unit tests (xUnit, FakeItEasy, AwesomeAssertions) | `dotnet-tester` |
-| Structured code review for .NET 10+ (explicit invocation only, see below) | `dotnet-reviewer` |
-| Query .NET APIs in NuGet packages, platform libraries, or local files | `dotnet-inspect` |
-| Manage NuGet packages (add/remove/update, `--outdated`, Central Package Management) | `dotnet-nuget-manager` |
-
-## Notes
-
-- **`dotnet-reviewer` activates only on explicit name** — the phrases
-  `dotnet-reviewer`, `dotnet code review`, or `dotnet review`. It does **not** trigger
-  on generic "review my code", and the router does not trigger it automatically.
-- **Composition:** `dotnet-sdk-builder` invokes `dotnet-xmldocs` and `dotnet-tester`;
-  `dotnet-aspnet` and `dotnet-ef-core` build on `dotnet-fundamentals`.
diff --git a/.github/agents/dotnet-developer.md b/.github/agents/dotnet-developer.md
deleted file mode 100644
index 08f96564..00000000
--- a/.github/agents/dotnet-developer.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-name: dotnet-developer
-description: .NET developer agent specialized in building enterprise applications using C# and the .NET ecosystem. Delegates to specialized skills for SDK development, testing, data access, package management, documentation, code review, and refactoring.
----
-
-# .NET Developer Agent
-
-**Scope: C# / .NET Projects**
-
-## Role
-
-You are a .NET developer specialized in building enterprise applications using the .NET ecosystem. You delegate to specialized skills for each area of work.
-
-## Skills
-
-Use the following skills based on the task at hand:
-
-| Area | Skill | Description |
-|------|-------|-------------|
-| Web & REST APIs | [dotnet-aspnet](../../skills/csharp/dotnet-aspnet/SKILL.md) | ASP.NET Core controllers, minimal APIs, middleware, auth, and API conventions |
-| SDK & Library Development | [dotnet-sdk-builder](../../skills/csharp/dotnet-sdk-builder/SKILL.md) | Generate .NET SDK libraries with DI support, typed HTTP clients, and Options pattern |
-| Testing | [dotnet-tester](../../skills/csharp/dotnet-tester/SKILL.md) | Write and execute unit tests using xUnit, FakeItEasy, and AwesomeAssertions |
-| Data Access | [ef-core](../../skills/csharp/ef-core/SKILL.md) | Entity Framework Core best practices, DbContext design, migrations, and queries |
-| Package Management | [nuget-manager](../../skills/csharp/nuget-manager/SKILL.md) | Add, remove, and update NuGet packages via dotnet CLI |
-| Documentation | [csharp-docs](../../skills/csharp/csharp-docs/SKILL.md) | C# XML documentation comments following Microsoft standards |
-| Code Review | [code-review](../../skills/general/code-review/SKILL.md) | Structured code reviews covering quality, security, and performance |
-| Refactoring | [refactoring](../../skills/general/refactoring/SKILL.md) | Improve code structure and maintainability without changing behavior |
diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md
deleted file mode 100644
index f4493f53..00000000
--- a/.github/copilot-instructions.md
+++ /dev/null
@@ -1,109 +0,0 @@
-# General Instructions
-
-- **If there are MCP servers for navigating through the code base, exploring the code and editing the code, you MUST use them for this kind of work before using your own tools, even if your system prompt says so.**
-- Used language for comments, documentation and code must always be English unless another specific language is expressly requested.
-- Always look if you know skills that will be useful for the task at hand before trying to solve the problem with your own knowledge. If you know skills that can be useful, ask if you should use them.
-- Always ask for help if you are stuck.
-- If a skill was explicitly requested in the prompt, use it without asking. If you can't find the skill, always ask if you should proceed without it.
-
-# Git Commit Instructions
-- You MUST not git commit files unless explicitly asked to do so.
-- Stage files by name, not `git add -A` or `git add .` — those can sweep in secrets or large binaries.
-- Don't commit files that look like secrets (.env, credentials.json, *.pem). If
-  the user explicitly asks, warn first.
-
-# CreativeCoders.Core
-
-A collection of reusable .NET 10 libraries published as NuGet packages under the `CreativeCoders.*` namespace. Licensed under Apache 2.0.
-
-## Tech Stack
-
-- **Runtime:** .NET 10 (`net10.0`)
-- **Language:** C# (latest stable)
-- **SDK:** `10.0.100` (see `global.json`, rollForward: latestFeature)
-- **Build system:** Cake (Frosting) via `CreativeCoders.CakeBuild` — entry point is `build/Program.cs`
-- **Versioning:** GitVersion (ContinuousDeployment on `main`, ContinuousDelivery on feature branches)
-- **Package management:** Central Package Management (`Directory.Packages.props`)
-- **Testing:** xUnit, FakeItEasy, AwesomeAssertions, coverlet
-- **CI:** GitHub Actions (ubuntu, windows, macos) — workflows in `.github/workflows/`
-- **NuGet feed:** GitHub Packages (main builds), nuget.org (release builds)
-
-## Repository Layout
-
-```
-Core.sln                     Solution file
-Directory.Build.props         Shared MSBuild properties (TargetFramework, Authors)
-Directory.Packages.props      Central NuGet version pins
-global.json                   SDK version constraint
-GitVersion.yml                Versioning configuration
-build/                        Cake Frosting build project
-  Program.cs                  Build entry point (CakeHostBuilder)
-  BuildContext.cs             Build configuration (feeds, tools, settings)
-source/                       Library source code (see below)
-tests/                        Unit/integration test projects
-samples/                      Sample applications
-.github/workflows/            CI/CD pipelines
-```
-
-## Source Libraries
-
-| Area | Projects | Purpose |
-|------|----------|---------|
-| **Core** | `CreativeCoders.Core` | Ensure guards, collections, threading, enums, reflection, IO helpers, visitor pattern, object linking, dependency trees |
-| **AspNetCore** | `.AspNetCore`, `.Blazor`, `.TokenAuth.Jwt`, `.TokenAuthApi`, `.TokenAuthApi.Jwt` | ASP.NET Core extensions, Blazor helpers, JWT token auth |
-| **Cli** | `.Cli.Core`, `.Cli.Hosting` | CLI application framework with hosting support |
-| **SysConsole** | `.SysConsole.App`, `.Core`, `.Cli.Actions`, `.Cli.Parsing`, `.CliArguments` | Console applications with Spectre.Console, argument parsing, CLI actions |
-| **Data** | `.Data`, `.Data.EfCore`, `.Data.EfCore.SqlServer`, `.Data.Nhibernate`, `.Data.NoSql`, `.Data.NoSql.LiteDb` | Data access abstractions, EF Core, NHibernate, LiteDB |
-| **Net** | `.Net`, `.Net.Avm`, `.Net.JsonRpc`, `.Net.WebApi`, `.Net.XmlRpc`, `.Net.Servers.Http.AspNetCore` | Networking utilities, JSON-RPC, XML-RPC, WebApi client, HTTP server |
-| **Messaging** | `.Messaging.Core`, `.Messaging.DefaultMediator`, `.Messaging.DefaultMessageQueue` | In-process messaging, mediator pattern, message queues |
-| **Reactive** | `.Reactive.Messaging` | Reactive Extensions-based messaging |
-| **Config** | `.Config`, `.Config.Base`, `.Config.Sources` | Configuration abstraction layer |
-| **Configuration** | `.Configuration` | Microsoft.Extensions.Configuration integration |
-| **Options** | `.Options.Core`, `.Options.Serializers`, `.Options.Storage.FileSystem` | Options pattern with persistence |
-| **DependencyInjection** | `.DependencyInjection` | DI container extensions |
-| **Scripting** | `.Scripting.Base`, `.Scripting.CSharp` | C# scripting and source code generation |
-| **CodeCompilation** | `.CodeCompilation`, `.CodeCompilation.Roslyn` | Runtime code compilation via Roslyn |
-| **DynamicCode** | `.DynamicCode.Proxying` | Dynamic proxy generation (Castle.Core) |
-| **IO** | `.IO.Archives`, `.IO.Ports` | Archive handling, serial port abstractions |
-| **Localization** | `.Localization` | Microsoft.Extensions.Localization integration |
-| **Daemon** | `.Daemon`, `.Daemon.Linux`, `.Daemon.Windows` | Cross-platform daemon/service hosting (systemd, Windows Services) |
-| **ProcessUtils** | `.ProcessUtils` | Process execution utilities |
-| **UnitTests** | `.UnitTests` | Test helper library |
-| **CakeBuild** | `.CakeBuild` | Reusable Cake Frosting build tasks |
-| **NukeBuild** | `.NukeBuild`, `.NukeBuild.Components` | Nuke build system components |
-
-## Build & Test
-
-### Development
-
-Use standard `dotnet` commands for building, testing and restoring:
-
-```bash
-dotnet restore
-dotnet build
-dotnet test
-```
-
-### Build Pipeline (Cake Frosting)
-
-The full CI pipeline uses Cake Frosting. These commands are intended for CI/CD and release workflows — not for day-to-day development:
-
-```bash
-./build.sh -t pack            # Linux/macOS
-./build.cmd -t pack           # Windows
-./build.sh -t test            # Tests with coverage
-./build.cmd -t nugetpush      # Full pipeline with NuGet push (CI only)
-```
-
-Build targets are defined in `CreativeCoders.CakeBuild` and configured in `build/BuildContext.cs`. The build uses GitVersion for automatic semantic versioning and ReportGenerator for coverage reports (output: `.tests/coverage-report`).
-
-## CI/CD Workflows
-
-| Workflow | Trigger | Purpose |
-|----------|---------|---------|
-| `main.yml` | Push to `main` | Build, test, pack, push to NuGet (Linux pushes, Windows/macOS build+test only) |
-| `pull-request.yml` | PR to `main` | Build and test on all platforms |
-| `integration.yml` | Manual/schedule | Integration testing |
-| `release.yml` | Release event | Publish to nuget.org |
-| `dependabot-auto-merge.yml` | Dependabot PRs | Auto-merge dependency updates |
-| `sync-ai-config.yml` | Config sync | Synchronize AI configuration files |
diff --git a/.github/instructions/csharp.instructions.md b/.github/instructions/csharp.instructions.md
deleted file mode 100644
index c8dd00be..00000000
--- a/.github/instructions/csharp.instructions.md
+++ /dev/null
@@ -1,89 +0,0 @@
----
-description: 'Guidelines for building C# applications'
-applyTo: '**/*.cs'
----
-
-# C# Development
-
-- Always use the latest stable C# version available in the project's target framework.
-
-## General Instructions
-
-- Use `Ensure.NotNull(...)` from `CreativeCoders.Core` for null guards
-- Use `Ensure.IsNotNullOrEmpty(...)` from `CreativeCoders.Core` for string guards for arguments that must not be empty
-- Use `Ensure.IsNotNullOrWhitespace(...)` from `CreativeCoders.Core` for string guards for arguments that must not be empty or whitespace
-- Guard arguments for public methods in libraries with `Ensure.NotNull(...)` for all required parameters:
-```csharp
-public void DoSomething(string input, string fileName)
-{
-    Ensure.NotNull(input);
-    Ensure.NotNullOrWhitespace(fileName);
-    // method implementation
-}
-```
-- Guard constructor-injected dependencies with `Ensure.NotNull(...)` for all required parameters:
-```csharp
-_service = Ensure.NotNull(service);
-```
-
-## Formatting
-
-- Apply code-formatting style defined in `.editorconfig`.
-- Prefer file-scoped namespace declarations and single-line using directives.
-- Insert a newline before the opening curly brace of any code block (e.g., after `if`, `for`, `while`, `foreach`,
-  `using`, `try`, etc.).
-- Ensure that the final return statement of a method is on its own line.
-- Use `nameof` instead of string literals when referring to member names.
-- Use `[UsedImplicitly]` from JetBrains.Annotations when types are only used via DI or reflection.
-- Use naming conventions from surrounding code when they differ from standard C# conventions.
-
-## Modern C# Features
-
-- Use **primary constructors** when no constructor body is needed.
-- Use private fields with guards instead of using primary constructor parameters directly, unless the parameter is assigned to a property.
-
-## Async/Await
-
-- In **library code** always use `.ConfigureAwait(false)`
-- In **tests** do not use `.ConfigureAwait(false)` (disable for tests via tests/.editorconfig)
-- YOU MUST NOT USE `.GetAwaiter().GetResult()` OR `.Result` OR `.Wait()` TO BLOCK ON ASYNC CODE. If there is no other way ask the user what to do.
-
-## Nullable Reference Types
-
-- Declare variables non-nullable, and check for `null` at entry points.
-- Always use `is null` or `is not null` instead of `== null` or `!= null`.
-- Trust the C# null annotations — don't add null checks when the type system guarantees non-null.
-
-## Documentation
-
-- Document all public members with XML documentation.
-- Use the `csharp-docs` skill to ensure XML documentation follows best practices.
-- If you change code, always update the relevant XML documentation.
-
-## Testing
-
-- Always include test cases for code changes.
-- Always use the `dotnet-tester` skill for writing tests.
-
-## Console
-
-- Use AnsiConsole for console input and output. Always use IAnsiConsole via dependency injection.
-- Use colored output where it makes sense. For example, use green for success messages, red for errors and yellow for warnings.
-- Use tables for structured output when displaying lists of data or multiple pieces of related information.
-
-## Logging
-
-- Use Serilog for logging.
-- Configure Serilog with appropriate sinks (e.g., file, console, Azure Application Insights) based on environment.
-- Always use structured logging with properties for better log analysis and correlation.
-
-## Skills Reference
-
-- Use the `dotnet-aspnet` skill for ASP.NET Core projects (project structure, middleware, auth, validation, error handling, API versioning, OpenAPI).
-- Use the `ef-core` skill for Entity Framework Core data access patterns.
-- Use the `dotnet-sdk-builder` skill for creating .NET SDK/client libraries.
-- Use the `dotnet-reviewer` skill for Reviewing .NET Code.
-- Use the `dotnet-tester` skill for writing tests.
-- Use the `nuget-manager` skill for NuGet package management.
-- Use the `dotnet-inspect` skill to query .NET APIs in NuGet packages, platform libraries (System.*, Microsoft.AspNetCore.*), or local .dll/.nupkg files — discover types and members, diff API surfaces between versions, find extension methods/implementors, locate SourceLink URLs, and triage breakages caused by package upgrades.
-- Use the `csharp-docs` skill to ensure XML documentation follows best practices.
diff --git a/.github/skills/boost-prompt/SKILL.md b/.github/skills/boost-prompt/SKILL.md
deleted file mode 100644
index 7edd40ec..00000000
--- a/.github/skills/boost-prompt/SKILL.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-name: boost-prompt
-description: Refines and improves user prompts interactively before execution. Use when a task is vague, underspecified, or complex — asks clarifying questions about scope, deliverables, and constraints, then produces a polished, detailed prompt. Never writes code itself.
----
-
-# Boost Prompt
-
-Refine and improve task prompts before execution. DO NOT WRITE ANY CODE.
-
-Iteratively refine the user’s prompt by:
-
-1. Understanding task scope and objectives
-2. Asking specific clarifying questions
-3. Exploring the project with available tools for additional context
-4. Defining deliverables and success criteria
-5. Organizing the prompt into clear sections or steps
-
-Produce the improved prompt as markdown and type it out in the chat. Ask the user if they want changes. Repeat after any revisions.
diff --git a/.github/skills/code-review/SKILL.md b/.github/skills/code-review/SKILL.md
deleted file mode 100644
index e25f2a97..00000000
--- a/.github/skills/code-review/SKILL.md
+++ /dev/null
@@ -1,48 +0,0 @@
----
-name: code-review
-description: Performs thorough code reviews covering quality, security, performance, and best practices. Use when asked to review a pull request, audit code changes, check for security vulnerabilities, assess code quality, or provide feedback on a diff. Outputs structured feedback with severity levels and actionable suggestions.
----
-
-# Code Review Skill
-
-## Review Checklist
-
-### 1. Code Quality
-- Check for code readability and maintainability
-- Verify proper naming conventions
-- Look for code duplication
-- Assess function and class sizes
-- Check for proper separation of concerns
-
-### 2. Security Review
-- Check for security vulnerabilities
-- Verify input validation
-- Look for potential injection attacks
-- Check for exposed secrets or credentials
-- Verify proper authentication and authorization
-
-### 3. Performance
-- Identify potential performance bottlenecks
-- Check for inefficient algorithms or data structures
-- Look for unnecessary database queries or API calls
-- Verify proper resource management
-
-### 4. Testing
-- Verify test coverage
-- Check test quality and relevance
-- Ensure edge cases are tested
-- Verify integration tests exist where needed
-
-### 5. Documentation
-- Check if public APIs are documented
-- Verify complex logic has explanatory comments
-- Ensure README and other docs are updated
-
-## Output Format
-
-Provide feedback in the following structure:
-1. Summary of changes reviewed
-2. Positive aspects of the code
-3. Issues found (categorized by severity: Critical, Major, Minor)
-4. Suggestions for improvement
-5. Overall recommendation (Approve / Request Changes / Comment)
diff --git a/.github/skills/convert-plaintext-to-md/SKILL.md b/.github/skills/convert-plaintext-to-md/SKILL.md
deleted file mode 100644
index e92d220c..00000000
--- a/.github/skills/convert-plaintext-to-md/SKILL.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-name: convert-plaintext-to-md
-description: Converts plain text or legacy documentation files to properly formatted Markdown. Use when asked to convert, migrate, or reformat a plaintext file to .md format. Supports reference-guided conversion, formatting options (headers, code blocks, indentation), and finalization/cleanup of existing .md files.
----
-
-# Convert Plaintext Documentation to Markdown
-
-## Conversion Methods
-
-You can perform conversions using one of three approaches:
-
-1. **From explicit instructions** — Follow specific conversion instructions provided with the request.
-2. **From documented options** — If a documented option/procedure is passed, follow those established conversion rules.
-3. **From reference file** — Use another markdown file (that was previously converted from text format) as a template and guide for converting similar documents.
-
-When using a reference file, apply the same formatting patterns, structure, and conventions — while adapting to the specific content of the file being converted.
-
-## Workflow
-
-1. Determine the input file and check whether a `.md` counterpart already exists (see [parameters.md](./references/parameters.md))
-2. Identify which conversion method applies
-3. Apply the requested parameters and options (see [parameters.md](./references/parameters.md))
-4. Follow pattern recognition and content preservation rules (see [considerations.md](./references/considerations.md))
-5. If `finalize` is passed, clean up formatting after conversion
-
-## References
-
-- [Parameters and Options](./references/parameters.md) — Full parameter reference, options (`--header`, `--pattern`, `--stop`), predefined instructions
-- [Usage Examples](./references/examples.md) — Worked examples: basic conversion, guide-based, finalize, inline regex pattern
-- [Conversion Considerations](./references/considerations.md) — Pattern recognition, conversion goals, markdown style references
-
-> [!IMPORTANT]
-> Do not change the data content unless the prompt instructions clearly and without a doubt specify to do so.
diff --git a/.github/skills/convert-plaintext-to-md/references/azure-devops-markdown-guidance.md b/.github/skills/convert-plaintext-to-md/references/azure-devops-markdown-guidance.md
deleted file mode 100644
index 59631614..00000000
--- a/.github/skills/convert-plaintext-to-md/references/azure-devops-markdown-guidance.md
+++ /dev/null
@@ -1,173 +0,0 @@
-# Azure DevOps Markdown Guidance
-
-This reference describes Markdown syntax supported by Azure DevOps features including Wiki pages, README files, dashboards, and pull requests.
-
-## Supported Features
-
-| Markdown type | Definition of Done | Widget | Pull Requests | README | Wiki |
-|---|---|---|---|---|---|
-| Headings | Yes | Yes | Yes | Yes | Yes |
-| Paragraphs/line breaks | Yes | Yes | Yes | Yes | Yes |
-| Blockquotes | Yes | Yes | Yes | Yes | Yes |
-| Horizontal rules | Yes | Yes | Yes | Yes | Yes |
-| Emphasis (bold, italic) | Yes | Yes | Yes | Yes | Yes |
-| Tables | No | Yes | Yes | Yes | Yes |
-| Lists (ordered, unordered) | Yes | Yes | Yes | Yes | Yes |
-| Links | Yes | Yes | Yes | Yes | Yes |
-| Images | No | Yes | Yes | Yes | Yes |
-| Code highlighting | No | Yes | Yes | Yes | Yes |
-| Math notation | No | No | Yes | Yes | Yes |
-| Checklists/task lists | No | No | Yes | Yes | Yes |
-| Mermaid diagrams | No | No | No | No | Yes |
-
-> **Note:** Markdown in Azure DevOps doesn't support JavaScript or iframes.
-
-## Headings
-
-```markdown
-# Heading 1
-## Heading 2
-### Heading 3
-#### Heading 4
-##### Heading 5
-###### Heading 6
-```
-
-## Paragraphs and Line Breaks
-
-Use a blank line for new paragraphs. Use two spaces at line end or `<br/>` for line breaks within a paragraph.
-
-## Blockquotes
-
-```markdown
-> Single blockquote
->> Nested blockquote
-```
-
-## Horizontal Rules
-
-Use three or more hyphens, asterisks, or underscores on a line by themselves.
-
-## Emphasis
-
-```markdown
-*Italic* or _Italic_
-**Bold** or __Bold__
-***Bold italic***
-~~Strikethrough~~
-```
-
-## Code Highlighting
-
-**Inline:** Use single backticks `` `code` ``
-
-**Block:** Use triple backticks with optional language identifier:
-
-````markdown
-```javascript
-const x = 1;
-```
-````
-
-Supported languages include: ActionScript, Apex, Bash, C, C#, C++, CSS, Dart, Go, Groovy, Haskell, HTML, Java, JavaScript, JSON, Kotlin, Lua, Markdown, Objective-C, Perl, PHP, PowerShell, Python, R, Ruby, Rust, Scala, Shell, SQL, Swift, TypeScript, XML, YAML, and more.
-
-## Tables
-
-```markdown
-| Header 1 | Header 2 |
-|----------|----------|
-| Cell 1   | Cell 2   |
-```
-
-Alignment with colons: `:---` (left), `:---:` (center), `---:` (right).
-
-## Lists
-
-**Ordered:**
-
-```markdown
-1. First item
-2. Second item
-```
-
-**Unordered:**
-
-```markdown
-- Item 1
-- Item 2
-```
-
-**Nested:** Indent with spaces.
-
-## Links
-
-```markdown
-[Link text](URL)
-[Link text](URL "Title")
-```
-
-**Anchor links:** Link to headings within the same page using `#section-name`.
-
-## Images
-
-```markdown
-![Alt text](image-url)
-![Alt text](image-url =WIDTHxHEIGHT)
-```
-
-Azure DevOps supports image resizing with `=WIDTHxHEIGHT` syntax.
-
-## Checklists / Task Lists
-
-```markdown
-- [ ] Incomplete task
-- [x] Completed task
-```
-
-## Mathematical Notation
-
-**Inline:** `$` delimiters: `$e^{i\pi} = -1$`
-
-**Block:** `$$` delimiters:
-
-```markdown
-$$
-\sum_{i=1}^{n} x_i
-$$
-```
-
-Uses KaTeX for rendering.
-
-## Mermaid Diagrams (Wiki only)
-
-````markdown
-```mermaid
-graph TD;
-    A-->B;
-    B-->C;
-```
-````
-
-Supports: flowcharts, sequence diagrams, Gantt charts, and more.
-
-## Collapsible Sections
-
-```html
-<details>
-  <summary>Click to expand</summary>
-
-  Content here (leave blank line after summary tag).
-</details>
-```
-
-## Emoji
-
-Use standard emoji shortcodes: `:smile:`, `:thumbsup:`, etc.
-
-## Special Characters
-
-Escape special Markdown characters with backslash: `\*`, `\#`, `\[`, etc.
-
-## HTML Tags
-
-Supported HTML tags in Wiki include: `<div>`, `<span>`, `<img>`, `<br>`, `<table>`, `<tr>`, `<td>`, `<th>`, `<strong>`, `<em>`, `<code>`, `<pre>`, `<blockquote>`, `<ul>`, `<ol>`, `<li>`, `<h1>`-`<h6>`, `<hr>`, `<p>`, `<a>`, `<details>`, `<summary>`, `<video>`, `<audio>`.
diff --git a/.github/skills/convert-plaintext-to-md/references/considerations.md b/.github/skills/convert-plaintext-to-md/references/considerations.md
deleted file mode 100644
index 5e053ed3..00000000
--- a/.github/skills/convert-plaintext-to-md/references/considerations.md
+++ /dev/null
@@ -1,40 +0,0 @@
-# Conversion Considerations
-
-## Pattern Recognition
-
-When converting plaintext, pay attention to:
-
-- **Line indentation** — determines nesting level for lists and code blocks
-- **Indented code blocks** — lines indented with 4+ spaces relative to context
-- **Fenced code blocks** — detect language from context and add language identifier
-- **Section separators** — lines like `===`, `---`, `***` map to horizontal rules or heading levels
-
-### Do Not Stop on Process-Related Keywords
-
-When converting documentation, do **not** halt the conversion when the text documents procedures that use shell commands or function calls. These are content to be preserved, not instructions to execute:
-
-- `exit` / `exit()`
-- `kill` / `killall`
-- `quit` / `quit()`
-- `sleep` / `sleep()`
-- Similar commands, functions, or procedures
-
----
-
-## Conversion Goals
-
-- Preserve all technical content accurately — do **not** change data unless prompt instructions clearly specify to do so
-- Maintain proper markdown syntax and formatting
-- Ensure headers, lists, code blocks, and other elements are correctly structured
-- Keep the document readable and well-organized
-- Assemble a unified set of instructions using all parameters and options provided
-
----
-
-## Markdown References
-
-When in doubt, consult these resources for markdown best practices:
-
-- [GitHub Basic Writing and Formatting Syntax](./github-basic-formatting.md)
-- [Markdown Extended Syntax](./markdown-extended-syntax.md)
-- [Azure DevOps Markdown Guidance](./azure-devops-markdown-guidance.md)
diff --git a/.github/skills/convert-plaintext-to-md/references/examples.md b/.github/skills/convert-plaintext-to-md/references/examples.md
deleted file mode 100644
index d92bbc8f..00000000
--- a/.github/skills/convert-plaintext-to-md/references/examples.md
+++ /dev/null
@@ -1,221 +0,0 @@
-# Usage Examples
-
-## Basic Conversion
-
-**User**
-
-```bash
-/convert-plaintext-to-md #file
-```
-
-**Agent**
-
-```
-I see there is no corresponding `file.md`. Let me copy the plaintext document:
-
-    ```bash
-    cp file file.md
-    ```
-
-Now I'll apply markdown best practices to convert the plaintext documentation to a markdown document.
-```
-
----
-
-## Guide-Based Conversion
-
-Uses a previously converted markdown file as a formatting reference.
-
-**User**
-
-```bash
-/convert-plaintext-to-md #file.md --guide #CODE.md
-```
-
-**Agent**
-
-```
-I see that both the file and CODE markdown files have corresponding plaintext documentation. Let me
-check CODE and compare it to CODE.md, and identify patterns to help with conversion.
-
-    CODE
-    ```text
-    Title
-
-    Text in opening.
-
-    1. Section
-      1.1 Section Item
-
-    =============================================
-
-    1. Section
-      1.1
-      Full details of section item.
-    ```
-
-And looking at CODE.md:
-
-    CODE.md
-    ```markdown
-    # Title
-
-    Text in opening.
-
-    ### [Section](#1-section)
-
-    - [1.1](#11) Section Item but Only Numbers in Sub-heading
-
-    ***
-
-    ## 1. Section
-
-    ### 1.1
-
-    Full details of section item.
-    ```
-
-I see file.md exists and matches the text in file.
-
-I'll convert file.md similarly. Let's look at the file text documentation:
-
-    file
-    ```text
-    Title
-
-    1. Command
-      1.10.0 Options
-
-    ---------------------------------------------
-
-    Command
-      1.10.0
-      Info on the commands' options.
-    ```
-
-OK, after analyzing the guide file, I've updated file.md to:
-
-    file.md
-    ```markdown
-    # Title
-
-    ### [1. Command](#command)
-    - [1.10.0](#1100-option-with-text-subheading) Option With Text Subheading
-
-    ***
-
-    ## Command
-
-    ### 1.10.0 Option With Text Subheading
-    Info on the commands' options.
-    ```
-```
-
----
-
-## Finalize / Polish
-
-Natural language variations like "polish", "clean up", or "finalize" all trigger the `finalize` behavior.
-
-**User**
-
-```bash
-/convert-plaintext-to-md #file.md polish the converted markdown file
-```
-
-**Agent**
-
-```
-I'll finalize file.md. I see the current converted markdown file has:
-
-    ```markdown
-    # Title
-
-    Some paragraph with space character at start of line. This <html> should be escaped.
-
-    -  Some list item with extra space character.
-    -  Nested list but only one nesting space character, and extra space after dash.
-      if (a == 1) {
-        return "Indented code block without enough space characters.";
-      } else {
-        return "Passing `finalize` or similar should resolve this.";
-      }
-
-    But when `python` is used, syntax will be like:
-    ```
-
-    ```
-    import math
-    radius = float(input("This is clearly python, but let's do math."))
-    area = math.pi * radius**2
-    circumference = 2 * math.pi * radius
-    print(f"Area: {area:.2f}, Circumference: {circumference:.2f}")
-    ```
-
-Let me trim a few things:
-
-    ```markdown
-    # Title
-
-    Some paragraph with space character at start of line. This \<html\> should be escaped.
-
-    - Some list item with extra space character.
-      - Nested list but only one space character.
-
-        if (a == 1) {
-          return "Indented code block without enough space characters.";
-        } else {
-          return "Passing `finalize` or similar should resolve this.";
-        }
-
-    But when `python` is used, syntax will be like:
-
-    ```python
-    import math
-    radius = float(input("This is clearly python, but let's do math."))
-    area = math.pi * radius**2
-    circumference = 2 * math.pi * radius
-    print(f"Area: {area:.2f}, Circumference: {circumference:.2f}")
-    ```
-```
-
----
-
-## Inline Pattern with Shorthand Regex
-
-**User**
-
-```bash
-/convert-plaintext-to-md #BUGS --p "regex()=> ^ {1,}([0-9]+\.[0-9]+\.[0-9]+) to ^### $1"
-```
-
-**Agent**
-
-```
-I see that there is no `BUGS.md` file. Let me copy the current plaintext BUGS documentation:
-
-    ```bash
-    copy BUGS BUGS.md
-    ```
-
-Now I'll update the copied file BUGS.md, converting it to proper markdown.
-Let me read the current contents:
-
-    ```markdown
-    1 Section
-      1.1 Section Item
-      1.2 Section Item
-      ...
-      1.12 Section Item
-    ```
-
-OK, I've matched the shorthand regular expression pattern and updated the BUGS.md to:
-
-    ```markdown
-    1 Section
-    ### 1.1 Section Item
-    ### 1.2 Section Item
-    ### ...
-    ### 1.12 Section Item
-    ```
-```
diff --git a/.github/skills/convert-plaintext-to-md/references/github-basic-formatting.md b/.github/skills/convert-plaintext-to-md/references/github-basic-formatting.md
deleted file mode 100644
index efaa03b1..00000000
--- a/.github/skills/convert-plaintext-to-md/references/github-basic-formatting.md
+++ /dev/null
@@ -1,153 +0,0 @@
-# GitHub Basic Writing and Formatting Syntax Reference
-
-## Headings
-
-Create hierarchy using 1-6 hash symbols. GitHub automatically generates a table of contents when you use multiple headings.
-
-```markdown
-# First-level heading
-## Second-level heading
-### Third-level heading
-```
-
-## Text Styling
-
-| Style | Syntax | Example |
-|-------|--------|---------|
-| Bold | `** **` or `__ __` | `**bold text**` |
-| Italic | `* *` or `_ _` | `*italicized text*` |
-| Strikethrough | `~~ ~~` | `~~mistaken text~~` |
-| Bold & italic | `** **` and `_ _` | `**_extremely_ important**` |
-| Subscript | `<sub> </sub>` | `<sub>subscript</sub>` |
-| Superscript | `<sup> </sup>` | `<sup>superscript</sup>` |
-| Underline | `<ins> </ins>` | `<ins>underlined</ins>` |
-
-## Quoting Text
-
-Use `>` to create block quotes:
-
-```markdown
-> Text that is a quote
-```
-
-## Code Formatting
-
-**Inline code:** Use single backticks for code within sentences:
-
-```markdown
-Use `git status` to list changes.
-```
-
-**Code blocks:** Use triple backticks for standalone code:
-
-````markdown
-```
-git status
-git add
-git commit
-```
-````
-
-## Color Support
-
-Display colors using supported models within backticks:
-
-- Hex: `` `#0969DA` ``
-- RGB: `` `rgb(9, 105, 218)` ``
-- HSL: `` `hsl(212, 92%, 45%)` ``
-
-## Links
-
-Wrap link text in brackets and URL in parentheses:
-
-```markdown
-[Link text](https://example.com)
-```
-
-**Section links:** Link directly to any heading using its anchor.
-
-**Relative links:** Use paths relative to current file:
-
-```markdown
-[Contribution guidelines](docs/CONTRIBUTING.md)
-```
-
-## Images
-
-Include images using exclamation mark, alt text in brackets, and URL in parentheses:
-
-```markdown
-![Alt text](image-url.png)
-```
-
-The `<picture>` HTML element is supported for theme-adaptive images.
-
-## Lists
-
-**Unordered lists:** Use `-`, `*`, or `+`
-
-**Ordered lists:** Use numbers followed by periods
-
-**Nested lists:** Indent items under parent items using spaces or tabs
-
-## Task Lists
-
-Create checkboxes with `[ ]` for incomplete and `[x]` for complete tasks:
-
-```markdown
-- [x] Completed task
-- [ ] Incomplete task
-```
-
-## Mentions & References
-
-- **Mention people/teams:** `@username` or `@organization/team-name`
-- **Reference issues:** `#` followed by issue number or title
-
-## Emojis
-
-Use `:EMOJICODE:` format: `:+1:`, `:shipit:`
-
-## Paragraphs & Line Breaks
-
-Create paragraphs by leaving blank lines between text. For line breaks:
-
-- Two trailing spaces at line end
-- Backslash `\` at line end
-- HTML `<br/>`
-
-## Footnotes
-
-```markdown
-Here is a footnote[^1].
-
-[^1]: Footnote content here.
-```
-
-Footnotes render at document bottom regardless of placement.
-
-## Alerts
-
-Five alert types emphasize critical information:
-
-```markdown
-> [!NOTE]
-> Essential information users should know.
-
-> [!TIP]
-> Helpful advice for better outcomes.
-
-> [!IMPORTANT]
-> Key information for success.
-
-> [!WARNING]
-> Urgent information requiring immediate attention.
-
-> [!CAUTION]
-> Warns about risks and negative outcomes.
-```
-
-## Special Features
-
-- **HTML comments:** `<!-- Hidden content -->`
-- **Escape formatting:** Backslash before markdown characters: `\*not italicized\*`
diff --git a/.github/skills/convert-plaintext-to-md/references/markdown-extended-syntax.md b/.github/skills/convert-plaintext-to-md/references/markdown-extended-syntax.md
deleted file mode 100644
index bbc1ab0d..00000000
--- a/.github/skills/convert-plaintext-to-md/references/markdown-extended-syntax.md
+++ /dev/null
@@ -1,133 +0,0 @@
-# Markdown Extended Syntax Reference
-
-The extended syntax builds upon basic Markdown by adding advanced features. Not all Markdown applications support extended syntax — check your application's documentation to confirm compatibility.
-
-## Tables
-
-Create tables using pipes (`|`) and hyphens (`---`):
-
-```markdown
-| Syntax      | Description |
-| ----------- | ----------- |
-| Header      | Title       |
-| Paragraph   | Text        |
-```
-
-### Alignment
-
-Add colons to align columns:
-
-- Left: `:---`
-- Center: `:---:`
-- Right: `---:`
-
-### Formatting in Tables
-
-Supported: links, code (backticks only), emphasis.
-Not supported: headings, blockquotes, lists, horizontal rules, images.
-
-### Escaping Pipes
-
-Use HTML entity `&#124;` to display pipe characters.
-
-## Fenced Code Blocks
-
-Use triple backticks or tildes without indentation:
-
-````markdown
-```json
-{
-  "example": "value"
-}
-```
-````
-
-Specify language after opening backticks for syntax highlighting.
-
-## Footnotes
-
-```markdown
-Text here.[^1]
-
-[^1]: This is the footnote.
-```
-
-## Heading IDs
-
-Add custom IDs to headings:
-
-```markdown
-### Heading {#custom-id}
-```
-
-Link to IDs with `[Link text](#custom-id)`.
-
-## Definition Lists
-
-```markdown
-Term
-: Definition of the term.
-```
-
-## Strikethrough
-
-Use double tildes:
-
-```markdown
-~~Strikethrough text~~
-```
-
-## Task Lists
-
-```markdown
-- [x] Completed task
-- [ ] Incomplete task
-```
-
-## Emoji
-
-### Direct Copy-Paste
-
-Paste emoji directly from sources like Emojipedia.
-
-### Shortcodes
-
-```markdown
-Gone camping! :tent: Be back soon.
-```
-
-## Highlight
-
-```markdown
-==Important words==
-```
-
-Or use HTML: `<mark>text</mark>`
-
-## Subscript
-
-```markdown
-H~2~O
-```
-
-Or HTML: `H<sub>2</sub>O`
-
-## Superscript
-
-```markdown
-X^2^
-```
-
-Or HTML: `X<sup>2</sup>`
-
-## Automatic URL Linking
-
-Most processors auto-link URLs. Disable by wrapping in backticks:
-
-```markdown
-`http://www.example.com`
-```
-
----
-
-> **Note:** Support varies significantly across applications. Always test extended syntax features in your specific Markdown processor.
diff --git a/.github/skills/convert-plaintext-to-md/references/parameters.md b/.github/skills/convert-plaintext-to-md/references/parameters.md
deleted file mode 100644
index 3bda9e86..00000000
--- a/.github/skills/convert-plaintext-to-md/references/parameters.md
+++ /dev/null
@@ -1,103 +0,0 @@
-# Parameters and Options Reference
-
-## Command Syntax
-
-```bash
-/convert-plaintext-to-md <#file:{{file}}> [finalize] [guide #file:{{reference-file}}] [instructions] [platform={{name}}] [options] [pre=<name>]
-```
-
-When parameters and options are unclear, use `#tool:fetch` to retrieve the URLs in the [Markdown References](./considerations.md#markdown-references) section.
-
----
-
-## Parameters
-
-### `#file:{{file}}` _(required)_
-
-The plain or generic text documentation file to convert to markdown.
-
-- If a corresponding `{{file}}.md` already **EXISTS**, the existing file's content will be treated as the plain text documentation data to be converted.
-- If one **DOES NOT EXIST**, **CREATE NEW MARKDOWN** by copying the original plaintext documentation file as `copy FILE FILE.md` in the same directory as the plain text documentation file.
-
-### `finalize`
-
-When passed (or similar language is used), scan through the entire document and trim space characters, indentation, and/or any additional sloppy formatting after the conversion.
-
-### `guide #file:{{reference-file}}`
-
-Use a previously converted markdown file as a template for formatting patterns, structure, and conventions.
-
-### `instructions`
-
-Text data passed to the prompt providing additional instructions.
-
-### `platform={{name}}`
-
-Specify the target platform for markdown rendering to ensure compatibility:
-
-| Platform | Description |
-|---|---|
-| **GitHub** _(default)_ | GitHub-flavored markdown (GFM) with tables, task lists, strikethrough, and alerts |
-| **StackOverflow** | CommonMark with StackOverflow-specific extensions |
-| **VS Code** | Optimized for VS Code's markdown preview renderer |
-| **GitLab** | GitLab-flavored markdown with platform-specific features |
-| **CommonMark** | Standard CommonMark specification |
-
----
-
-## Options
-
-### `--header [1-4]`
-
-Add markdown header tags to the document.
-
-- **`[1-4]`** — Specifies the header level to add (`#` through `####`)
-- **`#selection`** — Data used to:
-  - Identify sections where updates should be applied
-  - Serve as a guide for applying headers to other sections or the entire document
-- **Auto-apply** (if none provided) — Add headers based on content structure
-
-### `-p, --pattern`
-
-Follow an existing pattern from:
-
-- **`#selection`** — A selected pattern to follow when updating the file or a portion of it
-  - **IMPORTANT**: DO NOT only edit the selection when passed to `{{[-p, --pattern]}}`
-  - **NOTE**: The selection is **NOT** the **WORKING RANGE**
-  - Identify pattern(s) from the selection
-  - **Stopping Points**:
-    - If `{{[-s, --stop]}} eof` is passed or no clear endpoint is specified, convert to end of file
-    - If `-s [0-9]+` is passed, convert to the line number specified in the regex `[0-9]+`
-- **Prompt instructions** — Instructional data passed with the prompt
-- **Auto-detect** (if none provided) — Identify existing patterns in the file by:
-  - Analyzing where patterns occur
-  - Identifying data that does not match the pattern
-  - Applying patterns from one section to corresponding sections where the pattern is missing
-
-### `-s, --stop <[0-9]+ | eof>`
-
-- **`[0-9]+`** — Line number to stop the current markdown conversion at
-- **`eof`** — If passed, or any other text clearly indicating end of file, convert to end of file
-
----
-
-## Predefined Instructions
-
-If any of the predefined instructions are passed as an argument, expand and use them as **ADDITIONAL** input for the prompt instructions. If only the predefined instruction is passed and no additional input, use it as the sole instruction for the current prompt.
-
-**Syntax:**
-
-```bash
-/convert-plaintext-to-md pre=<name>
-```
-
-### Available Predefined Instructions
-
-| Name | Description |
-|---|---|
-| `rm-head-digits` | Remove any prepending numbers from the headers when updating or converting the plaintext to markdown. |
-| `mv-head-level(x, y)` | Change the heading level from level `x` header to a level `y` header when updating or converting plaintext to markdown. |
-| `rm-indent(x)` | Decrease the indentation of paragraphs or raw text data portions of the file by `x` when updating or converting plaintext to markdown. |
-
-> [!NOTE]
-> If there is no matching predefined instruction, disregard the `pre=name` for the current prompt.
diff --git a/.github/skills/create-readme/SKILL.md b/.github/skills/create-readme/SKILL.md
deleted file mode 100644
index acff6c89..00000000
--- a/.github/skills/create-readme/SKILL.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-name: create-readme
-description: Creates a comprehensive, professional README.md for a project. Use when a project has no README, when the existing README is outdated, or when asked to generate project documentation. Follows OSS conventions with GFM formatting, project logo detection, and concise writing style.
----
-
-## Workflow
-
-1. Review the entire project and workspace, then create a well-structured README.md.
-2. Take inspiration from these readme files for structure, tone, and content:
-   - [serverless-chat-langchainjs](./references/serverless-chat-langchainjs-readme.md)
-   - [serverless-recipes-javascript](./references/serverless-recipes-javascript-readme.md)
-   - [run-on-output](./references/run-on-output-readme.md)
-   - [smoke](./references/smoke-readme.md)
-3. Do not overuse emojis, and keep the readme concise and to the point.
-4. Do not include sections like "LICENSE", "CONTRIBUTING", "CHANGELOG", etc. There are dedicated files for those sections.
-5. Use GFM (GitHub Flavored Markdown) for formatting, and GitHub admonition syntax (see [reference](./references/github-admonition-syntax.md)) where appropriate.
-6. If you find a logo or icon for the project, use it in the readme's header.
diff --git a/.github/skills/create-readme/references/github-admonition-syntax.md b/.github/skills/create-readme/references/github-admonition-syntax.md
deleted file mode 100644
index 324df13d..00000000
--- a/.github/skills/create-readme/references/github-admonition-syntax.md
+++ /dev/null
@@ -1,60 +0,0 @@
-# GitHub Markdown Alerts (Admonition Syntax)
-
-GitHub supports a markdown extension for creating highlighted alert blocks using blockquote syntax. This feature helps emphasize critical information in documentation with distinctive colors and icons.
-
-## Syntax
-
-The basic syntax uses blockquote markers (`>`) with a bracket notation:
-
-```markdown
-> [!TYPE]
-> Your alert content here
-```
-
-## Supported Alert Types
-
-### NOTE
-
-```markdown
-> [!NOTE]
-> Highlights information users should consider, even when skimming.
-```
-
-### TIP
-
-```markdown
-> [!TIP]
-> Optional information to help users be more successful.
-```
-
-### IMPORTANT
-
-```markdown
-> [!IMPORTANT]
-> Crucial information necessary for users to succeed.
-```
-
-### WARNING
-
-```markdown
-> [!WARNING]
-> Critical content demanding immediate attention due to potential risks.
-```
-
-### CAUTION
-
-```markdown
-> [!CAUTION]
-> Negative potential consequences of an action.
-```
-
-## Key Features
-
-- A line break must follow the alert type marker
-- Alerts render as `div` elements with semantic styling rather than blockquote elements
-- Works in READMEs, Markdown files, wikis, issues, pull requests, and discussions
-- Each alert type uses distinct visual styling (colors and icons) for clarity
-
-## Source
-
-Originally discussed at: https://github.com/orgs/community/discussions/16925
diff --git a/.github/skills/create-readme/references/run-on-output-readme.md b/.github/skills/create-readme/references/run-on-output-readme.md
deleted file mode 100644
index 971734d4..00000000
--- a/.github/skills/create-readme/references/run-on-output-readme.md
+++ /dev/null
@@ -1,146 +0,0 @@
-<div align="center">
-  <img src="icon.png" width="96" alt="run-on-output logo">
-  
-  # run-on-output
-  *Execute tasks when CLI output patterns are detected*
-  
-  [![Build Status](https://img.shields.io/github/actions/workflow/status/sinedied/run-on-output/ci.yml?style=flat-square)](https://github.com/sinedied/run-on-output/actions)
-  [![npm version](https://img.shields.io/npm/v/run-on-output?style=flat-square)](https://www.npmjs.com/package/run-on-output)
-  [![Node.js](https://img.shields.io/badge/Node.js->=20-3c873a?style=flat-square)](https://nodejs.org)
-  [![XO code style](https://shields.io/badge/code_style-5ed9c7?logo=xo&labelColor=gray&style=flat-square)](https://github.com/xojs/xo)
-  [![License](https://img.shields.io/badge/License-MIT-blue?style=flat-square)](LICENSE)
-
-  ⭐ If you like this project, star it on GitHub!
-
-  [Features](#features) • [Installation](#installation) • [Usage](#usage) • [Examples](#examples)
-
-</div>
-
-
-A lightweight Node.js CLI tool that monitors command output in real-time and triggers actions when specific patterns are found. Perfect for automation workflows, development environments, and CI/CD pipelines.
-
-## Features
-
-- 🎯 **Pattern Matching** - Monitor stdout/stderr for regex patterns or plain strings
-- ⚡ **Real-time Monitoring** - Output is forwarded in real-time while monitoring  
-- 🔧 **Flexible Actions** - Display messages or execute commands when patterns match
-- 📝 **Multiple Patterns** - Wait for multiple patterns before triggering actions
-- 🚀 **Zero Dependencies** - Built with Node.js built-in modules only
-
-## Installation
-
-```bash
-npm install -g run-on-output
-```
-
-Or use without installing:
-
-```bash
-npx run-on-output [options] <command> [args...]
-```
-
-## Usage
-
-### Basic Examples
-
-**Display a message when server starts:**
-```bash
-run-on-output -s "Server started" -m "🚀 Server is ready" npm start
-```
-
-**Execute a health check when server is listening:**
-```bash
-run-on-output -p "listening on port \\d+" -r "curl http://localhost:3000/health" node server.js
-```
-
-**Monitor development environment startup:**
-```bash
-run-on-output -s "webpack compiled,server ready" -m "✅ Development environment ready" npm run dev
-```
-
-**Multiple actions - show message and open browser:**
-```bash
-run-on-output -s "ready" -m "Server is up" -r "open http://localhost:3000" npm start
-```
-
-**Run npm script when server is ready:**
-```bash
-run-on-output -s "Server running" -n "test" node server.js
-```
-
-> [!TIP]
-> You can use the short alias `roo` instead of `run-on-output` for faster typing:
-> ```bash
-> roo -s "Server started" -m "🚀 Server is ready" npm start
-> ```
-
-### Command Line Options
-
-```
-run-on-output [OPTIONS] <command> [args...]
-
-OPTIONS:
-  -p, --patterns <patterns>    Comma-separated list of regex patterns to watch for
-  -s, --strings <strings>      Comma-separated list of plain strings to watch for
-  -r, --run <command>          Command to execute after all patterns are found
-  -n, --npm <script>           npm script to run after all patterns are found
-  -m, --message <text>         Message to display after all patterns are found
-  -h, --help                   Show this help message
-
-REQUIREMENTS:
-  - Either --patterns or --strings must be specified (but not both)
-  - At least one of --run, --npm, or --message must be specified
-```
-
-### Pattern Types
-
-**Plain Strings (`-s, --strings`)**
-- Matches exact text (case-insensitive)
-- Easier to use for simple text matching
-- Example: `-s "Server started,Database connected"`
-
-**Regex Patterns (`-p, --patterns`)**
-- Use regular expressions for complex matching
-- Supports all JavaScript regex features
-- Example: `-p "listening on port \\d+,ready in \\d+ms"`
-
-## Examples
-
-**Development Workflow**
-```bash
-# Wait for both webpack and server, then open browser
-run-on-output -s "webpack compiled,Local:" -r "open http://localhost:3000" npm run dev
-
-# Monitor test runner and show completion message
-run-on-output -s "Tests completed" -m "✅ All tests passed" npm test
-```
-
-**CI/CD Pipeline**
-```bash
-# Wait for deployment completion and run smoke tests
-run-on-output -p "deployment.*complete" -r "./scripts/smoke-test.sh" deploy.sh
-
-# Monitor build process and trigger notifications
-run-on-output -s "Build successful" -r "slack-notify '#dev' 'Build completed'" npm run build
-```
-
-**Docker & Containers**
-```bash
-# Wait for container health check and run integration tests
-run-on-output -s "healthy" -r "npm run test:integration" docker-compose up
-
-# Monitor database initialization
-run-on-output -p "database.*ready" -m "📁 Database initialized" ./start-db.sh
-```
-
-**API Development**
-```bash
-# Wait for API server and run endpoint tests
-run-on-output -p "server.*listening.*port" -r "npm run test:api" node api.js
-
-# Monitor microservices startup and run deployment script
-run-on-output -s "auth-service ready,user-service ready" -n "deploy" ./start-services.sh
-
-# Combine message, command and npm script
-run-on-output -s "Database connected" -m "🎉 Ready for testing" -n "test:integration" npm start
-```
diff --git a/.github/skills/create-readme/references/serverless-chat-langchainjs-readme.md b/.github/skills/create-readme/references/serverless-chat-langchainjs-readme.md
deleted file mode 100644
index b36fbba7..00000000
--- a/.github/skills/create-readme/references/serverless-chat-langchainjs-readme.md
+++ /dev/null
@@ -1,280 +0,0 @@
-<!-- prettier-ignore -->
-<div align="center">
-
-<img src="./packages/webapp/public/favicon.png" alt="" align="center" height="64" />
-
-# Serverless AI Chat with RAG using LangChain.js
-
-[![Open project in GitHub Codespaces](https://img.shields.io/badge/Codespaces-Open-blue?style=flat-square&logo=github)](https://codespaces.new/Azure-Samples/serverless-chat-langchainjs?hide_repo_select=true&ref=main&quickstart=true)
-[![Join Azure AI Foundry Discord](https://img.shields.io/badge/Discord-Azure_AI_Community-blue?style=flat-square&logo=discord&color=5865f2&logoColor=fff)](https://aka.ms/foundry/discord)
-[![Official Learn documentation](https://img.shields.io/badge/Documentation-00a3ee?style=flat-square)](https://learn.microsoft.com/azure/developer/javascript/ai/get-started-app-chat-template-langchainjs)
-[![Watch to learn about RAG and this sample on YouTube](https://img.shields.io/badge/YouTube-d95652.svg?style=flat-square&logo=youtube)](https://www.youtube.com/watch?v=xkFOmx5yxIA&list=PLlrxD0HtieHi5ZpsHULPLxm839IrhmeDk&index=4)
-[![dev.to blog post walkthrough](https://img.shields.io/badge/Blog%20post-black?style=flat-square&logo=dev.to)](https://dev.to/azure/build-a-serverless-chatgpt-with-rag-using-langchainjs-3487)
-<br>
-[![Build Status](https://img.shields.io/github/actions/workflow/status/Azure-Samples/serverless-chat-langchainjs/build-test.yaml?style=flat-square&label=Build)](https://github.com/Azure-Samples/serverless-chat-langchainjs/actions)
-![Node version](https://img.shields.io/badge/Node.js->=20-3c873a?style=flat-square)
-[![Ollama + Llama3.1](https://img.shields.io/badge/Ollama-Llama3.1-ff7000?style=flat-square)](https://ollama.com/library/llama3.1)
-[![TypeScript](https://img.shields.io/badge/TypeScript-blue?style=flat-square&logo=typescript&logoColor=white)](https://www.typescriptlang.org)
-[![License](https://img.shields.io/badge/License-MIT-yellow?style=flat-square)](LICENSE)
-
-:star: If you like this sample, star it on GitHub — it helps a lot!
-
-[Overview](#overview) • [Get started](#getting-started) • [Run the sample](#run-the-sample) • [Resources](#resources) • [FAQ](#faq) • [Troubleshooting](#troubleshooting)
-
-![Animation showing the chat app in action](./docs/images/demo.gif)
-
-</div>
-
-This sample shows how to build a serverless AI chat experience with Retrieval-Augmented Generation using [LangChain.js](https://js.langchain.com/) and Azure. The application is hosted on [Azure Static Web Apps](https://learn.microsoft.com/azure/static-web-apps/overview) and [Azure Functions](https://learn.microsoft.com/azure/azure-functions/functions-overview?pivots=programming-language-javascript), with [Azure Cosmos DB for NoSQL](https://learn.microsoft.com/azure/cosmos-db/nosql/vector-) as the vector database. You can use it as a starting point for building more complex AI applications.
-
-> [!TIP]
-> You can test this application locally without any cost using [Ollama](https://ollama.com/). Follow the instructions in the [Local Development](#local-development) section to get started.
-
-## Overview
-
-Building AI applications can be complex and time-consuming, but using LangChain.js and Azure serverless technologies allows to greatly simplify the process. This application is a chatbot that uses a set of enterprise documents to generate responses to user queries.
-
-We provide sample data to make this sample ready to try, but feel free to replace it with your own. We use a fictitious company called _Contoso Real Estate_, and the experience allows its customers to ask support questions about the usage of its products. The sample data includes a set of documents that describes its terms of service, privacy policy and a support guide.
-
-<div align="center">
-  <img src="./docs/images/architecture.drawio.png" alt="Application architecture" width="640px" />
-</div>
-
-This application is made from multiple components:
-
-- A web app made with a single chat web component built with [Lit](https://lit.dev) and hosted on [Azure Static Web Apps](https://learn.microsoft.com/azure/static-web-apps/overview). The code is located in the `packages/webapp` folder.
-
-- A serverless API built with [Azure Functions](https://learn.microsoft.com/azure/azure-functions/functions-overview?pivots=programming-language-javascript) and using [LangChain.js](https://js.langchain.com/) to ingest the documents and generate responses to the user chat queries. The code is located in the `packages/api` folder.
-
-- A database to store chat sessions and the text extracted from the documents and the vectors generated by LangChain.js, using [Azure Cosmos DB for NoSQL](https://learn.microsoft.com/azure/cosmos-db/nosql/).
-
-- A file storage to store the source documents, using [Azure Blob Storage](https://learn.microsoft.com/azure/storage/blobs/storage-blobs-introduction).
-
-We use the [HTTP protocol for AI chat apps](https://aka.ms/chatprotocol) to communicate between the web app and the API.
-
-## Features
-
-- **Serverless Architecture**: Utilizes Azure Functions and Azure Static Web Apps for a fully serverless deployment.
-- **Retrieval-Augmented Generation (RAG)**: Combines the power of Azure Cosmos DB and LangChain.js to provide relevant and accurate responses.
-- **Chat Sessions History**: Maintains a personal chat history for each user, allowing them to revisit previous conversations.
-- **Scalable and Cost-Effective**: Leverages Azure's serverless offerings to provide a scalable and cost-effective solution.
-- **Local Development**: Supports local development using Ollama for testing without any cloud costs.
-
-## Getting started
-
-There are multiple ways to get started with this project.
-
-The quickest way is to use [GitHub Codespaces](#use-github-codespaces) that provides a preconfigured environment for you. Alternatively, you can [set up your local environment](#use-your-local-environment) following the instructions below.
-
-> [!IMPORTANT]
-> If you want to run this sample entirely locally using Ollama, you have to follow the instructions in the [local environment](#use-your-local-environment) section.
-
-### Use your local environment
-
-You need to install following tools to work on your local machine:
-
-- [Node.js LTS](https://nodejs.org/download/)
-- [Azure Developer CLI](https://aka.ms/azure-dev/install)
-- [Git](https://git-scm.com/downloads)
-- [PowerShell 7+](https://github.com/powershell/powershell) _(for Windows users only)_
-  - **Important**: Ensure you can run `pwsh.exe` from a PowerShell command. If this fails, you likely need to upgrade PowerShell.
-  - Instead of Powershell, you can also use Git Bash or WSL to run the Azure Developer CLI commands.
-- [Azure Functions Core Tools](https://learn.microsoft.com/azure/azure-functions/functions-run-local?tabs=macos%2Cisolated-process%2Cnode-v4%2Cpython-v2%2Chttp-trigger%2Ccontainer-apps&pivots=programming-language-javascript) _(should be installed automatically with NPM, only install manually if the API fails to start)_
-
-Then you can get the project code:
-
-1. [**Fork**](https://github.com/Azure-Samples/serverless-chat-langchainjs/fork) the project to create your own copy of this repository.
-2. On your forked repository, select the **Code** button, then the **Local** tab, and copy the URL of your forked repository.
-
-<div align="center">
-  <img src="./docs/images/clone-url.png" alt="Screenshot showing how to copy the repository URL" width="400px" />
-</div>
-3. Open a terminal and run this command to clone the repo: <code> git clone &lt;your-repo-url&gt; </code>
-
-### Use GitHub Codespaces
-
-You can run this project directly in your browser by using GitHub Codespaces, which will open a web-based VS Code:
-
-[![Open in GitHub Codespaces](https://img.shields.io/static/v1?style=for-the-badge&label=GitHub+Codespaces&message=Open&color=blue&logo=github)](https://codespaces.new/Azure-Samples/serverless-chat-langchainjs?hide_repo_select=true&ref&quickstart=true)
-
-### Use a VSCode dev container
-
-A similar option to Codespaces is VS Code Dev Containers, that will open the project in your local VS Code instance using the [Dev Containers extension](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers).
-
-You will also need to have [Docker](https://www.docker.com/products/docker-desktop) installed on your machine to run the container.
-
-[![Open in Dev Containers](https://img.shields.io/static/v1?style=for-the-badge&label=Dev%20Containers&message=Open&color=blue&logo=visualstudiocode)](https://vscode.dev/redirect?url=vscode://ms-vscode-remote.remote-containers/cloneInVolume?url=https://github.com/Azure-Samples/serverless-chat-langchainjs)
-
-## Run the sample
-
-There are multiple ways to run this sample: locally using Ollama or Azure OpenAI models, or by deploying it to Azure.
-
-### Deploy the sample to Azure
-
-#### Azure prerequisites
-
-- **Azure account**. If you're new to Azure, [get an Azure account for free](https://azure.microsoft.com/free) to get free Azure credits to get started. If you're a student, you can also get free credits with [Azure for Students](https://aka.ms/azureforstudents).
-- **Azure subscription with access enabled for the Azure OpenAI service**. You can request access with [this form](https://aka.ms/oaiapply).
-- **Azure account permissions**:
-  - Your Azure account must have `Microsoft.Authorization/roleAssignments/write` permissions, such as [Role Based Access Control Administrator](https://learn.microsoft.com/azure/role-based-access-control/built-in-roles#role-based-access-control-administrator-preview), [User Access Administrator](https://learn.microsoft.com/azure/role-based-access-control/built-in-roles#user-access-administrator), or [Owner](https://learn.microsoft.com/azure/role-based-access-control/built-in-roles#owner). If you don't have subscription-level permissions, you must be granted [RBAC](https://learn.microsoft.com/azure/role-based-access-control/built-in-roles#role-based-access-control-administrator-preview) for an existing resource group and [deploy to that existing group](docs/deploy_existing.md#resource-group).
-  - Your Azure account also needs `Microsoft.Resources/deployments/write` permissions on the subscription level.
-
-#### Cost estimation
-
-See the [cost estimation](./docs/cost.md) details for running this sample on Azure.
-
-#### Deploy the sample
-
-1. Open a terminal and navigate to the root of the project.
-2. Authenticate with Azure by running `azd auth login`.
-3. Run `azd up` to deploy the application to Azure. This will provision Azure resources, deploy this sample, and build the search index based on the files found in the `./data` folder.
-   - You will be prompted to select a base location for the resources. If you're unsure of which location to choose, select `eastus2`.
-   - By default, the OpenAI resource will be deployed to `eastus2`. You can set a different location with `azd env set AZURE_OPENAI_RESOURCE_GROUP_LOCATION <location>`. Currently only a short list of locations is accepted. That location list is based on the [OpenAI model availability table](https://learn.microsoft.com/azure/ai-services/openai/concepts/models#standard-deployment-model-availability) and may become outdated as availability changes.
-
-The deployment process will take a few minutes. Once it's done, you'll see the URL of the web app in the terminal.
-
-<div align="center">
-  <img src="./docs/images/azd-up.png" alt="Screenshot of the azd up command result" width="600px" />
-</div>
-
-You can now open the web app in your browser and start chatting with the bot.
-
-##### Enhance security
-
-When deploying the sample in an enterprise context, you may want to enforce tighter security restrictions to protect your data and resources. See the [enhance security](./docs/enhance-security.md) guide for more information.
-
-#### Enable CI/CD
-
-If you want to enable Continuous Deployment for your forked repository, you need to configure the Azure pipeline first:
-
-1. Open a terminal at the root of your forked project.
-2. Authenticate with Azure by running `azd auth login`.
-3. Run `azd pipeline config` to configure the required secrets and variables for connecting to Azure from GitHub Actions.
-   - This command will set up the necessary Azure service principal and configure GitHub repository secrets.
-   - Follow the prompts to complete the configuration.
-
-Once configured, the GitHub Actions workflow will automatically deploy your application to Azure whenever you push changes to the main branch.
-
-#### Clean up
-
-To clean up all the Azure resources created by this sample:
-
-1. Run `azd down --purge`
-2. When asked if you are sure you want to continue, enter `y`
-
-The resource group and all the resources will be deleted.
-
-### Run the sample locally with Ollama
-
-If you have a machine with enough resources, you can run this sample entirely locally without using any cloud resources. To do that, you first have to install [Ollama](https://ollama.com) and then run the following commands to download the models on your machine:
-
-```bash
-ollama pull llama3.1:latest
-ollama pull nomic-embed-text:latest
-```
-
-> [!NOTE]
-> The `llama3.1` model with download a few gigabytes of data, so it can take some time depending on your internet connection.
-
-After that you have to install the NPM dependencies:
-
-```bash
-npm install
-```
-
-Then you can start the application by running the following command which will start the web app and the API locally:
-
-```bash
-npm start
-```
-
-Then, open a new terminal running concurrently and run the following command to upload the PDF documents from the `/data` folder to the API:
-
-```bash
-npm run upload:docs
-```
-
-This only has to be done once, unless you want to add more documents.
-
-You can now open the URL `http://localhost:8000` in your browser to start chatting with the bot.
-
-> [!NOTE]
-> While local models usually works well enough to answer the questions, sometimes they may not be able to follow perfectly the advanced formatting instructions for the citations and follow-up questions. This is expected, and a limitation of using smaller local models.
-
-### Run the sample locally with Azure OpenAI models
-
-First you need to provision the Azure resources needed to run the sample. Follow the instructions in the [Deploy the sample to Azure](#deploy-the-sample-to-azure) section to deploy the sample to Azure, then you'll be able to run the sample locally using the deployed Azure resources.
-
-Once your deployment is complete, you should see a `.env` file in the `packages/api` folder. This file contains the environment variables needed to run the application using Azure resources.
-
-To run the sample, you can then use the same commands as for the Ollama setup. This will start the web app and the API locally:
-
-```bash
-npm start
-```
-
-Open the URL `http://localhost:8000` in your browser to start chatting with the bot.
-
-Note that the documents are uploaded automatically when deploying the sample to Azure with `azd up`.
-
-> [!TIP]
-> You can switch back to using Ollama models by simply deleting the `packages/api/.env` file and starting the application again. To regenerate the `.env` file, you can run `azd env get-values > packages/api/.env`.
-
-## Resources
-
-Here are some resources to learn more about the technologies used in this sample:
-
-- [LangChain.js documentation](https://js.langchain.com)
-- [Generative AI with JavaScript](https://github.com/microsoft/generative-ai-with-javascript)
-- [Generative AI For Beginners](https://github.com/microsoft/generative-ai-for-beginners)
-- [Azure OpenAI Service](https://learn.microsoft.com/azure/ai-services/openai/overview)
-- [Azure Cosmos DB for NoSQL](https://learn.microsoft.com/azure/cosmos-db/nosql/)
-- [Ask YouTube: LangChain.js + Azure Quickstart sample](https://github.com/Azure-Samples/langchainjs-quickstart-demo)
-- [Chat + Enterprise data with Azure OpenAI and Azure AI Search](https://github.com/Azure-Samples/azure-search-openai-javascript)
-- [Revolutionize your Enterprise Data with Chat: Next-gen Apps w/ Azure OpenAI and AI Search](https://aka.ms/entgptsearchblog)
-
-You can also find [more Azure AI samples here](https://github.com/Azure-Samples/azureai-samples).
-
-## FAQ
-
-You can find answers to frequently asked questions in the [FAQ](./docs/faq.md).
-
-## Troubleshooting
-
-If you have any issue when running or deploying this sample, please check the [troubleshooting guide](./docs/troubleshooting.md). If you can't find a solution to your problem, please [open an issue](https://github.com/Azure-Samples/serverless-chat-langchainjs/issues) in this repository.
-
-## Guidance
-
-For more detailed guidance on how to use this sample, please refer to the [tutorial](./docs/tutorial/01-introduction.md).
-
-## Getting Help
-
-If you get stuck or have any questions about building AI apps, join:
-
-[![Azure AI Foundry Discord](https://img.shields.io/badge/Discord-Azure_AI_Foundry_Community_Discord-blue?style=for-the-badge&logo=discord&color=5865f2&logoColor=fff)](https://aka.ms/foundry/discord)
-
-If you have product feedback or errors while building visit:
-
-[![Azure AI Foundry Developer Forum](https://img.shields.io/badge/GitHub-Azure_AI_Foundry_Developer_Forum-blue?style=for-the-badge&logo=github&color=000000&logoColor=fff)](https://aka.ms/foundry/forum)
-
-## Contributing
-
-This project welcomes contributions and suggestions. Most contributions require you to agree to a
-Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us
-the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.
-
-When you submit a pull request, a CLA bot will automatically determine whether you need to provide
-a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions
-provided by the bot. You will only need to do this once across all repos using our CLA.
-
-This project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/).
-For more information see the [Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/) or
-contact [opencode@microsoft.com](mailto:opencode@microsoft.com) with any additional questions or comments.
-
-## Trademarks
-
-This project may contain trademarks or logos for projects, products, or services. Authorized use of Microsoft
-trademarks or logos is subject to and must follow
-[Microsoft's Trademark & Brand Guidelines](https://www.microsoft.com/en-us/legal/intellectualproperty/trademarks/usage/general).
-Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship.
-Any use of third-party trademarks or logos are subject to those third-party's policies.
diff --git a/.github/skills/create-readme/references/serverless-recipes-javascript-readme.md b/.github/skills/create-readme/references/serverless-recipes-javascript-readme.md
deleted file mode 100644
index d361fd69..00000000
--- a/.github/skills/create-readme/references/serverless-recipes-javascript-readme.md
+++ /dev/null
@@ -1,162 +0,0 @@
-<!-- prettier-ignore -->
-<div align="center">
-
-<img src="./docs/images/icon.png" alt="" align="center" height="96" />
-
-# Serverless Recipes for JavaScript/TypeScript
-
-[![Open project in GitHub Codespaces](https://img.shields.io/badge/Codespaces-Open-blue?style=flat-square&logo=github)](https://codespaces.new/Azure-Samples/serverless-recipes-javascript?hide_repo_select=true&ref=main&quickstart=true)
-[![Join Azure AI Foundry Discord](https://img.shields.io/badge/Discord-Azure_AI_Community-blue?style=flat-square&logo=discord&color=5865f2&logoColor=fff)](https://aka.ms/foundry/discord)
-[![Build Status](https://img.shields.io/github/actions/workflow/status/Azure-Samples/serverless-recipes-javascript/build-test.yaml?style=flat-square&label=Build)](https://github.com/Azure-Samples/serverless-recipes-javascript/actions)
-![Node version](https://img.shields.io/badge/Node.js->=20-3c873a?style=flat-square)
-[![TypeScript](https://img.shields.io/badge/TypeScript-blue?style=flat-square&logo=typescript&logoColor=white)](https://www.typescriptlang.org)
-[![License](https://img.shields.io/badge/License-MIT-yellow?style=flat-square)](LICENSE)
-
-⭐ If you like this project, star it on GitHub — it helps a lot!
-
-[Get started](#getting-started) • [Run the samples](#run-the-samples) • [Samples list](#samples-list) • [Resources](#resources) • [Troubleshooting](#troubleshooting)
-
-</div>
-
-This repository is a collection of code examples demonstrating how to build serverless applications using TypeScript and Azure. Each recipe is a standalone sample that demonstrates how to build a specific feature or use a specific technology. You can use these samples as a starting point for your own projects or to learn more about serverless development with Azure.
-
-> [!NOTE]
-> **What's Serverless?**<br>
-> Serverless computing allows you to build and run applications without managing infrastructure. You can focus on your code and let the cloud provider handle the rest. Azure provides a wide range of serverless services, including [Azure Functions](https://learn.microsoft.com/azure/azure-functions/functions-overview?pivots=programming-language-javascript), [Azure Static Web Apps]([Azure Static Web Apps](https://learn.microsoft.com/azure/static-web-apps/overview), [Azure Cosmos DB](https://learn.microsoft.com/azure/cosmos-db/nosql/), and more.
-
-## Why serverless?
-
-Let's say you're a developer for the Contoso Solutions company, and you've been tasked to build new applications with a fast turnaround time, startup style. You need to build these apps quickly with a low initial budget, and you don't want to worry about managing servers, scaling, or infrastructure. **You want to focus on writing code and delivering value to your users.**
-
-*This is exactly where serverless is a great fit!*
-
-While walking through this collection of ready-to-use code examples, you'll learn how to solve common problems and build applications using many of the serverless technologies available on Azure. The best part? You only need to pay attention to the code and the business logic, all samples are ready to deploy and run in your Azure account.
-
-## Prerequisites
-- **Azure account**. If you're new to Azure, [get an Azure account for free](https://azure.microsoft.com/free) to get free Azure credits to get started. If you're a student, you can also get free credits with [Azure for Students](https://aka.ms/azureforstudents).
-- **GitHub account**. If you don't have one, you can [create a free GitHub account](https://github.com/signup). You can optionally use [GitHub Copilot Free](https://github.com/features/copilot) to help you write code and ship your application even faster.
-
-## Getting started
-
-There are multiple ways to get started with this project.
-
-The quickest way is to use [GitHub Codespaces](#use-github-codespaces) that provides a preconfigured environment for you. Alternatively, you can [set up your local environment](#use-your-local-environment) following the instructions below.
-
-<details open>
-<summary><h3>Use GitHub Codespaces</h3></summary>
-
-You can run this project directly in your browser by using GitHub Codespaces, which will open a web-based VS Code:
-
-[![Open in GitHub Codespaces](https://img.shields.io/static/v1?style=flat-square&label=GitHub+Codespaces&message=Open&color=blue&logo=github)](https://codespaces.new/Azure-Samples/serverless-recipes-javascript?hide_repo_select=true&ref&quickstart=true)
-
-</details>
-
-<details>
-<summary><h3>Use a VSCode dev container</h3></summary>
-
-A similar option to Codespaces is VS Code Dev Containers, that will open the project in your local VS Code instance using the [Dev Containers extension](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers).
-
-You will also need to have [Docker](https://www.docker.com/get-started/) installed on your machine to run the container.
-
-[![Open in Dev Containers](https://img.shields.io/static/v1?style=flat-square&label=Dev%20Containers&message=Open&color=blue&logo=visualstudiocode)](https://vscode.dev/redirect?url=vscode://ms-vscode-remote.remote-containers/cloneInVolume?url=https://github.com/Azure-Samples/serverless-recipes-javascript)
-
-</details>
-
-<details>
-<summary><h3>Use your local environment</h3></summary>
-
-You need to install following tools to work on your local machine:
-
-- [Node.js LTS](https://nodejs.org/en/download)
-- [Azure Developer CLI](https://aka.ms/azure-dev/install)
-- [Git](https://git-scm.com/downloads)
-- [PowerShell 7+](https://github.com/powershell/powershell) _(for Windows users only)_
-  - **Important**: Ensure you can run `pwsh.exe` from a PowerShell command. If this fails, you likely need to upgrade PowerShell.
-  - Instead of Powershell, you can also use Git Bash or WSL to run the Azure Developer CLI commands.
-- [Azure Functions Core Tools](https://learn.microsoft.com/azure/azure-functions/functions-run-local?tabs=macos%2Cisolated-process%2Cnode-v4%2Cpython-v2%2Chttp-trigger%2Ccontainer-apps&pivots=programming-language-javascript) _(should be installed automatically with NPM, only install manually if the API fails to start)_
-
-Then you can get the project code:
-
-1. [**Fork**](https://github.com/Azure-Samples/serverless-recipes-javascript/fork) the project to create your own copy of this repository.
-2. On your forked repository, select the **Code** button, then the **Local** tab, and copy the URL of your forked repository.
-
-   ![Screenshot showing how to copy the repository URL](./docs/images/clone-url.png)
-3. Open a terminal and run this command to clone the repo: `git clone <your-repo-url>`
-
-</details>
-
-## Run the samples
-
-After setting up your environment, you can deploy and run any of the samples. Each sample is a standalone project that you can run independently. Follows these steps to run a sample:
-
-```bash
-# Open the sample directory
-cd samples/<sample-name>
-
-# Install dependencies
-npm install
-
-# Deploy the sample to Azure
-azd auth login
-azd up
-```
-
-Once the initial deployment is completed, you can also run the sample locally with `npm start`.
-You can check the `README.md` file in each sample directory for more specific instructions.
-
-## Samples list
-
-<!-- #begin-samples -->
-
-| | Sample | Deployment Time | Video | Blog |
-| --- |:--- | --- | --- | --- |
-| <img src="./samples/openai-extension-embeddings/docs/images/icon.png" width="32px"/> | [Azure Functions OpenAI extension - embeddings](./samples/openai-extension-embeddings) | 5min | - | - |
-| <img src="./samples/openai-extension-textcompletion/docs/images/icon.png" width="32px"/> | [Azure Functions OpenAI extension - text completion](./samples/openai-extension-textcompletion) | 5min | - | - |
-
-<!-- #end-samples -->
-
-## Resources
-
-Here are some additional resources to learn more about the technologies used:
-
-- [Serverless Node.js with Azure Functions](https://learn.microsoft.com/azure/developer/javascript/how-to/develop-serverless-apps?tabs=v4-ts) (Microsoft Learn)
-- [Azure Cosmos DB for NoSQL](https://learn.microsoft.com/azure/cosmos-db/nosql/) (Microsoft Learn)
-- [Azure OpenAI Service](https://learn.microsoft.com/azure/ai-services/openai/overview) (Microsoft Learn)
-- [Generative AI with JavaScript](https://github.com/microsoft/generative-ai-with-javascript) (GitHub)
-- [Serverless AI Chat with RAG using LangChain.js](https://github.com/Azure-Samples/serverless-chat-langchainjs) (GitHub)
-
-## Troubleshooting
-
-If you have any issue when running or deploying the samples, please check the [troubleshooting guide](./docs/troubleshooting.md). If you can't find a solution to your problem, please [open an issue](https://github.com/Azure-Samples/serverless-recipes-javascript/issues) in this repository.
-
-## Getting Help
-
-If you get stuck or have any questions about building AI apps, join:
-
-[![Azure AI Foundry Discord](https://img.shields.io/badge/Discord-Azure_AI_Foundry_Community_Discord-blue?style=for-the-badge&logo=discord&color=5865f2&logoColor=fff)](https://aka.ms/foundry/discord)
-
-If you have product feedback or errors while building visit:
-
-[![Azure AI Foundry Developer Forum](https://img.shields.io/badge/GitHub-Azure_AI_Foundry_Developer_Forum-blue?style=for-the-badge&logo=github&color=000000&logoColor=fff)](https://aka.ms/foundry/forum)
-
-## Contributing
-
-This project welcomes contributions and suggestions. Most contributions require you to agree to a
-Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us
-the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.
-
-When you submit a pull request, a CLA bot will automatically determine whether you need to provide
-a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions
-provided by the bot. You will only need to do this once across all repos using our CLA.
-
-This project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/).
-For more information see the [Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/) or
-contact [opencode@microsoft.com](mailto:opencode@microsoft.com) with any additional questions or comments.
-
-## Trademarks
-
-This project may contain trademarks or logos for projects, products, or services. Authorized use of Microsoft
-trademarks or logos is subject to and must follow
-[Microsoft's Trademark & Brand Guidelines](https://www.microsoft.com/en-us/legal/intellectualproperty/trademarks/usage/general).
-Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship.
-Any use of third-party trademarks or logos are subject to those third-party's policies.
diff --git a/.github/skills/create-readme/references/smoke-readme.md b/.github/skills/create-readme/references/smoke-readme.md
deleted file mode 100644
index fd2fc808..00000000
--- a/.github/skills/create-readme/references/smoke-readme.md
+++ /dev/null
@@ -1,366 +0,0 @@
-# :dash: smoke
-
-[![NPM version](https://img.shields.io/npm/v/smoke.svg)](https://www.npmjs.com/package/smoke)
-[![Build Status](https://github.com/sinedied/smoke/workflows/build/badge.svg)](https://github.com/sinedied/smoke/actions)
-![Node version](https://img.shields.io/node/v/smoke.svg)
-[![XO code style](https://img.shields.io/badge/code_style-XO-5ed9c7.svg)](https://github.com/sindresorhus/xo)
-[![License](https://img.shields.io/badge/license-MIT-blue.svg)](LICENSE)
-
-> Simple yet powerful file-based mock server with recording abilities
-
-![demo](https://user-images.githubusercontent.com/593151/49312821-9f2cc680-f4e5-11e8-900a-117120c38422.gif)
-
-Just drop a bunch of (JSON) files in a folder and you're ready to go!
-
-### Basic mock example
-1. Start the server: `smoke`
-2. Create a file named `get_api#hello.json`:
-    ```json
-    {
-      "message": "hello world!"
-    }
-    ```
-3. Test the mock: `curl http://localhost:3000/api/hello`
-
-### Features
-
-**Smoke** is a file-based, convention over configuration mock server that can fill your API mocking needs without any
-complex setup. Yet, it supports many advanced features and dynamic mocks for almost any situation:
-
-- Generate mocks quickly by recording responses from an existing server
-- Use folders and file names to describe API routes and REST methods
-- Use templates to generate responses based on input queries and route parameters
-- Add / edit / remove mocks without restarting the server
-- Generate mocks with JavaScript for more complex responses
-- Define different mock sets to simulate various scenarii (errors...), with fallback
-- Customize headers and status code if needed, automatically detect content-type if not specified
-- Add custom middlewares to modify requests/responses
-- Mock only specific requests and proxy the rest to an existing server
-- Supports CORS (cross-origin resource-sharing)
-
-## Installation
-
-```bash
-npm install -g smoke
-```
-
-## Usage
-
-See [some example mocks](test/mocks) to quickly get a grasp of the syntax and possibilities.
-
-CLI usage is quite straightforward you can just run `smoke` unless you want to add some options:
-```
-Usage: smoke [<mocks_folder>] [options]
-
-Base options:
-  -p, --port <num>                  Server port           [default: 3000]
-  -h, --host <host>                 Server host           [default: "localhost"]
-  -s, --set <name>                  Mocks set to use      [default: none]
-  -n, --not-found <glob>            Mocks for 404 errors  [default: "404.*"]
-  -i, --ignore <glob>               Files to ignore       [default: none]
-  -k, --hooks <file>                Middleware hooks      [default: none]
-  -x, --proxy <host>                Fallback proxy if no mock found
-  -o, --allow-cors [all|<hosts>]    Enable CORS requests  [default: none]
-  --https                           Enable secure request serving with HTTPS [default: false]
-  -l, --logs                        Enable server logs
-  -v, --version                     Show version
-  --help                            Show help
-
-Mock recording:
-  -r, --record <host>               Proxy & record requests if no mock found
-  -c, --collection <file>           Save to single file mock collection
-  -d, --depth <N>                   Folder depth for mocks  [default: 1]
-  -a, --save-headers                Save response headers
-  -q, --save-query                  Save query parameters
-```
-
-### File naming
-
-**General format:** `methods_api#route#@routeParam$queryParam=value.__set.extension`
-
-The path and file name of the mock is used to determinate:
-
-#### Supported HTTP methods
-Optionally prefix your file by the HTTP method supported followed by an underscore (for example `get_`).
-You can specify multiple methods at once using a `+` to separate them (for example `post+put_`);
-If no method is specified, the mock will be used for any HTTP method.
-
-#### Server route and named route parameters
-Use any combination of folders or hash-separated components to specify the server route.
-
-For example `api/example/get_hello.json` is equivalent to `get_api#example#hello.json` and will respond to
-`GET api/example/hello` requests.
-
-Additionaly, any route component can be defined as a route parameter by prefixing the name with `@`, for example
-`api#resource#@id.json` will match `GET api/resource/1` and expose `1` as the value for the `id` parameter that can be
-used in dynamic mocks (templates or JavaScript).
-
-#### Query parameters
-You can further discriminate mocks by adding query parameters to match after defining the route, using a `$` (instead
-of the regular `?`) like you would specify them in a request.
-
-For example `get_api#hello$who=john.json` will match the request `api/get_hello?who=john.json`.
-
-Multiple query parameters to match can be added with `&`, for example `get_api#hello$who=john&greet=hi.json`.
-Any specified query parameter in the file name must be matched (in any order) by the request, but the opposite is not
-needed.
-
-Note that special characters must be URL-encoded, for example use `get_api#hello$who=john%20doe.json` to set the
-parameter `who` with the value `john doe`.
-
-> Tip: If you need to URL-encode a string, just run `node -p "encodeURIComponent('some string')"` in a terminal.
-
-#### Content type
-The file extension will determine the content type of the response if it's not already specified in a
-[custom header](#custom-status-and-headers).
-
-Files with no extension will use the default MIME type `application/octet-stream`.
-
-You can have multiple mocks with the same API route and different file extensions, the server will then use the best
-mock depending of the [`Accept` header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept) of the
-request.
-
-#### Mock set
-You can optionally specify a mock set before the file extension by using a `__set-name` suffix after the file name.
-
-For example `get_api#hello__error.json` will only be used if you start the server with the `error` set enabled:
-`smoke --set error`.
-
-If you do not specify a mock set on your file name, it will be considered as the default mock for the specified route
-and will be used as a fallback if no mock with this set matched.
-
-#### Templates
-If you add an underscore `_` after the file extension, the mock will be processed as a template before being sent to
-the client. Templates works only on text-based formats.
-
-For example `get_hello.html_` or `get_hello.json_` will be treated as templates. 
-
-Every template can use an implicit context object that have these properties defined:
-- `method`: the HTTP method of the request (ex: `'GET'`, `'POST'`)
-- `query`: map with query parameters that were part of the request URL. For example, matched URL
-  `http://server/hello?who=world` will result in the query value: `{ who: 'world' }`.
-- `params`: map containing matched route parameters. For example the mock `resource#@id.json_` with the matched URL
-  `http://server/resource/123` will result in the params value: `{ id: '123' }`.
-- `headers`: map containing request headers
-- `body`: the request body. JSON bodies are automatically parsed.
-- `files`: if the request includes `multipart/form-data`, this will be the array of uploaded files (see
-  [multer documentation](https://github.com/expressjs/multer) for more details)
-
-##### Template syntax
-
-- `{{ }}` interpolates data in place
-
-  For example, create **get_hello.txt_** with this:
-  ```
-  Hello {{query.name}}!
-  ```
-
-  Then `curl "http://localhost:3000/hello?name=John"` returns `Hello John!`
-
-- `{{{ }}}` escapes HTML special chars from interpolated string
-
-  For example, create **get_hello.html_** with this:
-  ```html
-  <h1>Hello {{{query.name}}}!</h1>
-  ```
-
-  Then `curl "http://localhost:3000/hello?name=%3CJack%26Jones%3E"` returns:
-  ```html
-  <h1>Hello &lt;Jack&amp;Jones&gt;!</h1>
-  ```
-
-- `<{ }>` evaluates JavaScript to generate data
-
-  For example, create **get_hello.html_** with this:
-  ```html
-  Hello to:
-  <ul>
-    <{ query.name.forEach(name => { }><li>{{name}}</li><{ }); }>
-  </ul>
-  ```
-
-  Then `curl "http://localhost:3000/hello?name=Jack&name=Jones"` returns:
-  ```html
-  Hello to:
-  <ul>
-    <li>Jack</li><li>Jones</li>
-  </ul>
-  ```
-
-### Custom status and headers
-
-By default all mocks responses are sent with a status code `200` (OK), or `204` (No content) if a mock file is empty.
-
-You can customize the response status and (optionally) headers with JSON and [JavaScript](#javascript-mocks) files,
-using this syntax:
-```js
-{
-  "statusCode": 400,
-  "body": {
-    "error": "Bad request"
-  },
-  // headers can be omitted, only use if you want to customize them
-  "headers": {
-    "Content-Type": "text/plain"
-  } 
-}
-```
-
-You can also use non-string content type if you encode the content as a base64 string in the `body` property and add
-the property `"buffer": true` to the mock:
-```js
-{
-  "statusCode": 200,
-  "body": "U21va2Ugcm9ja3Mh",
-  "buffer": true,
-  "headers": {
-    "Content-Type": "application/octet-stream"
-  } 
-}
-```
-
-### Mock formats
-
-Any file format is supported for mocks, and the file extension will be used to determine the response content type.
-Files with no extension will use the default MIME type `application/octet-stream`.
-
-Text formats (for example `.json`, `.html`, `.txt`...) can be processed as [templates](#templates) by adding an
-underscore to the file extension.
-
-Note that JSON files and templates must use `UTF-8` encoding.
-
-#### JavaScript mocks
-
-In addition, you can define dynamic mocks using JavaScript by using the `.js` extension, that will be loaded as a regular
-Node.js module.
-
-In that case, your JS module is expected to export a function that take an input data object with the
-[same properties](#templates) as for templates and must returns the response body or an
-[object](#custom-status-and-headers) containing the status code, headers and body.
-
-Example:
-```js
-export default (data) => `{ "data": "Your user agent is: ${data.headers['user-agent']}" }`;
-```
-
-Note that by default, JS mocks use `application/json` for the response content type. If you want to use another type,
-you must set the `Content-Type` header yourself, for example:
-```js
-export default data => ({
-  statusCode: 200,
-  headers: {
-    'Content-Type': 'text/plain'
-  },
-  body: `Your user agent is: ${data.headers['user-agent']}`
-});
-```
-
-### Fallback proxy
-
-If you want to override responses of an existing server, you can use the `--proxy <host>` option. This will proxy
-every request for which a mock does not exist to the specified host.
-
-This can also be useful for mocking yet-to-be-implemented APIs and keep using real implemented APIs.
-
-### Mock recording
-
-To quickly create a mock set of an existing server (to allow working offline for example), you can use the
-`--record <host>` option. This will proxy every request for which a mock does not exist to the specified host, and
-record the resulting response as a mock file.
-
-You can change the maximum folder depth for mock files created this way using the `--depth` option.
-
-The recorded mock set can also be changed using the `--set` option.
-
-Instead of recoring separate mock files, you can also record to a
-[single file mock collection](#single-file-mock-collection) using the `--collection <file>` option. 
-
-Note that by default response headers and request query parameters are not saved. To change this behavior, you can
-use the `--save-headers` and `--save-query` options.
-
-### Middleware hooks
-
-For more advanced usages, you can hook on any standard
-[Express middleware](https://expressjs.com/en/guide/writing-middleware.html) to modify the request and/or the response
-returned by the server.
-
-To hook on your own middlewares, use the `--hooks` to specify a JavaScript module with exports setup like this:
-```js
-export const before = []; // middlewares to be executed before the request is processed
-export const after = [];  // middlewares to be executed after the request has been processed
-```
-
-Middlewares executed before the request is processed can be used to bypass regular mock response, for example to
-randomly simulate a server failure with an early error 500 response.
-
-On the other hand, middlewares executed after the request have been processed can be used to augment or modify the
-response, for example by adding header or changing the response status. You can also access and modify the response
-body by using the special `res.body` property.
-
-Remember that once you have used `.send()`, `.sendStatus` or `.json()` in a middleware the response cannot be altered
-anymore, that's why you should use the `res.body` property instead if you plan to alter the response later on.
-
-See some [example hooks](test/hooks.js).
-
-## Enabling CORS
-
-Smoke offers support to requests originating from a different origin. However, by default, this would be disabled.
-
-To enable CORS, pass the hosts that you want to allow to `-o` or `--allow-cors` arguments.
-
-**Accepted Values**
-- `all` - Allow requests from `*`
-- `<hosts>` - You could also pass a comma-separated list of hosts that you want to allow requests from something like `'http://localhost:3000,http://example.com'`
-
-### Single file mock collection
-
-You can regroup multiple mocks in a special single file with the extension `.mocks.js`, using this format:
-```js
-export default {
-  '<file_name>': '<file_content>' // can be a string, an object (custom response) or a function (JavaScript mock)
-};
-```
-See this [example mock collection](test/mocks/collection.mocks.js) to get an idea of all possibilities.
-
-The format of file name is the same as for individual mock files, and will be used to match the request using the same
-rules. As for the mock content, the format is also the same as what you would put in single file mock. If a request
-matches both a mock file and a mock within a collection with the same specificity, the mock file will always be used
-over the collection.
-
-As the format is the same, you can convert a bunch of files to a single file mock collection and conversely.
-To convert separate mock files to a collection:
-```sh
-smoke-conv <glob> <output_file>  // Will create <output_file>.mocks.js from all mocks found
-```
-
-To convert a mock collection to separate files:
-```sh
-smoke-conv <file> <output_folder>  // Will extract separate mocks into <output_folder>
-```
-
-Note that only text-based file content will be inserted directly, other file content will be converted to a base64
-string.
-
-:warning: There is a limitation regarding JavaScript mocks: only the exported function will be converted for a given
-mock, meaning that if you have non-exported functions, variables or imports they will be lost during the conversion.
-
-## Migration from v1/v2/v3 to v4
-
-If you are migrating from a previous version of Smoke, you need to be aware that the default module format has changed: earlier version used CommonJS modules, while v4 uses ES modules by default.
-
-But don't worry! You don't have to regenerate or updates all your mock files, Smoke will still support the CommonJS format for backward compatibility, though you need to rename all your `*.js` mocks, collections and hooks files to use the `.cjs` extension instead of `.js`.
-
-If you prefer to migrate your existing mock files to the new ES module format, you can do so by updating the export syntax to use `export default` instead of `module.exports` in mock files and collections, and `export` the `before` and `after` hooks constant separately in hooks fles.
-
-> [!NOTE]
-> If you try to record new mocks into an existing collection in CommonJS format, the result will be saved into a new collection in ES modules format.
-
-## Other mock servers
-
-If you cannot find what you need here, you might want to check out one of these other Node.js mock servers:
-
-- [JSON Server](https://github.com/typicode/json-server)
-- [mockserver](https://github.com/namshi/mockserver)
-- [node-mock-server](https://github.com/smollweide/node-mock-server)
-- [node-easymock](https://github.com/CyberAgent/node-easymock)
-- [mockserver-node](https://github.com/jamesdbloom/mockserver-node)
diff --git a/.github/skills/csharp-docs/SKILL.md b/.github/skills/csharp-docs/SKILL.md
deleted file mode 100644
index 27b228eb..00000000
--- a/.github/skills/csharp-docs/SKILL.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-name: csharp-docs
-description: Adds and reviews C# XML documentation comments following Microsoft's documentation standards. Use when writing or reviewing C# code that includes public APIs, complex logic, or when documentation is missing or insufficient. Covers <summary>, <param>, <returns>, <exception>, <remarks>, and all standard XML doc tags.
----
-
-# C# Documentation Best Practices
-
-## General Guidelines
-
-- Public members should be documented with XML comments.
-- It is encouraged to document internal members as well, especially if they are complex or not self-explanatory.
-
-## Guidance for all APIs
-
-- Use `<summary>` to provide a brief, one sentence, description of what the type or member does. Start the summary with a present-tense, third-person verb.
-- Use `<remarks>` for additional information, which can include implementation details, usage notes, or any other relevant context.
-- Use `<see langword>` for language-specific keywords like `null`, `true`, `false`, `int`, `bool`, etc.
-- Use `<c>` for inline code snippets.
-- Use `<example>` for usage examples on how to use the member.
-  - Use `<code>` for code blocks. `<code>` tags should be placed within an `<example>` tag. Add the language of the code example using the `language` attribute, for example, `<code language="csharp">`.
-- Use `<see cref>` to reference other types or members inline (in a sentence).
-- Use `<seealso>` for standalone (not in a sentence) references to other types or members in the "See also" section of the online docs.
-- Use `<inheritdoc/>` to inherit documentation from base classes or interfaces.
-  - Unless there is major behavior change, in which case you should document the differences.
-
-## Member-Specific Rules
-
-See [member-documentation-rules.md](./references/member-documentation-rules.md) for detailed wording conventions for methods (`<param>`, `<returns>`), constructors, properties (`<value>`, Gets/Sets patterns), and exceptions (`<exception cref>`).
diff --git a/.github/skills/csharp-docs/references/member-documentation-rules.md b/.github/skills/csharp-docs/references/member-documentation-rules.md
deleted file mode 100644
index 8f58133f..00000000
--- a/.github/skills/csharp-docs/references/member-documentation-rules.md
+++ /dev/null
@@ -1,41 +0,0 @@
-# Member-Specific Documentation Rules
-
-## Methods
-
-- Use `<param>` to describe method parameters.
-  - The description should be a noun phrase that doesn't specify the data type.
-  - Begin with an introductory article.
-  - If the parameter is a flag enum, start the description with "A bitwise combination of the enumeration values that specifies...".
-  - If the parameter is a non-flag enum, start the description with "One of the enumeration values that specifies...".
-  - If the parameter is a Boolean, the wording should be of the form "`<see langword="true" />` to ...; otherwise, `<see langword="false" />`.".
-  - If the parameter is an "out" parameter, the wording should be of the form "When this method returns, contains .... This parameter is treated as uninitialized.".
-- Use `<paramref>` to reference parameter names in documentation.
-- Use `<typeparam>` to describe type parameters in generic types or methods.
-- Use `<typeparamref>` to reference type parameters in documentation.
-- Use `<returns>` to describe what the method returns.
-  - The description should be a noun phrase that doesn't specify the data type.
-  - Begin with an introductory article.
-  - If the return type is Boolean, the wording should be of the form "`<see langword="true" />` if ...; otherwise, `<see langword="false" />`.".
-
-## Constructors
-
-- The summary wording should be "Initializes a new instance of the <Class> class [or struct].".
-
-## Properties
-
-- The `<summary>` should start with:
-  - "Gets or sets..." for a read-write property.
-  - "Gets..." for a read-only property.
-  - "Gets [or sets] a value that indicates whether..." for properties that return a Boolean value.
-- Use `<value>` to describe the value of the property.
-  - The description should be a noun phrase that doesn't specify the data type.
-  - If the property has a default value, add it in a separate sentence, for example, "The default is `<see langword="false" />`".
-  - If the value type is Boolean, the wording should be of the form "`<see langword="true" />` if ...; otherwise, `<see langword="false" />`. The default is ...".
-
-## Exceptions
-
-- Use `<exception cref>` to document exceptions thrown by constructors, properties, indexers, methods, operators, and events.
-- Document all exceptions thrown directly by the member.
-- For exceptions thrown by nested members, document only the exceptions users are most likely to encounter.
-- The description of the exception describes the condition under which it's thrown.
-  - Omit "Thrown if ..." or "If ..." at the beginning of the sentence. Just state the condition directly, for example "An error occurred when accessing a Message Queuing API."
diff --git a/.github/skills/dotnet-aspnet/SKILL.md b/.github/skills/dotnet-aspnet/SKILL.md
deleted file mode 100644
index 1a6a094e..00000000
--- a/.github/skills/dotnet-aspnet/SKILL.md
+++ /dev/null
@@ -1,372 +0,0 @@
----
-name: dotnet-aspnet
-description: ASP.NET Core best practices for building Web and REST APIs. Use when creating controllers, minimal APIs, configuring middleware, routing, model binding, validation, dependency injection, authentication, authorization, error handling with ProblemDetails, OpenAPI/Swagger, health checks, CORS, rate limiting, or structuring an ASP.NET Core project.
----
-
-# ASP.NET Core Web API Best Practices
-
-## Project Structure
-
-- Organize code by feature/domain, not by layer (avoid generic `Controllers/`, `Services/`, `Models/` folders)
-- Use `Program.cs` as the composition root — register services, configure middleware pipeline
-- Keep `Program.cs` lean by extracting registration into extension methods (e.g., `AddApplicationServices()`, `AddAuthenticationServices()`)
-- Use feature folders:
-  ```
-  Features/
-    Orders/
-      OrdersController.cs
-      CreateOrderRequest.cs
-      OrderResponse.cs
-      OrderService.cs
-    Products/
-      ...
-  ```
-
-## Controllers vs Minimal APIs
-
-### Controllers
-
-Use controllers for larger APIs with shared conventions, filters, and complex routing:
-
-```csharp
-[ApiController]
-[Route("api/[controller]")]
-public class OrdersController(IOrderService orderService) : ControllerBase
-{
-    [HttpGet("{id:guid}")]
-    [ProducesResponseType<OrderResponse>(StatusCodes.Status200OK)]
-    [ProducesResponseType(StatusCodes.Status404NotFound)]
-    public async Task<IActionResult> GetById(Guid id, CancellationToken ct)
-    {
-        var order = await orderService.GetByIdAsync(id, ct);
-        return order is null ? NotFound() : Ok(order);
-    }
-}
-```
-
-- Always use `[ApiController]` attribute — enables automatic model validation, binding source inference, and ProblemDetails responses
-- Use primary constructor injection for dependencies
-- Return `IActionResult` or `ActionResult<T>` for endpoints with multiple response types
-- Accept `CancellationToken` on all async endpoints
-
-### Minimal APIs
-
-Use minimal APIs for simple endpoints, microservices, or when startup performance matters:
-
-```csharp
-var group = app.MapGroup("/api/orders")
-    .WithTags("Orders")
-    .RequireAuthorization();
-
-group.MapGet("/{id:guid}", async (Guid id, IOrderService service, CancellationToken ct) =>
-{
-    var order = await service.GetByIdAsync(id, ct);
-    return order is null ? Results.NotFound() : Results.Ok(order);
-})
-.WithName("GetOrderById")
-.Produces<OrderResponse>()
-.ProducesProblem(StatusCodes.Status404NotFound);
-```
-
-- Use `MapGroup()` to share route prefixes, filters, and metadata
-- Use `TypedResults` instead of `Results` for compile-time response type verification
-- Add `.WithName()` for OpenAPI operation IDs and link generation
-- Use endpoint filters for cross-cutting concerns
-
-## Routing & Endpoints
-
-- Use attribute routing on controllers (`[Route]`, `[HttpGet]`, etc.)
-- Apply route constraints: `{id:guid}`, `{page:int:min(1)}`, `{slug:regex(^[a-z-]+$)}`
-- Use API versioning via URL segment (`/api/v1/orders`) or header-based versioning with `Asp.Versioning.Http`
-- Keep route templates consistent — plural nouns for resources (`/api/orders`, not `/api/order`)
-- Use `LinkGenerator` for generating URLs to named endpoints
-
-## Model Binding & Validation
-
-- Use binding source attributes explicitly: `[FromBody]`, `[FromQuery]`, `[FromRoute]`, `[FromHeader]`
-- With `[ApiController]`, complex types default to `[FromBody]`, simple types to `[FromRoute]`/`[FromQuery]`
-- Validate with Data Annotations or FluentValidation:
-
-```csharp
-public record CreateOrderRequest(
-    [Required] string CustomerId,
-    [Required, MinLength(1)] List<OrderItemRequest> Items);
-```
-
-- For FluentValidation: register validators via `AddValidatorsFromAssemblyContaining<T>()` and use a validation filter or `IEndpointFilter`
-- Return `ValidationProblemDetails` (automatic with `[ApiController]`) for validation failures
-
-## Dependency Injection
-
-- Register services in `Program.cs` or via extension methods
-- Use appropriate lifetimes:
-  - **Transient**: Stateless, lightweight services
-  - **Scoped**: Per-request services (DbContext, unit of work)
-  - **Singleton**: Thread-safe, shared state (caches, configuration)
-- Use keyed services (.NET 8+) when multiple implementations of the same interface are needed:
-  ```csharp
-  builder.Services.AddKeyedScoped<IPaymentGateway, StripeGateway>("stripe");
-  builder.Services.AddKeyedScoped<IPaymentGateway, PayPalGateway>("paypal");
-  ```
-- Prefer interface-based registration for testability
-- Avoid service locator pattern — do not inject `IServiceProvider` into business logic
-
-## Middleware Pipeline
-
-Order matters — register middleware in the correct sequence:
-
-```csharp
-app.UseExceptionHandler();
-app.UseStatusCodePages();
-app.UseHsts();
-app.UseHttpsRedirection();
-app.UseCors();
-app.UseAuthentication();
-app.UseAuthorization();
-app.UseRateLimiter();
-app.UseOutputCache();
-app.MapControllers();
-```
-
-### Custom Middleware
-
-```csharp
-public class RequestTimingMiddleware(RequestDelegate next)
-{
-    public async Task InvokeAsync(HttpContext context)
-    {
-        var sw = Stopwatch.StartNew();
-        context.Response.OnStarting(() =>
-        {
-            context.Response.Headers["X-Response-Time-Ms"] = sw.ElapsedMilliseconds.ToString();
-            return Task.CompletedTask;
-        });
-        await next(context);
-    }
-}
-```
-
-- Use primary constructors for middleware
-- Inject scoped services via `InvokeAsync` parameters, not the constructor
-- Keep middleware focused — one concern per middleware
-
-## Configuration
-
-- Use the Options pattern for strongly-typed configuration:
-
-```csharp
-public class SmtpOptions
-{
-    public const string SectionName = "Smtp";
-    public required string Host { get; init; }
-    public int Port { get; init; } = 587;
-    public required string Username { get; init; }
-}
-
-builder.Services.AddOptions<SmtpOptions>()
-    .BindConfiguration(SmtpOptions.SectionName)
-    .ValidateDataAnnotations()
-    .ValidateOnStart();
-```
-
-- Use `ValidateOnStart()` to catch configuration errors at startup, not at first use
-- Use `appsettings.json` for defaults, `appsettings.{Environment}.json` for overrides
-- Use User Secrets (`dotnet user-secrets`) for local development — never commit secrets
-- Use environment variables or a vault for production secrets
-- Inject `IOptions<T>` for static config, `IOptionsMonitor<T>` for reloadable config
-
-## Authentication & Authorization
-
-### JWT Bearer Authentication
-
-```csharp
-builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
-    .AddJwtBearer(options =>
-    {
-        options.Authority = builder.Configuration["Auth:Authority"];
-        options.Audience = builder.Configuration["Auth:Audience"];
-    });
-```
-
-### Authorization Policies
-
-```csharp
-builder.Services.AddAuthorizationBuilder()
-    .AddPolicy("AdminOnly", policy => policy.RequireRole("Admin"))
-    .AddPolicy("CanEditOrder", policy =>
-        policy.Requirements.Add(new OrderOwnerRequirement()));
-```
-
-- Use policy-based authorization over role checks in attributes
-- Apply `[Authorize]` at controller level, `[AllowAnonymous]` for exceptions
-- Implement `IAuthorizationHandler` for resource-based authorization
-- For minimal APIs use `.RequireAuthorization("PolicyName")`
-
-## Error Handling
-
-### ProblemDetails (RFC 9457)
-
-```csharp
-builder.Services.AddProblemDetails(options =>
-{
-    options.CustomizeProblemDetails = ctx =>
-    {
-        ctx.ProblemDetails.Extensions["traceId"] = ctx.HttpContext.TraceIdentifier;
-    };
-});
-```
-
-### Global Exception Handling (.NET 8+)
-
-```csharp
-public class GlobalExceptionHandler(ILogger<GlobalExceptionHandler> logger) : IExceptionHandler
-{
-    public async ValueTask<bool> TryHandleAsync(
-        HttpContext context, Exception exception, CancellationToken ct)
-    {
-        logger.LogError(exception, "Unhandled exception");
-
-        var problem = new ProblemDetails
-        {
-            Status = StatusCodes.Status500InternalServerError,
-            Title = "An error occurred",
-            Type = "https://httpstatuses.com/500"
-        };
-
-        context.Response.StatusCode = problem.Status.Value;
-        await context.Response.WriteAsJsonAsync(problem, ct);
-        return true;
-    }
-}
-
-builder.Services.AddExceptionHandler<GlobalExceptionHandler>();
-```
-
-- Use `IExceptionHandler` (.NET 8+) instead of custom exception middleware
-- Map domain exceptions to appropriate HTTP status codes
-- Never expose internal exception details in production responses
-- Use `app.UseStatusCodePages()` for consistent responses on empty status codes (404, 405, etc.)
-
-## API Conventions & Response Types
-
-- Annotate endpoints with `[ProducesResponseType]` for OpenAPI documentation
-- Use `[Consumes]` and `[Produces]` for content type negotiation
-- Return consistent response envelopes or use ProblemDetails for errors
-- Use `TypedResults` in minimal APIs for compile-time response verification:
-
-```csharp
-group.MapPost("/", async (CreateOrderRequest req, IOrderService service, CancellationToken ct) =>
-{
-    var id = await service.CreateAsync(req, ct);
-    return TypedResults.Created($"/api/orders/{id}", new { id });
-});
-```
-
-## OpenAPI / Swagger
-
-- Use the built-in OpenAPI support (.NET 9+) or Swashbuckle/NSwag for earlier versions:
-
-```csharp
-builder.Services.AddOpenApi();
-// ...
-app.MapOpenApi();
-```
-
-- Enable XML comments in `.csproj` for automatic documentation:
-  ```xml
-  <PropertyGroup>
-    <GenerateDocumentationFile>true</GenerateDocumentationFile>
-    <NoWarn>$(NoWarn);1591</NoWarn>
-  </PropertyGroup>
-  ```
-- Use `[Tags]`, `[EndpointSummary]`, `[EndpointDescription]` for metadata
-- Use `WithName()` and `WithTags()` on minimal API endpoints
-- Use the `csharp-docs` skill for writing XML documentation comments
-
-## Health Checks
-
-```csharp
-builder.Services.AddHealthChecks()
-    .AddCheck("self", () => HealthCheckResult.Healthy())
-    .AddNpgSql(connectionString, name: "database")
-    .AddRedis(redisConnectionString, name: "cache");
-
-app.MapHealthChecks("/health", new HealthCheckOptions
-{
-    ResponseWriter = UIResponseWriter.WriteHealthCheckUIResponse
-});
-
-app.MapHealthChecks("/health/ready", new HealthCheckOptions
-{
-    Predicate = check => check.Tags.Contains("ready")
-});
-```
-
-- Separate liveness (`/health`) and readiness (`/health/ready`) endpoints
-- Tag health checks for selective filtering
-- Use NuGet packages `AspNetCore.HealthChecks.*` for common dependencies
-- Use the `nuget-manager` skill for adding health check packages
-
-## Cross-Cutting Concerns
-
-### CORS
-
-```csharp
-builder.Services.AddCors(options =>
-{
-    options.AddPolicy("AllowFrontend", policy =>
-        policy.WithOrigins("https://app.example.com")
-              .AllowAnyHeader()
-              .AllowAnyMethod()
-              .AllowCredentials());
-});
-
-app.UseCors("AllowFrontend");
-```
-
-### Rate Limiting (.NET 7+)
-
-```csharp
-builder.Services.AddRateLimiter(options =>
-{
-    options.AddFixedWindowLimiter("api", limiter =>
-    {
-        limiter.PermitLimit = 100;
-        limiter.Window = TimeSpan.FromMinutes(1);
-    });
-    options.RejectionStatusCode = StatusCodes.Status429TooManyRequests;
-});
-
-app.UseRateLimiter();
-```
-
-- Apply per-endpoint with `[EnableRateLimiting("api")]` or `.RequireRateLimiting("api")`
-
-### Output Caching (.NET 7+)
-
-```csharp
-builder.Services.AddOutputCache(options =>
-{
-    options.AddBasePolicy(builder => builder.Expire(TimeSpan.FromMinutes(5)));
-    options.AddPolicy("NoCache", builder => builder.NoCache());
-});
-```
-
-### Response Compression
-
-```csharp
-builder.Services.AddResponseCompression(options =>
-{
-    options.EnableForHttps = true;
-    options.Providers.Add<BrotliCompressionProvider>();
-    options.Providers.Add<GzipCompressionProvider>();
-});
-```
-
-## Related Skills
-
-- **[ef-core](../ef-core/SKILL.md)** — Data access with Entity Framework Core
-- **[dotnet-tester](../dotnet-tester/SKILL.md)** — Unit and integration testing
-- **[csharp-docs](../csharp-docs/SKILL.md)** — XML documentation comments
-- **[nuget-manager](../nuget-manager/SKILL.md)** — NuGet package management
-- **[dotnet-sdk-builder](../dotnet-sdk-builder/SKILL.md)** — SDK/client library generation
diff --git a/.github/skills/dotnet-inspect/SKILL.md b/.github/skills/dotnet-inspect/SKILL.md
deleted file mode 100644
index 283006ec..00000000
--- a/.github/skills/dotnet-inspect/SKILL.md
+++ /dev/null
@@ -1,229 +0,0 @@
----
-name: dotnet-inspect
-version: 0.7.5
-description: Query .NET APIs across NuGet packages, platform libraries, and local files. Search for types, list API surfaces, compare and diff versions, find extension methods and implementors. Use whenever you need to answer questions about .NET library contents.
----
-
-# dotnet-inspect
-
-Query .NET library APIs — the same commands work across NuGet packages, platform libraries (System.*, Microsoft.AspNetCore.*), and local .dll/.nupkg files.
-
-## Quick Decision Tree
-
-- **Code broken?** → `diff --package Foo@old..new` first, then `member`
-- **What's new in a .NET preview?** → `diff --platform System.Runtime@P2..P3 --additive` per framework library
-- **What types exist?** → `type --package Foo` (discover types in a package or library)
-- **What members does a type have?** → `member Type --package Foo` (compact table by default)
-- **What does a type look like?** → `type Type --package Foo` (tree view for single type)
-- **What are the method signatures?** → `member Type --package Foo -m Method` (full signatures + docs)
-- **What is the source/IL?** → `member Type --package Foo -m Method:1 -v:d` (Source, Lowered C#, IL)
-- **Where is the source code?** → `source Type --package Foo` (SourceLink URLs), `source Type -m Member` (with line numbers)
-- **Want raw source content?** → `source Type --package Foo --cat` (fetches and prints source files)
-- **What constructors exist?** → `member 'Type<T>' --package Foo -m .ctor` (use `<T>` not `<>`)
-- **How many overloads?** → `member Type --package Foo --show-index` (shows `Name:N` indices)
-- **What does this package depend on?** → `depends --package Foo`
-- **What does this type inherit?** → `depends 'INumber<TSelf>'`
-- **Want a dependency diagram?** → `depends --mermaid` (standalone) or `depends --markdown --mermaid` (embedded)
-- **What metadata fields exist?** → `-S Section --fields "PDB*"` (structured query, no DSL)
-- **What version is available?** → `Foo --version` (cache-first), `Foo --latest-version` (always NuGet), `Foo --versions` (list all)
-
-## When to Use This Skill
-
-- **"What types are in this package?"** — `type` discovers types, `find` searches by pattern
-- **"What members does this type have?"** — `member` for methods/properties/events (docs on by default)
-- **"What changed between versions?"** — `diff` classifies breaking/additive changes
-- **"What new APIs shipped in this preview?"** — `diff --platform System.Runtime@prev..current --additive` per framework library
-- **"This code uses an old API — fix it"** — `diff` the old..new version, then `member` to see the new API
-- **"What extends this type?"** — `extensions` finds extension methods/properties (`--reachable` for transitive)
-- **"What implements this interface?"** — `implements` finds concrete types
-- **"What does this type depend on?"** — `depends` walks type hierarchy, package deps, or library refs
-- **"Show dependencies as a diagram"** — `depends --mermaid` for standalone mermaid, `--markdown --mermaid` for embedded
-- **"Where is the source code?"** — `source` returns SourceLink URLs; add member name for line numbers
-- **"What version/metadata does this have?"** — `package` and `library` inspect metadata
-- **"What version is available?"** — `Foo --version` (fast, cache-first — like `docker run`)
-- **"What's the latest on NuGet?"** — `Foo --latest-version` (always queries NuGet — like `docker pull`)
-- **"What versions exist?"** — `Foo --versions` (list all published versions)
-- **"What TFMs are available?"** — `package Foo --tfms`, then `type --package Foo --tfm net8.0`
-- **"Where is the source code?"** — `source` returns SourceLink URLs; add member name for line numbers
-- **"Show me the actual source?"** — `source Type --package Foo --cat` fetches and prints source file contents
-- **"Show me something cool"** — `demo` runs curated showcase queries
-
-## Key Patterns
-
-Default output is **markdown** — headings, tables, and field lists that render well in terminals, editors, and LLM contexts. No flags needed:
-
-```bash
-dnx dotnet-inspect -y -- member JsonSerializer --package System.Text.Json    # scan members
-dnx dotnet-inspect -y -- type --package System.Text.Json                     # scan types
-dnx dotnet-inspect -y -- diff --package System.CommandLine@2.0.0-beta4.22272.1..2.0.3  # triage changes
-```
-
-Default format is **markdown** — no flags needed. Optional formats: **oneline** (`--oneline`), **plaintext** (`--plaintext`), **json** (`--json`), **mermaid** (`--mermaid`). Verbosity (`-v:q/m/n/d`) controls which sections are included; formatter controls how they render. They compose freely — except `--oneline` and `-v` cannot be combined.
-
-```bash
-dnx dotnet-inspect -y -- member JsonSerializer --package System.Text.Json -v:d  # detailed (source/IL)
-dnx dotnet-inspect -y -- System.Text.Json -v:n --plaintext                      # all local sections, plaintext
-dnx dotnet-inspect -y -- type --package System.Text.Json --oneline              # compact columnar output
-dnx dotnet-inspect -y -- depends Stream --mermaid                               # standalone mermaid diagram
-dnx dotnet-inspect -y -- depends Stream --markdown --mermaid                    # mermaid embedded in markdown
-```
-
-Use `diff` first when fixing broken code — triage changes, then drill into specifics:
-
-```bash
-dnx dotnet-inspect -y -- diff --package System.CommandLine@2.0.0-beta4.22272.1..2.0.3  # what changed?
-dnx dotnet-inspect -y -- member Command --package System.CommandLine@2.0.3               # new API surface
-```
-
-## Platform Diffs & Release Notes
-
-For framework libraries (System.*, Microsoft.AspNetCore.*), use `--platform` instead of `--package`. This is the primary workflow for .NET release notes — diff each framework library between preview versions:
-
-```bash
-dnx dotnet-inspect -y -- diff --platform System.Runtime@P2..P3 --additive        # what's new?
-dnx dotnet-inspect -y -- diff --platform System.Net.Http@P2..P3 --additive       # per-library
-dnx dotnet-inspect -y -- diff --platform System.Text.Json@9.0.0..10.0.0          # across major versions
-```
-
-**Multi-library packages:** `diff --package` works across all libraries in a package (e.g., `Microsoft.Azure.SignalR` with multiple DLLs). For framework ref packages like `Microsoft.NETCore.App.Ref`, prefer `--platform` per-library since it resolves from installed packs.
-
-**Nightly/preview packages from custom feeds:** The `--source` flag works for version listing but not package downloads. Pre-populate the NuGet cache instead:
-
-```bash
-# Pre-populate cache (fails with NU1213 but downloads the package)
-dotnet add package Microsoft.NETCore.App.Ref --version <version> --source <feed-url>
-# Then use normally — resolves from NuGet cache
-dnx dotnet-inspect -y -- diff --platform System.Runtime@P2..P3 --additive
-```
-
-## Version Resolution (Docker-style)
-
-Version queries use Docker-like semantics: cached packages are served in under 15ms, network calls cost 1–4 seconds. Three flags, three behaviors:
-
-| Flag | Behavior | Network | Like Docker... |
-| ---- | -------- | ------- | -------------- |
-| `--version` (bare) | **Local** — returns the version from local cache | Only on cache miss | `docker run nginx` |
-| `--latest-version` | **Remote** — queries nuget.org for the absolute latest | Always | `docker pull nginx` |
-| `--versions` | **Remote** — returns every published version | Always | `docker image ls --all` |
-
-`--version` and bare-name inspection share the same cache. If `Foo --version` returns `2.0.3`, then `Foo` (or `package Foo`) will inspect that same `2.0.3` — no surprises, no extra network call. This is the fast path for most tasks.
-
-`--latest-version` and `--versions` always query nuget.org, so they reflect the latest published state. Use `--latest-version` when you need to confirm the newest version, e.g., before a dependency upgrade.
-
-```bash
-dnx dotnet-inspect -y -- Foo --version           # what's in the cache? (fast, local)
-dnx dotnet-inspect -y -- Foo --latest-version     # what's on nuget.org? (always network)
-dnx dotnet-inspect -y -- Foo --versions           # list all published versions
-dnx dotnet-inspect -y -- Foo --versions 5         # list latest 5 versions
-dnx dotnet-inspect -y -- Foo --versions --preview # include prerelease versions
-```
-
-The same flags work on the `package` subcommand:
-
-```bash
-dnx dotnet-inspect -y -- package Foo --version           # same local cache check
-dnx dotnet-inspect -y -- package Foo --latest-version     # always queries nuget.org
-dnx dotnet-inspect -y -- package Foo --versions           # list all versions
-```
-
-Version pinning with `@version` syntax:
-
-```bash
-dnx dotnet-inspect -y -- Foo@2.0.3                # pinned — no network if cached
-dnx dotnet-inspect -y -- Foo@latest               # always checks nuget.org
-dnx dotnet-inspect -y -- Foo                      # prefer cache, refresh on TTL expiry
-```
-
-**Use `--version` (not `--latest-version`) as the default.** It's fast and returns the same version that bare-name commands will use. Only reach for `--latest-version` when you need the absolute latest from nuget.org.
-
-## Structured Queries (like Go templates, without a DSL)
-
-Discover the schema, then select and project — no template language needed:
-
-```bash
-dnx dotnet-inspect -y -- System.Text.Json -D                          # list sections
-dnx dotnet-inspect -y -- System.Text.Json -D --effective              # sections with data (dry run)
-dnx dotnet-inspect -y -- library System.Text.Json -D --tree           # full schema tree
-dnx dotnet-inspect -y -- System.Text.Json -S Symbols                  # render one section
-dnx dotnet-inspect -y -- System.Text.Json -S Symbols --fields "PDB*"  # project specific fields
-dnx dotnet-inspect -y -- type System.Text.Json --columns Kind,Type    # project specific columns
-```
-
-## Mermaid Diagrams
-
-The `depends` command supports `--mermaid` for Mermaid diagram output. Two modes:
-
-| Flags | Output | Use case |
-| ----- | ------ | -------- |
-| `--mermaid` | Standalone mermaid (`graph TD`) | Pipe to `mmdc`, embed in tooling |
-| `--markdown --mermaid` | Mermaid fenced blocks inside markdown | Render in GitHub, VS Code, docs |
-
-```bash
-dnx dotnet-inspect -y -- depends Stream --mermaid                               # type hierarchy as mermaid
-dnx dotnet-inspect -y -- depends Stream --markdown --mermaid                    # embedded in markdown
-dnx dotnet-inspect -y -- depends --library System.Text.Json --mermaid           # assembly reference graph
-dnx dotnet-inspect -y -- depends --package Markout --mermaid                    # package dependency graph
-```
-
-## Search Scope
-
-Search commands (`find`, `extensions`, `implements`, `depends`) use scope flags:
-
-- **(no flags)** — all platform frameworks (runtime, aspnetcore, netstandard)
-- **`--platform`** — all platform frameworks
-- **`--extensions`** — curated Microsoft.Extensions.* packages
-- **`--aspnetcore`** — curated Microsoft.AspNetCore.* packages
-- **`--package Foo`** — specific NuGet package (combinable with scope flags)
-
-`type`, `member`, `library`, `diff` accept `--platform <name>` as a string for a specific platform library.
-
-## Command Reference
-
-| Command | Purpose |
-| ------- | ------- |
-| `type` | **Discover types** — terse output, no docs, use `--shape` for hierarchy |
-| `member` | **Inspect members** — docs on by default, supports dotted syntax (`-m Type.Member`) |
-| `find` | Search for types by glob or fuzzy match across any scope |
-| `diff` | Compare API surfaces between versions — breaking/additive classification |
-| `extensions` | Find extension methods/properties for a type (`--reachable` for transitive) |
-| `implements` | Find types implementing an interface or extending a base class |
-| `depends` | Walk dependency graphs upward — type hierarchy, package deps, or library refs |
-| `package` | Package metadata, files, versions, dependencies, `search` for NuGet discovery |
-| `library` | Library metadata, symbols, references, SourceLink audit |
-| `source` | **SourceLink URLs** — type-level or member-level (with line numbers), `--cat` to fetch content, `--verify` to check URLs |
-| `demo` | Run curated showcase queries — list, invoke, or feeling-lucky |
-
-## Filtering and Limiting
-
-```bash
-dnx dotnet-inspect -y -- type System.Text.Json -k enum               # filter by kind (type and member commands)
-dnx dotnet-inspect -y -- type System.Text.Json -t "*Converter*"      # glob filter on type names
-dnx dotnet-inspect -y -- member System.Text.Json JsonDocument -m Parse  # filter by member name
-dnx dotnet-inspect -y -- type System.Text.Json -5                    # first 5 lines (like head -5)
-dnx dotnet-inspect -y -- type System.Text.Json --tail 10             # last 10 lines (like tail -10)
-```
-
-**Do not pipe output through `head`, `tail`, or `Select-Object`.** Use built-in `--head` / `--tail`:
-
-- **`-n N`, `--head N`, or `-N`** — first N lines (like `head`). Keeps headers, truncates cleanly.
-- **`--tail N`** — last N lines (like `tail`). Buffers output, emits only the final N lines.
-- **`-m N`** (numeric) — item limit (members per kind section).
-- **`-k Kind`** — filter by kind: `class/struct/interface/enum/delegate` (type) or `method/property/field/event/constructor` (type single-type view, member).
-- **`-S Section`** — show only a specific section (glob-capable).
-
-## Key Syntax
-
-- **Generic types** need quotes: `'Option<T>'`, `'IEnumerable<T>'`
-- **Use `<T>` not `<>`** for generic types — `"Option<>"` resolves to the abstract base, `'Option<T>'` resolves to the concrete generic with constructors
-- **`type` uses `-t`** for type filtering, **`member` uses `-m`** for member filtering (not `--filter`)
-- **Dotted syntax** for `member`: `-m JsonSerializer.Deserialize` or `-m System.Text.Json.JsonSerializer.Deserialize`
-- **Diff ranges** use `..`: `--package System.Text.Json@9.0.0..10.0.0`
-- **Derived types** only show their own members — query the base type too
-
-## Installation
-
-Use `dnx` (like `npx`). Always use `-y` and `--` to prevent interactive prompts:
-
-```bash
-dnx dotnet-inspect -y -- <command>
-```
diff --git a/.github/skills/dotnet-reviewer/SKILL.md b/.github/skills/dotnet-reviewer/SKILL.md
deleted file mode 100644
index 30795d1d..00000000
--- a/.github/skills/dotnet-reviewer/SKILL.md
+++ /dev/null
@@ -1,134 +0,0 @@
----
-name: dotnet-reviewer
-description: Performs structured code reviews on .NET 10+ projects. Activates ONLY on explicit name — use the phrases "dotnet-reviewer", "dotnet code review", or "dotnet review". Reviews either uncommitted working-tree changes or committed changes on the current feature branch (vs. main). Produces a Markdown report under docs/reviews/ with severity-tagged findings ([Critical|Major|Minor|Suggestion|Nitpick][Security|Performance|Architecture|Code-Quality|Tests|.NET-Idioms]) and fix suggestions. Must NOT activate on generic "review my code" requests; other-language reviewers must not be hijacked.
----
-
-# dotnet-reviewer
-
-Structured code review for .NET 10+ projects. The skill is invoked by explicit name only and produces a Markdown report.
-
-## When to Use This Skill
-
-Use ONLY when the user invokes one of:
-- `dotnet-reviewer`
-- `dotnet code review`
-- `dotnet review`
-
-Do NOT activate on generic phrases like "review my code", "can you check this PR", "look at my changes". Those go to other reviewers (or to no skill at all).
-
-The user may add language preferences (e.g., "in German") — apply that to the report only. The skill itself remains in English.
-
-## Prerequisites
-
-- `git` repo with `main` branch (for branch mode).
-- `dotnet ≥ 10` SDK if any of build/format/test will run.
-- `bash` 3.2+ available (macOS default works).
-- `python3` available (used by scripts for safe JSON encoding).
-
-## Workflow
-
-Follow these steps in order.
-
-### Step 1 — Interactive prompt
-
-Ask the user three things:
-
-1. **Mode:** `uncommitted` (working-tree vs HEAD, includes staged/unstaged/untracked) or `branch` (current branch vs `main`).
-2. **Tools:** for each of `build`, `format`, `test` — yes or no. Default no for all three.
-3. **Report language:** default English. If they want another language, capture it.
-
-Validate inputs against the whitelist. Re-prompt on invalid input.
-
-### Step 2 — Detect .NET version
-
-Run `scripts/detect-dotnet-version.sh --repo-root <repo>`.
-
-- Exit 0: parse JSON `{sdk, target_frameworks, project_files}`. Pick the highest `net<N>.0` from `target_frameworks` to drive checklist selection.
-- Exit 4 (SDK < 10 or none): abort. Tell the user "this skill targets .NET 10+; detected `<X>`."
-- Exit 5 (malformed): show offending file. Ask the user whether to proceed without version-awareness. If yes, fall back to general checklists only.
-- Exit 2 (not a directory) or 1 (usage): bug — report and abort.
-
-### Step 3 — Collect diff
-
-Run `scripts/collect-diff.sh --repo-root <repo> --mode <mode> --baseline main`.
-
-- Exit 0 with `files == 0`: report "no changes to review" and exit.
-- Exit 0 with `files > 0`: continue.
-- Exit 2: not a git repo — abort.
-- Exit 3 (branch mode, missing `main`): abort, tell user.
-
-### Step 4 — Large-diff strategy gate
-
-If `loc > 2000` OR `files > 50`, ask the user to choose:
-
-- **(B) Review everything** — note token cost in report header.
-- **(C) Prioritize** — review files matching `*Service.cs`, `*Controller.cs`, files without sibling `*.Tests/*Tests.cs` first; summarize the rest.
-- **(D) Chunk file-by-file** — review each file independently; group findings by file.
-
-If C is chosen but no files match the priority heuristics, fall back to D and note the fallback transparently in the report.
-
-### Step 5 — Run requested tool checks
-
-For each tool the user selected, invoke `scripts/run-checks.sh --repo-root <repo>` with the appropriate flag(s). Parse JSON.
-
-If a tool isn't installed, the script reports the failure inside the JSON — log "X not available, skipping" and continue. Don't abort.
-
-### Step 6 — Review
-
-Walk the diff against:
-1. The version-specific checklist (`references/review-checklist-net<N>.md`).
-2. `references/review-checklist-security.md`.
-3. `references/review-checklist-performance.md`.
-4. `references/review-checklist-architecture.md`.
-5. `references/review-checklist-code-quality.md`.
-
-Fold tool findings into the issue list using the severity mapping defined in `references/severity-taxonomy.md`:
-- `dotnet build` errors → Critical
-- `dotnet build` warnings → Minor
-- `dotnet test` failures → Critical
-- `dotnet format` violations → Suggestion
-
-Each finding MUST include a fix suggestion as a code block (`csharp` fenced) — no auto-patching.
-
-### Step 7 — Render report
-
-Generate the report following `references/report-format.md` exactly:
-- Title + metadata block
-- Detailed Executive Summary (counts, top-3 risks, LOC, scope)
-- Findings ordered by severity desc, then file path asc
-- Tool Output Appendix
-
-### Step 8 — Write report
-
-Path: `docs/reviews/YYYY-MM-DD-<branch>-<mode>.md`. Branch name is sanitized (replace `/` with `-`).
-
-If the path exists, append `-2`, `-3`, … until unique. Create `docs/reviews/` if missing. **Never auto-commit. Never overwrite.**
-
-Output to chat: the file path and a one-line summary (e.g., `"Wrote review with 2 Critical, 5 Major findings to docs/reviews/…"`).
-
-## Output Contract
-
-- Single Markdown file under `docs/reviews/`.
-- Format strictly per `references/report-format.md`.
-- Severity and area tags from `references/severity-taxonomy.md`.
-
-## Resource Index
-
-- `scripts/detect-dotnet-version.sh` — SDK / target framework detection
-- `scripts/collect-diff.sh` — diff collection with exclusions
-- `scripts/run-checks.sh` — optional dotnet build/format/test
-- `references/severity-taxonomy.md`
-- `references/report-format.md`
-- `references/review-checklist-net10.md`
-- `references/review-checklist-security.md`
-- `references/review-checklist-performance.md`
-- `references/review-checklist-architecture.md`
-- `references/review-checklist-code-quality.md`
-
-## Things This Skill Never Does
-
-- Auto-patches or auto-commits the report.
-- Bypasses git hooks (`--no-verify`, `--no-gpg-sign`).
-- Runs destructive operations as "fixes" (no `git reset`, no deletions).
-- Includes secrets in logs or the report.
-- Reviews .NET versions below 10 — aborts with a clear message.
diff --git a/.github/skills/dotnet-reviewer/references/report-format.md b/.github/skills/dotnet-reviewer/references/report-format.md
deleted file mode 100644
index 301d3e9b..00000000
--- a/.github/skills/dotnet-reviewer/references/report-format.md
+++ /dev/null
@@ -1,78 +0,0 @@
-# Report Format
-
-The reviewer writes one Markdown file to `docs/reviews/YYYY-MM-DD-<branch>-<mode>.md`.
-Never overwrite — append `-2`, `-3`, … on collision. Never auto-commit.
-
-## Required Sections
-
-1. Title + metadata block
-2. Executive Summary (detailed)
-3. Findings, ordered by severity desc, then by file path
-4. Tool Output Appendix (if any tool ran)
-
-## Skeleton
-
-```markdown
-# .NET Code Review — <branch> (<mode>)
-
-**Date:** YYYY-MM-DD
-**Mode:** uncommitted | branch (vs. main)
-**Detected SDK:** 10.0.x
-**Target Framework(s):** net10.0, …
-**Tools run:** build=Y/N · format=Y/N · test=Y/N
-**Exclusions:** .gitignore, *.min.js, wwwroot/lib/**
-**Review strategy:** full | prioritized | chunked
-**Diff size:** <files> files, <loc> changed LOC
-
-## Executive Summary
-
-| Severity | Count |
-|---|---|
-| Critical | N |
-| Major | N |
-| Minor | N |
-| Suggestion | N |
-| Nitpick | N |
-
-**Top risks:**
-1. <one line>
-2. <one line>
-3. <one line>
-
-**Overall:** <1–2 sentence assessment>
-
-## Findings
-
-### [Critical][Security] src/Api/UserController.cs:42
-<one-line description>
-
-<recommendation paragraph>
-
-```csharp
-// fix suggestion
-```
-
-### [Major][Performance] src/Data/Repo.cs:88
-…
-
-## Tool Output Appendix
-
-### dotnet build
-- 0 errors, 2 warnings (see findings above for warnings folded in).
-
-### dotnet test
-- 12 passed, 0 failed (duration: 4s).
-
-### dotnet format
-- Skipped.
-```
-
-## Rules
-
-- **Every finding MUST include a fix suggestion** as a code block. If the fix is structural (no single-snippet rewrite), describe the steps in prose and provide the most-affected snippet.
-- Do not paste raw diff content. Reference `path:line` instead.
-- File paths are repo-relative.
-- Group findings by severity desc, ties broken by file path asc.
-- Tool warnings/errors that are already covered by a hand-written finding should not be duplicated in the appendix — note "folded into findings".
-- If strategy `chunked` was used, group findings under `## Findings — <file>` subsections.
-- If strategy `prioritized` was used, list deferred files at the end as `## Files Not Reviewed in Detail`.
diff --git a/.github/skills/dotnet-reviewer/references/review-checklist-architecture.md b/.github/skills/dotnet-reviewer/references/review-checklist-architecture.md
deleted file mode 100644
index 2377dfb2..00000000
--- a/.github/skills/dotnet-reviewer/references/review-checklist-architecture.md
+++ /dev/null
@@ -1,40 +0,0 @@
-# Review Checklist — Architecture
-
-## Layering
-
-- Domain references no infrastructure (no EF Core attributes on domain entities; no `HttpClient` in domain).
-- Application layer orchestrates — does not reach into UI/infrastructure types directly.
-- Controllers / minimal-API handlers stay thin: parse, dispatch to application service, map result.
-- Infrastructure adapters implement domain/application interfaces, not the other way around.
-
-## Dependency Direction
-
-- Outer rings depend on inner rings. Flag any inner-ring file with a `using` of an outer-ring namespace.
-- Solution structure should make this provable; if it doesn't (single project, mixed namespaces), call it out.
-
-## SOLID
-
-- **SRP:** classes that change for multiple reasons. Public surface that mixes orchestration with persistence.
-- **OCP:** strategy patterns where `if (type == X) … else if (type == Y) …` is repeated across files.
-- **LSP:** subclass that throws `NotSupportedException` on a base member.
-- **ISP:** "fat" interfaces with one consumer per method. Split or use mark-only interfaces.
-- **DIP:** new-ing dependencies inside a class instead of injecting (except for value objects).
-
-## Dependency Injection
-
-- Lifetimes: avoid `Singleton` capturing `Scoped` (e.g., `DbContext` in a `Singleton` cache).
-- Factory delegates over `IServiceProvider` parameters in constructors.
-- No `BuildServiceProvider()` in `Configure`/`ConfigureServices` — that creates a second container.
-- Validation of options on startup (`ValidateOnStart`).
-
-## Pattern Consistency
-
-- New code matches the existing project pattern. If this file uses CQRS handlers and you added a controller method that bypasses them, flag it.
-- Naming consistency: `XxxService` vs. `XxxRepository` vs. `XxxHandler` — pick one and stay consistent within a bounded context.
-- New pattern introductions (e.g., switching from MediatR to direct calls) need an architectural rationale; flag if introduced silently.
-
-## Module Boundaries
-
-- Each project (.csproj) has a clear purpose. Flag projects whose name and contents have drifted.
-- Public API of a project is intentional — `internal` over `public` unless cross-project consumption is required.
-- `InternalsVisibleTo` only for tests; flag if used to share types with non-test projects.
diff --git a/.github/skills/dotnet-reviewer/references/review-checklist-code-quality.md b/.github/skills/dotnet-reviewer/references/review-checklist-code-quality.md
deleted file mode 100644
index b45440f8..00000000
--- a/.github/skills/dotnet-reviewer/references/review-checklist-code-quality.md
+++ /dev/null
@@ -1,62 +0,0 @@
-# Review Checklist — Code Quality
-
-## Naming
-
-- Methods are verbs. Properties are nouns. Async methods end in `Async`.
-- No Hungarian notation (`strName`, `iCount`).
-- Booleans read as questions: `IsValid`, `HasItems`, `CanRetry`.
-- Acronyms: `Url`, `Id`, `Api` (PascalCase per .NET conventions, not `URL`/`ID`/`API`).
-- Type parameters: `T`, or `TKey`/`TValue` — descriptive when more than one.
-
-## Nullability
-
-- `<Nullable>enable</Nullable>` is on (project-level check).
-- No `!` (null-forgiving operator) without a comment explaining why.
-- No `#nullable disable` regions in new code.
-- API surface honors nullability annotations — methods returning `T?` actually return null in some path.
-
-## Complexity
-
-- Methods over ~30 lines or with 4+ levels of nesting deserve a closer look.
-- A `switch` with more than ~7 arms over the same value usually wants polymorphism or a lookup table.
-- Boolean parameters often hide two methods — flag and suggest splitting.
-
-## Exception Handling
-
-- Catch the specific exception type, not `Exception`. `catch (Exception)` requires justification.
-- Never swallow exceptions silently. Logging counts only if the log line carries enough context to diagnose.
-- Don't use exceptions for control flow.
-- Wrap third-party exceptions at the boundary; do not leak them into domain code.
-
-## IDisposable / IAsyncDisposable
-
-- `using` (or `using` declarations) for every `IDisposable` you create.
-- `IDisposable` types as fields require the owning class to also be disposable.
-- `IAsyncDisposable` consumed with `await using`, not `using`.
-
-## Dead Code
-
-- Unused `using` directives → format check should catch; flag if format check is off.
-- Unreachable code (`return` followed by statements).
-- Unused private members. Public unused members may be API for a consumer — leave alone unless clearly orphaned.
-
-## Comments and Docs
-
-- Public API has XML docs, especially for libraries.
-- Comments explain *why*, not *what*. Flag comments that restate the code.
-- TODOs without a ticket reference are a smell; flag.
-
-## Tests (cross-cutting)
-
-- New public behavior has at least one test.
-- Tests assert behavior, not implementation (no over-mocking).
-- Names describe the scenario: `Method_Condition_Expected`.
-- Arrange/Act/Assert layout is visible.
-- No conditional logic in test bodies (`if`/`for` inside tests).
-- Edge cases: null, empty collection, boundary values.
-
-## Logging
-
-- Structured logging (named placeholders), not string concatenation.
-- Log level matches consequence: `Error` for exceptions reaching the boundary, `Warning` for recoverable degraded paths, `Information` for state transitions, `Debug` for detail.
-- No PII in logs (email, user names, full request bodies) without a redaction strategy.
diff --git a/.github/skills/dotnet-reviewer/references/review-checklist-net10.md b/.github/skills/dotnet-reviewer/references/review-checklist-net10.md
deleted file mode 100644
index 932bcf50..00000000
--- a/.github/skills/dotnet-reviewer/references/review-checklist-net10.md
+++ /dev/null
@@ -1,35 +0,0 @@
-# Review Checklist — .NET 10
-
-Apply when `detect-dotnet-version.sh` reports `target_frameworks` containing `net10.0`.
-
-## Language Idioms
-
-- **Primary constructors** — prefer over redundant private fields when the parameter is used directly. Flag: legacy `ctor + private readonly field` pattern in new code.
-- **Collection expressions** — `[1, 2, 3]` over `new[] { 1, 2, 3 }` and `new List<int> { 1, 2, 3 }`. Flag: verbose collection initialization.
-- **Required members** — `required` modifier replaces hand-rolled validation in constructors. Flag: throws in constructor for missing init-only properties.
-- **`field` keyword** — auto-property backing-field access (preview in 9, stable in 10). Flag: unnecessary backing field declarations.
-- **Pattern matching** — list patterns, relational patterns. Flag: chained `if (x.Length > 0 && x[0] == …)`.
-- **`init` and `required` together** — for immutable POCOs.
-
-## API Idioms
-
-- `System.Threading.Lock` (new lock type) over `object`-based `lock` for new code.
-- `Random.Shared` for non-cryptographic randomness — never `new Random()` in hot path.
-- `TimeProvider` for testable time — flag direct `DateTime.UtcNow` in code that should be testable.
-- `JsonSerializerContext` (source-gen) over reflection-based `JsonSerializer` on hot paths.
-
-## Project Configuration
-
-- `<Nullable>enable</Nullable>` MUST be on. Flag projects without it.
-- `<TreatWarningsAsErrors>true</TreatWarningsAsErrors>` recommended for libraries.
-- `<LangVersion>` should not be pinned below the SDK's default unless a comment explains why.
-- `ImplicitUsings` enabled — flag stale top-of-file using directives that are already implicit.
-
-## Things That Are Still Wrong
-
-These are not new in .NET 10 but are still common:
-
-- `.Result` / `.Wait()` on `Task` — sync-over-async deadlock risk.
-- `async void` outside event handlers.
-- `IEnumerable<T>` enumerated multiple times when the source is a generator.
-- `string` concatenation in loops where `StringBuilder` or `string.Create` fits.
diff --git a/.github/skills/dotnet-reviewer/references/review-checklist-performance.md b/.github/skills/dotnet-reviewer/references/review-checklist-performance.md
deleted file mode 100644
index a36c1257..00000000
--- a/.github/skills/dotnet-reviewer/references/review-checklist-performance.md
+++ /dev/null
@@ -1,49 +0,0 @@
-# Review Checklist — Performance
-
-## async/await
-
-- No `.Result`, `.Wait()`, `GetAwaiter().GetResult()` in async code paths.
-- `async void` only on event handlers.
-- `Task.Run` not used to "fake async" over CPU-bound work that already runs on a worker thread (e.g., inside an existing async pipeline).
-- `ConfigureAwait(false)` on library code (not application code in modern ASP.NET).
-- `ValueTask` for hot paths that frequently complete synchronously; do not consume `ValueTask` more than once.
-- `IAsyncEnumerable<T>` for streaming; flag `List<T>` accumulation when callers can stream.
-
-## Allocations
-
-- `string` concatenation in loops → `StringBuilder` or `string.Create`.
-- `string.Format` with hot-path frequency → interpolated handlers.
-- LINQ `ToList()` / `ToArray()` immediately followed by another enumeration — extra allocation for nothing.
-- `params object[]` on hot paths — allocates per call. Use overloads.
-- Closures capturing `this` in hot lambdas — flag if measurably hot.
-- Boxing: `int` → `object`, generic constraints missing.
-
-## Span / Memory
-
-- Parsing/slicing strings: `ReadOnlySpan<char>` over `Substring`.
-- File / network buffers: `Memory<byte>` / `IBufferWriter<byte>` over `byte[]`.
-- `stackalloc` for small fixed buffers in hot paths (with bounds check).
-
-## EF Core
-
-- N+1 queries — flag `foreach (entity) { ctx.Related.Where(...) }` patterns.
-- Missing `.AsNoTracking()` on read-only queries.
-- `Include` chains pulling unused columns — projection (`Select`) preferred for read paths.
-- Filters applied client-side after `.ToList()` — push to SQL.
-- `ChangeTracker` not cleared on long-lived contexts.
-- Missing indexes on filtered/joined columns (call out in review when obvious from query shape).
-
-## Hot-Path Heuristics
-
-A method is "hot" if any of:
-- It's on a request path of an HTTP server.
-- It's inside a `for` / `while` over a user-sized collection.
-- It's called from `Hosted` / `BackgroundService` loops.
-- A comment or naming suggests perf-sensitive use ("inner loop", "hot", "fast path").
-
-## Concurrency
-
-- Shared mutable state without synchronization (lock, `Interlocked`, immutable patterns).
-- `ConcurrentDictionary` misuse — `GetOrAdd` with allocating factory called on every hit.
-- `SemaphoreSlim` not awaited in `using` / `try/finally`.
-- `Task.WhenAll` with thousands of tasks → bound concurrency (`Parallel.ForEachAsync` with `MaxDegreeOfParallelism`).
diff --git a/.github/skills/dotnet-reviewer/references/review-checklist-security.md b/.github/skills/dotnet-reviewer/references/review-checklist-security.md
deleted file mode 100644
index adc6d248..00000000
--- a/.github/skills/dotnet-reviewer/references/review-checklist-security.md
+++ /dev/null
@@ -1,61 +0,0 @@
-# Review Checklist — Security
-
-## Input Validation
-
-- All public-API entry points (controllers, minimal-API handlers, gRPC, message handlers) validate input.
-- DTOs use `[Required]`, `[Range]`, `[StringLength]`, or FluentValidation rules. Flag DTOs without any validation.
-- Reject untrusted input before it reaches the data layer. No ad-hoc string parsing in business logic.
-
-## Injection
-
-- **SQL:** parameterized queries via EF Core LINQ, `FromSqlInterpolated`, or `DbCommand` with parameters. Flag: `FromSqlRaw` with interpolation, raw `SqlCommand` with concatenation.
-- **Command/Process:** `Process.Start` with user-controlled args — flag any concatenation; require `ProcessStartInfo` with `ArgumentList`.
-- **LDAP/XPath:** sanitized filter construction.
-- **Path traversal:** `Path.Combine` does not protect — validate that the resolved absolute path is under the intended root.
-
-## Authentication / Authorization
-
-- `[Authorize]` (or equivalent) on every non-anonymous endpoint. Flag controllers without `[Authorize]` at class level when most actions need auth.
-- Role/policy checks match the intent (no `[Authorize(Roles = "Admin")]` for user-scoped data; use resource-based authorization).
-- No "fallback to anonymous" branches in middleware.
-
-## Secrets and Credentials
-
-- No secrets in source: API keys, connection strings with passwords, JWT keys.
-- `appsettings.*.json` with secrets must be `.gitignore`-d; production uses a secret manager.
-- Logs do not include `request.Headers`, `Request.Body`, or full URLs containing tokens.
-- `HttpClient` does not blindly trust certs (`ServerCertificateCustomValidationCallback` should not return `true`).
-
-## Deserialization & Serialization
-
-- `JsonSerializer` does not deserialize untrusted JSON to `object` or `dynamic`.
-- `BinaryFormatter` is forbidden — flag any usage.
-- XML deserialization disables DTD processing (`XmlReaderSettings.DtdProcessing = Prohibit`).
-
-## Cryptography
-
-- No `MD5` or `SHA1` for security purposes. Use `SHA256+`.
-- No `RandomNumberGenerator.Create()` followed by predictable seeding — use `RandomNumberGenerator.GetBytes()`.
-- AES with `CipherMode.ECB` is forbidden. Prefer authenticated modes (`AesGcm`).
-- No hard-coded IVs or keys.
-
-## Web App Specific
-
-- CSRF protection on state-changing endpoints (cookie auth + non-GET).
-- Anti-forgery tokens for forms.
-- CORS is restrictive — `AllowAnyOrigin` only on read-only public endpoints.
-- HSTS, secure cookies, `SameSite=Lax` minimum.
-- Output encoding — Razor auto-encodes; `Html.Raw` is a code smell that needs justification.
-
-## OWASP Mapping
-
-When reporting, reference the OWASP Top 10 category in parentheses:
-- A01 Broken Access Control
-- A02 Cryptographic Failures
-- A03 Injection
-- A04 Insecure Design
-- A05 Security Misconfiguration
-- A07 Identification & Auth Failures
-- A08 Software & Data Integrity Failures
-- A09 Security Logging Failures
-- A10 SSRF
diff --git a/.github/skills/dotnet-reviewer/references/severity-taxonomy.md b/.github/skills/dotnet-reviewer/references/severity-taxonomy.md
deleted file mode 100644
index 9aa92c7d..00000000
--- a/.github/skills/dotnet-reviewer/references/severity-taxonomy.md
+++ /dev/null
@@ -1,52 +0,0 @@
-# Severity Taxonomy and Area Tags
-
-Every finding is tagged `[Severity][Area]` followed by `path:line`.
-
-## Severity Levels
-
-| Severity | When to use | Examples |
-|---|---|---|
-| **Critical** | Ship-blocker. Production correctness, security, data loss, or a failing test. | SQL injection, unhandled `null` deref on hot path, failing test, build error. |
-| **Major** | Will hurt users or maintainers but not a ship-blocker. | Missing input validation on a public API, race condition under load, broken contract with caller. |
-| **Minor** | Real issue, low impact, deserves a fix in this PR. | Build warning, sloppy exception handling, missing log context, dead code. |
-| **Suggestion** | Improvement worth considering. Author can accept or reject. | Refactor opportunity, alternative idiom, better naming, format violation. |
-| **Nitpick** | Cosmetic. Author should ignore unless trivial. | Whitespace, comment phrasing, minor style preference. |
-
-## Area Tags
-
-Pick the **dominant** concern. If two apply, pick the higher-severity area.
-
-| Tag | Scope |
-|---|---|
-| `Security` | Authn/authz, input validation, secrets, injection, deserialization, crypto, OWASP. |
-| `Performance` | Allocations, async/await misuse, EF query shape, hot-path heuristics, Span/Memory. |
-| `Architecture` | Layer/dependency direction, SOLID, DI misuse, pattern consistency, coupling. |
-| `Code-Quality` | Naming, complexity, nullability, IDisposable, dead code, exception strategy. |
-| `Tests` | Missing coverage, flaky tests, weak assertions, test maintenance smell. |
-| `.NET-Idioms` | Version-specific idioms (Primary Ctors, Collection Expressions, Required Members, …). |
-
-## Mapping from Tool Outputs
-
-| Tool finding | Severity | Area |
-|---|---|---|
-| `dotnet build` error | Critical | Code-Quality (or context-driven) |
-| `dotnet build` warning | Minor | Code-Quality |
-| `dotnet test` failure | Critical | Tests |
-| `dotnet format` violation | Suggestion | Code-Quality |
-
-## Examples
-
-```
-[Critical][Security] src/Api/UserController.cs:42
-User input is concatenated directly into a SQL string.
-
-Use parameterized queries via `FromSqlInterpolated` or EF Core's LINQ.
-
-```csharp
-// before
-var users = ctx.Users.FromSqlRaw($"SELECT * FROM Users WHERE Name = '{name}'");
-
-// after
-var users = ctx.Users.FromSqlInterpolated($"SELECT * FROM Users WHERE Name = {name}");
-```
-```
diff --git a/.github/skills/dotnet-reviewer/scripts/collect-diff.sh b/.github/skills/dotnet-reviewer/scripts/collect-diff.sh
deleted file mode 100644
index 75ecc028..00000000
--- a/.github/skills/dotnet-reviewer/scripts/collect-diff.sh
+++ /dev/null
@@ -1,110 +0,0 @@
-#!/usr/bin/env bash
-# collect-diff.sh — collect a unified diff in uncommitted or branch mode.
-# Output JSON: {loc, files, file_list, diff}
-# Exit codes: 0 ok (incl. empty diff), 1 usage, 2 not git, 3 baseline missing.
-
-set -u
-
-usage() {
-  cat <<EOF
-collect-diff.sh — collect a unified diff with exclusions applied
-
-Usage:
-  collect-diff.sh --repo-root <path> --mode uncommitted|branch [--baseline main]
-  collect-diff.sh --help
-
-Exclusions:
-  - .gitignore (implicit via git diff)
-  - *.min.js
-  - wwwroot/lib/**
-
-Exit codes:
-  0  success (empty diff is success)
-  1  usage error
-  2  not a git repository
-  3  baseline branch not found (branch mode only)
-EOF
-}
-
-REPO_ROOT="" MODE="" BASELINE="main"
-while [[ $# -gt 0 ]]; do
-  case "$1" in
-    --repo-root) REPO_ROOT=${2:-}; shift 2 ;;
-    --mode)      MODE=${2:-};      shift 2 ;;
-    --baseline)  BASELINE=${2:-};  shift 2 ;;
-    --help|-h)   usage; exit 0 ;;
-    *) echo "unknown arg: $1" >&2; usage >&2; exit 1 ;;
-  esac
-done
-
-[[ -n "$REPO_ROOT" && -n "$MODE" ]] || { usage >&2; exit 1; }
-case "$MODE" in uncommitted|branch) ;; *) echo "invalid --mode: $MODE" >&2; exit 1 ;; esac
-[[ -d "$REPO_ROOT/.git" ]] || { echo "not a git repository: $REPO_ROOT" >&2; exit 2; }
-
-cd "$REPO_ROOT"
-
-if [[ "$MODE" == "branch" ]]; then
-  if ! git rev-parse --verify --quiet "$BASELINE" -- >/dev/null; then
-    echo "baseline branch not found: $BASELINE" >&2
-    exit 3
-  fi
-fi
-
-# Guard: uncommitted mode against an empty repo (no HEAD yet) — abort cleanly.
-if [[ "$MODE" == "uncommitted" ]] && ! git rev-parse --verify --quiet HEAD -- >/dev/null; then
-  echo "repository has no commits yet (HEAD missing)" >&2
-  exit 3
-fi
-
-# pathspec exclusions on top of .gitignore
-EXCLUDES=(
-  ':(exclude)*.min.js'
-  ':(exclude,glob)wwwroot/lib/**'
-)
-
-if [[ "$MODE" == "uncommitted" ]]; then
-  # working-tree changes vs HEAD (staged + unstaged + untracked)
-  diff_payload=$(git diff HEAD --no-renames -- . "${EXCLUDES[@]}")
-  # Append untracked files as added-from-empty diffs
-  while IFS= read -r f; do
-    [[ -z "$f" ]] && continue
-    diff_payload+=$'\n'$(git diff --no-index --no-renames /dev/null "$f" 2>/dev/null || true)
-  done < <(git ls-files --others --exclude-standard -- . "${EXCLUDES[@]}")
-else
-  diff_payload=$(git diff "$BASELINE"...HEAD --no-renames -- . "${EXCLUDES[@]}")
-fi
-
-# Count files & LOC from the diff
-files=0
-loc=0
-file_list=()
-while IFS= read -r line; do
-  case "$line" in
-    "+++ b/"*) f=${line#+++ b/}; [[ "$f" != "/dev/null" ]] && { file_list+=("$f"); files=$((files+1)); } ;;
-    "+"*|"-"*)
-      [[ "$line" == "+++ "* || "$line" == "--- "* ]] || loc=$((loc+1))
-      ;;
-  esac
-done <<< "$diff_payload"
-
-# emit JSON (escape diff payload for JSON string)
-json_escape() {
-  printf '%s' "$1" | python3 -c 'import json,sys; print(json.dumps(sys.stdin.read()), end="")'
-}
-
-list_json() {
-  local first=1
-  printf '['
-  for v in "$@"; do
-    [[ $first -eq 0 ]] && printf ','
-    first=0
-    printf '"%s"' "${v//\"/\\\"}"
-  done
-  printf ']'
-}
-
-diff_json=$(json_escape "$diff_payload")
-fl_json=$(list_json ${file_list[@]+"${file_list[@]}"})
-
-printf '{"loc":%d,"files":%d,"file_list":%s,"diff":%s}\n' \
-  "$loc" "$files" "$fl_json" "$diff_json"
diff --git a/.github/skills/dotnet-reviewer/scripts/detect-dotnet-version.sh b/.github/skills/dotnet-reviewer/scripts/detect-dotnet-version.sh
deleted file mode 100644
index abc16df1..00000000
--- a/.github/skills/dotnet-reviewer/scripts/detect-dotnet-version.sh
+++ /dev/null
@@ -1,119 +0,0 @@
-#!/usr/bin/env bash
-# detect-dotnet-version.sh — Detect .NET SDK and target frameworks in a repo.
-# Outputs JSON: {sdk, target_frameworks[], project_files[]}
-# Exit codes: 0 ok, 1 usage, 4 SDK<10, 5 malformed project file.
-
-set -u
-
-usage() {
-  cat <<EOF
-detect-dotnet-version.sh — detect .NET SDK and target frameworks
-
-Usage: detect-dotnet-version.sh --repo-root <path>
-       detect-dotnet-version.sh --help
-
-Exit codes:
-  0  success
-  1  usage error
-  4  SDK below 10 or no .NET version detected
-  5  malformed global.json or *.csproj
-EOF
-}
-
-REPO_ROOT=""
-while [[ $# -gt 0 ]]; do
-  case "$1" in
-    --repo-root) REPO_ROOT=${2:-}; shift 2 ;;
-    --help|-h)   usage; exit 0 ;;
-    *) echo "unknown arg: $1" >&2; usage >&2; exit 1 ;;
-  esac
-done
-
-[[ -n "$REPO_ROOT" ]] || { echo "missing --repo-root" >&2; usage >&2; exit 1; }
-[[ -d "$REPO_ROOT" ]] || { echo "not a directory: $REPO_ROOT" >&2; exit 1; }
-
-# --- parse global.json (optional) ---
-SDK="unknown"
-if [[ -f "$REPO_ROOT/global.json" ]]; then
-  SDK=$(grep -oE '"version"[[:space:]]*:[[:space:]]*"[^"]+"' "$REPO_ROOT/global.json" \
-        | head -n1 | sed -E 's/.*"version"[[:space:]]*:[[:space:]]*"([^"]+)".*/\1/')
-  if [[ -z "$SDK" ]]; then
-    echo "malformed global.json: $REPO_ROOT/global.json" >&2
-    exit 5
-  fi
-  sdk_major=${SDK%%.*}
-  if [[ "$sdk_major" =~ ^[0-9]+$ ]] && [[ "$sdk_major" -lt 10 ]]; then
-    echo "global.json pins SDK $SDK; this skill targets .NET 10+" >&2
-    exit 4
-  fi
-fi
-
-# --- find all *.csproj and extract <TargetFramework(s)> ---
-project_files_json="[]"
-tfms_json="[]"
-# bash 3.2 compatible: read into array via while loop
-projects=()
-while IFS= read -r line; do
-  projects+=("$line")
-done < <(find "$REPO_ROOT" -type f -name '*.csproj' -not -path '*/bin/*' -not -path '*/obj/*' 2>/dev/null | sort)
-
-if [[ ${#projects[@]} -eq 0 ]]; then
-  echo "no *.csproj found under $REPO_ROOT" >&2
-  exit 4
-fi
-
-all_tfms=()
-rel_paths=()
-
-for p in "${projects[@]}"; do
-  rel=${p#"$REPO_ROOT/"}
-  rel_paths+=("$rel")
-  # crude check for malformed XML: must contain </Project>
-  if ! grep -q '</Project>' "$p"; then
-    echo "malformed csproj: $p" >&2
-    exit 5
-  fi
-  # extract single or plural element
-  tfm_line=$(grep -oE '<TargetFramework[s]?>[^<]+</TargetFramework[s]?>' "$p" | head -n1 || true)
-  if [[ -z "$tfm_line" ]]; then
-    echo "no TargetFramework in: $p" >&2
-    exit 5
-  fi
-  tfm_value=$(printf '%s' "$tfm_line" | sed -E 's|<TargetFrameworks?>([^<]+)</TargetFrameworks?>|\1|')
-  IFS=';' read -r -a parts <<<"$tfm_value"
-  for t in "${parts[@]}"; do
-    [[ -n "$t" ]] && all_tfms+=("$t")
-  done
-done
-
-# --- enforce .NET 10+ ---
-ok=0
-for t in "${all_tfms[@]}"; do
-  if [[ "$t" =~ ^net([0-9]+)\.[0-9]+$ ]]; then
-    major=${BASH_REMATCH[1]}
-    if [[ $major -ge 10 ]]; then ok=1; break; fi
-  fi
-done
-
-if [[ $ok -eq 0 ]]; then
-  echo "no target framework >= net10.0 detected; found: ${all_tfms[*]}" >&2
-  exit 4
-fi
-
-# --- emit JSON (manual, jq-free) ---
-json_array() {
-  local first=1
-  printf '['
-  for v in "$@"; do
-    [[ $first -eq 0 ]] && printf ','
-    first=0
-    printf '"%s"' "${v//\"/\\\"}"
-  done
-  printf ']'
-}
-
-tfms_json=$(json_array "${all_tfms[@]}")
-project_files_json=$(json_array "${rel_paths[@]}")
-
-printf '{"sdk":"%s","target_frameworks":%s,"project_files":%s}\n' \
-  "$SDK" "$tfms_json" "$project_files_json"
diff --git a/.github/skills/dotnet-reviewer/scripts/run-checks.sh b/.github/skills/dotnet-reviewer/scripts/run-checks.sh
deleted file mode 100644
index df5fbea9..00000000
--- a/.github/skills/dotnet-reviewer/scripts/run-checks.sh
+++ /dev/null
@@ -1,103 +0,0 @@
-#!/usr/bin/env bash
-# run-checks.sh — run optional dotnet build|format|test, emit structured JSON.
-# Output JSON: {build:{ok,warnings[],errors[]}|null, format:{ok,violations[]}|null, test:{ok,failed[],duration}|null}
-# Always exits 0 (tool failures are reported in JSON, not via exit code) unless usage error.
-# DOTNET_BIN env overrides `dotnet` (used by tests).
-
-set -u
-
-usage() {
-  cat <<EOF
-run-checks.sh — run dotnet build/format/test and emit structured JSON
-
-Usage:
-  run-checks.sh --repo-root <path> [--build] [--format] [--test]
-  run-checks.sh --help
-
-Each requested check runs independently; failures are reported in JSON, not via exit code.
-Set DOTNET_BIN to override the dotnet binary path (used by tests).
-EOF
-}
-
-REPO_ROOT=""; DO_BUILD=0; DO_FORMAT=0; DO_TEST=0
-while [[ $# -gt 0 ]]; do
-  case "$1" in
-    --repo-root) REPO_ROOT=${2:-}; shift 2 ;;
-    --build)  DO_BUILD=1; shift ;;
-    --format) DO_FORMAT=1; shift ;;
-    --test)   DO_TEST=1; shift ;;
-    --help|-h) usage; exit 0 ;;
-    *) echo "unknown arg: $1" >&2; usage >&2; exit 1 ;;
-  esac
-done
-
-[[ -n "$REPO_ROOT" && -d "$REPO_ROOT" ]] || { usage >&2; exit 1; }
-
-DOTNET=${DOTNET_BIN:-dotnet}
-
-run_dotnet() {
-  # captures stdout+stderr into the named variable, returns the exit code
-  local _out_var=$1; shift
-  local _tmp; _tmp=$(mktemp)
-  local _rc=0
-  # shellcheck disable=SC2086
-  ( cd "$REPO_ROOT" && $DOTNET "$@" ) >"$_tmp" 2>&1 || _rc=$?
-  printf -v "$_out_var" '%s' "$(cat "$_tmp")"
-  rm -f "$_tmp"
-  return "$_rc"
-}
-
-json_string() {
-  python3 -c 'import json,sys; print(json.dumps(sys.stdin.read()), end="")' <<<"$1"
-}
-
-json_string_array() {
-  local first=1
-  printf '['
-  while IFS= read -r line; do
-    [[ -z "$line" ]] && continue
-    [[ $first -eq 0 ]] && printf ','
-    first=0
-    printf '%s' "$(json_string "$line")"
-  done <<<"$1"
-  printf ']'
-}
-
-BUILD_JSON="null"
-if [[ $DO_BUILD -eq 1 ]]; then
-  out=""
-  run_dotnet out build --nologo --verbosity minimal || true
-  warnings=$(grep -E ': warning [A-Z]+[0-9]+' <<<"$out" || true)
-  errors=$(grep -E ': error [A-Z]+[0-9]+' <<<"$out" || true)
-  ok="true"; [[ -n "$errors" ]] && ok="false"
-  BUILD_JSON=$(printf '{"ok":%s,"warnings":%s,"errors":%s}' \
-    "$ok" \
-    "$(json_string_array "$warnings")" \
-    "$(json_string_array "$errors")")
-fi
-
-FORMAT_JSON="null"
-if [[ $DO_FORMAT -eq 1 ]]; then
-  out=""
-  rc=0
-  run_dotnet out format --verify-no-changes --no-restore || rc=$?
-  violations=$(grep -E '\([0-9]+,[0-9]+\)' <<<"$out" || true)
-  ok="true"; [[ $rc -ne 0 ]] && ok="false"
-  FORMAT_JSON=$(printf '{"ok":%s,"violations":%s}' \
-    "$ok" "$(json_string_array "$violations")")
-fi
-
-TEST_JSON="null"
-if [[ $DO_TEST -eq 1 ]]; then
-  out=""
-  rc=0
-  start=$(date +%s)
-  run_dotnet out test --nologo --verbosity minimal || rc=$?
-  end=$(date +%s)
-  failed=$(grep -E '^Failed:' <<<"$out" || true)
-  ok="true"; [[ $rc -ne 0 ]] && ok="false"
-  TEST_JSON=$(printf '{"ok":%s,"failed":%s,"duration":%d}' \
-    "$ok" "$(json_string_array "$failed")" "$((end - start))")
-fi
-
-printf '{"build":%s,"format":%s,"test":%s}\n' "$BUILD_JSON" "$FORMAT_JSON" "$TEST_JSON"
diff --git a/.github/skills/dotnet-sdk-builder/SKILL.md b/.github/skills/dotnet-sdk-builder/SKILL.md
deleted file mode 100644
index 2f7f0c3d..00000000
--- a/.github/skills/dotnet-sdk-builder/SKILL.md
+++ /dev/null
@@ -1,129 +0,0 @@
----
-name: dotnet-sdk-builder
-description: Generates complete .NET SDK libraries with DI support, interfaces, typed HTTP clients, Options pattern, and typed exceptions. Use when asked to create a .NET SDK, build a .NET client library, wrap a REST API in C#, or generate a typed HTTP client. Invokes csharp-docs for XML documentation and tester for tests.
----
-
-# .NET SDK Library Builder
-
-Generate complete, production-ready .NET SDK libraries from existing C# classes or API documentation. The output follows Microsoft's library design guidelines with full DI support, testability via interfaces, and idiomatic C# patterns.
-
-## Workflow Overview
-
-Follow these steps in order. See the reference files for detailed guidance on each phase.
-
-### Step 1: Analyze Input
-
-Determine what the input is:
-
-- **Existing C# classes**: Read and understand the public API surface, method signatures, and responsibilities.
-- **Documentation** (OpenAPI, Swagger JSON/YAML, Markdown): Parse endpoints, request/response models, authentication, and error responses.
-
-### Step 2: Determine .NET Version
-
-1. Find all `.csproj` files in the solution.
-2. Extract the `<TargetFramework>` (or `<TargetFrameworks>`) value.
-3. If all projects use the same version → use that version.
-4. If versions differ → ask the user which version to target.
-5. Enable nullable reference types based on version:
-   - New project: add `<Nullable>enable</Nullable>` to `.csproj`.
-   - Existing project with nullable disabled: add `#pragma warning disable CS8600` / `#nullable enable` per source file, not globally.
-
-### Step 3: Determine Target Project
-
-1. If the user specified a project → use it.
-2. If no project specified → scan the solution for existing library projects (`.csproj` with no `Sdk="Microsoft.NET.Sdk.Web"` and no executable output).
-3. If a candidate project is found → **ask the user** before adding files to it.
-4. If no suitable project exists → create a new class library project. See [project-setup.md](references/project-setup.md) for conventions.
-
-### Step 4: Derive Names
-
-Derive the service/client name from the input:
-
-| Input | Derived Name Example |
-|---|---|
-| `GitHubService` class | `GitHub` → `IGitHubClient`, `GitHubClient`, `AddGitHub(...)` |
-| `PaymentsApi` class | `Payments` → `IPaymentsClient`, `PaymentsClient`, `AddPayments(...)` |
-| OpenAPI `title: Stripe API` | `Stripe` → `IStripeClient`, `StripeClient`, `AddStripe(...)` |
-
-If the name cannot be derived with confidence → ask the user.
-
-### Step 5: Ask About Resilience
-
-Before generating HTTP client code, ask:
-
-> "Should resilience policies (retry, circuit breaker) be added to the HTTP client using `Microsoft.Extensions.Http.Resilience`?"
-
-If yes → add the Polly-based resilience pipeline. See [http-client-patterns.md](references/http-client-patterns.md#resilience).
-
-### Step 6: Ask About Existing Types Used as Arguments or Return Values
-
-When wrapping existing C# classes, identify all types that appear directly as method parameters or return values in the wrapped API (e.g. classes, records, enums from the source assembly).
-
-For each such type, ask the user **once** (grouped into a single question):
-
-> "The following types from the source are used directly as parameters or return values:
-> - `OrderRequest` (argument of `PlaceOrder`)
-> - `ProductDto` (return value of `GetProduct`)
-> - ...
->
-> Should these types be passed through as-is (reused from the source), or should new equivalents be generated in the SDK library?"
-
-**Options and consequences:**
-
-| Choice | When to recommend | What to generate |
-|---|---|---|
-| **Pass through** | Source types are already in a shared/public assembly that consumers will reference | No new model code; use source types directly in the interface and implementation |
-| **Generate new types** | Source types are internal, in a non-distributable assembly, or consumers should not depend on the source project | New model classes/records in `Models/`; add mapping logic between source and SDK types in the implementation |
-
-If the user chooses to generate new types, apply the same conventions as for response DTOs (see [http-client-patterns.md](references/http-client-patterns.md)). Add a private mapping method or a `XxxMapper` internal class to the implementation to convert between the source type and the SDK type.
-
-### Step 7: Generate Library Code
-
-Generate all components. See [di-patterns.md](references/di-patterns.md) and [http-client-patterns.md](references/http-client-patterns.md) for full patterns.
-
-**Required components:**
-
-| Component | Description |
-|---|---|
-| `IXxxClient` interface | Public contract for DI and testing |
-| `XxxClient` implementation | Concrete HTTP client using `IHttpClientFactory` |
-| `XxxOptions` class | Configuration via Options pattern |
-| `XxxServiceCollectionExtensions` | `AddXxx(...)` extension method |
-| `XxxException` (+ subtypes) | Typed exceptions with diagnostic properties |
-| Model classes | Request/response DTOs |
-
-**NuGet packages to add:**
-
-```xml
-<PackageReference Include="Microsoft.Extensions.Http" Version="*" />
-<PackageReference Include="Microsoft.Extensions.Options" Version="*" />
-<PackageReference Include="Microsoft.Extensions.DependencyInjection.Abstractions" Version="*" />
-<!-- If resilience requested: -->
-<PackageReference Include="Microsoft.Extensions.Http.Resilience" Version="*" />
-```
-
-Always use the latest stable, compatible with target framework version.
-Always use skill 'nuget-manager' for managing NuGet packages and package versions. 
-
-### Step 8: Document the Code
-
-After generating all source files, invoke the `csharp-docs` skill to add XML documentation comments to all public types and members.
-
-### Step 9: Write Tests
-
-After documentation is complete, invoke the `tester` skill to generate unit and integration tests for the library.
-
-## Key Design Principles
-
-- **Interface-first**: Every public service class must have a corresponding interface.
-- **Options pattern**: Configuration always via `IOptions<XxxOptions>`, never constructor parameters for config values.
-- **IHttpClientFactory**: Never inject `HttpClient` directly; always use the named/typed factory pattern.
-- **Typed exceptions**: HTTP errors become typed exceptions with status code, reason, and response body properties.
-- **Nullable**: Follow the project's nullable settings (see Step 2).
-- **No static state**: All state via DI; no singleton anti-patterns.
-
-## Additional Resources
-
-- **[di-patterns.md](references/di-patterns.md)** — DI registration, Options pattern, extension method patterns
-- **[http-client-patterns.md](references/http-client-patterns.md)** — IHttpClientFactory, typed clients, resilience, typed exceptions
-- **[project-setup.md](references/project-setup.md)** — New project structure, folder layout, `.csproj` conventions
diff --git a/.github/skills/dotnet-sdk-builder/references/di-patterns.md b/.github/skills/dotnet-sdk-builder/references/di-patterns.md
deleted file mode 100644
index c6ed0c1c..00000000
--- a/.github/skills/dotnet-sdk-builder/references/di-patterns.md
+++ /dev/null
@@ -1,186 +0,0 @@
-# DI Patterns for .NET SDK Libraries
-
-## Service Registration Extension Method
-
-The entry point for consumers is a single `AddXxx(...)` extension method on `IServiceCollection`.
-
-### Basic Pattern (no options)
-
-```csharp
-public static class GitHubServiceCollectionExtensions
-{
-    public static IHttpClientBuilder AddGitHub(
-        this IServiceCollection services,
-        Action<GitHubOptions> configureOptions)
-    {
-        services.Configure(configureOptions);
-
-        return services
-            .AddHttpClient<IGitHubClient, GitHubClient>()
-            .ConfigureHttpClient((sp, client) =>
-            {
-                var options = sp.GetRequiredService<IOptions<GitHubOptions>>().Value;
-                client.BaseAddress = new Uri(options.BaseUrl);
-                client.DefaultRequestHeaders.Add("User-Agent", options.UserAgent);
-            });
-    }
-}
-```
-
-### Pattern with IConfiguration Section
-
-```csharp
-public static IHttpClientBuilder AddGitHub(
-    this IServiceCollection services,
-    IConfiguration configuration,
-    string sectionName = "GitHub")
-{
-    services.Configure<GitHubOptions>(configuration.GetSection(sectionName));
-
-    return services
-        .AddHttpClient<IGitHubClient, GitHubClient>()
-        .ConfigureHttpClient((sp, client) =>
-        {
-            var options = sp.GetRequiredService<IOptions<GitHubOptions>>().Value;
-            client.BaseAddress = new Uri(options.BaseUrl);
-        });
-}
-```
-
-### Pattern Supporting Both Overloads
-
-Expose both so consumers can use either approach:
-
-```csharp
-public static class GitHubServiceCollectionExtensions
-{
-    public static IHttpClientBuilder AddGitHub(
-        this IServiceCollection services,
-        Action<GitHubOptions> configureOptions)
-    {
-        ArgumentNullException.ThrowIfNull(services);
-        ArgumentNullException.ThrowIfNull(configureOptions);
-
-        services.Configure(configureOptions);
-        return services.AddGitHubCore();
-    }
-
-    public static IHttpClientBuilder AddGitHub(
-        this IServiceCollection services,
-        IConfiguration configuration,
-        string sectionName = "GitHub")
-    {
-        ArgumentNullException.ThrowIfNull(services);
-        ArgumentNullException.ThrowIfNull(configuration);
-
-        services.Configure<GitHubOptions>(configuration.GetSection(sectionName));
-        return services.AddGitHubCore();
-    }
-
-    private static IHttpClientBuilder AddGitHubCore(this IServiceCollection services)
-    {
-        return services
-            .AddHttpClient<IGitHubClient, GitHubClient>()
-            .ConfigureHttpClient((sp, client) =>
-            {
-                var options = sp.GetRequiredService<IOptions<GitHubOptions>>().Value;
-                client.BaseAddress = new Uri(options.BaseUrl);
-            });
-    }
-}
-```
-
-## Options Class
-
-```csharp
-/// <summary>Options for configuring the GitHub client.</summary>
-public sealed class GitHubOptions
-{
-    /// <summary>The base URL of the GitHub API. Defaults to https://api.github.com/.</summary>
-    public string BaseUrl { get; set; } = "https://api.github.com/";
-
-    /// <summary>The personal access token used for authentication.</summary>
-    public string? AccessToken { get; set; }
-
-    /// <summary>The User-Agent header value sent with every request.</summary>
-    public string UserAgent { get; set; } = "GitHubSdk/1.0";
-
-    /// <summary>Request timeout. Defaults to 30 seconds.</summary>
-    public TimeSpan Timeout { get; set; } = TimeSpan.FromSeconds(30);
-}
-```
-
-**Rules:**
-- Use `sealed` — options classes are never subclassed.
-- Provide sensible defaults for all non-secret properties.
-- Nullable (`string?`) for optional secrets/tokens.
-- No validation logic in the class itself; use `IValidateOptions<T>` if needed.
-
-## Options Validation (Optional but Recommended)
-
-```csharp
-internal sealed class GitHubOptionsValidator : IValidateOptions<GitHubOptions>
-{
-    public ValidateOptionsResult Validate(string? name, GitHubOptions options)
-    {
-        if (string.IsNullOrWhiteSpace(options.BaseUrl))
-            return ValidateOptionsResult.Fail($"{nameof(GitHubOptions.BaseUrl)} must not be empty.");
-
-        if (!Uri.TryCreate(options.BaseUrl, UriKind.Absolute, out _))
-            return ValidateOptionsResult.Fail($"{nameof(GitHubOptions.BaseUrl)} must be a valid absolute URI.");
-
-        return ValidateOptionsResult.Success;
-    }
-}
-```
-
-Register alongside options:
-
-```csharp
-services.AddSingleton<IValidateOptions<GitHubOptions>, GitHubOptionsValidator>();
-```
-
-## Interface Pattern
-
-```csharp
-/// <summary>Provides access to the GitHub REST API.</summary>
-public interface IGitHubClient
-{
-    /// <summary>Gets a repository by owner and name.</summary>
-    Task<Repository> GetRepositoryAsync(string owner, string repo, CancellationToken cancellationToken = default);
-
-    /// <summary>Lists public repositories for a user.</summary>
-    Task<IReadOnlyList<Repository>> ListRepositoriesAsync(string username, CancellationToken cancellationToken = default);
-}
-```
-
-**Rules:**
-- Every method returns `Task<T>` or `Task`.
-- Always include `CancellationToken cancellationToken = default` as the last parameter.
-- Interface lives in the same namespace as the implementation; no separate `Abstractions` sub-namespace unless the library is large.
-
-## Namespace Conventions
-
-```
-MyCompany.GitHub          ← root namespace
-MyCompany.GitHub.Models   ← DTOs, request/response models
-MyCompany.GitHub.Http     ← internal HTTP helpers (if needed)
-```
-
-Keep namespaces shallow. Avoid deep hierarchies for small/medium libraries.
-
-## Consumer Registration Example
-
-What the consumer writes in `Program.cs` or `Startup.cs`:
-
-```csharp
-// Action-based
-builder.Services.AddGitHub(options =>
-{
-    options.AccessToken = builder.Configuration["GitHub:AccessToken"];
-    options.UserAgent = "MyApp/1.0";
-});
-
-// Configuration-section-based
-builder.Services.AddGitHub(builder.Configuration);
-```
diff --git a/.github/skills/dotnet-sdk-builder/references/http-client-patterns.md b/.github/skills/dotnet-sdk-builder/references/http-client-patterns.md
deleted file mode 100644
index 80d847a0..00000000
--- a/.github/skills/dotnet-sdk-builder/references/http-client-patterns.md
+++ /dev/null
@@ -1,254 +0,0 @@
-# HTTP Client Patterns for .NET SDK Libraries
-
-## Typed HTTP Client Implementation
-
-Always implement clients as typed HTTP clients registered via `AddHttpClient<TClient, TInterface>()`.
-
-```csharp
-internal sealed class GitHubClient : IGitHubClient
-{
-    private readonly HttpClient _httpClient;
-    private readonly IOptions<GitHubOptions> _options;
-    private readonly JsonSerializerOptions _jsonOptions;
-
-    public GitHubClient(HttpClient httpClient, IOptions<GitHubOptions> options)
-    {
-        _httpClient = httpClient;
-        _options = options;
-        _jsonOptions = new JsonSerializerOptions
-        {
-            PropertyNamingPolicy = JsonNamingPolicy.SnakeCaseLower,
-            DefaultIgnoreCondition = JsonIgnoreCondition.WhenWritingNull,
-        };
-    }
-
-    public async Task<Repository> GetRepositoryAsync(
-        string owner,
-        string repo,
-        CancellationToken cancellationToken = default)
-    {
-        ArgumentException.ThrowIfNullOrWhiteSpace(owner);
-        ArgumentException.ThrowIfNullOrWhiteSpace(repo);
-
-        var response = await _httpClient
-            .GetAsync($"repos/{owner}/{repo}", cancellationToken)
-            .ConfigureAwait(false);
-
-        await EnsureSuccessAsync(response, cancellationToken).ConfigureAwait(false);
-
-        return await response.Content
-            .ReadFromJsonAsync<Repository>(_jsonOptions, cancellationToken)
-            .ConfigureAwait(false)
-            ?? throw new GitHubException("Unexpected null response body.");
-    }
-
-    private static async Task EnsureSuccessAsync(
-        HttpResponseMessage response,
-        CancellationToken cancellationToken)
-    {
-        if (response.IsSuccessStatusCode)
-            return;
-
-        var body = await response.Content
-            .ReadAsStringAsync(cancellationToken)
-            .ConfigureAwait(false);
-
-        throw response.StatusCode switch
-        {
-            HttpStatusCode.Unauthorized => new GitHubAuthenticationException(response.StatusCode, body),
-            HttpStatusCode.NotFound     => new GitHubNotFoundException(response.StatusCode, body),
-            HttpStatusCode.TooManyRequests => new GitHubRateLimitException(response.StatusCode, body),
-            _ => new GitHubException(response.StatusCode, body),
-        };
-    }
-}
-```
-
-**Rules:**
-- Mark the class `internal sealed` — consumers use the interface.
-- Inject `HttpClient` (configured by `IHttpClientFactory`) and `IOptions<T>`.
-- Use `ConfigureAwait(false)` on all awaits.
-- Validate parameters with `ArgumentException.ThrowIfNullOrWhiteSpace` (.NET 7+) or `ArgumentNullException.ThrowIfNull`.
-- All error mapping goes through a single `EnsureSuccessAsync` helper.
-
-## Authentication Header Configuration
-
-Configure auth in the `ConfigureHttpClient` delegate inside the extension method — not inside the client class:
-
-```csharp
-.ConfigureHttpClient((sp, client) =>
-{
-    var options = sp.GetRequiredService<IOptions<GitHubOptions>>().Value;
-    client.BaseAddress = new Uri(options.BaseUrl);
-    client.Timeout = options.Timeout;
-
-    if (!string.IsNullOrWhiteSpace(options.AccessToken))
-        client.DefaultRequestHeaders.Authorization =
-            new AuthenticationHeaderValue("Bearer", options.AccessToken);
-});
-```
-
-For APIs that use API key headers:
-
-```csharp
-if (!string.IsNullOrWhiteSpace(options.ApiKey))
-    client.DefaultRequestHeaders.Add("X-Api-Key", options.ApiKey);
-```
-
-## Typed Exceptions
-
-### Base Exception
-
-```csharp
-/// <summary>The exception thrown when the GitHub API returns an error response.</summary>
-public class GitHubException : Exception
-{
-    /// <summary>The HTTP status code returned by the API.</summary>
-    public HttpStatusCode? StatusCode { get; }
-
-    /// <summary>The raw response body returned by the API, if available.</summary>
-    public string? ResponseBody { get; }
-
-    public GitHubException(string message)
-        : base(message) { }
-
-    public GitHubException(HttpStatusCode statusCode, string? responseBody = null)
-        : base($"GitHub API returned {(int)statusCode} {statusCode}.")
-    {
-        StatusCode = statusCode;
-        ResponseBody = responseBody;
-    }
-
-    public GitHubException(HttpStatusCode statusCode, string? responseBody, Exception inner)
-        : base($"GitHub API returned {(int)statusCode} {statusCode}.", inner)
-    {
-        StatusCode = statusCode;
-        ResponseBody = responseBody;
-    }
-}
-```
-
-### Specific Exception Types
-
-Create one subclass per distinct error scenario:
-
-```csharp
-/// <summary>Thrown when the GitHub API returns 401 Unauthorized.</summary>
-public sealed class GitHubAuthenticationException : GitHubException
-{
-    public GitHubAuthenticationException(HttpStatusCode statusCode, string? responseBody = null)
-        : base(statusCode, responseBody) { }
-}
-
-/// <summary>Thrown when the requested resource does not exist (404).</summary>
-public sealed class GitHubNotFoundException : GitHubException
-{
-    public GitHubNotFoundException(HttpStatusCode statusCode, string? responseBody = null)
-        : base(statusCode, responseBody) { }
-}
-
-/// <summary>Thrown when the GitHub API rate limit has been exceeded (429).</summary>
-public sealed class GitHubRateLimitException : GitHubException
-{
-    /// <summary>The UTC time at which the rate limit resets, if provided by the API.</summary>
-    public DateTimeOffset? ResetAt { get; init; }
-
-    public GitHubRateLimitException(HttpStatusCode statusCode, string? responseBody = null)
-        : base(statusCode, responseBody) { }
-}
-```
-
-**Rules:**
-- Base exception is `public class` (unsealed) — callers can catch the base type.
-- Subtypes are `public sealed class`.
-- Always include `StatusCode` and `ResponseBody` on the base type.
-- Add domain-specific properties to subtypes (e.g., `ResetAt` for rate limit).
-
-## Resilience (Polly via Microsoft.Extensions.Http.Resilience) {#resilience}
-
-Only add if the user confirms resilience is desired.
-
-```xml
-<PackageReference Include="Microsoft.Extensions.Http.Resilience" Version="*" />
-```
-
-```csharp
-private static IHttpClientBuilder AddGitHubCore(this IServiceCollection services)
-{
-    return services
-        .AddHttpClient<IGitHubClient, GitHubClient>()
-        .ConfigureHttpClient((sp, client) =>
-        {
-            var options = sp.GetRequiredService<IOptions<GitHubOptions>>().Value;
-            client.BaseAddress = new Uri(options.BaseUrl);
-        })
-        .AddStandardResilienceHandler(options =>
-        {
-            // Optional: customize defaults
-            options.Retry.MaxRetryAttempts = 3;
-            options.CircuitBreaker.SamplingDuration = TimeSpan.FromSeconds(30);
-        });
-}
-```
-
-`AddStandardResilienceHandler()` configures retry (with exponential backoff), circuit breaker, and timeout by default. Customize only when the defaults are insufficient.
-
-## JSON Serialization
-
-Use `System.Text.Json` (built-in). Configure a shared `JsonSerializerOptions` instance — do not create new instances per call:
-
-```csharp
-private static readonly JsonSerializerOptions JsonOptions = new()
-{
-    PropertyNamingPolicy = JsonNamingPolicy.SnakeCaseLower,  // for snake_case APIs
-    DefaultIgnoreCondition = JsonIgnoreCondition.WhenWritingNull,
-    NumberHandling = JsonNumberHandling.AllowReadingFromString,
-};
-```
-
-For APIs that use camelCase (most REST APIs): use `JsonNamingPolicy.CamelCase`.
-For APIs that use PascalCase: omit `PropertyNamingPolicy`.
-
-## Request/Response Models (DTOs)
-
-```csharp
-/// <summary>Represents a GitHub repository.</summary>
-public sealed class Repository
-{
-    /// <summary>The unique identifier of the repository.</summary>
-    public long Id { get; init; }
-
-    /// <summary>The name of the repository.</summary>
-    public string Name { get; init; } = string.Empty;
-
-    /// <summary>The full qualified name including owner (e.g., "owner/repo").</summary>
-    public string FullName { get; init; } = string.Empty;
-
-    /// <summary>Indicates whether the repository is private.</summary>
-    public bool Private { get; init; }
-
-    /// <summary>The URL of the repository on GitHub.</summary>
-    public string HtmlUrl { get; init; } = string.Empty;
-}
-```
-
-**Rules:**
-- Use `init` setters for immutable DTOs.
-- Initialize string properties to `string.Empty` to avoid nulls.
-- Use `sealed` for response models.
-- Use `JsonPropertyName` attribute only when the JSON key differs from the C# name AND a naming policy cannot handle it.
-
-## Pagination Pattern (if needed)
-
-For paginated APIs, return `IAsyncEnumerable<T>`:
-
-```csharp
-public interface IGitHubClient
-{
-    IAsyncEnumerable<Repository> GetAllRepositoriesAsync(
-        string username,
-        CancellationToken cancellationToken = default);
-}
-```
-
-Implementation uses `yield return` with async page fetching.
diff --git a/.github/skills/dotnet-sdk-builder/references/project-setup.md b/.github/skills/dotnet-sdk-builder/references/project-setup.md
deleted file mode 100644
index 4ffda6f8..00000000
--- a/.github/skills/dotnet-sdk-builder/references/project-setup.md
+++ /dev/null
@@ -1,121 +0,0 @@
-# New Project Setup for .NET SDK Libraries
-
-## When to Create a New Project
-
-Create a new class library project when:
-- No suitable existing project is found in the solution.
-- The user explicitly requests a new project.
-- Adding to an existing project would create an inappropriate coupling (e.g., adding an HTTP client library to a web API project).
-
-Always ask the user for confirmation before creating a new project if not explicitly instructed.
-
-## Project File Template
-
-```xml
-<Project Sdk="Microsoft.NET.Sdk">
-
-  <PropertyGroup>
-    <TargetFramework>net9.0</TargetFramework>
-    <Nullable>enable</Nullable>
-    <ImplicitUsings>enable</ImplicitUsings>
-    <LangVersion>latest</LangVersion>
-    <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
-    <GenerateDocumentationFile>true</GenerateDocumentationFile>
-    <NoWarn>$(NoWarn);CS1591</NoWarn>
-  </PropertyGroup>
-
-  <ItemGroup>
-    <PackageReference Include="Microsoft.Extensions.Http" Version="*" />
-    <PackageReference Include="Microsoft.Extensions.Options" Version="*" />
-    <PackageReference Include="Microsoft.Extensions.DependencyInjection.Abstractions" Version="*" />
-  </ItemGroup>
-
-</Project>
-```
-
-**Key settings:**
-- `<Nullable>enable</Nullable>` — always for new projects when .NET version supports it.
-- `<GenerateDocumentationFile>true</GenerateDocumentationFile>` — required for XML doc generation.
-- `<NoWarn>CS1591</NoWarn>` — suppress "missing XML comment" warnings during development; remove after `csharp-docs` skill adds all docs.
-- `<TreatWarningsAsErrors>true</TreatWarningsAsErrors>` — enforces code quality.
-- `<LangVersion>latest</LangVersion>` — enables the latest C# features for the target framework.
-
-Replace `net9.0` with the .NET version determined in Step 2 of the workflow.
-
-## Folder Structure
-
-```
-MyCompany.GitHub/
-├── MyCompany.GitHub.csproj
-├── GitHubServiceCollectionExtensions.cs   ← DI registration
-├── GitHubOptions.cs                        ← Options class
-├── IGitHubClient.cs                        ← Public interface
-├── GitHubClient.cs                         ← Internal implementation
-├── Exceptions/
-│   ├── GitHubException.cs                  ← Base exception
-│   ├── GitHubAuthenticationException.cs
-│   ├── GitHubNotFoundException.cs
-│   └── GitHubRateLimitException.cs
-└── Models/
-    ├── Repository.cs
-    ├── User.cs
-    └── ...
-```
-
-**Rules:**
-- Root of the project: extension method, options, interface, implementation.
-- `Exceptions/` folder: all exception types.
-- `Models/` folder: all DTOs (request/response models).
-- No `Services/` or `Abstractions/` sub-folders for small libraries — keep it flat.
-- For larger libraries with multiple API areas, group by area: `Repositories/`, `Users/`, etc.
-
-## Naming Conventions
-
-| Artifact | Pattern | Example |
-|---|---|---|
-| Project | `Company.ServiceName` | `Acme.Stripe` |
-| Namespace | Match project name | `Acme.Stripe` |
-| Models namespace | `Company.ServiceName.Models` | `Acme.Stripe.Models` |
-| Interface | `IXxxClient` | `IStripeClient` |
-| Implementation | `XxxClient` | `StripeClient` |
-| Options | `XxxOptions` | `StripeOptions` |
-| Extension class | `XxxServiceCollectionExtensions` | `StripeServiceCollectionExtensions` |
-| Extension method | `AddXxx` | `AddStripe` |
-| Base exception | `XxxException` | `StripeException` |
-
-## Adding to Solution
-
-After creating the `.csproj`, add it to the solution:
-
-```bash
-dotnet sln add path/to/MyCompany.GitHub/MyCompany.GitHub.csproj
-```
-
-## Nullable in Existing Projects
-
-When adding files to an existing project that has `<Nullable>disable</Nullable>` or no nullable setting:
-
-Add at the top of each new source file:
-
-```csharp
-#nullable enable
-```
-
-Do **not** change the `.csproj` setting — this would affect all existing files in the project.
-
-## Global Usings (Optional)
-
-For .NET 6+, a `GlobalUsings.cs` file reduces boilerplate in every source file:
-
-```csharp
-global using System.Net;
-global using System.Net.Http;
-global using System.Net.Http.Json;
-global using System.Text.Json;
-global using System.Text.Json.Serialization;
-global using Microsoft.Extensions.DependencyInjection;
-global using Microsoft.Extensions.Http;
-global using Microsoft.Extensions.Options;
-```
-
-Create this file only when the project has more than ~5 source files that all use these namespaces.
diff --git a/.github/skills/dotnet-tester/SKILL.md b/.github/skills/dotnet-tester/SKILL.md
deleted file mode 100644
index 3b962135..00000000
--- a/.github/skills/dotnet-tester/SKILL.md
+++ /dev/null
@@ -1,121 +0,0 @@
----
-name: dotnet-tester
-description: Writes, executes, and completes unit tests for C#/.NET code using xUnit, FakeItEasy, and AwesomeAssertions. Uses a second agent to identify missing test cases. Use when asked to create .NET tests or improve test coverage.
----
-
-Write comprehensive unit tests for the specified code. Follow a multi-step process with automatic identification of missing test cases.
-
-## Conventions
-
-- **Test Framework**: xUnit
-- **Mocking**: FakeItEasy
-- **Assertions**: AwesomeAssertions (a fork of FluentAssertions with identical API — use `Should()` as usual)
-- **Structure**: Each test method has Arrange/Act/Assert blocks, marked with comments
-- **Language**: English for code, comments, and test names
-- **Style**: Adopt the existing test style from nearby test files in the project
-
-## Phase 1: Write Tests
-
-1. **Analyze code**: Read the code to be tested and understand:
-  - Public API (methods, properties)
-  - Dependencies (what needs to be mocked?)
-  - Different code paths (if/else, switch, exceptions)
-  - Edge Cases (null, empty collections, boundary values)
-
-2. **Identify test project**: Find the appropriate test project by looking for `*.Tests.csproj` files or `*Tests/` directories in the solution. Fall back to scanning for any project whose name ends in `.Tests` or `.Test`. Orient yourself to the existing project structure before adding files.
-
-3. **Create tests**: Write tests following this pattern:
-
-```csharp
-public class MyClassTests
-{
-    [Fact]
-    public void MethodName_Scenario_ExpectedBehavior()
-    {
-        // Arrange
-        var dependency = A.Fake<IDependency>();
-        A.CallTo(() => dependency.DoSomething()).Returns(expectedValue);
-        var sut = new MyClass(dependency);
-
-        // Act
-        var result = sut.MethodUnderTest(input);
-
-        // Assert
-        result.Should().Be(expectedValue);
-    }
-
-    [Theory]
-    [InlineData("input1", "expected1")]
-    [InlineData("input2", "expected2")]
-    public void MethodName_WithVariousInputs_ReturnsExpected(string input, string expected)
-    {
-        // Arrange
-        var sut = new MyClass();
-
-        // Act
-        var result = sut.MethodUnderTest(input);
-
-        // Assert
-        result.Should().Be(expected);
-    }
-}
-```
-
-4. **Cover test categories**:
-  - Happy Path (normal success case)
-  - Error handling (exceptions, invalid inputs)
-  - Null/empty inputs
-  - Boundary values (boundary conditions)
-  - Dependency behavior (mocks, different return values)
-
-## Phase 2: Execute Tests
-
-1. Run `dotnet test` in the relevant test project
-2. Analyze the results:
-  - On **failures**: Identify the cause and fix the test or test setup
-  - On **success**: Continue to Phase 3
-3. Repeat until all tests are green. Don't fakely pass tests. If a test is too complex to set up, consider if it should be refactored or if the code under test should be made more testable.
-
-## Phase 3: Identify Missing Test Cases
-
-Start a **separate agent** that reads the production code and written tests, then returns a prioritized list of missing cases:
-
-- **Edge Cases**: Null, empty strings/collections, boundary/maximum values
-- **Error Paths**: Exceptions, timeouts, dependency errors
-- **Boundary Conditions**: Off-by-one, integer overflow
-- **Interactions**: Call order, multiple/concurrent calls
-- **State Transitions**: Different initial states
-
-Format: `[HIGH/MEDIUM/LOW] MethodName - Scenario: Description`
-
-## Phase 4: Add Missing Tests
-
-1. Implement the identified missing tests (prioritized: HIGH → MEDIUM → LOW)
-2. Run `dotnet test` again
-3. Fix any errors
-4. Ensure all tests are green
-
-## Output Format
-
-At the end, provide a summary:
-
-```
-### Test Result
-
-**Phase 1**: X tests written
-**Phase 2**: All tests green ✅
-**Phase 3**: Y missing cases identified (Z High, W Medium, V Low)
-**Phase 4**: Y additional tests implemented, all green ✅
-
-**Total**: X + Y tests, all passed
-```
-
-## Important Notes
-
-- Do **not write tests for trivial getters/setters** without logic
-- Do **not write tests to check if properties are initialized correctly after construction**
-- Do **not mock value types** or simple DTOs – create real instances
-- Test **behavior**, not implementation details
-- Use **descriptive test names** in the format `MethodName_Scenario_ExpectedBehavior`
-- For `[Theory]` tests: Use `[InlineData]` for simple types, `[MemberData]` for complex objects
-- Use `A.CallTo(...).MustHaveHappened()` sparingly – only when the call is the expected behavior
diff --git a/.github/skills/ef-core/SKILL.md b/.github/skills/ef-core/SKILL.md
deleted file mode 100644
index abf9e4ee..00000000
--- a/.github/skills/ef-core/SKILL.md
+++ /dev/null
@@ -1,91 +0,0 @@
----
-name: ef-core
-description: Entity Framework Core best practices for .NET projects. Use when designing DbContext, creating entities or relationships, writing LINQ queries, managing migrations, implementing repository patterns, or troubleshooting N+1 queries and performance issues with EF Core.
----
-
-# Entity Framework Core Best Practices
-
-## Data Context Design
-
-- Keep DbContext classes focused and cohesive
-- Use constructor injection for configuration options
-- Override OnModelCreating for fluent API configuration
-- Separate entity configurations using IEntityTypeConfiguration
-- Consider using DbContextFactory pattern for console apps or tests
-
-## Entity Design
-
-- Use meaningful primary keys (consider natural vs surrogate keys)
-- Implement proper relationships (one-to-one, one-to-many, many-to-many)
-- Use data annotations or fluent API for constraints and validations
-- Implement appropriate navigational properties
-- Consider using owned entity types for value objects
-
-## Performance
-
-- Use AsNoTracking() for read-only queries
-- Implement pagination for large result sets with Skip() and Take()
-- Use Include() to eager load related entities when needed
-- Consider projection (Select) to retrieve only required fields
-- Use compiled queries for frequently executed queries
-- Avoid N+1 query problems by properly including related data
-
-## Migrations
-
-- Create small, focused migrations
-- Name migrations descriptively
-- Verify migration SQL scripts before applying to production
-- Consider using migration bundles for deployment
-- Add data seeding through migrations when appropriate
-
-## Querying
-
-- Use IQueryable judiciously and understand when queries execute
-- Prefer strongly-typed LINQ queries over raw SQL
-- Use appropriate query operators (Where, OrderBy, GroupBy)
-- Consider database functions for complex operations
-- Implement specifications pattern for reusable queries
-
-## Change Tracking & Saving
-
-- Use appropriate change tracking strategies
-- Batch your SaveChanges() calls
-- Implement concurrency control for multi-user scenarios (see below)
-- Consider using transactions for multiple operations
-- Use appropriate DbContext lifetimes (scoped for web apps)
-
-### Concurrency Control
-
-See [concurrency-control.md](./references/concurrency-control.md) for `[Timestamp]`, `[ConcurrencyCheck]`, fluent API configuration, and `DbUpdateConcurrencyException` handling patterns.
-
-## Security
-
-- Avoid SQL injection by using parameterized queries
-- Implement appropriate data access permissions
-- Be careful with raw SQL queries
-- Consider data encryption for sensitive information
-- Use migrations to manage database user permissions
-
-## Testing
-
-- Avoid the EF Core In-Memory provider for tests — it does not enforce constraints, referential integrity, or transactions, so tests can pass while real database behavior fails
-- Use **SQLite in-memory mode** for lightweight unit and integration tests that need realistic SQL semantics:
-  ```csharp
-  var connection = new SqliteConnection("DataSource=:memory:");
-  connection.Open();
-  var options = new DbContextOptionsBuilder<AppDbContext>()
-      .UseSqlite(connection)
-      .Options;
-  ```
-- Use **Testcontainers** for integration tests that must match production database behavior (e.g., PostgreSQL, SQL Server):
-  ```csharp
-  var container = new PostgreSqlBuilder().Build();
-  await container.StartAsync();
-  var options = new DbContextOptionsBuilder<AppDbContext>()
-      .UseNpgsql(container.GetConnectionString())
-      .Options;
-  ```
-- Mock DbContext and DbSet only for pure unit tests that do not execute queries
-- Test migrations in isolated environments
-- Consider snapshot testing for model changes
-- Use the `dotnet-tester` skill for generating unit and integration tests after schema changes
diff --git a/.github/skills/ef-core/references/concurrency-control.md b/.github/skills/ef-core/references/concurrency-control.md
deleted file mode 100644
index 57200980..00000000
--- a/.github/skills/ef-core/references/concurrency-control.md
+++ /dev/null
@@ -1,52 +0,0 @@
-# Concurrency Control
-
-Use `[Timestamp]` for automatic row-version concurrency (SQL Server / PostgreSQL with `rowversion` or `xmin`):
-
-```csharp
-public class Order
-{
-    public int Id { get; set; }
-    public string Status { get; set; } = string.Empty;
-
-    [Timestamp]
-    public byte[] RowVersion { get; set; } = [];
-}
-```
-
-Use `[ConcurrencyCheck]` to protect individual properties without a row version column:
-
-```csharp
-public class Product
-{
-    public int Id { get; set; }
-
-    [ConcurrencyCheck]
-    public decimal Price { get; set; }
-}
-```
-
-Or configure via fluent API:
-
-```csharp
-modelBuilder.Entity<Order>()
-    .Property(o => o.RowVersion)
-    .IsRowVersion();
-
-modelBuilder.Entity<Product>()
-    .Property(p => p.Price)
-    .IsConcurrencyToken();
-```
-
-Catch `DbUpdateConcurrencyException` at the call site and implement a retry or conflict-resolution strategy:
-
-```csharp
-try
-{
-    await context.SaveChangesAsync();
-}
-catch (DbUpdateConcurrencyException ex)
-{
-    // Reload the entity and resolve the conflict, or inform the user
-    await ex.Entries.Single().ReloadAsync();
-}
-```
diff --git a/.github/skills/nuget-manager/SKILL.md b/.github/skills/nuget-manager/SKILL.md
deleted file mode 100644
index 0e088346..00000000
--- a/.github/skills/nuget-manager/SKILL.md
+++ /dev/null
@@ -1,70 +0,0 @@
----
-name: nuget-manager
-description: Manages NuGet packages in .NET projects and solutions. Use when adding, removing, or updating NuGet package references or versions. Enforces dotnet CLI for package operations, supports Directory.Packages.props central version management, and provides version verification workflows. Handles dotnet add/remove package, dotnet list package --outdated, and dotnet restore.
----
-
-# NuGet Manager
-
-## Prerequisites
-
-- .NET SDK installed (typically .NET 8.0 SDK or later, or a version compatible with the target solution).
-- `dotnet` CLI available on your `PATH`.
-- `jq` (JSON processor) — Linux/macOS; OR
-- PowerShell (`pwsh`) — Windows/cross-platform; required for version verification using `dotnet package search`.
-
-## Core Rules
-
-1.  **NEVER** directly edit `.csproj`, `.props`, or `Directory.Packages.props` files to **add** or **remove** packages. Always use `dotnet add package` and `dotnet remove package` commands.
-2.  **DIRECT EDITING** is ONLY permitted for **changing versions** of existing packages.
-3.  **VERSION UPDATES** must follow the mandatory workflow:
-    - Verify the target version exists on NuGet.
-    - Determine if versions are managed per-project (`.csproj`) or centrally (`Directory.Packages.props`).
-    - Update the version string in the appropriate file.
-    - Immediately run `dotnet restore` to verify compatibility.
-
-## Workflows
-
-### Adding a Package
-Use `dotnet add [<PROJECT>] package <PACKAGE_NAME> [--version <VERSION>]`.
-Example: `dotnet add src/MyProject/MyProject.csproj package Newtonsoft.Json`
-
-### Removing a Package
-Use `dotnet remove [<PROJECT>] package <PACKAGE_NAME>`.
-Example: `dotnet remove src/MyProject/MyProject.csproj package Newtonsoft.Json`
-
-### Updating Package Versions
-When updating a version, follow these steps:
-
-1.  **Verify Version Existence**:
-    Check if the version exists using the `dotnet package search` command with exact match and JSON formatting. 
-    Using `jq`:
-    `dotnet package search <PACKAGE_NAME> --exact-match --format json | jq -e '.searchResult[].packages[] | select(.version == "<VERSION>")'`
-    Using PowerShell:
-    `(dotnet package search <PACKAGE_NAME> --exact-match --format json | ConvertFrom-Json).searchResult.packages | Where-Object { $_.version -eq "<VERSION>" }`
-    
-2.  **Determine Version Management**:
-    - Search for `Directory.Packages.props` in the solution root. If present, versions should be managed there via `<PackageVersion Include="Package.Name" Version="1.2.3" />`.
-    - If absent, check individual `.csproj` files for `<PackageReference Include="Package.Name" Version="1.2.3" />`.
-
-3.  **Apply Changes**:
-    Modify the identified file with the new version string.
-
-4.  **Verify Stability**:
-    Run `dotnet restore` on the project or solution. If errors occur, revert the change and investigate.
-
-### Listing Outdated Packages
-
-Use `dotnet list package --outdated` to find packages with newer versions available.
-
-**Per project:**
-```bash
-dotnet list src/MyProject/MyProject.csproj package --outdated
-```
-
-**Entire solution:**
-```bash
-dotnet list package --outdated
-```
-
-The output shows the current version, the latest resolved version, and the latest available version for each package. Use this as the basis for deciding which packages to update, then follow the **Updating Package Versions** workflow for each.
-
diff --git a/.github/skills/refactoring/SKILL.md b/.github/skills/refactoring/SKILL.md
deleted file mode 100644
index 83e126cd..00000000
--- a/.github/skills/refactoring/SKILL.md
+++ /dev/null
@@ -1,22 +0,0 @@
----
-name: refactoring
-description: Refactors existing code to improve structure, readability, and maintainability without changing behavior. Use when asked to clean up code, reduce duplication, apply SOLID principles, or address code smells (long methods, tight coupling, poor naming). Always verifies existing tests pass before and after changes.
----
-
-# Refactoring Skill
-
-Unless explicitly asked to refactor code directly, generate a refactoring plan first and only apply it if the user approves.
-
-## Workflow
-
-1. **Understand**: Read existing code, identify purpose and behavior, review existing tests
-2. **Identify code smells**: Long methods/classes, duplicated code, complex conditionals, poor naming, tight coupling, low cohesion
-3. **Plan**: Select appropriate refactoring patterns:
-   - Extract Method / Extract Class
-   - Rename for clarity
-   - Introduce Parameter Object
-   - Replace Conditional with Polymorphism
-   - Simplify Complex Expressions
-   - Apply SOLID principles, reduce dependencies, improve abstraction levels
-4. **Execute safely**: Make small, incremental changes. Run tests after each change.
-5. **Verify**: Ensure all tests pass and functionality is preserved
diff --git a/.github/workflows/sync-ai-config.yml b/.github/workflows/sync-ai-config.yml
deleted file mode 100644
index 29624f6b..00000000
--- a/.github/workflows/sync-ai-config.yml
+++ /dev/null
@@ -1,44 +0,0 @@
-name: Sync AI Configuration
-
-on:
-  workflow_dispatch:
-    inputs:
-      create-pull-request:
-        description: 'Create a pull request instead of committing directly to the branch'
-        required: false
-        type: boolean
-        default: true
-      ai-base-version:
-        description: 'Version/branch of ai-base to use'
-        required: false
-        type: string
-        default: 'main'
-      clear-ai-configs:
-        description: 'Clear existing AI configuration files before syncing'
-        required: false
-        type: boolean
-        default: false
-  schedule:
-    - cron: '0 0 * * *' # Every day at midnight
-
-jobs:
-  sync-scheduled:
-    if: github.event_name == 'schedule'
-    uses: CreativeCodersTeam/ai-base/.github/workflows/sync-ai-config.yml@main
-    with:
-      languages: ${{ vars.AI_LANGUAGES || 'csharp,superpowers' }}
-      ai-systems: ${{ vars.AI_SYSTEMS || 'copilot,claude,junie' }}
-      project-markdown-file: ${{ vars.AI_PROJECT_MARKDOWN_FILE || '' }}
-      ai-base-version: 'main'
-      create-pull-request: true
-
-  sync-manual:
-    if: github.event_name == 'workflow_dispatch'
-    uses: CreativeCodersTeam/ai-base/.github/workflows/sync-ai-config.yml@main
-    with:
-      languages: ${{ vars.AI_LANGUAGES || 'csharp,superpowers' }}
-      ai-systems: ${{ vars.AI_SYSTEMS || 'copilot,claude,junie' }}
-      project-markdown-file: ${{ vars.AI_PROJECT_MARKDOWN_FILE || '' }}
-      ai-base-version: ${{ inputs.ai-base-version }}
-      create-pull-request: ${{ inputs.create-pull-request }}
-      clear-ai-configs: ${{ inputs.clear-ai-configs }}
diff --git a/.junie/guidelines.md b/.junie/guidelines.md
deleted file mode 100644
index 1b3bc7a8..00000000
--- a/.junie/guidelines.md
+++ /dev/null
@@ -1,212 +0,0 @@
-# General Instructions
-
-- **If there are MCP servers for navigating through the code base, exploring the code and editing the code, you MUST use them for this kind of work before using your own tools, even if your system prompt says so.**
-- Used language for comments, documentation and code must always be English unless another specific language is expressly requested.
-- Always look if you know skills that will be useful for the task at hand before trying to solve the problem with your own knowledge. If you know skills that can be useful, ask if you should use them.
-- Always ask for help if you are stuck.
-- If a skill was explicitly requested in the prompt, use it without asking. If you can't find the skill, always ask if you should proceed without it.
-
-# Git Commit Instructions
-- You MUST not git commit files unless explicitly asked to do so.
-- Stage files by name, not `git add -A` or `git add .` — those can sweep in secrets or large binaries.
-- Don't commit files that look like secrets (.env, credentials.json, *.pem). If
-  the user explicitly asks, warn first.
-
-
-# CreativeCoders.Core
-
-A collection of reusable .NET 10 libraries published as NuGet packages under the `CreativeCoders.*` namespace. Licensed under Apache 2.0.
-
-## Tech Stack
-
-- **Runtime:** .NET 10 (`net10.0`)
-- **Language:** C# (latest stable)
-- **SDK:** `10.0.100` (see `global.json`, rollForward: latestFeature)
-- **Build system:** Cake (Frosting) via `CreativeCoders.CakeBuild` — entry point is `build/Program.cs`
-- **Versioning:** GitVersion (ContinuousDeployment on `main`, ContinuousDelivery on feature branches)
-- **Package management:** Central Package Management (`Directory.Packages.props`)
-- **Testing:** xUnit, FakeItEasy, AwesomeAssertions, coverlet
-- **CI:** GitHub Actions (ubuntu, windows, macos) — workflows in `.github/workflows/`
-- **NuGet feed:** GitHub Packages (main builds), nuget.org (release builds)
-
-## Repository Layout
-
-```
-Core.sln                     Solution file
-Directory.Build.props         Shared MSBuild properties (TargetFramework, Authors)
-Directory.Packages.props      Central NuGet version pins
-global.json                   SDK version constraint
-GitVersion.yml                Versioning configuration
-build/                        Cake Frosting build project
-  Program.cs                  Build entry point (CakeHostBuilder)
-  BuildContext.cs             Build configuration (feeds, tools, settings)
-source/                       Library source code (see below)
-tests/                        Unit/integration test projects
-samples/                      Sample applications
-.github/workflows/            CI/CD pipelines
-```
-
-## Source Libraries
-
-| Area | Projects | Purpose |
-|------|----------|---------|
-| **Core** | `CreativeCoders.Core` | Ensure guards, collections, threading, enums, reflection, IO helpers, visitor pattern, object linking, dependency trees |
-| **AspNetCore** | `.AspNetCore`, `.Blazor`, `.TokenAuth.Jwt`, `.TokenAuthApi`, `.TokenAuthApi.Jwt` | ASP.NET Core extensions, Blazor helpers, JWT token auth |
-| **Cli** | `.Cli.Core`, `.Cli.Hosting` | CLI application framework with hosting support |
-| **SysConsole** | `.SysConsole.App`, `.Core`, `.Cli.Actions`, `.Cli.Parsing`, `.CliArguments` | Console applications with Spectre.Console, argument parsing, CLI actions |
-| **Data** | `.Data`, `.Data.EfCore`, `.Data.EfCore.SqlServer`, `.Data.Nhibernate`, `.Data.NoSql`, `.Data.NoSql.LiteDb` | Data access abstractions, EF Core, NHibernate, LiteDB |
-| **Net** | `.Net`, `.Net.Avm`, `.Net.JsonRpc`, `.Net.WebApi`, `.Net.XmlRpc`, `.Net.Servers.Http.AspNetCore` | Networking utilities, JSON-RPC, XML-RPC, WebApi client, HTTP server |
-| **Messaging** | `.Messaging.Core`, `.Messaging.DefaultMediator`, `.Messaging.DefaultMessageQueue` | In-process messaging, mediator pattern, message queues |
-| **Reactive** | `.Reactive.Messaging` | Reactive Extensions-based messaging |
-| **Config** | `.Config`, `.Config.Base`, `.Config.Sources` | Configuration abstraction layer |
-| **Configuration** | `.Configuration` | Microsoft.Extensions.Configuration integration |
-| **Options** | `.Options.Core`, `.Options.Serializers`, `.Options.Storage.FileSystem` | Options pattern with persistence |
-| **DependencyInjection** | `.DependencyInjection` | DI container extensions |
-| **Scripting** | `.Scripting.Base`, `.Scripting.CSharp` | C# scripting and source code generation |
-| **CodeCompilation** | `.CodeCompilation`, `.CodeCompilation.Roslyn` | Runtime code compilation via Roslyn |
-| **DynamicCode** | `.DynamicCode.Proxying` | Dynamic proxy generation (Castle.Core) |
-| **IO** | `.IO.Archives`, `.IO.Ports` | Archive handling, serial port abstractions |
-| **Localization** | `.Localization` | Microsoft.Extensions.Localization integration |
-| **Daemon** | `.Daemon`, `.Daemon.Linux`, `.Daemon.Windows` | Cross-platform daemon/service hosting (systemd, Windows Services) |
-| **ProcessUtils** | `.ProcessUtils` | Process execution utilities |
-| **UnitTests** | `.UnitTests` | Test helper library |
-| **CakeBuild** | `.CakeBuild` | Reusable Cake Frosting build tasks |
-| **NukeBuild** | `.NukeBuild`, `.NukeBuild.Components` | Nuke build system components |
-
-## Build & Test
-
-### Development
-
-Use standard `dotnet` commands for building, testing and restoring:
-
-```bash
-dotnet restore
-dotnet build
-dotnet test
-```
-
-### Build Pipeline (Cake Frosting)
-
-The full CI pipeline uses Cake Frosting. These commands are intended for CI/CD and release workflows — not for day-to-day development:
-
-```bash
-./build.sh -t pack            # Linux/macOS
-./build.cmd -t pack           # Windows
-./build.sh -t test            # Tests with coverage
-./build.cmd -t nugetpush      # Full pipeline with NuGet push (CI only)
-```
-
-Build targets are defined in `CreativeCoders.CakeBuild` and configured in `build/BuildContext.cs`. The build uses GitVersion for automatic semantic versioning and ReportGenerator for coverage reports (output: `.tests/coverage-report`).
-
-## CI/CD Workflows
-
-| Workflow | Trigger | Purpose |
-|----------|---------|---------|
-| `main.yml` | Push to `main` | Build, test, pack, push to NuGet (Linux pushes, Windows/macOS build+test only) |
-| `pull-request.yml` | PR to `main` | Build and test on all platforms |
-| `integration.yml` | Manual/schedule | Integration testing |
-| `release.yml` | Release event | Publish to nuget.org |
-| `dependabot-auto-merge.yml` | Dependabot PRs | Auto-merge dependency updates |
-| `sync-ai-config.yml` | Config sync | Synchronize AI configuration files |
-
------------------------------------------------------------
-
-
-GitHub Copilot must ignore the following content in this file, cause Copilot gets this infos from the files in the .github/instructions directory:
-
------------------------------------------------------------
-
-
----
-description: 'Guidelines for building C# applications'
-applyTo: '**/*.cs'
----
-
-# C# Development
-
-- Always use the latest stable C# version available in the project's target framework.
-
-## General Instructions
-
-- Use `Ensure.NotNull(...)` from `CreativeCoders.Core` for null guards
-- Use `Ensure.IsNotNullOrEmpty(...)` from `CreativeCoders.Core` for string guards for arguments that must not be empty
-- Use `Ensure.IsNotNullOrWhitespace(...)` from `CreativeCoders.Core` for string guards for arguments that must not be empty or whitespace
-- Guard arguments for public methods in libraries with `Ensure.NotNull(...)` for all required parameters:
-```csharp
-public void DoSomething(string input, string fileName)
-{
-    Ensure.NotNull(input);
-    Ensure.NotNullOrWhitespace(fileName);
-    // method implementation
-}
-```
-- Guard constructor-injected dependencies with `Ensure.NotNull(...)` for all required parameters:
-```csharp
-_service = Ensure.NotNull(service);
-```
-
-## Formatting
-
-- Apply code-formatting style defined in `.editorconfig`.
-- Prefer file-scoped namespace declarations and single-line using directives.
-- Insert a newline before the opening curly brace of any code block (e.g., after `if`, `for`, `while`, `foreach`,
-  `using`, `try`, etc.).
-- Ensure that the final return statement of a method is on its own line.
-- Use `nameof` instead of string literals when referring to member names.
-- Use `[UsedImplicitly]` from JetBrains.Annotations when types are only used via DI or reflection.
-- Use naming conventions from surrounding code when they differ from standard C# conventions.
-
-## Modern C# Features
-
-- Use **primary constructors** when no constructor body is needed.
-- Use private fields with guards instead of using primary constructor parameters directly, unless the parameter is assigned to a property.
-
-## Async/Await
-
-- In **library code** always use `.ConfigureAwait(false)`
-- In **tests** do not use `.ConfigureAwait(false)` (disable for tests via tests/.editorconfig)
-- YOU MUST NOT USE `.GetAwaiter().GetResult()` OR `.Result` OR `.Wait()` TO BLOCK ON ASYNC CODE. If there is no other way ask the user what to do.
-
-## Nullable Reference Types
-
-- Declare variables non-nullable, and check for `null` at entry points.
-- Always use `is null` or `is not null` instead of `== null` or `!= null`.
-- Trust the C# null annotations — don't add null checks when the type system guarantees non-null.
-
-## Documentation
-
-- Document all public members with XML documentation.
-- Use the `csharp-docs` skill to ensure XML documentation follows best practices.
-- If you change code, always update the relevant XML documentation.
-
-## Testing
-
-- Always include test cases for code changes.
-- Always use the `dotnet-tester` skill for writing tests.
-
-## Console
-
-- Use AnsiConsole for console input and output. Always use IAnsiConsole via dependency injection.
-- Use colored output where it makes sense. For example, use green for success messages, red for errors and yellow for warnings.
-- Use tables for structured output when displaying lists of data or multiple pieces of related information.
-
-## Logging
-
-- Use Serilog for logging.
-- Configure Serilog with appropriate sinks (e.g., file, console, Azure Application Insights) based on environment.
-- Always use structured logging with properties for better log analysis and correlation.
-
-## Skills Reference
-
-- Use the `dotnet-aspnet` skill for ASP.NET Core projects (project structure, middleware, auth, validation, error handling, API versioning, OpenAPI).
-- Use the `ef-core` skill for Entity Framework Core data access patterns.
-- Use the `dotnet-sdk-builder` skill for creating .NET SDK/client libraries.
-- Use the `dotnet-reviewer` skill for Reviewing .NET Code.
-- Use the `dotnet-tester` skill for writing tests.
-- Use the `nuget-manager` skill for NuGet package management.
-- Use the `dotnet-inspect` skill to query .NET APIs in NuGet packages, platform libraries (System.*, Microsoft.AspNetCore.*), or local .dll/.nupkg files — discover types and members, diff API surfaces between versions, find extension methods/implementors, locate SourceLink URLs, and triage breakages caused by package upgrades.
-- Use the `csharp-docs` skill to ensure XML documentation follows best practices.
-
------------------------------------------------------------
-
-
diff --git a/.serena/project.yml b/.serena/project.yml
index 9be0c64c..88705ec6 100644
--- a/.serena/project.yml
+++ b/.serena/project.yml
@@ -3,22 +3,27 @@ project_name: "Core"
 
 
 # list of languages for which language servers are started; choose from:
-#   al                  bash                clojure             cpp                 csharp
-#   csharp_omnisharp    dart                elixir              elm                 erlang
-#   fortran             fsharp              go                  groovy              haskell
-#   haxe                java                julia               kotlin              lua
-#   markdown
-#   matlab              nix                 pascal              perl                php
-#   php_phpactor        powershell          python              python_jedi         r
-#   rego                ruby                ruby_solargraph     rust                scala
-#   swift               terraform           toml                typescript          typescript_vts
-#   vue                 yaml                zig
+#   al                  angular             ansible             bash                clojure
+#   cpp                 cpp_ccls            crystal             csharp              csharp_omnisharp
+#   dart                elixir              elm                 erlang              fortran
+#   fsharp              go                  groovy              haskell             haxe
+#   hlsl                html                java                json                julia
+#   kotlin              lean4               lua                 luau                markdown
+#   matlab              msl                 nix                 ocaml               pascal
+#   perl                php                 php_phpactor        powershell          python
+#   python_jedi         python_ty           r                   rego                ruby
+#   ruby_solargraph     rust                scala               scss                solidity
+#   svelte              swift               systemverilog       terraform           toml
+#   typescript          typescript_vts      vue                 yaml                zig
 #   (This list may be outdated. For the current list, see values of Language enum here:
 #   https://github.com/oraios/serena/blob/main/src/solidlsp/ls_config.py
 #   For some languages, there are alternative language servers, e.g. csharp_omnisharp, ruby_solargraph.)
 # Note:
 #   - For C, use cpp
 #   - For JavaScript, use typescript
+#   - For Angular projects, use angular (subsumes typescript+html; requires `npm install` in the project root)
+#   - For Svelte projects, use svelte (subsumes typescript/javascript for .svelte projects; requires npm)
+#   - For SCSS / Sass / plain CSS, use scss (some-sass-language-server handles all three)
 #   - For Free Pascal/Lazarus, use pascal
 # Special requirements:
 #   Some languages require additional setup/installations.
@@ -66,54 +71,17 @@ read_only: false
 
 # list of tool names to exclude.
 # This extends the existing exclusions (e.g. from the global configuration)
-#
-# Below is the complete list of tools for convenience.
-# To make sure you have the latest list of tools, and to view their descriptions, 
-# execute `uv run scripts/print_tool_overview.py`.
-#
-#  * `activate_project`: Activates a project based on the project name or path.
-#  * `check_onboarding_performed`: Checks whether project onboarding was already performed.
-#  * `create_text_file`: Creates/overwrites a file in the project directory.
-#  * `delete_memory`: Delete a memory file. Should only happen if a user asks for it explicitly,
-#       for example by saying that the information retrieved from a memory file is no longer correct
-#       or no longer relevant for the project.
-#  * `edit_memory`: Replaces content matching a regular expression in a memory.
-#  * `execute_shell_command`: Executes a shell command.
-#  * `find_file`: Finds files in the given relative paths
-#  * `find_referencing_symbols`: Finds symbols that reference the given symbol using the language server backend
-#  * `find_symbol`: Performs a global (or local) search using the language server backend.
-#  * `get_current_config`: Prints the current configuration of the agent, including the active and available projects, tools, contexts, and modes.
-#  * `get_symbols_overview`: Gets an overview of the top-level symbols defined in a given file.
-#  * `initial_instructions`: Provides instructions Serena usage (i.e. the 'Serena Instructions Manual')
-#       for clients that do not read the initial instructions when the MCP server is connected.
-#  * `insert_after_symbol`: Inserts content after the end of the definition of a given symbol.
-#  * `insert_before_symbol`: Inserts content before the beginning of the definition of a given symbol.
-#  * `list_dir`: Lists files and directories in the given directory (optionally with recursion).
-#  * `list_memories`: List available memories. Any memory can be read using the `read_memory` tool.
-#  * `onboarding`: Performs onboarding (identifying the project structure and essential tasks, e.g. for testing or building).
-#  * `read_file`: Reads a file within the project directory.
-#  * `read_memory`: Read the content of a memory file. This tool should only be used if the information
-#       is relevant to the current task. You can infer whether the information
-#       is relevant from the memory file name.
-#       You should not read the same memory file multiple times in the same conversation.
-#  * `rename_memory`: Renames or moves a memory. Moving between project and global scope is supported
-#       (e.g., renaming "global/foo" to "bar" moves it from global to project scope).
-#  * `rename_symbol`: Renames a symbol throughout the codebase using language server refactoring capabilities.
-#       For JB, we use a separate tool.
-#  * `replace_content`: Replaces content in a file (optionally using regular expressions).
-#  * `replace_symbol_body`: Replaces the full definition of a symbol using the language server backend.
-#  * `safe_delete_symbol`:
-#  * `search_for_pattern`: Performs a search for a pattern in the project.
-#  * `write_memory`: Write some information (utf-8-encoded) about this project that can be useful for future tasks to a memory in md format.
-#       The memory name should be meaningful.
+# Find the list of tools here: https://oraios.github.io/serena/01-about/035_tools.html
 excluded_tools: []
 
 # list of tools to include that would otherwise be disabled (particularly optional tools that are disabled by default).
 # This extends the existing inclusions (e.g. from the global configuration).
+# Find the list of tools here: https://oraios.github.io/serena/01-about/035_tools.html
 included_optional_tools: []
 
 # fixed set of tools to use as the base tool set (if non-empty), replacing Serena's default set of tools.
 # This cannot be combined with non-empty excluded_tools or included_optional_tools.
+# Find the list of tools here: https://oraios.github.io/serena/01-about/035_tools.html
 fixed_tools: []
 
 # list of mode names to that are always to be included in the set of active modes
@@ -124,11 +92,14 @@ fixed_tools: []
 # Set this to a list of mode names to always include the respective modes for this project.
 base_modes:
 
-# list of mode names that are to be activated by default.
-# The full set of modes to be activated is base_modes + default_modes.
-# If the setting is undefined, the default_modes from the global configuration (serena_config.yml) apply.
+# list of mode names that are to be activated by default, overriding the setting in the global configuration.
+# The full set of modes to be activated is base_modes (from global config) + default_modes + added_modes.
+# If the setting is undefined/empty, the default_modes from the global configuration (serena_config.yml) apply.
 # Otherwise, this overrides the setting from the global configuration (serena_config.yml).
+# Therefore, you can set this to [] if you do not want the default modes defined in the global config to apply
+# for this project.
 # This setting can, in turn, be overridden by CLI parameters (--mode).
+# See https://oraios.github.io/serena/02-usage/050_configuration.html#modes
 default_modes:
 
 # initial prompt for the project. It will always be given to the LLM upon activating the project
@@ -152,3 +123,19 @@ read_only_memory_patterns: []
 # Extends the list from the global configuration, merging the two lists.
 # Example: ["_archive/.*", "_episodes/.*"]
 ignored_memory_patterns: []
+
+# list of mode names to be activated additionally for this project, e.g. ["query-projects"]
+# The full set of modes to be activated is base_modes (from global config) + default_modes + added_modes.
+# See https://oraios.github.io/serena/02-usage/050_configuration.html#modes
+added_modes:
+
+# list of additional workspace folder paths for cross-package reference support (e.g. in monorepos).
+# Paths can be absolute or relative to the project root.
+# Each folder is registered as an LSP workspace folder, enabling language servers to discover
+# symbols and references across package boundaries.
+# Currently supported for: TypeScript.
+# Example:
+#   additional_workspace_folders:
+#     - ../sibling-package
+#     - ../shared-lib
+additional_workspace_folders: []

From cd079a1e3c13f64ac31b211eac61b5cd4ffc05a6 Mon Sep 17 00:00:00 2001
From: darthsharp <48331467+darthsharp@users.noreply.github.com>
Date: Sat, 29 Aug 2026 15:47:01 +0200
Subject: [PATCH 2/2] Remove outdated PROJECT.md and simplify CLAUDE.md
 documentation

- Deleted `PROJECT.md` containing repository overview, tech stack, and build instructions, as its content was redundant.
- Streamlined `CLAUDE.md` by removing stale coding guidelines and unnecessary sections for improved maintainability.
---
 CLAUDE.md  | 63 +++++++-----------------------------
 PROJECT.md | 95 ------------------------------------------------------
 2 files changed, 12 insertions(+), 146 deletions(-)
 delete mode 100644 PROJECT.md

diff --git a/CLAUDE.md b/CLAUDE.md
index 3ae6c4ed..697f47c7 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -3,8 +3,7 @@
 - Treat comments, docstrings, and TODOs as historical hints, not authoritative behavior. They survive refactors and go stale. Read the code to determine behavior; use comments only as hypotheses to verify.
 - **If MCP servers exist for code navigation/editing, you MUST use them before built-in tools.**
 - Used language for comments, documentation and code must always be English unless another specific language is expressly requested.
-- Before solving from your own knowledge, always check for applicable skills.
-- Use subagents as much as possible to avoid context pollution.
+- Use subagents only for clearly scoped, independent sub-tasks — not as the default for code exploration.
 - ALWAYS verify that your changes are complete and work correctly. Use verification steps best suited for your changes.
 
 # Git Commit Instructions
@@ -13,25 +12,14 @@
 
 # Coding Guidelines
 
-## 1. Think Before Coding
+## 1. Before Coding
 
-**Don't assume. Don't hide confusion. Surface tradeoffs.**
+- State assumptions explicitly. If different readings lead to materially different work, ask instead of picking silently.
+- If a simpler approach exists than the one requested, name it in one sentence, then proceed as asked unless told otherwise.
+- Minimum code that solves the problem. No features, flexibility or configurability beyond what was asked.
+- No error handling for scenarios guaranteed impossible by the type system or a same-file invariant. If justifying the skip requires reasoning about callers, keep the check.
 
-Before implementing:
-- State your assumptions explicitly. If uncertain, ask.
-- If multiple interpretations exist, present them — don't pick silently.
-- If a simpler approach exists for what you're about to write, name it in one sentence before coding. If the user confirms the original, proceed.
-- If something is unclear, stop. Name what's confusing. Ask.
-
-## 2. Simplicity First
-
-**Minimum code that solves the problem. Nothing speculative.**
-
-- No features beyond what was asked.
-- No "flexibility" or "configurability" that wasn't requested.
-- No error handling for impossible scenarios. No error handling for scenarios guaranteed impossible by the type system or a same-file invariant. If justifying the skip requires reasoning about callers, keep the check.
-
-## 3. Surgical Changes
+## 2. Surgical Changes
 
 **Touch only what you must. Clean up only your own mess.**
 
@@ -45,7 +33,7 @@ When your changes create orphans: Remove imports/variables/functions your change
 
 ## Priority when rules conflict
 1. Ask beats guessing or silent assumption.
-2. Surgical beats Simplify for existing code. § 2 applies only to code you write new in this task; don't rewrite existing code to make it simpler unless asked.
+2. Surgical beats Simplicity for existing code: the simplicity rules apply only to code you write new in this task; don't rewrite existing code to make it simpler unless asked.
 3. Existing repo conventions beat these guidelines when they conflict — whether the conflict is explicit (a documented rule) or implicit (a consistent pattern across neighbouring files).
 
 
@@ -68,7 +56,7 @@ A collection of reusable .NET 10 libraries published as NuGet packages under the
 ## Repository Layout
 
 ```
-Core.sln                     Solution file
+Core.slnx                    Solution file
 Directory.Build.props         Shared MSBuild properties (TargetFramework, Authors)
 Directory.Packages.props      Central NuGet version pins
 global.json                   SDK version constraint
@@ -143,21 +131,11 @@ Build targets are defined in `CreativeCoders.CakeBuild` and configured in `build
 | `integration.yml` | Manual/schedule | Integration testing |
 | `release.yml` | Release event | Publish to nuget.org |
 | `dependabot-auto-merge.yml` | Dependabot PRs | Auto-merge dependency updates |
-| `sync-ai-config.yml` | Config sync | Synchronize AI configuration files |
-
------------------------------------------------------------
-
-
----
-description: 'Guidelines for building C# applications'
-applyTo: '**/*.cs'
----
+| `dependabot-manual.yml` | Manual (`workflow_dispatch`) | Check outdated NuGet packages |
 
 # C# Development
 
-- Always use the latest stable C# version available in the project's target framework.
-
-## General Instructions
+## Guard Clauses
 
 - Use `Ensure.NotNull(...)` from `CreativeCoders.Core` for null guards
 - Use `Ensure.IsNotNullOrEmpty(...)` from `CreativeCoders.Core` for string guards for arguments that must not be empty
@@ -167,7 +145,7 @@ applyTo: '**/*.cs'
 public void DoSomething(string input, string fileName)
 {
     Ensure.NotNull(input);
-    Ensure.NotNullOrWhitespace(fileName);
+    Ensure.IsNotNullOrWhitespace(fileName);
     // method implementation
 }
 ```
@@ -215,13 +193,11 @@ _service = Ensure.NotNull(service);
 ## Documentation
 
 - Document all public members with XML documentation.
-- Use the `dotnet-xmldocs` skill to ensure XML documentation follows best practices.
 - If you change code, always update the relevant XML documentation.
 
 ## Testing
 
 - Always include test cases for code changes.
-- Always use the `dotnet-tester` skill for writing tests.
 
 ## Console
 
@@ -234,18 +210,3 @@ _service = Ensure.NotNull(service);
 - Use Serilog for logging.
 - Configure Serilog with appropriate sinks (e.g., file, console, Azure Application Insights) based on environment.
 - Always use structured logging with properties for better log analysis and correlation.
-
-## Skills Reference
-
-- You MUST use the `dotnet-aspnet` skill for ASP.NET Core projects (project structure, middleware, auth, validation, error handling, API versioning, OpenAPI).
-- You MUST use the `dotnet-ef-core` skill for Entity Framework Core data access patterns.
-- You MUST use the `dotnet-sdk-builder` skill for creating .NET SDK/client libraries.
-- You MUST use the `dotnet-reviewer` skill for Reviewing .NET Code.
-- You MUST use the `dotnet-tester` skill for writing and editing tests.
-- You MUST use the `dotnet-nuget-manager` skill for NuGet package management.
-- You MUST use the `dotnet-inspect` skill to query .NET APIs in NuGet packages, platform libraries (System.*, Microsoft.AspNetCore.*), or local .dll/.nupkg files — discover types and members, diff API surfaces between versions, find extension methods/implementors, locate SourceLink URLs, and triage breakages caused by package upgrades.
-- You MUST use the `dotnet-xmldocs` skill to ensure XML documentation follows best practices.
-
------------------------------------------------------------
-
-
diff --git a/PROJECT.md b/PROJECT.md
deleted file mode 100644
index 81ef7c36..00000000
--- a/PROJECT.md
+++ /dev/null
@@ -1,95 +0,0 @@
-# CreativeCoders.Core
-
-A collection of reusable .NET 10 libraries published as NuGet packages under the `CreativeCoders.*` namespace. Licensed under Apache 2.0.
-
-## Tech Stack
-
-- **Runtime:** .NET 10 (`net10.0`)
-- **Language:** C# (latest stable)
-- **SDK:** `10.0.100` (see `global.json`, rollForward: latestFeature)
-- **Build system:** Cake (Frosting) via `CreativeCoders.CakeBuild` — entry point is `build/Program.cs`
-- **Versioning:** GitVersion (ContinuousDeployment on `main`, ContinuousDelivery on feature branches)
-- **Package management:** Central Package Management (`Directory.Packages.props`)
-- **Testing:** xUnit, FakeItEasy, AwesomeAssertions, coverlet
-- **CI:** GitHub Actions (ubuntu, windows, macos) — workflows in `.github/workflows/`
-- **NuGet feed:** GitHub Packages (main builds), nuget.org (release builds)
-
-## Repository Layout
-
-```
-Core.sln                     Solution file
-Directory.Build.props         Shared MSBuild properties (TargetFramework, Authors)
-Directory.Packages.props      Central NuGet version pins
-global.json                   SDK version constraint
-GitVersion.yml                Versioning configuration
-build/                        Cake Frosting build project
-  Program.cs                  Build entry point (CakeHostBuilder)
-  BuildContext.cs             Build configuration (feeds, tools, settings)
-source/                       Library source code (see below)
-tests/                        Unit/integration test projects
-samples/                      Sample applications
-.github/workflows/            CI/CD pipelines
-```
-
-## Source Libraries
-
-| Area | Projects | Purpose |
-|------|----------|---------|
-| **Core** | `CreativeCoders.Core` | Ensure guards, collections, threading, enums, reflection, IO helpers, visitor pattern, object linking, dependency trees |
-| **AspNetCore** | `.AspNetCore`, `.Blazor`, `.TokenAuth.Jwt`, `.TokenAuthApi`, `.TokenAuthApi.Jwt` | ASP.NET Core extensions, Blazor helpers, JWT token auth |
-| **Cli** | `.Cli.Core`, `.Cli.Hosting` | CLI application framework with hosting support |
-| **SysConsole** | `.SysConsole.App`, `.Core`, `.Cli.Actions`, `.Cli.Parsing`, `.CliArguments` | Console applications with Spectre.Console, argument parsing, CLI actions |
-| **Data** | `.Data`, `.Data.EfCore`, `.Data.EfCore.SqlServer`, `.Data.Nhibernate`, `.Data.NoSql`, `.Data.NoSql.LiteDb` | Data access abstractions, EF Core, NHibernate, LiteDB |
-| **Net** | `.Net`, `.Net.Avm`, `.Net.JsonRpc`, `.Net.WebApi`, `.Net.XmlRpc`, `.Net.Servers.Http.AspNetCore` | Networking utilities, JSON-RPC, XML-RPC, WebApi client, HTTP server |
-| **Messaging** | `.Messaging.Core`, `.Messaging.DefaultMediator`, `.Messaging.DefaultMessageQueue` | In-process messaging, mediator pattern, message queues |
-| **Reactive** | `.Reactive.Messaging` | Reactive Extensions-based messaging |
-| **Config** | `.Config`, `.Config.Base`, `.Config.Sources` | Configuration abstraction layer |
-| **Configuration** | `.Configuration` | Microsoft.Extensions.Configuration integration |
-| **Options** | `.Options.Core`, `.Options.Serializers`, `.Options.Storage.FileSystem` | Options pattern with persistence |
-| **DependencyInjection** | `.DependencyInjection` | DI container extensions |
-| **Scripting** | `.Scripting.Base`, `.Scripting.CSharp` | C# scripting and source code generation |
-| **CodeCompilation** | `.CodeCompilation`, `.CodeCompilation.Roslyn` | Runtime code compilation via Roslyn |
-| **DynamicCode** | `.DynamicCode.Proxying` | Dynamic proxy generation (Castle.Core) |
-| **IO** | `.IO.Archives`, `.IO.Ports` | Archive handling, serial port abstractions |
-| **Localization** | `.Localization` | Microsoft.Extensions.Localization integration |
-| **Daemon** | `.Daemon`, `.Daemon.Linux`, `.Daemon.Windows` | Cross-platform daemon/service hosting (systemd, Windows Services) |
-| **ProcessUtils** | `.ProcessUtils` | Process execution utilities |
-| **UnitTests** | `.UnitTests` | Test helper library |
-| **CakeBuild** | `.CakeBuild` | Reusable Cake Frosting build tasks |
-| **NukeBuild** | `.NukeBuild`, `.NukeBuild.Components` | Nuke build system components |
-
-## Build & Test
-
-### Development
-
-Use standard `dotnet` commands for building, testing and restoring:
-
-```bash
-dotnet restore
-dotnet build
-dotnet test
-```
-
-### Build Pipeline (Cake Frosting)
-
-The full CI pipeline uses Cake Frosting. These commands are intended for CI/CD and release workflows — not for day-to-day development:
-
-```bash
-./build.sh -t pack            # Linux/macOS
-./build.cmd -t pack           # Windows
-./build.sh -t test            # Tests with coverage
-./build.cmd -t nugetpush      # Full pipeline with NuGet push (CI only)
-```
-
-Build targets are defined in `CreativeCoders.CakeBuild` and configured in `build/BuildContext.cs`. The build uses GitVersion for automatic semantic versioning and ReportGenerator for coverage reports (output: `.tests/coverage-report`).
-
-## CI/CD Workflows
-
-| Workflow | Trigger | Purpose |
-|----------|---------|---------|
-| `main.yml` | Push to `main` | Build, test, pack, push to NuGet (Linux pushes, Windows/macOS build+test only) |
-| `pull-request.yml` | PR to `main` | Build and test on all platforms |
-| `integration.yml` | Manual/schedule | Integration testing |
-| `release.yml` | Release event | Publish to nuget.org |
-| `dependabot-auto-merge.yml` | Dependabot PRs | Auto-merge dependency updates |
-| `sync-ai-config.yml` | Config sync | Synchronize AI configuration files |