@pratikpsl/agent-skills 0.8.0 → 1.0.0

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@pratikpsl/agent-skills",
   "type": "module",
-  "version": "0.8.0",
+  "version": "1.0.0",
   "description": "CLI to scaffold and manage AI agent skills across projects — like shadcn/ui, but for Cursor, Claude, Codex, Copilot, Antigravity, and more",
   "bin": {
     "agent-skills": "dist/bin/agent-skills.js"
@@ -47,7 +47,7 @@
     "build": "tsc",
     "test": "vitest run",
     "test:watch": "vitest",
-    "dry-run": "bun run build && npm publish --dry-run"
+    "dry-run": "npm run build && npm pack --dry-run"
   },
   "dependencies": {
     "commander": "^15.0.0"

package/templates/default/instructions.md

@@ -2,36 +2,35 @@
 
 ## Goal
 Implement the requested change with production-quality code, preserving existing behavior and
-minimizing the diff, following the project's own architecture and conventions - unless explicitly
-told otherwise.
+minimizing the diff, following the project's own architecture and conventions.
 
 ## Principles
-- Match existing code style, patterns, naming, architecture, and folder structure.
-- Prefer simple, clean, clear, efficient, maintainable, manageable code over clever or complex solutions.
-- Make the smallest change that satisfies the request; don't touch unrelated code.
-- Favor deletion over addition - don't grow the codebase for changes that don't need it.
-- Reuse existing utilities/helpers/components before writing new ones.
-- No new dependencies unless necessary. If one is needed: popular, actively maintained,
-  permissively licensed (MIT/Apache-2.0), no known security issues.
-- Apply SOLID, DRY, KISS. Single-responsibility functions/classes, Separation of concern. No duplicated logic.
-- No magic numbers/strings - use named constants/enums.
-- Each function must be a maximum of 50 lines.
-- Use meaningful names for classes, methods, variables, and all other code.
-- Handle errors the way the codebase already does.
-- Never hardcode secrets, keys, or credentials; follow the project's existing security practices.
-- Use idiomatic async/non-blocking I/O and ensure the code is free of race conditions and deadlocks.
-- Avoid deprecated APIs and patterns.
-- Comment only where intent isn't obvious from the code itself.
-- Don't change public APIs/interfaces, formatting, or file layout unless the task requires it.
-- Don't add features, abstractions, or "improvements" that weren't asked for.
-- If a requirement is ambiguous or missing critical detail, ask before guessing.
+
+### Scope & Intent
+- Make the smallest change that satisfies the request; touch only what is explicitly required.
+- Do not add unrequested features, speculative abstractions, or unsolicited refactoring (YAGNI).
+- Favor deletion over addition; reuse existing utilities and helpers before creating new ones.
+- If requirements are ambiguous or missing critical details, ask before guessing.
+
+### Code Quality & Design
+- Match existing code style, patterns, naming, error handling, and folder structure.
+- Apply SOLID, DRY, and KISS: single-responsibility functions, separation of concerns, no duplicated logic.
+- Keep functions under 50 lines, nesting depth at most 2 levels (prefer early returns), and signatures under 4 parameters.
+- Use meaningful names and named constants/enums (no magic numbers or strings).
+- Design self-describing APIs, structured schemas, and human-/machine-readable contracts.
+- Comment only where non-obvious rationale is required, not what the code already says.
+
+### Reliability & Security
+- Never hardcode, commit, or log secrets, credentials, tokens, or sensitive user data.
+- Validate and sanitize external input; use parameterized queries to prevent injection.
+- Use idiomatic non-blocking `async`/`await`; ensure code is free of race conditions and deadlocks.
+- Avoid deprecated APIs and patterns; introduce new dependencies only when strictly necessary (permissive license, actively maintained).
 
 ## Definition of Done
-- Builds and runs without errors.
-- No debug code, dead code, unused imports, or temp files left behind.
-- Tests pass; add/update tests for the change if the project has a test suite.
-- The change is minimal, focused, and easy to review.
+- Builds cleanly and all tests pass without errors or warnings.
+- No debug code, dead code, unused imports, or temporary files left behind.
+- Changes are minimal, focused, covered by tests, and easy to review.
 
 ## Agent Memory
-Read `AgentSkills/memory/index.md` at the start of every task; load only the relevant domain file(s).
-After a task, if a mistake was corrected, append one line to the correct `AgentSkills/memory/lessons/<domain>.md` and update the count in `index.md`.
+- Read `AgentSkills/memory/index.md` at the start of every task (create if missing); load only relevant domain lessons.
+- When a mistake is corrected or a durable rule discovered, record an actionable lesson in `AgentSkills/memory/lessons/<domain>.md` (create if missing) and update `index.md`.

package/templates/dotnet/AgentSkills/agents/architect.agent.md

@@ -1,59 +1,13 @@
 ---
 name: architect
-description: >
-  Load when designing features, planning CQRS structure,
-  designing SQL schema, or planning MCP server contracts.
-  Do not write implementation code; output structure only.
+description: .NET architectural design, Clean Architecture, CQRS, and API boundaries.
 ---
 
-# Architect Agent
+# .NET Architect
 
-## Responsibilities
-
-- Design CQRS command/query split before any code is written.
-- Define SQL schema and relationships.
-- Define MCP tool contracts including name, input, and output.
-- Identify performance-sensitive read/write paths and expected data volume.
-- Reject designs that violate SOLID, KISS, or YAGNI.
-- Prefer simple, small designs that are easy to delete.
-
-## CQRS Rules
-
-- Commands mutate state and return nothing, an ID, or a small result.
-- Queries read state and never mutate.
-- Controllers dispatch only; no business logic belongs in controllers.
-- Use one handler per command or query.
-- Query designs returning collections must specify projection, pagination, and tracking behavior.
-
-## Output Format
-
-Before implementation, produce:
-
-1. Command/query split with input and output.
-2. SQL schema if new tables are needed.
-3. MCP tool contract if the MCP surface changes.
-4. Proposed folder structure.
-
-## Example Command / Query Split
-
-| Type | Name | Input | Output |
-|---|---|---|---|
-| Command | CreateOrderCommand | CreateOrderRequest | OrderId |
-| Query | GetOrderByIdQuery | OrderId | OrderDto |
-
-## Example Folder Structure
-
-```text
-Features/
-└── Orders/
-    ├── Commands/
-    │   └── CreateOrder/
-    │       ├── CreateOrderCommand.cs
-    │       ├── CreateOrderHandler.cs
-    │       └── CreateOrderValidator.cs
-    └── Queries/
-        └── GetOrderById/
-            ├── GetOrderByIdQuery.cs
-            ├── GetOrderByIdHandler.cs
-            └── OrderDto.cs
-```
+## Architectural Principles
+- **Separation of Concerns**: Enforce clean boundaries (Domain, Application, Infrastructure, API).
+- **CQRS Pattern**: Separate commands (mutating state) from queries (read-only projections).
+- **Domain Encapsulation**: Place core business rules in domain entities or domain services; keep API controllers and minimal endpoints thin.
+- **Contract-First Design**: Define relational schemas, entity relationships, indexes, and immutable DTO contracts before implementation.
+- **Protocol Neutrality**: Design application handlers (e.g. MediatR) to serve REST, gRPC, and MCP tools without coupling to transport logic.

package/templates/dotnet/AgentSkills/agents/developer.agent.md

@@ -1,88 +1,13 @@
 ---
 name: developer
-description: >
-  Load when implementing features in .NET C# API.
-  Always load architect guidance first if structure is not defined.
-  Always follows CQRS and loads code-standards plus dotnet-best-practices.
+description: .NET C# feature implementation, ASP.NET Core APIs, MediatR, and EF Core.
 ---
 
-# Developer Agent
+# .NET Developer
 
-## Stack
-
-- .NET 10 and modern C#.
-- ASP.NET Core Minimal APIs or controllers.
-- MediatR for CQRS dispatch.
-- FluentValidation for input validation.
-- EF Core for persistence.
-- MCP Server SDK for AI tool surface.
-
-## Implementation Rules
-
-- Use records for commands, queries, and DTOs when immutability is appropriate.
-- Mark classes `sealed` unless inheritance is intentionally supported.
-- Keep controllers thin; they should validate transport concerns and dispatch through MediatR.
-- Keep business rules in domain entities or domain/application services, not controllers or handlers.
-- Use repositories or data access abstractions where the project already follows that convention.
-- Use async all the way; never block with `.Result`, `.Wait()`, or `.GetAwaiter().GetResult()`.
-- Pass `CancellationToken` through request, handler, EF Core, HTTP, and MCP boundaries.
-- Optimize read queries with `.AsNoTracking()`, DTO projection, pagination, and no N+1 queries.
-- Keep API payloads small and avoid excessive logging in hot paths.
-
-## CQRS Pattern
-
-```csharp
-public sealed record CreateOrderCommand(Guid CustomerId, IReadOnlyList<OrderItem> Items)
-    : IRequest<Guid>;
-
-public sealed class CreateOrderHandler(IOrderRepository repository)
-    : IRequestHandler<CreateOrderCommand, Guid>
-{
-    public async Task<Guid> Handle(
-        CreateOrderCommand command,
-        CancellationToken cancellationToken)
-    {
-        var order = Order.Create(command.CustomerId, command.Items);
-        await repository.AddAsync(order, cancellationToken);
-        return order.Id;
-    }
-}
-```
-
-## Controller Rule
-
-Controllers dispatch only.
-
-```csharp
-[HttpPost]
-public async Task<IActionResult> Create(
-    CreateOrderRequest request,
-    CancellationToken cancellationToken)
-{
-    var orderId = await mediator.Send(
-        new CreateOrderCommand(request.CustomerId, request.Items),
-        cancellationToken);
-
-    return CreatedAtAction(nameof(GetById), new { orderId }, null);
-}
-```
-
-## MCP Tool Rule
-
-MCP tools should reuse the same command/query handlers as REST endpoints.
-
-```csharp
-[McpTool("create_order", "Creates a new order")]
-public static async Task<CreateOrderResult> CreateOrderAsync(
-    Guid customerId,
-    IReadOnlyList<OrderItem> items,
-    IMediator mediator,
-    CancellationToken cancellationToken)
-{
-    var orderId = await mediator.Send(
-        new CreateOrderCommand(customerId, items),
-        cancellationToken);
-
-    return new CreateOrderResult(orderId);
-}
-```
+## Implementation Principles
+- **Modern C# Idioms**: Use `record` for immutable DTOs/commands/queries, `sealed` classes by default, and primary constructors where appropriate.
+- **Clean Endpoints**: Keep controllers thin; handle validation and dispatch requests through mediator handlers.
+- **Async & Cancellation**: Use non-blocking `async`/`await` throughout; propagate `CancellationToken` to all EF Core, HTTP, and async calls.
+- **Query Efficiency**: Always use `.AsNoTracking()` for read-only queries, project explicitly to DTOs, and prevent N+1 query patterns.
+- **Complexity Limits**: Keep methods under 50 lines, avoid blocking calls (`.Result`, `.Wait()`), and eliminate magic numbers/strings.

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

@@ -1,68 +1,42 @@
 ---
 name: csharp-xunit
-description: 'Get best practices for XUnit unit testing, including data-driven tests'
+description: Best practices for xUnit testing, data-driven theories, mocking, fixtures, and assertions.
 ---
 
-# XUnit Best Practices
+# xUnit Best Practices
 
-Your goal is to help me write effective unit tests with XUnit, covering both standard and data-driven testing approaches.
+Guidelines for writing effective, isolated, and maintainable unit and integration tests with xUnit.
 
-## Project Setup
+## Project Setup & Conventions
+- Place tests in a dedicated test project named `[ProjectName].Tests`.
+- Reference `Microsoft.NET.Test.Sdk`, `xunit`, and `xunit.runner.visualstudio`.
+- Match test class names to the class under test (e.g., `OrderServiceTests` for `OrderService`).
+- Execute tests via standard CLI: `dotnet test`.
 
-- 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 & Naming
+- Follow the **Arrange-Act-Assert (AAA)** pattern.
+- Use the standard naming convention: `MethodName_Scenario_ExpectedBehavior`.
+- Use constructors for test initialization and `IDisposable.Dispose()` for teardown.
+- Use `IClassFixture<T>` for shared context across tests in a single class.
+- Use `ICollectionFixture<T>` for shared context across multiple test classes.
 
-## 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
+## Fact vs. Theory Tests
+- **`[Fact]`**: For single-condition tests verifying one specific behavior.
+- **`[Theory]`**: For data-driven tests testing multiple inputs and edge cases.
+  - `[InlineData(arg1, arg2)]`: For simple scalar test cases.
+  - `[MemberData(nameof(TestDataMethod))]`: For complex or generated test objects.
+  - `[ClassData(typeof(CustomTestDataClass))]`: For reusable external test datasets.
 
 ## 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
+- Use specific assertions expressing intent:
+  - Values: `Assert.Equal(expected, actual)`, `Assert.NotEqual(...)`
+  - References: `Assert.Same(expected, actual)`
+  - Conditions: `Assert.True(condition)`, `Assert.False(condition)`
+  - Collections: `Assert.Contains(item, list)`, `Assert.DoesNotContain(...)`
+  - Exceptions: `Assert.Throws<T>(() => ...)` or `await Assert.ThrowsAsync<T>(() => ...)`
+- Alternatively, use `FluentAssertions` where it improves assertion readability.
+
+## Isolation & Mocking
+- Mock external dependencies and I/O boundaries using Moq or NSubstitute.
+- Code against interfaces to enable clean mock substitution.
+- Keep tests isolated, independent, and idempotent (no reliance on execution order or external state).

package/templates/dotnet/AgentSkills/skills/dotnet-best-practices/SKILL.md

@@ -8,163 +8,72 @@ description: >
 
 # .NET/C# Best Practices
 
-Use this skill to keep .NET/C# changes simple, maintainable, testable, and aligned with this repository.
-
-## Repository Defaults
-
-- Follow the target framework and language version declared in `Directory.Build.props`.
-- Current defaults are `net10.0` and `LangVersion` set to `latest`.
-- Use modern C# features only when they improve readability or correctness.
-- Prefer clear, boring code over clever code.
-- Keep changes scoped to the current feature or bug.
-
-## Documentation and Structure
-
-- Add XML documentation comments for public APIs when they are part of the external or shared surface.
-- Include meaningful parameter and return descriptions when they add information beyond the name.
-- Organize code by feature/domain when the project already follows that structure.
-- Keep controllers, endpoints, handlers, validators, repositories, and DTOs in predictable folders.
-- Use namespaces that match the project and feature structure.
-
-## CQRS and Architecture
-
-- Commands mutate state and should return nothing, an ID, or a small result.
-- Queries read state and must not mutate data.
-- Keep controllers and minimal API endpoints thin; they should validate transport concerns and dispatch through MediatR.
-- Put business rules in domain/application services or entities, not controllers.
-- Use one handler per command or query.
-- Prefer records for commands, queries, and DTOs when immutability is appropriate.
-- Mark classes `sealed` unless inheritance is intentionally supported.
-- Use interfaces for boundaries that need substitution, testing, or multiple implementations.
-
-## Dependency Injection and Services
-
+Use this skill to keep .NET/C# changes simple, maintainable, testable, and aligned with repository conventions.
+
+## Repository Defaults & Structure
+- Follow target framework and language versions in `Directory.Build.props` (default `net10.0`, `LangVersion` `latest`).
+- Add XML documentation comments for public/shared API surfaces.
+- Organize code by feature or domain slices; place controllers, handlers, validators, repositories, and DTOs predictably.
+- Prefer clear, direct code over complex or speculative patterns (YAGNI).
+
+## CQRS & Architecture
+- **Commands**: Mutate state; return void, an identifier, or a minimal result.
+- **Queries**: Read state only; never mutate data.
+- **Thin Endpoints**: Keep controllers and minimal API endpoints thin; validate transport concerns and dispatch via mediator handlers.
+- **Domain Logic**: Encapsulate domain rules in domain entities or domain services, never in transport handlers.
+- **Immutability**: Use `record` for commands, queries, and DTOs; mark classes `sealed` unless inheritance is intentionally designed.
+- **Interfaces**: Define interfaces for boundaries requiring testing, multiple implementations, or out-of-process integration.
+
+## Dependency Injection & Lifetimes
 - Use constructor injection or primary constructors for required dependencies.
-- Validate required dependencies when nullable flow does not already prove safety.
-- Register services with the narrowest correct lifetime:
-  - `Singleton` for stateless, thread-safe services.
-  - `Scoped` for request-bound services and EF Core `DbContext`.
-  - `Transient` for lightweight stateless services.
-- Do not resolve services manually from `IServiceProvider` unless there is a clear framework boundary.
-- Avoid hidden global state.
-
-## Async/Await
-
-- Use async/await for I/O, database, network, and long-running operations.
-- Do not block async work with `.Result`, `.Wait()`, or `.GetAwaiter().GetResult()`.
-- Prefer async all the way through the call chain.
-- Accept and pass `CancellationToken` on request, handler, EF Core, and HTTP calls.
-- Use `ConfigureAwait(false)` in reusable library code when appropriate; it is usually unnecessary in ASP.NET Core request code.
-- Avoid `async void` except for event handlers.
-
-## EF Core and Database Performance
-
-- Avoid N+1 queries. Use projections, `Include`, explicit joins, or separate optimized queries.
-- Use `.AsNoTracking()` for read-only queries.
-- Select only required columns into DTOs instead of loading full entities.
-- Add pagination for list endpoints; avoid returning unbounded result sets.
-- Filter in the database, not in memory.
-- Use indexes for frequent filters, joins, and ordering paths.
-- Prefer `AnyAsync` over `CountAsync` when checking existence.
-- Avoid lazy loading in APIs unless there is a specific measured reason.
-- Use `SplitQuery` only when it avoids cartesian explosion from large includes.
-- Batch writes where possible and call `SaveChangesAsync` once per unit of work.
-- Consider `ExecuteUpdateAsync` and `ExecuteDeleteAsync` for bulk updates/deletes.
-- Consider compiled queries only for measured hot paths.
-- Always parameterize raw SQL if raw SQL is truly needed.
-
-## Memory and Allocation Performance
-
-- Avoid unnecessary object creation in hot paths.
-- Use `StringBuilder` for repeated string concatenation in loops or large text generation.
-- Be careful with LINQ in hot paths; simple loops can reduce allocations and improve clarity.
-- Avoid exceptions for normal control flow.
-- Prefer `Array.Empty<T>()` over new empty arrays.
-- Reuse static readonly immutable data when safe.
-- Use pooling, `Span<T>`, `Memory<T>`, or `ValueTask` only when measurement shows a real benefit.
-
-## Caching
-
-- Cache frequently used, slow-changing data to reduce database and network load.
-- Use in-memory caching for single-instance or per-node data.
-- Use distributed caching such as Redis for multi-instance deployments or shared cache state.
-- Define clear cache keys, expiration, invalidation, and size limits.
-- Avoid caching sensitive user data unless encryption, isolation, and expiry are correct.
-- Prevent cache stampedes for expensive entries with locking or single-flight behavior.
-- Do not cache data that must be strongly consistent unless the domain explicitly allows staleness.
-
-## API Payload and Response Performance
-
-- Return DTOs that contain only the fields the caller needs.
-- Use pagination, filtering, and sorting parameters for collection endpoints.
-- Avoid sending large object graphs.
-- Enable response compression for compressible text responses such as JSON, HTML, CSS, and JavaScript.
-- Do not compress already compressed content such as images, videos, zip files, or PDFs.
-- Use ETags, `Last-Modified`, or cache headers where HTTP caching is safe.
-- Prefer streaming for large downloads instead of buffering the full payload in memory.
-
-## Logging and Observability
-
-- Use structured logging with message templates and named properties.
-- Avoid excessive logging in hot paths, especially per-item logs in loops.
-- Do not use string interpolation for expensive log messages unless guarded by `logger.IsEnabled(...)`.
-- Log enough context to diagnose failures without logging secrets or personal data.
-- Use correlation IDs, request IDs, or tracing context across request boundaries.
-- Use metrics/tracing for performance-critical paths instead of relying only on logs.
-
-## Efficient Data Structures
-
-- Use `Dictionary<TKey, TValue>` for fast key lookups.
-- Use `HashSet<T>` for uniqueness checks and membership tests.
-- Avoid repeated linear searches over large collections.
-- Use `List<T>` when order matters and append/read operations dominate.
-- Choose immutable or read-only collections when shared state should not change.
-
-## HTTP and External Calls
-
+- Register services with the narrowest appropriate lifetime:
+  - `Singleton`: Stateless, thread-safe services.
+  - `Scoped`: Request-bound services and EF Core `DbContext`.
+  - `Transient`: Lightweight, stateless operations.
+- Avoid resolving services manually via `IServiceProvider` or introducing static global state.
+
+## Async & I/O
+- Use `async`/`await` for all I/O, database, network, and file operations.
+- Never block async code using `.Result`, `.Wait()`, or `.GetAwaiter().GetResult()`.
+- Accept and propagate `CancellationToken` through all handler, EF Core, and outbound HTTP calls.
+- Avoid `async void` except for top-level event handlers.
+
+## EF Core & Data Access
+- Avoid N+1 queries by using explicit projections, `.Include()`, or separate optimized queries.
+- Use `.AsNoTracking()` for all read-only queries.
+- Select only needed columns into DTOs instead of loading full tracked entities.
+- Implement server-side pagination, filtering, and sorting; never filter unbounded sets in memory.
+- Prefer `AnyAsync()` over `CountAsync()` when testing for existence.
+- Use `ExecuteUpdateAsync` and `ExecuteDeleteAsync` for bulk operations where appropriate.
+
+## Logging & Observability
+- Use structured logging with message templates and named properties (`LogInformation("Order {OrderId} processed", id)`).
+- Avoid logging inside tight loops or hot execution paths.
+- Propagate correlation/request IDs across service and HTTP boundaries.
+- Never log secrets, passwords, connection strings, or sensitive personal data (PII).
+
+## HTTP & Resilient Integration
 - Use `IHttpClientFactory` for outbound HTTP calls.
-- Set timeouts and pass cancellation tokens.
-- Avoid retry storms; use bounded retries with backoff for transient failures.
-- Do not make external calls inside tight loops when batching is possible.
-- Prefer resilient integration patterns for unreliable dependencies.
+- Set explicit timeouts and pass cancellation tokens to all HTTP calls.
+- Use bounded retries with exponential backoff for transient failures; avoid unbounded retry storms.
+- Batch outbound requests rather than making external calls inside tight loops.
 
-## Security
-
-- Validate and sanitize external input.
-- Use FluentValidation or existing validation patterns for request validation.
-- Never concatenate user input into SQL, file paths, shell commands, or logs.
-- Do not log secrets, tokens, passwords, connection strings, or sensitive personal data.
-- Use least-privilege configuration for database and external services.
+## Security & Validation
+- Validate all incoming request payloads using FluentValidation or Data Annotations.
+- Never concatenate raw user input into SQL queries, shell commands, or file paths.
+- Follow the principle of least privilege for database connections and external service credentials.
 
 ## Testing Standards
-
-- Use xUnit for unit tests.
-- Use FluentAssertions where it improves readability.
-- Use Moq or the existing repository mocking style for dependencies.
-- Follow Arrange, Act, Assert.
-- Test success, failure, validation, null/empty input, and cancellation paths when relevant.
-- Keep tests deterministic and independent.
-
-## Performance Workflow
-
-- Measure before optimizing unless the issue is obvious and local.
-- Prefer simple fixes before complex optimizations.
-- Use realistic data sizes when validating performance.
-- Consider tools such as logs, metrics, traces, `dotnet-counters`, `dotnet-trace`, BenchmarkDotNet, or database query plans.
-- Document any non-obvious optimization with the measured reason.
-- Do not trade correctness, security, or maintainability for small unmeasured gains.
+- Use xUnit for unit and integration testing.
+- Structure tests using Arrange-Act-Assert (AAA).
+- Test happy paths, edge cases, validation failures, and cancellation flows.
+- Keep tests isolated, deterministic, and idempotent.
 
 ## Review Checklist
-
-- [ ] No avoidable N+1 queries.
-- [ ] Read-only EF Core queries use `.AsNoTracking()`.
-- [ ] Queries project only required columns.
-- [ ] Async code does not block on tasks.
-- [ ] Cancellation tokens flow through I/O boundaries.
-- [ ] No excessive allocations in hot paths.
-- [ ] Caching has clear expiration and invalidation.
-- [ ] Logs are structured and not excessive.
-- [ ] API responses avoid unnecessary payload size.
-- [ ] Compression and HTTP caching are used only where appropriate.
-- [ ] Data structures match access patterns.
-- [ ] Tests cover the changed behavior.
+- [ ] No N+1 queries; read-only EF Core queries use `.AsNoTracking()`.
+- [ ] DTO projections used; no full entity graphs exposed to callers.
+- [ ] Async methods propagate `CancellationToken` without blocking.
+- [ ] DI lifetimes correctly configured (`Scoped` for DbContext).
+- [ ] Structured logging used without leaking sensitive data or secrets.
+- [ ] Input validation applied at boundaries.
+- [ ] Tests pass and cover edge cases.

package/templates/dotnet/AgentSkills/skills/performance/SKILL.md

@@ -0,0 +1,18 @@
+---
+name: performance
+description: .NET memory allocation reduction, Span/ReadOnlySpan, EF Core query tuning, and async efficiency.
+---
+
+# .NET Performance
+
+## Memory & Allocation Optimization
+- Minimize heap allocations in hot paths using `ReadOnlySpan<T>`, `Span<T>`, and `Memory<T>`.
+- Use `ValueTask<T>` for asynchronous methods that frequently complete synchronously.
+- Avoid boxing value types and eliminate unnecessary LINQ allocations inside tight loops.
+- Use `ArrayPool<T>` or `StringBuilder` for buffer reuse in repetitive or large text/byte operations.
+
+## Database & I/O Efficiency
+- Always use `.AsNoTracking()` for read-only EF Core queries to eliminate change tracking overhead.
+- Use explicit projection (`.Select(x => new ... )`) to fetch only necessary database columns into DTOs.
+- Stream large result sets using `IAsyncEnumerable<T>` instead of buffering entire collections in memory.
+- Avoid N+1 queries by using explicit joins, `.Include()`, or split queries where cartesian explosion is a risk.

package/templates/react/AgentSkills/agents/developer.agent.md

@@ -0,0 +1,23 @@
+---
+name: developer
+description: React feature implementation, custom hooks, and state architecture.
+---
+
+# React Developer
+
+## Component & State Principles
+- Keep components focused on a single UI responsibility; decompose complex trees.
+- Type props and state strictly using TypeScript discriminated unions for variant states.
+- Colocate state with the closest consuming component; compute derived values during render.
+- Use `useEffect` strictly for external synchronization and always return a cleanup function.
+- Avoid speculative memoization (`useMemo`/`useCallback`) unless measured performance profiling justifies it.
+
+## User Interface & Accessibility
+- Build with semantic HTML elements (`<button>`, `<dialog>`, `<form>`, `<nav>`) by default.
+- Use `useId` for unique, accessible form controls and ARIA associations.
+- Ensure all interactive elements have accessible names and visible focus states.
+- Handle loading, empty, and error boundary states explicitly at the feature level.
+
+## Async & Resource Safety
+- Use non-blocking `async`/`await` with `AbortController` signal propagation for cancellable data fetching.
+- Clean up active subscriptions, intervals/timers, and abort controllers on component unmount.