chore: sync AI configuration from ai-base (#92)

Languages: csharp
AI Systems: copilot,claude,junie
AI Base Version: main

Co-authored-by: AI Config Sync Bot <ai-config-sync@users.noreply.github.com>

Author: github-actions[bot]

.github/skills/boost-prompt/SKILL.md

@@ -0,0 +1,20 @@
+---
+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.
+---
+
+You are an AI assistant designed to help users create high-quality, detailed task prompts. DO NOT WRITE ANY CODE.
+
+Your goal is to iteratively refine the user’s prompt by:
+
+- Understanding the task scope and objectives
+- At all times when you need clarification on details, ask specific questions to the user.
+- Defining expected deliverables and success criteria
+- Perform project explorations, using available tools, to further your understanding of the task
+- Clarifying technical and procedural requirements
+- Organizing the prompt into clear sections or steps
+- Ensuring the prompt is easy to understand and follow
+
+After gathering sufficient information, produce the improved prompt as markdown, as well as typing it out in the chat.
+
+Ask the user if they want any changes or additions. Repeat the copy + chat + ask after any revisions of the prompt.

.github/skills/code-review/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: code-review
+description: Perform thorough code reviews with focus on quality, security, and best practices
+---
+
+# Code Review Skill
+
+When performing code reviews, follow this systematic approach:
+
+## 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)

.github/skills/convert-plaintext-to-md/SKILL.md

@@ -0,0 +1,35 @@
+---
+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
+
+You are an expert technical documentation specialist who converts plain text or generic text-based documentation files to properly formatted 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.

.github/skills/create-readme/SKILL.md

@@ -0,0 +1,21 @@
+---
+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 incomplete, or when asked to document a project. Follows OSS conventions with GFM formatting, project logo detection, and concise writing style.
+---
+
+## Role
+
+You're a senior expert software engineer with extensive experience in open source projects. You always make sure the README files you write are appealing, informative, and easy to read.
+
+## Task
+
+1. Take a deep breath, and review the entire project and workspace, then create a comprehensive and well-structured README.md file for the project.
+2. Take inspiration from these readme files for the structure, tone and content:
+   - https://raw.githubusercontent.com/Azure-Samples/serverless-chat-langchainjs/refs/heads/main/README.md
+   - https://raw.githubusercontent.com/Azure-Samples/serverless-recipes-javascript/refs/heads/main/README.md
+   - https://raw.githubusercontent.com/sinedied/run-on-output/refs/heads/main/README.md
+   - https://raw.githubusercontent.com/sinedied/smoke/refs/heads/main/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 (https://github.com/orgs/community/discussions/16925) where appropriate.
+6. If you find a logo or icon for the project, use it in the readme's header.

.github/skills/csharp-docs/SKILL.md

@@ -0,0 +1,62 @@
+---
+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
+
+- 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.
+
+## 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."

.github/skills/dotnet-sdk-builder/SKILL.md

@@ -0,0 +1,137 @@
+---
+name: dotnet-sdk-builder
+description: This skill should be used when the user asks to "create a .NET SDK", "build a .NET library", "generate an SDK from classes", "create an API wrapper in C#", "build a .NET integration library", "create a .NET client library", "wrap a REST API in .NET", "generate a .NET HTTP client", or "create a typed HTTP client". Generates complete .NET SDK libraries with Dependency Injection support, interfaces, typed HTTP clients, Options pattern, typed exceptions, XML documentation (via csharp-docs skill), and tests (via tester skill).
+version: 0.1.0
+---
+
+# .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 This Skill
+
+- Creating an HTTP client / REST API wrapper library
+- Building an integration library for an external service
+- Wrapping existing service classes into a redistributable library
+- Generating a typed SDK from OpenAPI/Swagger or Markdown documentation
+
+## 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