@pratikpsl/agent-skills 0.2.0 → 0.3.0

package/src/templates/dotnet/AgentSkills/skills/code-standards/SKILL.md

@@ -1,122 +1,122 @@
----
-name: code-standards
-description: >
-  Load when writing, reviewing, or refactoring C# code.
-  Covers naming, structure, comments, and commit hygiene.
----
-
-# Code Standards
-
-Language: C#. Every example is production code, not pseudocode.
-
-## 1. No Magic Values
-
-```csharp
-// Bad
-if (role == 3) { }
-
-// Good
-private const int AdminRoleId = 3;
-if (role == AdminRoleId) { }
-```
-
-## 2. Meaningful Names
-
-Names explain what a value represents and why it matters. If a comment is needed to explain a variable, rename it.
-
-```csharp
-// Bad
-int d = 86400;
-bool flag = true;
-
-// Good
-const int SecondsPerDay = 86400;
-bool isUserVerified = true;
-```
-
-## 3. One Function, One Responsibility
-
-One function should do one thing. If you cannot summarize it in one sentence, split it.
-
-## 4. Descriptive Booleans
-
-```csharp
-// Bad
-bool check = true;
-
-// Good
-bool hasPermission = true;
-bool isSessionExpired = false;
-```
-
-## 5. DRY
-
-Keep one source of truth per piece of logic. Apply judgment: premature abstraction is also harmful.
-
-## 6. Early Returns Over Deep Nesting
-
-```csharp
-// Bad
-void Process(User user)
-{
-    if (user != null)
-    {
-        if (user.IsActive)
-        {
-            // Main logic
-        }
-    }
-}
-
-// Good
-void Process(User user)
-{
-    if (user is null) return;
-    if (!user.IsActive) return;
-
-    // Main logic
-}
-```
-
-## 7. Comment Why, Not What
-
-```csharp
-// Bad
-// Increment counter.
-count++;
-
-// Good
-// Back off before HTTP 429; this API caps requests at 100 per minute.
-if (requestCount >= RateLimitBackoffThreshold) { }
-```
-
-## 8. Limit Function Arguments
-
-More than 3 arguments should usually become a config object, command object, or record.
-
-```csharp
-// Bad
-CreateUser("Alice", "alice@example.com", true, "admin", "UTC");
-
-// Good
-CreateUser(new UserConfig
-{
-    Name = "Alice",
-    Email = "alice@example.com",
-    IsVerified = true,
-    Role = Role.Admin,
-    Timezone = "UTC"
-});
-```
-
-## 9. Meaningful Commits
-
-```text
-Bad:
-fix bug
-update stuff
-
-Good:
-fix: prevent double-submit on payment
-refactor: extract shared email validation
-```
+---
+name: code-standards
+description: >
+  Load when writing, reviewing, or refactoring C# code.
+  Covers naming, structure, comments, and commit hygiene.
+---
+
+# Code Standards
+
+Language: C#. Every example is production code, not pseudocode.
+
+## 1. No Magic Values
+
+```csharp
+// Bad
+if (role == 3) { }
+
+// Good
+private const int AdminRoleId = 3;
+if (role == AdminRoleId) { }
+```
+
+## 2. Meaningful Names
+
+Names explain what a value represents and why it matters. If a comment is needed to explain a variable, rename it.
+
+```csharp
+// Bad
+int d = 86400;
+bool flag = true;
+
+// Good
+const int SecondsPerDay = 86400;
+bool isUserVerified = true;
+```
+
+## 3. One Function, One Responsibility
+
+One function should do one thing. If you cannot summarize it in one sentence, split it.
+
+## 4. Descriptive Booleans
+
+```csharp
+// Bad
+bool check = true;
+
+// Good
+bool hasPermission = true;
+bool isSessionExpired = false;
+```
+
+## 5. DRY
+
+Keep one source of truth per piece of logic. Apply judgment: premature abstraction is also harmful.
+
+## 6. Early Returns Over Deep Nesting
+
+```csharp
+// Bad
+void Process(User user)
+{
+    if (user != null)
+    {
+        if (user.IsActive)
+        {
+            // Main logic
+        }
+    }
+}
+
+// Good
+void Process(User user)
+{
+    if (user is null) return;
+    if (!user.IsActive) return;
+
+    // Main logic
+}
+```
+
+## 7. Comment Why, Not What
+
+```csharp
+// Bad
+// Increment counter.
+count++;
+
+// Good
+// Back off before HTTP 429; this API caps requests at 100 per minute.
+if (requestCount >= RateLimitBackoffThreshold) { }
+```
+
+## 8. Limit Function Arguments
+
+More than 3 arguments should usually become a config object, command object, or record.
+
+```csharp
+// Bad
+CreateUser("Alice", "alice@example.com", true, "admin", "UTC");
+
+// Good
+CreateUser(new UserConfig
+{
+    Name = "Alice",
+    Email = "alice@example.com",
+    IsVerified = true,
+    Role = Role.Admin,
+    Timezone = "UTC"
+});
+```
+
+## 9. Meaningful Commits
+
+```text
+Bad:
+fix bug
+update stuff
+
+Good:
+fix: prevent double-submit on payment
+refactor: extract shared email validation
+```

package/src/templates/dotnet/AgentSkills/skills/core/SKILL.md

@@ -1,26 +1,26 @@
----
-name: core
-description: >
-  Load on every task. Non-negotiable principles that govern
-  all work: how to think, what to change, and how to verify.
----
-
-# Core Principles
-
-> Simplification is the ultimate sophistication.
-> Write code that is simple, small, easy to delete, and adds nothing unnecessary.
-
-1. **Think Before Coding** – Understand the goal before writing a line. If requirements are ambiguous, **stop and ask** — assumptions compound. Surface tradeoffs to the caller, not just in comments.
-2. **Simplicity First** - Write the minimum code that correctly solves the problem. Avoid speculative features.
-3. **Surgical Changes** – Touch only what the task requires. Avoid "while I'm here" changes. Refactoring is a separate, explicit task — never bundled into a feature or fix.
-4. **Goal-Driven Testing** – Define success before writing code. Tests are the contract. Cover the failure path — a test suite that only passes on happy inputs is not a contract, it's a wish.
-5. **No Race Conditions** - Treat shared mutable state as dangerous. Prefer immutability.
-6. **Agent Memory**  – Every task is a learning loop. Read `AgentSkills/memory/index.md` at task start, then load only the domain file(s) matching your task. Before closing, check if a new lesson is warranted — if so, read `AgentSkills/memory/schema.md`, append one line to the correct domain file, and update the count in `index.md`.
-
-7. **Fail Loudly, Recover Gracefully** – Errors are a first-class output. When something goes wrong, fail loudly with context (what, where, relevant IDs). Never swallow exceptions silently. Recovery paths must be as deliberate as the happy path.
-
-8. **Prefer Reversible Moves** – When two approaches solve the problem equally well, choose the one that can be undone. Flag irreversible changes (schema drops, destructive migrations, hard deletes) explicitly before executing them.
-
+---
+name: core
+description: >
+  Load on every task. Non-negotiable principles that govern
+  all work: how to think, what to change, and how to verify.
+---
+
+# Core Principles
+
+> Simplification is the ultimate sophistication.
+> Write code that is simple, small, easy to delete, and adds nothing unnecessary.
+
+1. **Think Before Coding** – Understand the goal before writing a line. If requirements are ambiguous, **stop and ask** — assumptions compound. Surface tradeoffs to the caller, not just in comments.
+2. **Simplicity First** - Write the minimum code that correctly solves the problem. Avoid speculative features.
+3. **Surgical Changes** – Touch only what the task requires. Avoid "while I'm here" changes. Refactoring is a separate, explicit task — never bundled into a feature or fix.
+4. **Goal-Driven Testing** – Define success before writing code. Tests are the contract. Cover the failure path — a test suite that only passes on happy inputs is not a contract, it's a wish.
+5. **No Race Conditions** - Treat shared mutable state as dangerous. Prefer immutability.
+6. **Agent Memory**  – Every task is a learning loop. Read `AgentSkills/memory/index.md` at task start, then load only the domain file(s) matching your task. Before closing, check if a new lesson is warranted — if so, read `AgentSkills/memory/schema.md`, append one line to the correct domain file, and update the count in `index.md`.
+
+7. **Fail Loudly, Recover Gracefully** – Errors are a first-class output. When something goes wrong, fail loudly with context (what, where, relevant IDs). Never swallow exceptions silently. Recovery paths must be as deliberate as the happy path.
+
+8. **Prefer Reversible Moves** – When two approaches solve the problem equally well, choose the one that can be undone. Flag irreversible changes (schema drops, destructive migrations, hard deletes) explicitly before executing them.
+
 ## Prerequisite Gate
 
 Every task starts with the shared operating contract in

package/src/templates/dotnet/AgentSkills/skills/csharp-xunit/SKILL.md

@@ -1,68 +1,68 @@
----
-name: csharp-xunit
-description: 'Get best practices for XUnit unit testing, including data-driven tests'
----
-
-# XUnit Best Practices
-
-Your goal is to help me write effective unit tests with XUnit, covering both standard and data-driven testing approaches.
-
-## Project Setup
-
-- Use a separate test project with naming convention `[ProjectName].Tests`
-- Reference Microsoft.NET.Test.Sdk, xunit, and xunit.runner.visualstudio packages
-- Create test classes that match the classes being tested (e.g., `CalculatorTests` for `Calculator`)
-- Use .NET SDK test commands: `dotnet test` for running tests
-
-## Test Structure
-
-- No test class attributes required (unlike MSTest/NUnit)
-- Use fact-based tests with `[Fact]` attribute for simple tests
-- Follow the Arrange-Act-Assert (AAA) pattern
-- Name tests using the pattern `MethodName_Scenario_ExpectedBehavior`
-- Use constructor for setup and `IDisposable.Dispose()` for teardown
-- Use `IClassFixture<T>` for shared context between tests in a class
-- Use `ICollectionFixture<T>` for shared context between multiple test classes
-
-## Standard Tests
-
-- Keep tests focused on a single behavior
-- Avoid testing multiple behaviors in one test method
-- Use clear assertions that express intent
-- Include only the assertions needed to verify the test case
-- Make tests independent and idempotent (can run in any order)
-- Avoid test interdependencies
-
-## Data-Driven Tests
-
-- Use `[Theory]` combined with data source attributes
-- Use `[InlineData]` for inline test data
-- Use `[MemberData]` for method-based test data
-- Use `[ClassData]` for class-based test data
-- Create custom data attributes by implementing `DataAttribute`
-- Use meaningful parameter names in data-driven tests
-
-## Assertions
-
-- Use `Assert.Equal` for value equality
-- Use `Assert.Same` for reference equality
-- Use `Assert.True`/`Assert.False` for boolean conditions
-- Use `Assert.Contains`/`Assert.DoesNotContain` for collections
-- Use `Assert.Matches`/`Assert.DoesNotMatch` for regex pattern matching
-- Use `Assert.Throws<T>` or `await Assert.ThrowsAsync<T>` to test exceptions
-- Use fluent assertions library for more readable assertions
-
-## Mocking and Isolation
-
-- Consider using Moq or NSubstitute alongside XUnit
-- Mock dependencies to isolate units under test
-- Use interfaces to facilitate mocking
-- Consider using a DI container for complex test setups
-
-## Test Organization
-
-- Group tests by feature or component
-- Use `[Trait("Category", "CategoryName")]` for categorization
-- Use collection fixtures to group tests with shared dependencies
-- Consider output helpers (`ITestOutputHelper`) for test diagnostics
+---
+name: csharp-xunit
+description: 'Get best practices for XUnit unit testing, including data-driven tests'
+---
+
+# XUnit Best Practices
+
+Your goal is to help me write effective unit tests with XUnit, covering both standard and data-driven testing approaches.
+
+## Project Setup
+
+- Use a separate test project with naming convention `[ProjectName].Tests`
+- Reference Microsoft.NET.Test.Sdk, xunit, and xunit.runner.visualstudio packages
+- Create test classes that match the classes being tested (e.g., `CalculatorTests` for `Calculator`)
+- Use .NET SDK test commands: `dotnet test` for running tests
+
+## Test Structure
+
+- No test class attributes required (unlike MSTest/NUnit)
+- Use fact-based tests with `[Fact]` attribute for simple tests
+- Follow the Arrange-Act-Assert (AAA) pattern
+- Name tests using the pattern `MethodName_Scenario_ExpectedBehavior`
+- Use constructor for setup and `IDisposable.Dispose()` for teardown
+- Use `IClassFixture<T>` for shared context between tests in a class
+- Use `ICollectionFixture<T>` for shared context between multiple test classes
+
+## Standard Tests
+
+- Keep tests focused on a single behavior
+- Avoid testing multiple behaviors in one test method
+- Use clear assertions that express intent
+- Include only the assertions needed to verify the test case
+- Make tests independent and idempotent (can run in any order)
+- Avoid test interdependencies
+
+## Data-Driven Tests
+
+- Use `[Theory]` combined with data source attributes
+- Use `[InlineData]` for inline test data
+- Use `[MemberData]` for method-based test data
+- Use `[ClassData]` for class-based test data
+- Create custom data attributes by implementing `DataAttribute`
+- Use meaningful parameter names in data-driven tests
+
+## Assertions
+
+- Use `Assert.Equal` for value equality
+- Use `Assert.Same` for reference equality
+- Use `Assert.True`/`Assert.False` for boolean conditions
+- Use `Assert.Contains`/`Assert.DoesNotContain` for collections
+- Use `Assert.Matches`/`Assert.DoesNotMatch` for regex pattern matching
+- Use `Assert.Throws<T>` or `await Assert.ThrowsAsync<T>` to test exceptions
+- Use fluent assertions library for more readable assertions
+
+## Mocking and Isolation
+
+- Consider using Moq or NSubstitute alongside XUnit
+- Mock dependencies to isolate units under test
+- Use interfaces to facilitate mocking
+- Consider using a DI container for complex test setups
+
+## Test Organization
+
+- Group tests by feature or component
+- Use `[Trait("Category", "CategoryName")]` for categorization
+- Use collection fixtures to group tests with shared dependencies
+- Consider output helpers (`ITestOutputHelper`) for test diagnostics
 - Skip tests conditionally with `Skip = "reason"` in fact/theory attributes

package/src/templates/dotnet/AgentSkills/skills/design/SKILL.md

@@ -1,108 +1,108 @@
----
-name: design
-description: >
-  Load when designing, architecting, or implementing patterns in C#.
-  Covers project folder structure (vertical slice), SOLID, KISS, YAGNI,
-  DRY, composition, Singleton, and Factory.
----
-
-# Design Principles and Patterns
-
-## Project Structure
-
-Organise by **feature (vertical slice)**, not by technical layer.
-Each feature folder owns everything needed for its use case: command, handler, DTO, validator, and endpoint.
-This keeps changes local, avoids cross-cutting layers, and scales without requiring global refactors.
-
-```text
-src/
-├── Features/
-│   ├── Products/
-│   │   ├── CreateProductCommand.cs
-│   │   ├── CreateProductHandler.cs
-│   │   ├── ProductDto.cs
-│   │   ├── ProductValidator.cs
-│   │   └── ProductEndpoints.cs
-│   ├── Orders/
-│   │   ├── CreateOrderCommand.cs
-│   │   ├── CreateOrderHandler.cs
-│   │   ├── OrderDto.cs
-│   │   ├── OrderValidator.cs
-│   │   └── OrderEndpoints.cs
-│   └── ...
-├── Shared/
-│   ├── Middleware/
-│   └── Utilities/
-└── Program.cs
-```
-
-**Rules:**
-- One folder per feature — never split a feature across `Commands/`, `Queries/`, `Controllers/` top-level layers.
-- When a feature grows, split it into sub-features within the same `Features/<Feature>/` directory before creating a new top-level folder.
-- Shared cross-cutting code (middleware, utilities, base types) lives in `Shared/`, not duplicated per feature.
-- `Program.cs` wires up DI, middleware, and endpoint registration only — no business logic.
-
-## SOLID
-
-| | Principle | In Practice |
-|---|---|---|
-| S | Single Responsibility | One class, one reason to change |
-| O | Open / Closed | Open to extension, closed to modification |
-| L | Liskov Substitution | Subtypes must work wherever the base type works |
-| I | Interface Segregation | Small, focused interfaces over large, general ones |
-| D | Dependency Inversion | Depend on abstractions, not concrete implementations |
-
-## KISS
-
-Prefer the obvious solution. If a junior engineer cannot understand it in 5 minutes, simplify it.
-
-## YAGNI
-
-Do not build something until it is needed. Solve today's requirement, not tomorrow's guess.
-
-```csharp
-// Bad: built "just in case" when only one format exists.
-public interface IExporter { }
-public class ExporterFactory { }
-
-// Good: solve what exists now.
-public string ExportToCsv(Report report) { }
-```
-
-## DRY
-
-Keep one source of truth per piece of knowledge: logic, configuration, and data schemas.
-
-## Composition Over Inheritance
-
-Use inheritance only for true "is-a" relationships. Prefer interfaces and delegation.
-
-## Pattern: Singleton
-
-Use when exactly one instance must coordinate shared state. Avoid when it creates hidden global state.
-
-```csharp
-public sealed class AppConfig
-{
-    private static readonly Lazy<AppConfig> InstanceHolder =
-        new(() => new AppConfig());
-
-    public static AppConfig Instance => InstanceHolder.Value;
-
-    private AppConfig()
-    {
-    }
-}
-```
-
-## Pattern: Factory
-
-Use when creation is complex, varies by type, or must be decoupled from consumers.
-
-```csharp
-// Bad
-var handler = type == "email" ? new EmailHandler() : new SmsHandler();
-
-// Good
-var handler = NotificationFactory.Create(type);
-```
+---
+name: design
+description: >
+  Load when designing, architecting, or implementing patterns in C#.
+  Covers project folder structure (vertical slice), SOLID, KISS, YAGNI,
+  DRY, composition, Singleton, and Factory.
+---
+
+# Design Principles and Patterns
+
+## Project Structure
+
+Organise by **feature (vertical slice)**, not by technical layer.
+Each feature folder owns everything needed for its use case: command, handler, DTO, validator, and endpoint.
+This keeps changes local, avoids cross-cutting layers, and scales without requiring global refactors.
+
+```text
+src/
+├── Features/
+│   ├── Products/
+│   │   ├── CreateProductCommand.cs
+│   │   ├── CreateProductHandler.cs
+│   │   ├── ProductDto.cs
+│   │   ├── ProductValidator.cs
+│   │   └── ProductEndpoints.cs
+│   ├── Orders/
+│   │   ├── CreateOrderCommand.cs
+│   │   ├── CreateOrderHandler.cs
+│   │   ├── OrderDto.cs
+│   │   ├── OrderValidator.cs
+│   │   └── OrderEndpoints.cs
+│   └── ...
+├── Shared/
+│   ├── Middleware/
+│   └── Utilities/
+└── Program.cs
+```
+
+**Rules:**
+- One folder per feature — never split a feature across `Commands/`, `Queries/`, `Controllers/` top-level layers.
+- When a feature grows, split it into sub-features within the same `Features/<Feature>/` directory before creating a new top-level folder.
+- Shared cross-cutting code (middleware, utilities, base types) lives in `Shared/`, not duplicated per feature.
+- `Program.cs` wires up DI, middleware, and endpoint registration only — no business logic.
+
+## SOLID
+
+| | Principle | In Practice |
+|---|---|---|
+| S | Single Responsibility | One class, one reason to change |
+| O | Open / Closed | Open to extension, closed to modification |
+| L | Liskov Substitution | Subtypes must work wherever the base type works |
+| I | Interface Segregation | Small, focused interfaces over large, general ones |
+| D | Dependency Inversion | Depend on abstractions, not concrete implementations |
+
+## KISS
+
+Prefer the obvious solution. If a junior engineer cannot understand it in 5 minutes, simplify it.
+
+## YAGNI
+
+Do not build something until it is needed. Solve today's requirement, not tomorrow's guess.
+
+```csharp
+// Bad: built "just in case" when only one format exists.
+public interface IExporter { }
+public class ExporterFactory { }
+
+// Good: solve what exists now.
+public string ExportToCsv(Report report) { }
+```
+
+## DRY
+
+Keep one source of truth per piece of knowledge: logic, configuration, and data schemas.
+
+## Composition Over Inheritance
+
+Use inheritance only for true "is-a" relationships. Prefer interfaces and delegation.
+
+## Pattern: Singleton
+
+Use when exactly one instance must coordinate shared state. Avoid when it creates hidden global state.
+
+```csharp
+public sealed class AppConfig
+{
+    private static readonly Lazy<AppConfig> InstanceHolder =
+        new(() => new AppConfig());
+
+    public static AppConfig Instance => InstanceHolder.Value;
+
+    private AppConfig()
+    {
+    }
+}
+```
+
+## Pattern: Factory
+
+Use when creation is complex, varies by type, or must be decoupled from consumers.
+
+```csharp
+// Bad
+var handler = type == "email" ? new EmailHandler() : new SmsHandler();
+
+// Good
+var handler = NotificationFactory.Create(type);
+```