agent-skills

Run all 12 TypeScript code quality hunters in parallel as subagents and write each report to a timestamped reports folder. Covers boundary, doc, error, invariant, perf, security, simplicity, slop, smell, solid, test, and type hunters. Use when: running a full TypeScript codebase audit, scanning all quality dimensions at once, preparing for a code review, or generating a comprehensive findings report.

Audit TypeScript code for unnecessary structural complexity — duplication, avoidable abstractions, dead logic paths, flag-heavy APIs, deep nesting, mixed concerns, and coexisting abstraction generations left behind by unfinished migrations. Recommends the simplest shape that preserves intended behavior. Use when: reviewing TypeScript code for over-engineering, reducing complexity after prototyping, enforcing reuse over addition, simplifying before a refactor, or auditing a codebase after a framework or library migration.

Grilling session that challenges your requirements against the existing codebase. Reports omit empty sections — no placeholder headings, empty tables, or negative statements like "no issues found".

Audit Go packages for boundary violations — leaked internals via exports, coupling through shared types, import cycles, missing internal/ packages, over-exported APIs, and dependency direction violations. Use when: reviewing package structure, shrinking public API surface, enforcing encapsulation, preparing packages for replacement, or untangling tight coupling between layers.

Audit Go code for missing documentation where the "why" is not obvious — obscure calculations, non-trivial business rules, surprising behavior, implicit constraints, workarounds, and missing godoc on exported symbols. Finds where a comment would save the next reader significant time. Use when: reviewing Go code for long-term maintainability, onboarding new team members, auditing undocumented business logic, or preparing code for handoff.

Audit Go code for weak invariants — unchecked errors, nil pointer risks, ignored context cancellation, unsafe type assertions, zero-value traps, panic/recover misuse, and missing validation at construction boundaries. Use when: tightening domain models, reducing panic risks, increasing error handling discipline, or establishing a safety baseline before refactoring.

Run all 10 Go code quality hunters in parallel as subagents and write each report to a timestamped reports folder. Covers boundary, doc, invariant, security, simplicity, slop, smell, solid, test, and type hunters. Use when: running a full Go codebase audit, scanning all quality dimensions at once, preparing for a code review, or generating a comprehensive findings report.

Audit Go code for security vulnerabilities — hardcoded secrets, injection risks (SQL, command, template, path), missing input validation at trust boundaries, insecure defaults, auth gaps, sensitive data exposure, unsafe package usage, and weak crypto. Use when: reviewing Go code before deployment, auditing trust boundaries, preparing for a security review, onboarding third-party integrations, or hardening an application.

Audit Go code for unnecessary structural complexity — duplication, avoidable abstractions, dead logic paths, over-parameterized APIs, deep nesting, interface pollution, channel misuse, and mixed concerns. Recommends the simplest shape that preserves intended behavior. Use when: reviewing Go code for over-engineering, reducing complexity after prototyping, enforcing reuse over addition, or simplifying before a refactor.

Audit Go code for AI-generated noise — redundant comments, verbose documentation, style drift from project conventions and gofmt, trivially dead code, and unnecessary error wrapping. Surface-level hygiene pass; defaults to branch diff but supports any scope. Use when: reviewing AI-assisted Go code before merge, cleaning up generated code, enforcing project style on new contributions, or reducing review noise.

Audit Go code for classic code smells — feature envy, data clumps, shotgun surgery, primitive obsession, temporal coupling, comments as deodorant, temporary fields, init() abuse, package-level mutable state, and stuttering names. Use when: reviewing Go code for structural design problems, preparing for a refactor, auditing code after rapid feature development, or hunting for misplaced responsibilities.

Audit Go code for design principle violations — god packages, rigid extension points, broken interface contracts, fat interfaces, and concrete dependency chains. Adapted from SOLID for Go's composition-over-inheritance model. Use when: reviewing package structure, preparing for extension with new variants, reducing coupling between packages, or improving testability.

Audit Go test code for quality gaps — missing coverage on critical paths, brittle tests coupled to implementation, over-mocking, assertion-free tests, missing edge cases, table-driven test misuse, and race condition blindness. Focuses on test effectiveness. Use when: reviewing Go test suites for reliability, reducing false-positive test failures, improving coverage of critical business logic, or cleaning up test debt.

Audit Go type definitions for design debt — duplicated struct shapes, misused generics, under-constrained type parameters, embedding antipatterns, poor enum patterns, and disorganized type architecture. Type structure and maintainability. Use when: reviewing type definitions for maintainability, reducing type duplication, simplifying over-engineered generics, or reorganizing type architecture after growth.

Audit TypeScript modules for black-box boundary violations — leaked internals via exports, coupling through shared types, Law of Demeter chains, missing abstraction layers around externals, and over-exported APIs. Use when: reviewing module structure, shrinking public API surface, enforcing encapsulation, preparing modules for replacement, or untangling tight coupling between layers.

Audit TypeScript code for missing inline documentation where the "why" is not obvious — obscure calculations, non-trivial business rules, surprising behavior, implicit constraints, and workarounds. Finds where a comment would save the next reader significant time. Use when: reviewing TypeScript code for long-term maintainability, onboarding new team members, auditing undocumented business logic, or preparing code for handoff.

Audit TypeScript code for error handling design quality — missing Error hierarchies, lost Error.cause chains, return-undefined antipatterns, over-broad try/catch, silent suppression, poor error context, framework handler gaps, Result type opportunities, and missing error boundaries. Use when: reviewing error handling strategy, tightening exception design before deployment, auditing error propagation paths, standardizing API error responses, or establishing error handling conventions after rapid feature development.

Audit TypeScript types for weak invariants — unnecessary casts, loose optionality, defensive `?.`/`??` masking missing guarantees, leaky discriminated unions, and runtime checks the type system should enforce. Use when: tightening domain models, reducing type assertions, increasing type coverage, reviewing discriminated unions, or establishing a type-safety baseline before refactoring.

Audit TypeScript/Node.js code for performance antipatterns and resource management issues — event loop blocking, sequential awaits, N+1 queries, unclosed resources, unbounded caches, eager materialization, missing connection pooling, and expensive operations in hot paths. Use when: reviewing async correctness, auditing resource lifecycle, hunting N+1 query patterns, checking connection pool configuration, or profiling structurally inefficient code.

Audit TypeScript code for security vulnerabilities — hardcoded secrets, injection risks, missing input validation at trust boundaries, insecure defaults, auth gaps, sensitive data exposure, and unsafe patterns like eval or innerHTML. Use when: reviewing TypeScript code before deployment, auditing trust boundaries, preparing for a security review, onboarding third-party integrations, or hardening an application.

Audit TypeScript code for AI-generated noise — redundant comments, verbose documentation, style drift from project conventions, and trivially dead code. Surface-level hygiene pass; defaults to branch diff but supports any scope. Use when: reviewing AI-assisted TypeScript code before merge, cleaning up generated code, enforcing project style on new contributions, or reducing review noise.

Audit TypeScript code for classic code smells — feature envy, data clumps, shotgun surgery, primitive obsession, temporal coupling, comments as deodorant, temporary fields, and class abuse. Use when: reviewing TypeScript code for structural design problems, preparing for a refactor, auditing code after rapid feature development, or hunting for misplaced responsibilities.

Audit TypeScript class and interface design for SOLID violations — god classes, rigid extension points, broken substitutability, fat interfaces, and concrete dependency chains. Focuses on responsibility assignment and abstraction fitness. Use when: reviewing class hierarchies, preparing for extension with new variants, reducing coupling between services, or improving testability of class-heavy code.

Audit TypeScript test code for quality gaps — missing coverage on critical paths, brittle tests coupled to implementation, over-mocking, assertion-free tests, missing edge cases, and duplicated test setup. Focuses on test effectiveness, not production code structure. Use when: reviewing TypeScript test suites for reliability, reducing false-positive test failures, improving coverage of critical business logic, or cleaning up test debt.

Audit TypeScript type definitions for design debt — duplicated shapes, missing derivations, over-engineered generics, under-constrained type parameters, reinvented utility types, and disorganized type architecture. Type structure and maintainability, not type enforcement. Use when: reviewing type definitions for maintainability, reducing type duplication, simplifying over-engineered type-level logic, or reorganizing type architecture after growth.

Review a GitHub pull request — fetches context, builds an intent model, runs 3 parallel review agents (Correctness, Conventions, Efficiency & Safety), validates findings against actual code, and publishes one structured review. Triggers on "review this PR", "review PR #123", "review github.com/owner/repo/pull/N", "check this pull request". Reports omit empty sections — no placeholder headings, empty tables, or negative statements like "no issues found".

Act as a senior Go engineer performing a critical design and testing review. Evaluates architecture, patterns, idiomaticity, over-engineering, testing strategy, and proposes concrete improvements — all grounded in the codebase. Use when: reviewing a Go codebase for design soundness, testing robustness, or overall code quality before merging or after prototyping. Reports omit empty sections — no placeholder headings, empty tables, or negative statements like "no issues found".

Clarify the user’s intent for vague, incomplete, or ambiguous clauses, statements, and requirements before modifying the code. Reports omit empty sections — no placeholder headings, empty tables, or negative statements like "no issues found".

Audit Python packages and modules for black-box boundary violations — leaked internals via exports, coupling through shared types, Law of Demeter chains, missing abstraction layers around externals, and over-exported APIs. Use when: reviewing package structure, shrinking public API surface, enforcing encapsulation, preparing modules for replacement, or untangling tight coupling between layers. Reports omit empty sections — no placeholder headings, empty tables, or negative statements like "no issues found".

Audit Python code for missing or misleading inline documentation where the "why" is not obvious — obscure calculations, non-trivial business rules, surprising behavior, implicit constraints, workarounds, and stale comments that contradict the current code. Finds where a comment would save the next reader significant time, or where an existing comment actively misleads. Use when: reviewing Python code for long-term maintainability, onboarding new team members, auditing undocumented business logic, or preparing code for handoff. Reports omit empty sections — no placeholder headings, empty tables, or negative statements like "no issues found".

Audit Python code for error handling design quality — missing exception hierarchies, lost exception chains, return-None antipatterns, over-broad try/except, silent suppression, poor exception context, framework handler gaps, and missing error boundaries. Use when: reviewing error handling strategy, tightening exception design before deployment, auditing error propagation paths, standardizing API error responses, or establishing error handling conventions after rapid feature development. Reports omit empty sections — no placeholder headings, empty tables, or negative statements like "no issues found".

Audit Python code for weak invariants — unnecessary casts, loose optionality, defensive None-checks masking missing guarantees, leaky tagged unions, error suppression, and runtime checks that the type system or construction boundaries should enforce. Use when: tightening post-construction guarantees, reducing type: ignore and cast() usage, reviewing dataclass/TypedDict optionality, auditing error-handling hygiene, or establishing a type-safety baseline before refactoring. Reports omit empty sections — no placeholder headings, empty tables, or negative statements like "no issues found".

Run all 12 Python code quality hunters in parallel as subagents and write each report to a timestamped reports folder. Covers boundary, doc, error, invariant, perf, security, simplicity, slop, smell, solid, test, and type hunters. Use when: running a full Python codebase audit, scanning all quality dimensions at once, preparing for a code review, or generating a comprehensive findings report. Reports omit empty sections — no placeholder headings, empty tables, or negative statements like "no issues found".

Audit Python code for performance antipatterns and resource management issues — blocking I/O in async contexts, sequential awaits, N+1 queries, unclosed resources, unbounded caches, eager materialization, missing connection pooling, and expensive operations in hot paths. Use when: reviewing async correctness, auditing resource lifecycle, hunting N+1 query patterns, checking connection pool configuration, or profiling structurally inefficient code. Reports omit empty sections — no placeholder headings, empty tables, or negative statements like "no issues found".

Audit Python code for security vulnerabilities — hardcoded secrets, injection risks, missing input validation at trust boundaries, insecure defaults, auth gaps, sensitive data exposure, and unsafe patterns like eval, pickle, or shell injection. Use when: reviewing Python code before deployment, auditing trust boundaries, preparing for a security review, onboarding third-party integrations, or hardening an application. Reports omit empty sections — no placeholder headings, empty tables, or negative statements like "no issues found".

Audit Python code for unnecessary structural complexity — duplication, avoidable abstractions, dead logic paths, flag-heavy APIs, deep nesting, and mixed concerns. Recommends the simplest shape that preserves intended behavior. Use when: reviewing Python code for over-engineering, reducing complexity after prototyping, enforcing reuse over addition, or simplifying before a refactor. Reports omit empty sections — no placeholder headings, empty tables, or negative statements like "no issues found".

Audit Python code for AI-generated noise — redundant comments, verbose documentation, style drift from project conventions, and trivially dead code. Surface-level hygiene pass; defaults to branch diff but supports any scope. Use when: reviewing AI-assisted Python code before merge, cleaning up generated code, enforcing project style on new contributions, or reducing review noise. Reports omit empty sections — no placeholder headings, empty tables, or negative statements like "no issues found".

Audit Python code for classic code smells — feature envy, data clumps, shotgun surgery, temporal coupling, comments as deodorant, temporary fields, god modules, mutable default arguments, and class abuse. Use when: reviewing Python code for structural design problems, preparing for a refactor, auditing code after rapid feature development, or hunting for misplaced responsibilities. Reports omit empty sections — no placeholder headings, empty tables, or negative statements like "no issues found".

Audit Python class and interface design for SOLID violations — god classes, rigid extension points, broken substitutability, fat ABCs/Protocols, and concrete dependency chains. Focuses on responsibility assignment and abstraction fitness. Use when: reviewing class hierarchies, preparing for extension with new variants, reducing coupling between services, or improving testability of class-heavy code. Reports omit empty sections — no placeholder headings, empty tables, or negative statements like "no issues found".

Audit Python test code for quality gaps — missing coverage on critical paths, brittle tests coupled to implementation, over-mocking, assertion-free tests, missing edge cases, and duplicated test setup. Focuses on test effectiveness, not production code structure. Use when: reviewing Python test suites for reliability, reducing false-positive test failures, improving coverage of critical business logic, or cleaning up test debt. Reports omit empty sections — no placeholder headings, empty tables, or negative statements like "no issues found".