@pratikpsl/agent-skills 0.9.0 → 1.0.0

package/templates/dotnet/AgentSkills/memory/index.md

@@ -1,22 +0,0 @@
-# Memory Index
-
-Always load this file first. Then load **only** the domain file(s) that match your task.
-Do NOT load domain files you do not need. Never load all files at once.
-
-## Domain Map
-
-| Domain  | Load when                                                     | File                                     | Lessons |
-| ------- | ------------------------------------------------------------- | ---------------------------------------- | ------- |
-| api     | CQRS, MediatR, commands, queries, controllers, endpoints      | [lessons/api.md](lessons/api.md)         | 1       |
-| db      | EF Core, migrations, schema, seeding, repositories            | [lessons/db.md](lessons/db.md)           | 0       |
-| infra   | Build, paths, CI, tooling, portability, AgentSkills setup     | [lessons/infra.md](lessons/infra.md)     | 6       |
-| auth    | Authentication, authorisation, JWT, policies, claims          | [lessons/auth.md](lessons/auth.md)       | 0       |
-| testing | xUnit, test data, mocking, coverage, assertions               | [lessons/testing.md](lessons/testing.md) | 0       |
-| csharp  | C# language features, async/await, naming, code style         | [lessons/csharp.md](lessons/csharp.md)   | 0       |
-| design  | SOLID, CQRS, Repository, patterns, architecture decisions     | [lessons/design.md](lessons/design.md)   | 0       |
-| mcp     | MCP server tools, transports, contracts, .NET MCP integration | [lessons/mcp.md](lessons/mcp.md)         | 0       |
-
-## Writing a lesson?
-
-Load `memory/schema.md` for the one-line format. Do not inline logging instructions here.
-Update the lesson count in this table after appending to the domain file.

package/templates/dotnet/AgentSkills/memory/lessons/api.md

@@ -1,3 +0,0 @@
-# API Lessons
-
-RULE: Controllers dispatch only via MediatR; all business rules belong in Domain Entities or Domain Services, never in Handlers or Controllers. #cqrs-violation 2026-05-31

package/templates/dotnet/AgentSkills/memory/lessons/auth.md

@@ -1,3 +0,0 @@
-# Auth Lessons
-
-<!-- No lessons yet. Append using the format in memory/schema.md -->

package/templates/dotnet/AgentSkills/memory/lessons/csharp.md

@@ -1,3 +0,0 @@
-# C# Lessons
-
-<!-- No lessons yet. Append using the format in memory/schema.md -->

package/templates/dotnet/AgentSkills/memory/lessons/db.md

@@ -1,3 +0,0 @@
-# DB Lessons
-
-<!-- No lessons yet. Append using the format in memory/schema.md -->

package/templates/dotnet/AgentSkills/memory/lessons/design.md

@@ -1,3 +0,0 @@
-# Design Lessons
-
-RULE: Always use flat vertical slice feature folders; never create nested Commands or Queries subfolders. #wrong-path 2026-07-05

package/templates/dotnet/AgentSkills/memory/lessons/infra.md

@@ -1,8 +0,0 @@
-# Infra Lessons
-
-RULE: Never overwrite files in AgentSkills/ without verifying they are backed up; it is the single source of truth and tool-specific entry points must point to it, never duplicate it. #circular-redirect 2026-05-31
-RULE: Use repo-relative paths in all agent and IDE instruction files; never write absolute local drive paths in shared documentation. #wrong-path 2026-06-06
-RULE: When splitting a monolithic memory file into domain files, grep the whole repo for the old path and update every reference before deleting the original. #stale-reference 2026-06-07
-RULE: Always check native command exit codes explicitly in PowerShell harness scripts. #native-exit-code 2026-06-21
-RULE: Run dotnet format after patching C# files; this repo enforces CRLF and no final newline. #format-fail 2026-07-01
-RULE: Always execute the full AgentSkills bootstrap sequence before any code-changing task, even simple ones. #bootstrap-skip 2026-07-05

package/templates/dotnet/AgentSkills/memory/lessons/mcp.md

@@ -1,3 +0,0 @@
-# MCP Lessons
-
-<!-- No lessons yet. Append using the format in memory/schema.md -->

package/templates/dotnet/AgentSkills/memory/lessons/testing.md

@@ -1,3 +0,0 @@
-# Testing Lessons
-
-<!-- No lessons yet. Append using the format in memory/schema.md -->

package/templates/dotnet/AgentSkills/memory/schema.md

@@ -1,26 +0,0 @@
-# Lesson Logging Schema
-
-Load this file **only when writing a new lesson** at the end of a task.
-Never load at task start — it adds no value during execution.
-
-## Format
-
-Append one line per lesson to the correct domain file in `memory/lessons/`:
-
-```
-RULE: <imperative sentence — what to always do or never do> #tag YYYY-MM-DD
-```
-
-## Rules for a good entry
-
-- Start with **Always**, **Never**, or an action verb.
-- Keep it under 20 words. The rule only — no symptom narrative, no root cause prose.
-- Add one `#tag` describing the symptom class (e.g. `#build-fail`, `#wrong-path`, `#cqrs-violation`).
-- Pick the correct domain from `memory/index.md`. If unsure, use `infra.md`.
-- After appending, **increment the lesson count** for that domain in `memory/index.md`.
-
-## Example
-
-```
-RULE: Never place business logic in MediatR Handlers; delegate to domain entities or services. #cqrs-violation 2026-05-31
-```

package/templates/dotnet/AgentSkills/skills/INDEX.md

@@ -1,21 +0,0 @@
-# Skills Index
-
-Load the relevant skill from `AgentSkills/skills/` before starting any task.
-Start with `AgentSkills/OPERATING.md` for the shared prerequisite and completion workflow.
-
-`AgentSkills/` is the single source of truth for all skills and agents.
-Do not duplicate skill content under `.github/`, `.copilot/`, `.codex/`, or other tool-specific folders.
-All AI tools and IDEs should load skills from this folder.
-
-## Skills
-
-| Skill | Load when | Path |
-|---|---|---|
-| **core** | Every task | [SKILL.md](core/SKILL.md) |
-| **code-standards** | Writing, reviewing, or refactoring C# code | [SKILL.md](code-standards/SKILL.md) |
-| **design** | Designing, architecting, or implementing patterns | [SKILL.md](design/SKILL.md) |
-| **dotnet-best-practices** | Writing, reviewing, refactoring, or optimizing .NET/C# code | [SKILL.md](dotnet-best-practices/SKILL.md) |
-| **csharp-xunit** | Get best practices for XUnit unit testing, including data-driven tests | [SKILL.md](csharp-xunit/SKILL.md) |
-| **mcp_dotnet** | Building, reviewing, or extending .NET MCP server tools, transports, and integration points | [SKILL.md](mcp_dotnet/SKILL.md) |
-| **dotnet-api** | Creating, structuring, or reviewing .NET 10 Web API projects with Swagger/OpenAPI, CORS, compression, auth, versioning, and error handling | [SKILL.md](dotnet-api/SKILL.md) |
-| **harness** | Changing agent instructions, validation scripts, CI workflows, hooks, or operational guardrails | [SKILL.md](harness/SKILL.md) |

package/templates/dotnet/AgentSkills/skills/README.md

@@ -1,14 +0,0 @@
-# Skills
-
-This folder is the canonical source of truth for reusable skills used by all AI tools and IDEs in this repository.
-
-Do not duplicate skill content under `.github/`, `.copilot/`, `.codex/`, or other tool-specific folders.
-Those tools should load skill definitions from this folder.
-
-## Skill Index
-
-Start with `AgentSkills/skills/INDEX.md`, then load only the skills that match the task.
-
-## Harness Skill
-
-Use `AgentSkills/skills/harness/SKILL.md` when changing guides, sensors, hooks, CI, validation, or operational guardrails.

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

@@ -1,122 +0,0 @@
----
-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/templates/dotnet/AgentSkills/skills/core/SKILL.md

@@ -1,83 +0,0 @@
----
-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
-`AgentSkills/OPERATING.md`.
-
-Before editing, confirm that you have:
-
-- [ ] Read `AgentSkills/memory/index.md` and loaded only the relevant domain
-      lesson file(s).
-- [ ] Read `AgentSkills/skills/INDEX.md`.
-- [ ] Loaded this core skill.
-- [ ] Loaded task-specific skills and agent definitions only when they apply.
-- [ ] Identified the expected verification command(s).
-- [ ] Checked the worktree context so existing user changes are preserved.
-
-## Pre-submit Checklist
-
-### Scope
-
-- [ ] Only required files changed; no unrelated refactors or metadata churn.
-- [ ] Public documentation changed only when behavior, setup, commands, or usage changed.
-- [ ] Commit message states what changed and why, when a commit is made.
-- [ ] Memory was updated only if a mistake or durable project-specific rule was discovered.
-
-### Design and Maintainability
-
-- [ ] Code is as simple as possible, but no simpler.
-- [ ] No speculative generality or unused extension points.
-- [ ] Each function does one thing.
-- [ ] No argument list longer than 4; use an object, options type, or record.
-- [ ] No nesting deeper than 2 levels; prefer early returns.
-- [ ] No duplicated logic; shared behavior is extracted only when it is real reuse.
-- [ ] SOLID respected, especially Single Responsibility.
-- [ ] Important values are named; no magic literals.
-- [ ] Comments explain why, not what the code already says.
-
-### Reliability and Security
-
-- [ ] No race condition on shared mutable state.
-- [ ] All async operations have a cancellation path.
-- [ ] No sensitive data such as keys, PII, or tokens appears in logs, errors, commits, or responses.
-- [ ] External inputs are validated before use.
-- [ ] Rendered outputs are sanitized where applicable.
-- [ ] Errors include useful context: what failed, where, and relevant IDs.
-- [ ] Structured log entries are used; no raw string concatenation in logs.
-- [ ] Correlation or trace IDs are propagated on cross-service calls.
-
-### API and Contract Behavior
-
-- [ ] API responses use correct HTTP status codes; errors are not returned as `200`.
-- [ ] Collection endpoints include pagination and filtering where applicable.
-- [ ] Existing API contracts are preserved unless a versioned breaking change is intentional.
-- [ ] MCP, REST, and application contracts stay aligned when they expose the same behavior.
-
-### Tests and Verification
-
-- [ ] Tests cover failure paths, not just happy paths.
-- [ ] Test names describe behavior, not implementation.
-- [ ] Tests do not depend on external state or execution order.
-- [ ] Relevant build, test, format, and harness commands were run, or skipped with a clear reason.

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

@@ -1,108 +0,0 @@
----
-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);
-```

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

@@ -1,62 +0,0 @@
----
-name: harness
-description: >
-  Load when changing agent instructions, validation scripts, CI workflows,
-  hooks, or repository operational guardrails.
----
-
-# Harness Engineering
-
-Harness engineering is the operational layer around the model:
-
-```text
-Agent = Model + Harness
-```
-
-Use this skill when adding or changing guide rails, validation, recovery, or feedback loops.
-
-## Controls
-
-| Control | Purpose | Repo examples |
-|---|---|---|
-| Guides | Feedforward controls that steer work before action | `AGENTS.md`, `AgentSkills/skills/INDEX.md`, `AgentSkills/agents/` |
-| Sensors | Feedback controls that observe output after action | `tools/Harness/validate.ps1`, `.github/workflows/dotnet.yml`, `.editorconfig` |
-
-## Rules
-
-- Keep `AgentSkills/` as the canonical source of truth.
-- Tool-specific folders may contain lightweight entry points only.
-- Prefer one shared validation command over duplicated CI, hook, and README commands.
-- Sensors must be deterministic first: restore, build, test, format.
-- Use inferential review only after computational checks pass.
-- Keep harness changes small, readable, and easy to remove.
-
-## Agent and IDE Entry Point Contract
-
-All coding agents and AI-enabled IDEs must start from
-`AgentSkills/OPERATING.md`.
-
-Tool-specific entry points must be short router files that:
-
-- Identify themselves as lightweight entry points.
-- Point to `AgentSkills/OPERATING.md`.
-- Point to `AgentSkills/skills/INDEX.md` for skill routing.
-- Point to `AgentSkills/agents/` for optional role definitions.
-- Avoid duplicating project rules, checklists, memory instructions, or skill content.
-
-When a new agent or IDE integration is added, create only the smallest entry
-point required by that tool and route it back to `AgentSkills/`.
-
-## Validation
-
-Run the shared sensor before finishing changes:
-
-```powershell
-pwsh ./tools/Harness/validate.ps1
-```
-
-For quick local loops:
-
-```powershell
-pwsh ./tools/Harness/validate.ps1 -Configuration Debug -SkipFormat
-```

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

@@ -1,54 +0,0 @@
----
-name: mcp_dotnet
-description: >
-  Load when building, reviewing, or extending .NET MCP server tools,
-  transports, contracts, and IDE/client integration.
----
-
-# MCP .NET Skill
-
-Use this skill for Model Context Protocol work in this repository.
-
-## Project Rules
-
-- Keep MCP tools thin; route behavior through the same MediatR commands and queries used by REST endpoints.
-- Do not duplicate business logic in MCP tool methods.
-- Treat MCP tool contracts as public API: use stable names, clear descriptions, explicit input types, and small output DTOs.
-- Pass `CancellationToken` through all tool, mediator, EF Core, and HTTP boundaries.
-- Keep stdout reserved for MCP protocol messages when using stdio transport; send logs to stderr.
-- Validate tool inputs before dispatching commands or queries.
-- Avoid exposing raw entities, stack traces, connection strings, secrets, or internal schema details.
-- Add or update tests for tool behavior and contract mapping when MCP behavior changes.
-
-## Tool Design Checklist
-
-- [ ] Tool name is action-oriented and stable, for example `get_employee_by_id`.
-- [ ] Description tells the model when to use the tool.
-- [ ] Inputs are minimal and strongly typed.
-- [ ] Output is a DTO or result object, not an EF entity.
-- [ ] Tool delegates to MediatR or an existing application service.
-- [ ] Errors are structured and safe to show to an AI client.
-- [ ] Cancellation token is accepted and passed through.
-- [ ] New tools are documented in the relevant MCP docs when public usage changes.
-
-## Implementation Shape
-
-```csharp
-[McpTool("get_employee_by_id", "Gets one employee by id.")]
-public static async Task<EmployeeDto?> GetEmployeeByIdAsync(
-    Guid employeeId,
-    IMediator mediator,
-    CancellationToken cancellationToken)
-{
-    return await mediator.Send(
-        new GetEmployeeByIdQuery(employeeId),
-        cancellationToken);
-}
-```
-
-## Transport Notes
-
-- HTTP transport can share ASP.NET Core middleware for auth, validation, logging, and error handling.
-- Stdio transport must not write normal logs to stdout.
-- Keep `mcp.json` entries simple and point to built server artifacts or stable commands.
-- If a client cannot discover tools, verify the server builds, starts, and returns valid MCP initialize/list-tools responses.

package/templates/shared/manifest.json

@@ -1,57 +0,0 @@
-{
-  "name": "@pratikpsl/agent-skills",
-  "version": "0.9.0",
-  "description": "Universal single-file AI agent instructions for all programming languages, OSes, and IDEs (Cursor, Claude, Copilot, Codex, Antigravity, Windsurf, Cline).",
-  "skills": [
-    {
-      "name": "instructions",
-      "description": "Canonical single-file coding agent instructions (Goal, Principles, Definition of Done).",
-      "path": "instructions.md",
-      "dest": "AGENTS.md"
-    },
-    {
-      "name": "entry-point:codex",
-      "description": "Universal Codex/OpenAI agent entry point.",
-      "path": "instructions.md",
-      "dest": "AGENTS.md"
-    },
-    {
-      "name": "entry-point:claude",
-      "description": "Claude Code / Anthropic entry point.",
-      "path": "instructions.md",
-      "dest": "CLAUDE.md"
-    },
-    {
-      "name": "entry-point:copilot",
-      "description": "GitHub Copilot custom instructions entry point.",
-      "path": "instructions.md",
-      "dest": ".github/copilot-instructions.md"
-    },
-    {
-      "name": "entry-point:cursor",
-      "description": "Cursor IDE project rules entry point.",
-      "path": "instructions.md",
-      "dest": ".cursor/rules/instructions.md"
-    },
-    {
-      "name": "entry-point:antigravity",
-      "description": "Antigravity (Google DeepMind) / Gemini rules entry point.",
-      "path": "instructions.md",
-      "dest": ".agents/GEMINI.md"
-    },
-    {
-      "name": "entry-point:windsurf",
-      "description": "Windsurf / Codeium rules entry point.",
-      "path": "instructions.md",
-      "dest": ".windsurfrules"
-    },
-    {
-      "name": "entry-point:cline",
-      "description": "Cline / Roo Code rules entry point.",
-      "path": "instructions.md",
-      "dest": ".clinerules"
-    }
-  ]
-}
-
-