@pratikpsl/agent-skills 1.3.0 → 1.4.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -113,7 +113,7 @@ Options:
113
113
  | `dotnet` | `templates/dotnet/` | .NET/C# skills, architecture & developer agents (`architect.md`, `developer.md`), memory |
114
114
  | `python` | `templates/python/` | Python skills (PEP 8, uv, typing, testing, performance), architecture & developer agents (`architect.md`, `developer.md`) |
115
115
  | `react` | `templates/react/` | React & TypeScript skills, frontend testing, developer agent (`developer.md`) |
116
- | `rust` | `templates/rust/` | Rust skills (ownership, best-practices, testing, performance), architecture & developer agents (`architect.md`, `developer.md`) |
116
+ | `rust` | `templates/rust/` | Rust skills (standards, ownership, testing, performance), architecture & developer agents (`architect.md`, `developer.md`) |
117
117
  | `default` | `templates/default/` | Compact single-file agent instructions without AgentSkills folder |
118
118
 
119
119
  ---
package/package.json CHANGED
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "name": "@pratikpsl/agent-skills",
3
3
  "type": "module",
4
- "version": "1.3.0",
4
+ "version": "1.4.0",
5
5
  "description": "CLI to scaffold and manage AI agent skills across projects — like shadcn/ui, but for Cursor, Claude, Codex, Copilot, Antigravity, and more",
6
6
  "bin": {
7
7
  "agent-skills": "dist/bin/agent-skills.js"
@@ -34,9 +34,10 @@ minimizing the diff, following the project's own architecture and conventions.
34
34
  - Maximum 2 levels of nesting; prefer early returns to flatten control flow.
35
35
 
36
36
  ## Definition of Done
37
- - Builds cleanly without any errors.
37
+ - Lint, types, and the framework build are clean.
38
+ - Tests are added or run only when the user asks, and they pass when run.
38
39
  - No debug code, dead code, unused imports, or temporary files left behind.
39
- - Changes are minimal, focused, covered by tests, and easy to review.
40
+ - Changes are minimal, focused, and easy to review.
40
41
 
41
42
  ## Agent Memory
42
43
  - Read `AgentSkills/memory/index.md` at the start of every task (create if missing); load only relevant domain lessons.
@@ -0,0 +1,68 @@
1
+ ---
2
+ name: dotnet-standards
3
+ description: >
4
+ Load on every C# or .NET change. AI agents use this when writing, reviewing,
5
+ refactoring, or optimizing C# for standards and implementation: project
6
+ conventions, CQRS, EF Core, DI lifetimes, async, logging, validation, and maintainability.
7
+ compatibility: Requires the .NET SDK declared by the repository (Directory.Build.props, default net10.0). Build with dotnet build.
8
+ ---
9
+
10
+ # C# and .NET Standards
11
+
12
+ AI agents load this file on every C# or .NET edit, with shared principles and standards. Apply these rules while writing.
13
+
14
+ ## Repository Defaults & Structure
15
+ - Follow target framework and language versions in `Directory.Build.props` (default `net10.0`, `LangVersion` `latest`).
16
+ - Add XML documentation comments for public and shared API surfaces.
17
+ - Organize code by feature or domain slices. Place controllers, handlers, validators, repositories, and DTOs in that slice.
18
+ - Prefer clear, direct code over speculative patterns (YAGNI).
19
+
20
+ ## CQRS & Architecture
21
+ - **Commands**: Mutate state. Return void, an identifier, or a minimal result.
22
+ - **Queries**: Read state only.
23
+ - **Thin endpoints**: Validate transport concerns and dispatch to a handler.
24
+ - **Domain logic**: Keep rules in domain entities or domain services.
25
+ - **Immutability**: Use `record` for commands, queries, and DTOs. Mark classes `sealed` unless inheritance is designed.
26
+ - **Interfaces**: Define an interface for a boundary that needs a test double, more than one implementation, or an out-of-process call.
27
+
28
+ ## Dependency Injection & Lifetimes
29
+ - Use constructor injection or a primary constructor for required dependencies.
30
+ - Register the narrowest lifetime: `Singleton` for stateless thread-safe services, `Scoped` for a request and for `DbContext`, `Transient` for a lightweight stateless operation.
31
+ - Do not resolve services from `IServiceProvider`, and do not add static global state.
32
+
33
+ ## Async & I/O
34
+ - Use `async`/`await` for I/O, database, network, and file work.
35
+ - Do not block with `.Result`, `.Wait()`, or `.GetAwaiter().GetResult()`.
36
+ - Accept and pass `CancellationToken` through handlers, EF Core, and outbound HTTP.
37
+ - `async void` only for a top-level event handler.
38
+
39
+ ## EF Core & Data Access
40
+ - Avoid N+1 queries with a projection, `.Include()`, or a separate query.
41
+ - Use `.AsNoTracking()` for a read-only query.
42
+ - Select the columns the caller needs. Do not load a full tracked entity for a DTO.
43
+ - Paginate, filter, and sort on the server.
44
+ - Prefer `AnyAsync()` to test existence. Use `ExecuteUpdateAsync` and `ExecuteDeleteAsync` for bulk changes.
45
+
46
+ ## Logging, HTTP, validation
47
+ - Log with a message template and named properties. Do not log secrets, passwords, connection strings, or PII.
48
+ - Propagate the correlation id. Do not log inside a tight loop.
49
+ - Use `IHttpClientFactory`, an explicit timeout, and the caller's `CancellationToken`. Retry transient failures with a bounded backoff.
50
+ - Validate inbound payloads with FluentValidation or data annotations. Do not concatenate user input into SQL, a shell command, or a file path.
51
+
52
+ ## Review Checklist
53
+ - [ ] Read-only EF Core queries use `.AsNoTracking()`. No N+1 queries.
54
+ - [ ] Callers receive a DTO projection, not a tracked entity graph.
55
+ - [ ] Async methods take a `CancellationToken` and do not block.
56
+ - [ ] `DbContext` is `Scoped`.
57
+ - [ ] Logs are structured and contain no secrets.
58
+ - [ ] Input is validated at the boundary.
59
+ - [ ] `dotnet build` is clean.
60
+
61
+ ## Verify
62
+ After C# edits, run the framework build and fix what it reports:
63
+
64
+ ```bash
65
+ dotnet build
66
+ ```
67
+
68
+ Add or run tests only when the user asks. Then load `csharp-xunit` and run `dotnet test`.
@@ -8,7 +8,7 @@ Consult this index to load only the skills relevant to the current task.
8
8
  | standards | AgentSkills/skills/standards/SKILL.md | Code quality, 50-line limits, shallow nesting, clean signatures |
9
9
  | security | AgentSkills/skills/security/SKILL.md | Input validation, secrets handling, safe queries, least privilege |
10
10
  | review | AgentSkills/skills/review/SKILL.md | Code review framework, five review dimensions, verification rules |
11
- | dotnet-best-practices | AgentSkills/skills/dotnet-best-practices/SKILL.md | C# idioms, CQRS, EF Core, DI lifetimes, async/await, logging |
11
+ | dotnet-standards | AgentSkills/skills/dotnet-standards/SKILL.md | Load on every C# or .NET change. CQRS, EF Core, DI, async, logging |
12
12
  | dotnet-api | AgentSkills/skills/dotnet-api/SKILL.md | RESTful API design, HTTP methods, pagination, OpenAPI/Swagger |
13
13
  | csharp-xunit | AgentSkills/skills/csharp-xunit/SKILL.md | xUnit testing, AAA pattern, Facts vs Theories, mocking, assertions |
14
14
  | performance | AgentSkills/skills/performance/SKILL.md | Span/ReadOnlySpan, ValueTask, EF Core query tuning, memory pooling |
@@ -8,7 +8,6 @@ Consult this index to load only the skills relevant to the current task.
8
8
  | standards | AgentSkills/skills/standards/SKILL.md | Code quality, 50-line limits, shallow nesting, clean signatures |
9
9
  | security | AgentSkills/skills/security/SKILL.md | Input validation, secrets handling, safe queries, least privilege |
10
10
  | review | AgentSkills/skills/review/SKILL.md | Code review framework, five review dimensions, verification rules |
11
- | python-best-practices | AgentSkills/skills/python-best-practices/SKILL.md | PEP 8 conventions, uv project setup, ruff, async patterns, logging |
12
- | python-typing | AgentSkills/skills/python-typing/SKILL.md | Strict static typing, mypy/pyright, pydantic models, Protocol, TypeVar |
11
+ | python-standards | AgentSkills/skills/python-standards/SKILL.md | Load on every Python change. PEP 8, typing, uv, ruff, async, logging |
13
12
  | testing | AgentSkills/skills/testing/SKILL.md | pytest, pytest-asyncio, hypothesis property testing, fixtures, mocks |
14
13
  | performance | AgentSkills/skills/performance/SKILL.md | cProfile/memray, generators, asyncio concurrency, connection pooling |
@@ -0,0 +1,72 @@
1
+ ---
2
+ name: python-standards
3
+ description: >
4
+ Load on every Python change. AI agents use this when writing, reviewing,
5
+ refactoring, or optimizing Python for standards, typing, and implementation:
6
+ PEP 8, uv, ruff, mypy or pyright, pydantic, Protocol, TypeVar, Literal,
7
+ TypedDict, async I/O, errors, logging, and maintainability.
8
+ compatibility: Requires Python 3.11+ and uv. Lint and types use ruff and mypy, or pyright when the project already uses it. pydantic for models that cross a boundary.
9
+ ---
10
+
11
+ # Python Standards
12
+
13
+ AI agents load this file on every Python edit, with shared principles and standards. Apply these rules while writing.
14
+
15
+ ## Naming (PEP 8)
16
+ - Modules, packages, functions, variables: `snake_case`
17
+ - Classes: `PascalCase`. Constants: `UPPER_SNAKE_CASE`. Non-public: `_prefix`
18
+ - Use dunder names only for language protocols
19
+
20
+ ## Project
21
+ - Manage the project with `uv` (`uv add`, `uv sync`, `uv run`). Do not `pip install` into the global environment.
22
+ - Put project metadata and tool config in `pyproject.toml`. Commit `uv.lock`.
23
+
24
+ ## Types
25
+ - First statement of every module: `from __future__ import annotations`
26
+ - Annotate every parameter, return, and class attribute. Write `-> None` when a function returns nothing.
27
+ - Do not use `Any`. Use `object`, a bounded `TypeVar`, or `Literal` for a closed set of values.
28
+ - Prefer `Protocol` for injectable behavior. Use `type` aliases on 3.12+, otherwise `TypeAlias`.
29
+ - `TypedDict` for an external dict shape. `pydantic.BaseModel` for data that crosses a layer. `ConfigDict(frozen=True)` for value objects.
30
+ - Validate at the outer boundary (API, CLI, queue), then pass models inward.
31
+ - Enable strict checking. Minimum ruff selection is `E`, `F`, `I`, `UP`, `ANN`.
32
+
33
+ ```toml
34
+ [tool.mypy]
35
+ strict = true
36
+
37
+ [tool.ruff.lint]
38
+ select = ["E", "F", "I", "UP", "ANN"]
39
+ ```
40
+
41
+ If the repository already uses pyright, keep pyright on strict mode instead of adding mypy.
42
+
43
+ ## Async, errors, logging
44
+ - Use `async`/`await` for I/O. Inside `async def`, do not call `time.sleep`, sync `open`, or a sync client.
45
+ - Run independent tasks in `asyncio.TaskGroup`. Re-raise `asyncio.CancelledError`.
46
+ - Domain errors subclass one project base. Catch the narrowest type. Do not use a bare `except`.
47
+ - Use `contextlib.suppress` only for an error the caller intends to ignore.
48
+ - Log with `structlog` or JSON `logging`. No `print` on a production path.
49
+ - Bind request and user ids on the request logger. Never log secrets, tokens, or PII.
50
+
51
+ ## Review Checklist
52
+ - [ ] Names follow PEP 8.
53
+ - [ ] `uv` manages dependencies. `pyproject.toml` and `uv.lock` are current.
54
+ - [ ] Every signature is annotated. No unexplained `Any`.
55
+ - [ ] Boundary data is a pydantic model. External dicts use `TypedDict`.
56
+ - [ ] Async functions do no blocking I/O. `CancelledError` is re-raised.
57
+ - [ ] Exceptions are narrow. Logs are structured and contain no secrets.
58
+ - [ ] `ruff` and the type checker are clean.
59
+
60
+ ## Verify
61
+ After Python edits, run lint, types, and the framework build. Fix what they report:
62
+
63
+ ```bash
64
+ uv run ruff check
65
+ uv run ruff format --check
66
+ uv run mypy
67
+ uv build
68
+ ```
69
+
70
+ Use `uv run pyright` instead of mypy when that is the repository checker. When `pyproject.toml` has no build backend, run `uv run python -m compileall` on the source tree instead of `uv build`.
71
+
72
+ Add or run tests only when the user asks. Then load the `testing` skill and run `uv run pytest`.
@@ -8,6 +8,6 @@ Consult this index to load only the skills relevant to the current task.
8
8
  | standards | AgentSkills/skills/standards/SKILL.md | Code quality, 50-line limits, shallow nesting, clean signatures |
9
9
  | security | AgentSkills/skills/security/SKILL.md | Input validation, secrets handling, safe queries, least privilege |
10
10
  | review | AgentSkills/skills/review/SKILL.md | Code review framework, five review dimensions, verification rules |
11
- | react-typescript | AgentSkills/skills/react-typescript/SKILL.md | React & TypeScript props typing, custom hooks, discriminated unions |
11
+ | react-typescript | AgentSkills/skills/react-typescript/SKILL.md | Load on every React, TypeScript, or JavaScript change. Strict types, props, hooks |
12
12
  | testing | AgentSkills/skills/testing/SKILL.md | Vitest & React Testing Library, user-event, test coverage |
13
13
  | performance | AgentSkills/skills/performance/SKILL.md | Render optimization, lazy loading, state colocation, memoization |
@@ -1,22 +1,44 @@
1
1
  ---
2
2
  name: react-typescript
3
- description: React & TypeScript component typing, custom hook design, and type-safe state modeling.
3
+ description: >
4
+ Load on every React, TypeScript, or JavaScript change. AI agents use this
5
+ when writing, reviewing, or refactoring React, TypeScript, and JavaScript:
6
+ strict types, component props, discriminated unions, custom hooks, and forms.
7
+ compatibility: Requires TypeScript with strict enabled and React 18 or newer. Typecheck with tsc --noEmit and lint with the project's ESLint.
4
8
  ---
5
9
 
6
- # React & TypeScript Guidance
10
+ # React and TypeScript Standards
7
11
 
8
- ## Type Design & Component Contracts
9
- - Define strict prop interfaces; avoid `any` or loose `Record<string, unknown>`.
10
- - Use discriminated unions for distinct component states (e.g., `{ status: 'loading' } | { status: 'success'; data: T } | { status: 'error'; error: Error }`).
11
- - Explicitly type event handlers and custom hook return values (use `as const` for tuple returns).
12
+ AI agents load this file on every React, TypeScript, or JavaScript edit, with shared principles and standards. Apply these rules while writing.
12
13
 
13
- ## Custom Hook Guidelines
14
- - Encapsulate reusable stateful logic into focused custom hooks prefixed with `use`.
15
- - Keep hook parameter signatures clean (maximum 4 arguments; use options objects for complex configurations).
16
- - Pass `AbortSignal` to asynchronous functions initiated inside hooks for safe cancellation.
17
- - Return only stable handlers, derived state, and minimal state setters required by callers.
14
+ ## TypeScript
15
+ - Keep `strict` enabled. Do not use `any`. Use `unknown` and narrow it.
16
+ - Export the props type and the return type of every public component and hook.
18
17
 
19
- ## Form & Input Patterns
20
- - Prefer controlled inputs for dynamic form validation; use native form actions where appropriate.
21
- - Bind labels to inputs using `htmlFor` and `id` generated via `useId` for SSR safety.
22
- - Handle disabled, aria-invalid, and error message associations (`aria-describedby`) for robust UX.
18
+ ## Component Contracts
19
+ - Type props with an interface or type alias. Avoid a loose `Record<string, unknown>`.
20
+ - Model states that differ in shape as a discriminated union (`{ status: "loading" } | { status: "success"; data: T } | { status: "error"; error: Error }`).
21
+ - Type event handlers. For a hook tuple return, use `as const`.
22
+
23
+ ## Custom Hooks
24
+ - Put reusable state in a hook named `useSomething`.
25
+ - Keep the parameter list to four. Pass an options object past that.
26
+ - Pass an `AbortSignal` into async work started by the hook.
27
+ - Return stable handlers, derived state, and only the setters the caller needs.
28
+
29
+ ## Forms
30
+ - Use a controlled input when validation is dynamic. Use a native form action when the platform covers it.
31
+ - Bind each label with `htmlFor` and an `id` from `useId`.
32
+ - Wire `aria-invalid` and `aria-describedby` to the error message.
33
+
34
+ ## Review Checklist
35
+ - [ ] `strict` is on. New code has no `any`.
36
+ - [ ] States with different shapes use a discriminated union.
37
+ - [ ] Hooks start with `use`, stay within four parameters, and return stable values.
38
+ - [ ] Async work in a hook accepts an `AbortSignal`.
39
+ - [ ] Inputs have labels, and errors are referenced with `aria-describedby`.
40
+
41
+ ## Verify
42
+ After TypeScript, JavaScript, or React edits, run the project's typecheck, ESLint, and framework build. Fix what they report.
43
+
44
+ Add or run tests only when the user asks. Then load the `testing` skill and run the project's test script.
@@ -8,7 +8,6 @@ Consult this index to load only the skills relevant to the current task.
8
8
  | standards | AgentSkills/skills/standards/SKILL.md | Code quality, 50-line limits, shallow nesting, clean signatures |
9
9
  | security | AgentSkills/skills/security/SKILL.md | Input validation, secrets handling, safe queries, least privilege |
10
10
  | review | AgentSkills/skills/review/SKILL.md | Code review framework, five review dimensions, verification rules |
11
- | rust-best-practices | AgentSkills/skills/rust-best-practices/SKILL.md | API guidelines, cargo clippy/fmt, thiserror/anyhow, tracing logging |
12
- | rust-ownership | AgentSkills/skills/rust-ownership/SKILL.md | Ownership, borrowing, lifetimes, Arc/Mutex, Send+Sync safety |
11
+ | rust-standards | AgentSkills/skills/rust-standards/SKILL.md | Load on every Rust change. Ownership, clippy, thiserror, tracing |
13
12
  | testing | AgentSkills/skills/testing/SKILL.md | cargo test, tokio::test, proptest property testing, mockall |
14
13
  | performance | AgentSkills/skills/performance/SKILL.md | criterion benchmarking, zero-copy parsing, allocation reduction |
@@ -0,0 +1,52 @@
1
+ ---
2
+ name: rust-standards
3
+ description: >
4
+ Load on every Rust change. AI agents use this when writing, reviewing,
5
+ refactoring, or optimizing Rust for standards, ownership, and implementation:
6
+ API naming, rustfmt, clippy, thiserror, anyhow, tracing, Cargo layout,
7
+ borrowing, lifetimes, Arc/Mutex, and Send + Sync.
8
+ compatibility: Requires a stable Rust toolchain and Cargo. Format and lint use rustfmt and clippy. thiserror for library errors, anyhow for applications, tracing for logs.
9
+ ---
10
+
11
+ # Rust Standards
12
+
13
+ AI agents load this file on every Rust edit, with shared principles and standards. Apply these rules while writing.
14
+
15
+ ## Naming
16
+ - Types and traits: `PascalCase`. Functions, methods, variables, modules: `snake_case`.
17
+ - Constants and statics: `UPPER_SNAKE_CASE`. Lifetimes: a short lowercase name (`'a`).
18
+ - Library crate names: `snake_case`. Package names in `Cargo.toml`: `kebab-case`.
19
+ - Document public items with `///`.
20
+
21
+ ## Ownership
22
+ - One owner at a time. Many shared borrows (`&T`) or one mutable borrow (`&mut T`), never both.
23
+ - Add a lifetime only when elision cannot see it. Prefer owned `String` and `Vec` in public APIs.
24
+ - `Arc<Mutex<T>>` for shared mutable state. `Arc<RwLock<T>>` when reads dominate. Drop the guard before `.await`.
25
+ - Prefer a channel when the work is producer and consumer. No `Rc` or `Cell` across threads.
26
+ - Do not `clone()` to silence the borrow checker. Restructure the ownership.
27
+
28
+ ## Errors, logging, dependencies
29
+ - Libraries: `thiserror`. Applications: `anyhow` with `context`.
30
+ - No `unwrap()` or `expect()` on a production path. Return `Result` and use `?`. Reserve `panic!` for a programmer bug.
31
+ - Log with `tracing`. Attach fields with `#[tracing::instrument]`. No `println!` in production. Never log secrets.
32
+ - Add a crate only when the standard library does not cover the job. Dev-only crates go in `[dev-dependencies]`.
33
+ - Set `default-features = false` when the crate supports it.
34
+
35
+ ## Review Checklist
36
+ - [ ] `cargo fmt --check` and `cargo clippy -- -D warnings` are clean.
37
+ - [ ] No `unwrap()`, `expect()`, or borrow-checker `clone()` in production code.
38
+ - [ ] Lifetimes appear only where elision fails. Guards drop before `.await`.
39
+ - [ ] Library errors use `thiserror`. Application errors use `anyhow`.
40
+ - [ ] `tracing` is used. Logs contain no secrets. Public items have `///` docs.
41
+ - [ ] `cargo audit` reports no known vulnerabilities.
42
+
43
+ ## Verify
44
+ After Rust edits, run format, clippy, and the framework build. Fix what they report:
45
+
46
+ ```bash
47
+ cargo fmt --check
48
+ cargo clippy -- -D warnings
49
+ cargo build
50
+ ```
51
+
52
+ Add or run tests only when the user asks. Then load the `testing` skill and run `cargo test`.
@@ -5,11 +5,11 @@
5
5
  2. **Role & Skill Discovery**: Consult `AgentSkills/skills/index.md` to identify and load task-specific skills from `AgentSkills/skills/` (including `AgentSkills/skills/review/SKILL.md`). Load relevant role guidance from `AgentSkills/agents/` (`architect.md`, `reviewer.md`, `developer.md`).
6
6
  3. **Pre-flight Inspection**: Inspect current codebase patterns, dependencies, and baseline build/test state.
7
7
  4. **Surgical Implementation**: Apply the minimal change required; adhere strictly to DRY, KISS, and YAGNI.
8
- 5. **Verification**: Run the project's build and test commands (e.g. `npm test`, `dotnet test`, `cargo test`, `uv run pytest`, or project test suite) to verify happy paths and edge cases per `AgentSkills/skills/review/SKILL.md`.
8
+ 5. **Verification**: Run the language skill's lint, type feedback, and framework build, and fix what they report. Add or run tests only when the user asks. Follow `AgentSkills/skills/review/SKILL.md`.
9
9
  6. **Learning Loop**: If a mistake was made and corrected or a durable rule discovered, record a concise lesson in `AgentSkills/memory/lessons/<domain>.md` and update `index.md`.
10
10
 
11
11
  ## Completion Checklist
12
- - [ ] Project builds cleanly with zero errors or warnings.
13
- - [ ] Automated tests pass and cover failure paths and edge cases.
12
+ - [ ] Lint, types, and the framework build are clean.
13
+ - [ ] Tests were added or run only because the user asked. They pass when run.
14
14
  - [ ] No dead code, debug logging, unused imports, or temporary files remain.
15
15
  - [ ] Relevant documentation or memory lessons updated if applicable.
@@ -14,10 +14,9 @@ Universal review guidance for AI agents and human reviewers across all stacks. S
14
14
  - **Review**: Adhere strictly to `AgentSkills/skills/review/SKILL.md`.
15
15
 
16
16
  ## Verification & Automated Checks
17
- - [ ] **Clean Build**
18
- - [ ] **Zero Lint Errors**
19
- - [ ] **Tests Pass**
20
- - [ ] **Test Robustness**
17
+ - [ ] **Lint, types, and framework build**
18
+ - [ ] **Tests** added or run only when the user asks
19
+ - [ ] **Test Robustness** when the user asked for tests
21
20
 
22
21
  ## Standards & Skill Compliance
23
22
  - [ ] **Principles**: `AgentSkills/skills/principles/SKILL.md`
@@ -27,5 +27,5 @@ Bug fix = root cause, not symptom. A bug report names a symptom. Grep every call
27
27
  - **Think Before Coding**: Thoroughly understand requirements. If ambiguous, ask before guessing.
28
28
  - **Surgical Changes**: Make the smallest change that satisfies the request; touch only what is explicitly required.
29
29
  - **Simplicity First (KISS / YAGNI)**: Favor simple, clear, maintainable solutions over clever abstractions. Do not add unrequested features.
30
- - **Zero-Error Builds**: Every change must compile cleanly and pass existing and newly added tests.
30
+ - **Build**: Run the language framework build and fix what it reports before finishing. Add or run tests only when the user asks.
31
31
  - **Standards, Security & Review**: Adhere strictly to `AgentSkills/skills/standards/SKILL.md`, `AgentSkills/skills/security/SKILL.md`, and `AgentSkills/skills/review/SKILL.md`.
@@ -15,9 +15,8 @@ Universal review framework and verification standards for AI agents and human re
15
15
  5. **Performance**: Avoid N+1 queries, unbounded loops, blocking operations in async flows, and redundant re-computations.
16
16
 
17
17
  ## Verification & Automated Checks
18
- - [ ] **Clean Build**: Project builds cleanly with zero errors or warnings.
19
- - [ ] **Zero Lint Errors**: Code adheres to project formatting and static analysis rules.
20
- - [ ] **Tests Pass**: Run test suite; all existing and newly added tests must pass.
18
+ - [ ] **Lint, types, and build**: Formatting, static checks, and the language framework build are clean.
19
+ - [ ] **Tests**: Add or run tests only when the user asks. When run, they pass.
21
20
  - [ ] **Test Robustness**: Tests must cover failure paths, edge cases, and boundary conditions, not just happy paths.
22
21
 
23
22
  ## Review Output Format
@@ -17,12 +17,13 @@ minimizing the diff, following the project's own architecture, standards, and co
17
17
  - **Think Before Coding**: Thoroughly understand requirements. If ambiguous, ask before guessing.
18
18
  - **Surgical Changes**: Make the smallest change that satisfies the request; touch only what is explicitly required.
19
19
  - **Simplicity First (KISS / YAGNI)**: Favor simple, clear, maintainable solutions over clever abstractions. Do not add unrequested features.
20
- - **Zero-Error Builds**: Every change must compile cleanly and pass existing and newly added tests.
20
+ - **Build**: Run the language framework build and fix what it reports before finishing. Add or run tests only when the user asks.
21
21
 
22
22
  ## Definition of Done
23
- - Builds cleanly without any errors.
23
+ - Lint, types, and the framework build are clean.
24
+ - Tests are added or run only when the user asks, and they pass when run.
24
25
  - No debug code, dead code, unused imports, or temporary files left behind.
25
- - Changes are minimal, focused, covered by tests, and easy to review.
26
+ - Changes are minimal, focused, and easy to review.
26
27
 
27
28
  ## Agent & Contributor Memory
28
29
  - Read `AgentSkills/memory/index.md` at the start of every task (create if missing); load only relevant domain lessons.
@@ -1,79 +0,0 @@
1
- ---
2
- name: dotnet-best-practices
3
- description: >
4
- Load when writing, reviewing, refactoring, or optimizing .NET/C# code.
5
- Covers project conventions, CQRS, EF Core, async, testing, performance,
6
- logging, security, and maintainability.
7
- ---
8
-
9
- # .NET/C# Best Practices
10
-
11
- Use this skill to keep .NET/C# changes simple, maintainable, testable, and aligned with repository conventions.
12
-
13
- ## Repository Defaults & Structure
14
- - Follow target framework and language versions in `Directory.Build.props` (default `net10.0`, `LangVersion` `latest`).
15
- - Add XML documentation comments for public/shared API surfaces.
16
- - Organize code by feature or domain slices; place controllers, handlers, validators, repositories, and DTOs predictably.
17
- - Prefer clear, direct code over complex or speculative patterns (YAGNI).
18
-
19
- ## CQRS & Architecture
20
- - **Commands**: Mutate state; return void, an identifier, or a minimal result.
21
- - **Queries**: Read state only; never mutate data.
22
- - **Thin Endpoints**: Keep controllers and minimal API endpoints thin; validate transport concerns and dispatch via mediator handlers.
23
- - **Domain Logic**: Encapsulate domain rules in domain entities or domain services, never in transport handlers.
24
- - **Immutability**: Use `record` for commands, queries, and DTOs; mark classes `sealed` unless inheritance is intentionally designed.
25
- - **Interfaces**: Define interfaces for boundaries requiring testing, multiple implementations, or out-of-process integration.
26
-
27
- ## Dependency Injection & Lifetimes
28
- - Use constructor injection or primary constructors for required dependencies.
29
- - Register services with the narrowest appropriate lifetime:
30
- - `Singleton`: Stateless, thread-safe services.
31
- - `Scoped`: Request-bound services and EF Core `DbContext`.
32
- - `Transient`: Lightweight, stateless operations.
33
- - Avoid resolving services manually via `IServiceProvider` or introducing static global state.
34
-
35
- ## Async & I/O
36
- - Use `async`/`await` for all I/O, database, network, and file operations.
37
- - Never block async code using `.Result`, `.Wait()`, or `.GetAwaiter().GetResult()`.
38
- - Accept and propagate `CancellationToken` through all handler, EF Core, and outbound HTTP calls.
39
- - Avoid `async void` except for top-level event handlers.
40
-
41
- ## EF Core & Data Access
42
- - Avoid N+1 queries by using explicit projections, `.Include()`, or separate optimized queries.
43
- - Use `.AsNoTracking()` for all read-only queries.
44
- - Select only needed columns into DTOs instead of loading full tracked entities.
45
- - Implement server-side pagination, filtering, and sorting; never filter unbounded sets in memory.
46
- - Prefer `AnyAsync()` over `CountAsync()` when testing for existence.
47
- - Use `ExecuteUpdateAsync` and `ExecuteDeleteAsync` for bulk operations where appropriate.
48
-
49
- ## Logging & Observability
50
- - Use structured logging with message templates and named properties (`LogInformation("Order {OrderId} processed", id)`).
51
- - Avoid logging inside tight loops or hot execution paths.
52
- - Propagate correlation/request IDs across service and HTTP boundaries.
53
- - Never log secrets, passwords, connection strings, or sensitive personal data (PII).
54
-
55
- ## HTTP & Resilient Integration
56
- - Use `IHttpClientFactory` for outbound HTTP calls.
57
- - Set explicit timeouts and pass cancellation tokens to all HTTP calls.
58
- - Use bounded retries with exponential backoff for transient failures; avoid unbounded retry storms.
59
- - Batch outbound requests rather than making external calls inside tight loops.
60
-
61
- ## Security & Validation
62
- - Validate all incoming request payloads using FluentValidation or Data Annotations.
63
- - Never concatenate raw user input into SQL queries, shell commands, or file paths.
64
- - Follow the principle of least privilege for database connections and external service credentials.
65
-
66
- ## Testing Standards
67
- - Use xUnit for unit and integration testing.
68
- - Structure tests using Arrange-Act-Assert (AAA).
69
- - Test happy paths, edge cases, validation failures, and cancellation flows.
70
- - Keep tests isolated, deterministic, and idempotent.
71
-
72
- ## Review Checklist
73
- - [ ] No N+1 queries; read-only EF Core queries use `.AsNoTracking()`.
74
- - [ ] DTO projections used; no full entity graphs exposed to callers.
75
- - [ ] Async methods propagate `CancellationToken` without blocking.
76
- - [ ] DI lifetimes correctly configured (`Scoped` for DbContext).
77
- - [ ] Structured logging used without leaking sensitive data or secrets.
78
- - [ ] Input validation applied at boundaries.
79
- - [ ] Tests pass and cover edge cases.
@@ -1,59 +0,0 @@
1
- ---
2
- name: python-best-practices
3
- description: >
4
- Load when writing, reviewing, refactoring, or optimizing Python code.
5
- Covers PEP conventions, uv project management, async patterns, error handling,
6
- structured logging, and maintainability.
7
- ---
8
-
9
- # Python Best Practices
10
-
11
- ## Naming Conventions (PEP 8)
12
- - **Modules & packages**: `snake_case` (`user_service.py`, `auth/`)
13
- - **Functions & variables**: `snake_case` (`get_user`, `is_valid`)
14
- - **Classes**: `PascalCase` (`UserService`, `OrderRepository`)
15
- - **Constants**: `UPPER_SNAKE_CASE` (`MAX_RETRIES`, `DEFAULT_TIMEOUT`)
16
- - **Private members**: single underscore prefix (`_internal_helper`)
17
- - **Dunder methods**: reserved for Python protocols (`__init__`, `__repr__`)
18
-
19
- ## Project Setup with uv
20
- ```bash
21
- uv init my-project # scaffold pyproject.toml, src layout
22
- uv add fastapi pydantic # add runtime dependencies
23
- uv add --dev pytest mypy ruff # add dev dependencies
24
- uv sync # install from uv.lock
25
- uv run pytest # run commands in the managed venv
26
- ```
27
- - Always use `uv`; never run bare `pip install` against the global environment.
28
- - Declare all metadata in `pyproject.toml` (`[project]`, `[build-system]`, tool configs).
29
-
30
- ## Code Quality & Formatting
31
- - Use `ruff` for linting and formatting (replaces `flake8`, `isort`, `black`).
32
- - Enable `ruff` rules `E`, `F`, `I`, `UP`, `ANN` at minimum in `pyproject.toml`.
33
- - Run `mypy --strict` in CI; no type errors are acceptable in production code.
34
-
35
- ## Async & I/O
36
- - Use `async`/`await` for all I/O-bound operations (HTTP, database, file, queue).
37
- - Never call blocking functions (`time.sleep`, `open()`, sync DB calls) inside an async context; use their async equivalents.
38
- - Use `asyncio.TaskGroup` (Python 3.11+) for structured concurrent tasks.
39
- - Propagate `asyncio.CancelledError`; never catch it without re-raising.
40
-
41
- ## Error Handling
42
- - Define domain-specific exception classes inheriting from a project base (`AppError`).
43
- - Catch the narrowest exception type possible; never use bare `except:` or `except Exception:` without logging and re-raising.
44
- - Use `contextlib.suppress` only for explicitly expected, recoverable errors.
45
-
46
- ## Logging
47
- - Use structured logging (`structlog` or `logging` with a JSON formatter) — never `print()` in production code.
48
- - Bind contextual fields (request IDs, user IDs) to the logger at request scope.
49
- - Never log secrets, tokens, passwords, or PII.
50
-
51
- ## Review Checklist
52
- - [ ] All names follow PEP 8 conventions.
53
- - [ ] `uv` used for dependency management; `pyproject.toml` up to date.
54
- - [ ] No bare `pip install` or unpinned dependencies.
55
- - [ ] `ruff` passes with zero errors.
56
- - [ ] `mypy --strict` passes with zero errors.
57
- - [ ] No blocking calls inside `async` functions.
58
- - [ ] Structured logging used; no `print()` statements remain.
59
- - [ ] Narrow exception handling; no silent swallowing of errors.
@@ -1,42 +0,0 @@
1
- ---
2
- name: python-typing
3
- description: >
4
- Load when writing or reviewing Python code. Covers strict static typing with mypy/pyright,
5
- pydantic data models, Protocol, TypeVar, Literal, and TypedDict patterns.
6
- ---
7
-
8
- # Python Static Typing
9
-
10
- ## Module Setup
11
- - Add `from __future__ import annotations` as the first import in every module to enable postponed evaluation of annotations (PEP 563).
12
- - Enable strict mode in `pyproject.toml`:
13
- ```toml
14
- [tool.mypy]
15
- strict = true
16
- warn_return_any = true
17
- disallow_untyped_defs = true
18
- ```
19
-
20
- ## Function & Variable Annotations
21
- - Annotate every function parameter, return type, and class attribute without exception.
22
- - Use `None` as an explicit return type for functions that return nothing; never omit the annotation.
23
- - Avoid `Any` — use `object` for truly unknown types, or narrow with generics and `TypeVar`.
24
-
25
- ## Type Constructs
26
- - **`TypeAlias`**: Use `type Alias = ...` (Python 3.12+) or `TypeAlias` from `typing` for readable compound types.
27
- - **`Protocol`**: Prefer structural subtyping (`Protocol`) over ABCs for dependency injection and testability.
28
- - **`TypeVar` / `ParamSpec`**: Use for generic functions and decorators; constrain with `bound=` where applicable.
29
- - **`Literal`**: Use `Literal["value"]` to narrow string/int constants in type signatures.
30
- - **`TypedDict`**: Use for dict shapes at external boundaries (JSON, config); prefer `pydantic.BaseModel` for mutable internal models.
31
-
32
- ## Pydantic Models
33
- - Define all data contracts as `pydantic.BaseModel` subclasses; never pass raw `dict` across layer boundaries.
34
- - Use `model_config = ConfigDict(frozen=True)` for immutable value objects.
35
- - Validate external inputs at the outermost boundary (API, CLI, queue consumer) before passing into application logic.
36
-
37
- ## Review Checklist
38
- - [ ] `from __future__ import annotations` present in every module.
39
- - [ ] No `Any` without a documented justification comment.
40
- - [ ] All function signatures fully annotated (parameters + return).
41
- - [ ] Pydantic models used at all data boundaries.
42
- - [ ] `mypy --strict` passes with zero errors.
@@ -1,48 +0,0 @@
1
- ---
2
- name: rust-best-practices
3
- description: >
4
- Load when writing, reviewing, refactoring, or optimizing Rust code.
5
- Covers naming conventions, clippy/rustfmt enforcement, error handling with
6
- thiserror/anyhow, structured logging with tracing, and Cargo workspace layout.
7
- ---
8
-
9
- # Rust Best Practices
10
-
11
- ## Naming Conventions (Rust API Guidelines)
12
- - **Types & Traits**: `PascalCase` (`UserRepository`, `Deserialize`)
13
- - **Functions, methods, variables, modules**: `snake_case` (`get_user`, `user_service`)
14
- - **Constants & statics**: `UPPER_SNAKE_CASE` (`MAX_CONNECTIONS`, `DEFAULT_TIMEOUT`)
15
- - **Lifetime parameters**: short lowercase single letters (`'a`, `'db`)
16
- - **Crates**: `snake_case` for library crates, `kebab-case` in `Cargo.toml` names
17
-
18
- ## Tooling Discipline
19
- - **Format**: `cargo fmt` — enforce in CI with `cargo fmt --check`.
20
- - **Lint**: `cargo clippy -- -D warnings` — all warnings are errors in CI; suppress individually only with a comment explaining the justification.
21
- - **Audit**: `cargo audit` — run in CI to catch known vulnerabilities in dependencies.
22
- - **Build**: `cargo check` for fast feedback; `cargo build --release` for benchmarks and deployment.
23
-
24
- ## Error Handling
25
- - Use `thiserror` to define typed, domain-specific errors for library crates.
26
- - Use `anyhow` for application-level error aggregation and context chaining (`context()`, `with_context()`).
27
- - Never use `unwrap()` or `expect()` in production paths; propagate with `?`.
28
- - Return `Result<T, E>` from all fallible functions; reserve `panic!` for truly unrecoverable programmer errors.
29
-
30
- ## Logging & Observability
31
- - Use `tracing` for structured, async-aware logging: `tracing::info!`, `tracing::error!`, `tracing::instrument`.
32
- - Attach contextual fields with `#[tracing::instrument(fields(user_id = %id))]`.
33
- - Initialize the subscriber once at the application entry point (`tracing_subscriber::fmt::init()`).
34
- - Never log secrets, tokens, passwords, or sensitive personal data.
35
-
36
- ## Dependency Management
37
- - Minimize external dependencies; evaluate the maintenance status and license before adding a new crate.
38
- - Add dev-only dependencies under `[dev-dependencies]` in `Cargo.toml`.
39
- - Use feature flags to keep the dependency graph lean (`default-features = false`).
40
-
41
- ## Review Checklist
42
- - [ ] `cargo fmt --check` passes.
43
- - [ ] `cargo clippy -- -D warnings` passes with zero warnings.
44
- - [ ] No `unwrap()` / `expect()` in non-test production code.
45
- - [ ] `thiserror` used for library errors; `anyhow` for application errors.
46
- - [ ] Structured `tracing` logging used; no `println!` in production.
47
- - [ ] `cargo audit` passes; no known vulnerabilities.
48
- - [ ] All public API items documented with `///` doc comments.
@@ -1,40 +0,0 @@
1
- ---
2
- name: rust-ownership
3
- description: >
4
- Load when writing or reviewing Rust code. Covers ownership, borrowing, lifetimes,
5
- shared-state concurrency with Arc/Mutex, and Send + Sync safety.
6
- ---
7
-
8
- # Rust Ownership & Borrowing
9
-
10
- ## Core Rules
11
- - A value has exactly one owner at a time; ownership transfers on move.
12
- - Borrow immutably (`&T`) as many times as needed, or mutably (`&mut T`) exactly once — never both simultaneously.
13
- - References must never outlive the value they point to; the compiler enforces this via lifetimes.
14
-
15
- ## Lifetime Annotations
16
- - Add explicit lifetime annotations (`'a`) only when the compiler cannot infer them — let elision work first.
17
- - For structs that hold references, annotate struct lifetime parameters and bound them on the relevant fields.
18
- - Prefer owned types (`String`, `Vec<T>`) over references in public APIs to avoid lifetime propagation into callers.
19
-
20
- ## Shared State
21
- - Use `Arc<Mutex<T>>` for shared mutable state across threads; use `Arc<RwLock<T>>` when reads dominate.
22
- - Lock mutexes for the shortest scope possible; never hold a lock across an `.await` point.
23
- - Prefer message-passing (`tokio::sync::mpsc`, `std::sync::mpsc`) over shared state when tasks are naturally producer/consumer.
24
-
25
- ## Send & Sync
26
- - Ensure types shared across thread boundaries implement `Send + Sync`; the compiler enforces this.
27
- - Avoid `Rc<T>` and `Cell<T>` in async or multi-threaded contexts; use `Arc` and `Mutex` instead.
28
- - Use `#[derive(Clone)]` sparingly on types that are expensive to clone; document where clones occur.
29
-
30
- ## Common Pitfalls
31
- - Never use `unwrap()` or `expect()` in production paths — propagate errors with `?` instead.
32
- - Avoid `clone()` as a workaround for borrow-checker conflicts; restructure ownership or use a reference instead.
33
- - Do not hold a `MutexGuard` across an `await` point — drop it explicitly before awaiting.
34
-
35
- ## Review Checklist
36
- - [ ] No `unwrap()` / `expect()` in non-test production code.
37
- - [ ] No `clone()` used to paper over borrow-checker issues.
38
- - [ ] Explicit lifetime annotations present only where elision fails.
39
- - [ ] `Mutex` guards released before any `.await` points.
40
- - [ ] `Arc<Mutex<T>>` used for all cross-thread mutable state.