nledford
- 77 skills
- 0 followers
- 5 hours ago last updated
- ▌ Impeccable · nledford bundleUse when the user wants to design, redesign, shape, critique, audit, polish, clarify, distill, harden, optimize, adapt, animate, colorize, extract, or otherwise improve a frontend interface. Covers websites, landing pages, dashboards, product UI, app shells, components, forms, settings, onboarding, and empty states. Handles UX review, visual hierarchy, information architecture, cognitive load, accessibility, performance, responsive behavior, theming, anti-patterns, typography, fonts, spacing, layout, alignment, color, motion, micro-interactions, UX copy, error states, edge cases, i18n, and reusable design systems or tokens. Also use for bland designs that need to become bolder or more delightful, loud designs that should become quieter, live browser iteration on UI elements, or ambitious visual effects that should feel technically extraordinary. Not for backend-only or non-UI tasks.
- ▌ Gherkin · nledfordWrite clear, idiomatic formal Gherkin feature specifications. Use when creating or editing .feature files, Scenario Outlines, Examples tables, Background sections, dialect keywords, or step wording. Do not use for behavior clarification before a formal artifact; use behavior-driven-development.
- ▌ Justfiles · nledford bundleCreate, refactor, audit, and explain Justfiles for the just command runner. Use when writing or changing Justfile recipes, variables, parameters, groups, imports/modules, aliases, shells/scripts, safety gates, or project workflow commands. Do not use when only running existing recipes without assessing or changing Justfile design, or for hosted CI/release-provider or Docker/OCI/Compose semantics beyond the Just wrappers that invoke them.
- ▌ API Design · nledfordAPI design and contract guidance. Use when defining, changing, reviewing, or testing service or public interface contracts: HTTP/REST resources, RPC/GraphQL operations, webhooks, event/message schemas, request/response/error envelopes, pagination/filtering/sorting, idempotency, versioning/deprecation/backward compatibility, OpenAPI/AsyncAPI/JSON Schema/protobuf artifacts, SDK or CLI public surfaces, or consumer/provider compatibility. Do not use for ordinary language/framework implementation, Rust handler mechanics, SQL schema/query design, architecture boundary selection, security controls, BDD/TDD mechanics, observability instrumentation, or documentation-only API references after the contract is set; load those existing skills instead or alongside it when their trigger is primary. Use semantic-versioning when the primary question is choosing or applying a patch, minor, or major release bump after contract impact is understood.
- ▌ Git Commit · nledford bundleWrite high-quality git commits and commit messages. Use when the user asks to commit changes, split a working tree into logical commits, improve commit messages, prepare reviewer-friendly new commits, or apply Conventional Commits guidance in any plain git repository. Do not use for amend/fixup/autosquash, branch operations, integration, recovery, push, tags, or worktrees; use git-workflows.
- ▌ Code Review · nledfordPerform repository-local code reviews. Use for requested diff or pull-request audits, final focused review after implementation, or changes that affect behavior, APIs, domain boundaries, tests, security, workflows, dependencies, CI, documentation, or agent instructions. Do not use as the primary workflow for repository-wide technical-debt portfolio audits, implementation, active failure debugging, or design-only threat modeling.
- ▌ Brainstorming · nledfordStructured ideation for ambiguous software engineering work. Use when agents need to generate multiple options, compare tradeoffs, or converge on a recommendation before implementation, architecture, domain modeling, API design, migration, refactor, testing strategy, or debugging choices after systematic reproduction. Do not use for simple mechanical tasks, obvious single-path fixes, or active unexplained symptoms; use systematic-debugging first.
- ▌ Git Workflows · nledford bundleSafe Git branch, remote, history-inspection, integration, rewrite, conflict, recovery, tag, and worktree workflows. Use when switching or restoring, fetching/pulling/pushing, managing upstreams or remotes, inspecting history with log/blame/bisect, merging/rebasing/squashing/cherry-picking/reverting/resetting, resolving conflicts, recovering with reflog, or managing tags and worktrees. Do not use for commit grouping or message drafting, checked-in CI/release automation, code review, GitHub pull-request operations, or release-readiness decisions.
- ▌ Playwright E2e · nledfordPlaywright browser E2E guidance. Use when adding, updating, running, or debugging checked-in Playwright tests, playwright.config files, browser test helpers, targeted test runs, traces, reports, cross-browser projects, or testing browser-visible behavior through checked-in Playwright tests. Do not use for non-browser domain logic, frontend implementation without a durable Playwright artifact, or generic manual browser automation.
- ▌ Rust Async Web · nledford bundleAsync Rust and Rust web/full-stack guidance. Use when working with Tokio, async tasks, cancellation, timeouts, backpressure, channels, shared state, synchronization, Axum handlers/extractors/state/middleware, Leptos components, leptos-use, server functions, SSR/hydration/WASM, or Axum-Leptos full-stack applications. Use rust-desktop-gui for native desktop GUI event-loop integration, api-design for endpoint contracts, observability-engineering for durable telemetry, css-scss-styling for CSS/SCSS/Leptos styling decisions, rust-persistence-sql for SQLx/database work, and rust-testing-quality for test lanes.
- ▌ Domain Modeling · nledfordReview tactical DDD models, aggregates, entities, value objects, invariants, domain services, and ubiquitous language. Use for a focused audit of an existing domain model; do not use to design a new model or force DDD onto simple data-centric work.
- ▌ PHP Engineering · nledford bundlePHP engineering guidance for PHP source, Composer manifests and lockfiles, runtime and extension discovery, PHP 8.4 implementation or migration, PHPUnit/Pest configuration, PHPStan/Psalm, PHP-CS-Fixer/PHP_CodeSniffer, PHP templates, packaging, and project quality commands. Use for ordinary PHP implementation and project mechanics; use php-design-patterns for pattern choice, php-antipatterns for smell-focused review, and php-testing-quality for test-lane work.
- ▌ Security Review · nledfordSecurity review and audit guidance for concrete code, config, docs, and command-surface changes. Use when implemented changes touch authentication, authorization, crypto, certificates, tokens, signatures, secrets, passwords, sessions, session cookies, CORS, CSP, CSRF, OAuth/OIDC/SAML, redirect/callback handling, input validation, file paths, command execution, or other trust boundaries. Pair with code-review for review findings; use threat-modeling for design-time boundary analysis and dependency-supply-chain-review for supply-chain-specific review.
- ▌ SQL Engineering · nledfordDatabase-neutral SQL engineering guidance. Use when reading, writing, refactoring, reviewing, testing, or optimizing SQL queries, schemas, migrations, tables, views, functions, triggers, constraints, indexes, transactions, reporting queries, or data behavior before choosing a database-specific skill. Use api-design when SQL changes affect published contracts, observability-engineering for database telemetry, and PostgreSQL, MySQL/MariaDB, or SQLite skills for engine-specific behavior.
- ▌ Threat Modeling · nledfordThreat modeling and security design analysis. Use when asked to threat model, identify abuse cases, model actors/assets/data flows/trust boundaries, STRIDE, attack trees, attack surface, security requirements, mitigations, assumptions, or residual risk for new features, systems, integrations, APIs, tenants, uploads, plugins, webhooks, command surfaces, or sensitive-data flows. Do not use for ordinary code review, confirmed vulnerability validation, dependency/SBOM/CVE supply-chain review, language implementation, or third-party API docs.
- ▌ Zod Engineering · nledford bundleSelect, add, migrate, review, test, or optimize Zod schemas; parse unknown JSON, form, query, environment, event, or tool data; map Zod errors; or use Zod-to-JSON-Schema and backend interoperability. Do not use for static TypeScript-only work, backend-native validation, public API design, authorization, sanitization, or domain-invariant ownership.
- ▌ CSS Scss Styling · nledford bundleCSS, SCSS/Sass, and Tailwind CSS styling guidance. Use when adding, changing, reviewing, refactoring, adopting, or migrating .css, .scss, .sass, CSS modules, design tokens, cascade layers, container/media queries, responsive layout, stylesheet build pipelines, Tailwind or other utility-class conventions, CSS-in-JS, or styling integration in HTML, JavaScript/TypeScript, PHP/Smarty templates, Python templates, or Rust Leptos/Axum apps. Use ux-accessibility-review for interface accessibility or UX audits. Use language/framework skills for non-styling implementation mechanics and do not use for behavior changes with no styling surface.
- ▌ PHP Antipatterns · nledfordEvidence-backed PHP smell review and refactoring guidance. Use when auditing or refactoring PHP for dynamic properties, magic accessors, weak types, global state, unsafe loading, injection risks, framework leakage, brittle tests, dependency sprawl, or PHP 8.4 migration smells. Do not use for ordinary implementation, pattern selection, or test execution; use php-engineering, php-design-patterns, or php-testing-quality instead.
- ▌ Ruby Engineering · nledfordRuby engineering guidance. Use when creating, changing, reviewing, testing, packaging, or scripting Ruby source, gems, Gemfiles, Bundler, Rake, Minitest, RSpec, Rails-adjacent Ruby, or Ruby CLIs. Do not use merely to choose among scripting languages without Ruby implementation, or for framework-specific behavior whose owning skill is more precise.
- ▌ Rust Code Review · nledfordReview Rust code with Rust-specific rigor. Use with code-review when changes touch Rust ownership, lifetimes, traits, error contracts, crate boundaries, feature flags, tests, Rustdoc, async, Tokio, Axum, Leptos, SQLx, SeaQuery, SeaORM, Diesel, SQLite, unsafe code, macros, FFI, public APIs, design patterns, anti-patterns, or performance-sensitive behavior. Use sql-engineering, postgresql-sql-engineering, mysql-mariadb-sql-engineering, or sqlite-sql-engineering too for database-native schema, SQL, migrations, privileges, or query plans.
- ▌ Rust Desktop Gui · nledford bundleNative Rust desktop GUI guidance. Use when building, changing, testing, debugging, or packaging Windows, macOS, or Linux desktop applications with Iced, egui/eframe, Slint, or Tauri, including event loops, UI-thread work, widgets, themes, accessibility, background work, and native distribution.
- ▌ Rust Engineering · nledfordCore Rust engineering guidance. Use when adding or changing Rust crates, modules, public APIs, domain logic, ownership and lifetime structure, traits, generics, error types, feature flags, workspaces, refactors, design patterns, or declarative/procedural macros. Do not use for checked-in hosted CI/release-provider or Docker/OCI/Compose configuration except the Rust commands they invoke; use ci-release-engineering or container-engineering. Use api-design for public service/SDK/CLI contracts, observability-engineering for telemetry/logging signal design, rust-testing-quality for test and CI lanes, rust-async-web for Tokio/Axum/Leptos work, rust-desktop-gui for native desktop GUI frameworks and delivery, rust-persistence-sql for SQLx, SeaQuery, and database adapter work, and rust-code-review for requested reviews.
- ▌ Testing Strategy · nledfordReview test strategy, confidence gaps, TDD and BDD fit, flaky tests, boundary coverage, and suite maintainability. Use for a risk-focused audit of tests or test plans; do not use to write a single test, debug an active failure, or run a routine TDD loop.
- ▌ Release Readiness · nledfordAssess merge and release readiness across tests, docs, migrations, rollout, rollback, operations, and cross-functional risk. Use for a final ship or hold decision; do not use to choose a semantic patch, minor, or major version, or as the primary implementation, code-review, or deployment workflow.
- ▌ Rust Antipatterns · nledfordRust anti-pattern detection and correction guidance. Use when reviewing or refactoring Rust code for generated-code smells, borrow-checker workarounds, unnecessary clones, Arc<Mutex> misuse, boxed indirection, deref polymorphism, deny-warnings misuse, panic/unwrap at boundaries, async overuse, leaky framework or SQL types, brittle tests, or architecture boundary violations. Do not use for ordinary Rust implementation; use rust-engineering instead.
- ▌ Adversarial Review · nledfordSkeptically verify completed changes, agent work, merge readiness, and hidden regressions. Use after implementation when claims need independent proof; do not use as the primary implementation or ordinary code-review workflow.
- ▌ Clean Architecture · nledfordClean Architecture guidance centered on the dependency rule, entities, use cases/interactors, and interface adapters that keep business policy independent from frameworks, databases, and UI. Use when the main design question is how policy flows through use cases and adapter boundaries. Use hexagonal-architecture when named inbound/outbound ports around external actors are the main concern, onion-architecture when explicit concentric domain/application rings are the requested model, and architecture-review for a read-only audit. Do not use for simple CRUD, prototypes, or framework-convention-first apps where added layers reduce clarity.
- ▌ Create Agent Skill · nledfordCreate or improve reusable agent skills. Use when the user asks to create a new skill, update an existing skill, define skill instructions, scaffold a SKILL.md-based skill directory, validate skill structure, or turn repeated agent workflows into a global or project skill. Do not use for ordinary documentation edits, application implementation, or ignored third-party runtime skills.
- ▌ Hound Web Research · nledford bundleUse the Hound MCP server for public web research, source discovery, URL or PDF retrieval, bounded same-domain crawling, OCR, and evidence capture with smart_search, smart_fetch, smart_crawl, screenshot, cache_clear, or version. Use when current external evidence is needed. Do not use for repository-local facts, structured GitHub platform objects, signed-in browser interaction, checked-in Playwright tests, private or sensitive resources, or Hound installation and upgrades unless explicitly requested.
- ▌ Onion Architecture · nledfordOnion Architecture guidance centered on explicit concentric domain, application, and infrastructure rings with dependencies pointing inward. Use when the main design question is ring membership, domain/application separation, or keeping infrastructure at the edge, especially when the project names Onion Architecture. Use hexagonal-architecture when inbound/outbound ports around external actors are primary, clean-architecture for use-case/interactor and interface-adapter policy flow, and architecture-review for a read-only audit. Do not use for simple CRUD, prototypes, or framework-convention-first apps where added layers reduce clarity.
- ▌ Performance Review · nledfordReview performance and scalability using workload, baseline, profiling, query-plan, rendering, concurrency, and resource evidence. Use for bottleneck audits, benchmark plans, capacity risks, or performance-sensitive changes; do not use for active unexplained regressions or implementation mechanics alone.
- ▌ Python Engineering · nledford bundlePython engineering guidance with uv. Use when adding, changing, reviewing, testing, packaging, linting, formatting, typing, dependency-managing, or refactoring Python code, pyproject.toml, uv.lock, pytest/unittest tests, Python scripts, Python web templates, or Python project workflows. Do not use as the primary skill for distributed PySpark SQL/DataFrame execution, execution plans, shuffles, Structured Streaming, or notebook/cluster lifecycle; use data-platform-engineering. Do not use as the primary skill for smell-focused Python audits; use python-antipatterns. Do not use for checked-in hosted CI/release-provider or Docker/OCI/Compose configuration except the Python commands they invoke; use ci-release-engineering or container-engineering. Use api-design for public service/SDK/CLI contracts, observability-engineering for telemetry/logging signal design, and css-scss-styling for CSS/SCSS/template styling decisions.
- ▌ Script Engineering · nledfordScript and automation engineering guidance. Use when creating, changing, reviewing, or testing POSIX shell, Bash, zsh, Fish, PowerShell, Python, Ruby, PHP, Node, or other repository scripts; choosing a scripting language or interpreter; deciding whether automation belongs in a script or shell; or exposing script workflows through Just or package scripts. Do not use when only running an existing script or recipe, for ordinary application code with no automation surface, or for hosted CI/release-provider or container semantics beyond the commands scripts invoke.
- ▌ Architecture Review · nledfordReview architectural boundaries, dependency direction, ports and adapters, Clean/Onion/Hexagonal/DDD hybrids, and modular monolith structure. Use for architecture-focused audits of existing systems or changes; do not use for ordinary implementation or architecture design without a review request.
- ▌ PHP Design Patterns · nledfordPHP-native design-pattern guidance. Use when choosing or reviewing value objects, readonly DTOs, enums, factories, interfaces, dependency injection, adapters, repositories, application services, presenters, middleware, property hooks, or resource ownership in PHP. Do not use for ordinary PHP implementation, test-lane execution, or smell-focused review; use php-engineering, php-testing-quality, or php-antipatterns instead.
- ▌ PHP Testing Quality · nledfordPHP testing and quality-lane guidance. Use when selecting, adding, running, or reviewing PHPUnit, Pest, Behat, PHPStan, Psalm, PHP_CodeSniffer, PHP-CS-Fixer, Infection, framework harnesses, PHP integration tests, browser E2E tests, or PHP 8.4 compatibility tests. Do not use for ordinary PHP implementation, pattern choice, or smell-only review; use php-engineering, php-design-patterns, or php-antipatterns instead.
- ▌ Python Antipatterns · nledfordPython anti-pattern detection and correction guidance. Use when reviewing or refactoring generated or hand-written Python for mutable defaults, global state, import-time side effects, broad Any or dict-shaped data, broad exception handling, monkeypatch-heavy tests, Pydantic/ORM/framework leakage, async blocking, resource leaks, dependency sprawl, brittle tests, or architecture boundary violations. Do not use for ordinary Python implementation or workflow, or for positive pattern selection.
- ▌ Root Cause Analysis · nledfordStructured root-cause analysis for recurring failures, incidents, regressions, systemic process gaps, and postmortem-style prevention work. Use after the direct cause of a current symptom is understood; use systematic-debugging first for active failing tests, crashes, or unknown immediate causes.
- ▌ Semantic Versioning · nledfordDetermine, recommend, review, or apply Semantic Versioning changes. Use when deciding whether a release needs a patch, minor, or major bump; calculating the next version; auditing changes since the last release; handling 0.x, 1.0.0, prerelease, deprecation, dependency, or mixed-change cases; or updating version metadata after the bump is chosen. Do not use as the primary skill for designing an API contract, changing checked-in release automation, creating Git tags, publishing artifacts, or making the final ship-or-hold decision.
- ▌ Domain Driven Design · nledfordApply Domain-Driven Design to complex business logic and module boundaries. Use when modeling domains, bounded contexts, aggregates, value objects, repositories, domain services, policies, domain events, ubiquitous language, or refactoring toward clearer domain behavior. Do not use for focused audits of an existing domain model; use domain-modeling. Avoid simple CRUD or data-centric work without meaningful domain pressure.
- ▌ Gossamer Engineering · nledfordGossamer `.gos`, `gos`, `project.toml`, and `project.lock` engineering guidance. Use for existing Gossamer repositories and explicitly requested bounded Gossamer evaluation/proof work: implementation, review, testing, build, package, deployment, Rust bindings, goroutines, or targets. Do not use for generic language/toolchain selection before Gossamer is selected, including standalone Wasm requirements, or for the unrelated ChainSafe Go project named Gossamer.
- ▌ Rust Design Patterns · nledfordRust design pattern and idiom guidance. Use when choosing, implementing, or reviewing Rust patterns such as newtypes, builders, RAII guards, traits, strategy, visitor, command, compose-structs, small crates, contained unsafe modules, custom traits for complex bounds, macros, or ownership-driven API design. Use rust-antipatterns for smell-focused audits and load rust-engineering whenever applying or implementing a pattern.
- ▌ Rust Persistence SQL · nledfordRust persistence, SQLx, SeaQuery, and SQL-library guidance. Use when adding, changing, reviewing, or testing SQLx queries/macros, SeaQuery builders, SeaORM, Diesel, raw SQL choices, Rust database adapters, pools, transactions, offline query metadata, migrations invoked from Rust, SQLite support, database-backed Rust tests, dynamic SQL construction, or persistence boundaries. Use sql-engineering, postgresql-sql-engineering, mysql-mariadb-sql-engineering, or sqlite-sql-engineering for database-native design.
- ▌ Rust Testing Quality · nledfordRust testing and quality-gate guidance. Use when writing, updating, running, filtering, or reporting Rust unit, integration, end-to-end, property-style, compile-fail, or Rustdoc tests; when applying TDD or BDD to Rust changes; or when using cargo fmt, cargo check, cargo test, cargo test --doc, cargo clippy, cargo-nextest, Bacon/bacon.toml feedback loops, and CI-oriented Rust validation. Do not use for checked-in hosted CI/release-provider configuration except the Rust commands and test lanes it invokes; use ci-release-engineering.
- ▌ Suggest Lucide Icons · nledfordPick real Lucide icons for a concept, UI placement, button, section header, or note frontmatter. Use when the user asks what Lucide icon to use, requests icon candidates, or needs an icon name verified. Do not use for non-Lucide icon libraries or general icon or artwork design.
- ▌ Systematic Debugging · nledford bundleEvidence-driven debugging for active bugs, failing tests, runtime exceptions, flaky behavior, performance regressions, build/lint/type/compile failures, integration failures, crashes, and unexpected behavior. Use before proposing fixes for a current symptom. Use root-cause-analysis for recurring incidents, systemic failures, and postmortem-style prevention work.
- ▌ Technical Debt Audit · nledfordPerform repository-wide or focused technical-debt audits covering maintainability, complexity, duplication, dependency health, testing gaps, architecture erosion, documentation drift, and remediation priorities. Use when the user asks to assess accumulated debt, modernization risk, change friction, quick wins, or blockers to future work or scaling. Do not use for an ordinary diff review, an active unexplained failure, implementation, or a vulnerability-only audit.
- ▌ Container Engineering · nledfordImplement, change, review, or test Dockerfile, Containerfile, .dockerignore, BuildKit/OCI image, and Docker Compose configuration, including build contexts and stages, caches, runtime users, entrypoints, health checks, ports, networks, volumes, secrets, lifecycle, and resource or privilege controls. Do not use for routine command execution or log inspection, Kubernetes/Helm/ECS/Nomad/cloud deployment, application-only changes, supply-chain-only or security-review-only audits, hosted CI pipelines, final ship decisions, or unexplained container failures.
- ▌ CI Release Engineering · nledfordImplement, change, review, or test checked-in CI and release provider configuration, including workflow triggers, job graphs, matrices, caches, artifacts, permissions, concurrency, environments, automated versioning, tags, releases, and package or binary publication. Do not use to choose a semantic patch, minor, or major bump from application changes; use semantic-versioning. Do not use for underlying language/test commands, Justfile wrappers, manual Git operations, final ship/hold decisions, unexplained CI failures, supply-chain-only or security-review-only audits, or production deployment infrastructure implementation.
- ▌ Hexagonal Architecture · nledfordHexagonal Architecture / Ports and Adapters guidance centered on how external actors drive or are driven by an application through explicit inbound and outbound ports and adapters. Use when classifying port ownership, replacing delivery or infrastructure mechanisms, or testing the core through those seams. Use clean-architecture when entities, use cases/interactors, and interface-adapter policy flow are primary, onion-architecture for explicit concentric domain/application rings, and architecture-review for a read-only audit. Do not use for simple CRUD, prototypes, or trivial pass-through interfaces.
- ▌ MCP Server Engineering · nledford bundleMCP server engineering guidance. Use when creating, updating, refactoring, testing, or reviewing Model Context Protocol servers, tools, resources, prompts, capability discovery, stdio transport, Streamable HTTP, or legacy HTTP+SSE compatibility. Do not use merely to operate an existing MCP server; use the applicable provider or service skill instead.
- ▌ Powershell Engineering · nledfordCross-platform PowerShell engineering guidance. Use when creating, changing, reviewing, or testing `.ps1`, `.psm1`, or `.psd1` files, PowerShell functions/modules, Pester tests, PSScriptAnalyzer configuration, native-command orchestration, or Windows/macOS/Linux PowerShell automation. Do not use merely to run an existing PowerShell command or for generic script-language selection with no PowerShell implementation.
- ▌ Python Design Patterns · nledfordPython design pattern guidance. Use when choosing, implementing, or reviewing idiomatic Python patterns such as dataclasses, value objects, protocols, context managers, dependency injection, adapters, repositories, factories, CLI/service boundaries, async resource handling, pytest fixtures, or Clean/Hexagonal/Onion expression in Python. Use python-antipatterns for smell-focused audits and python-engineering for broader Python workflow.
- ▌ Sqlite SQL Engineering · nledfordSQLite and SQL engineering guidance. Use with sql-engineering when adding, changing, reviewing, testing, or optimizing SQLite schemas, migrations, constraints, indexes, transactions, query behavior, local/embedded database workflows, SQLite-backed tests, or SQLite-specific adapter boundaries in any language stack. Do not use for unchanged-SQL ORM or generic adapter mechanics. Use api-design when SQLite schemas or exports affect published contracts and observability-engineering for durable SQLite diagnostics.
- ▌ Parallelism Engineering · nledfordDesign and implement cross-language CPU-bound, data-parallel, and task-parallel computation. Use when decomposing a measured workload into partitions or tasks; selecting granularity, executors or worker pools, reductions, cancellation, failure handling, or deterministic concurrency tests. Do not use for routine async I/O, distributed coordination, Spark, GPU programming, or review-only performance work.
- ▌ Random Data Identifiers · nledfordRandomness, generated identifiers, random words, sentences, passphrases, synthetic text, and test data guidance. Use when generating random numbers, UUIDs, CUIDs, ULIDs, nonces, tokens, filenames, fixture data, reproducible seeded simulations, human-readable synthetic content, or collision-resistant IDs in code or tests. Prefer cryptographically secure randomness for secrets, passphrases, security-sensitive IDs, and public IDs that must be unguessable; use explicit seeded PRNGs for reproducible tests and simulations. Do not use for fixed examples with no randomness, copyediting fixed text, or database-native ID/index design without a generated-value decision.
- ▌ Test Driven Development · nledfordApply Test-Driven Development to implementation and bug fixes. Use when adding or changing behavior, fixing defects, writing regression tests, choosing test levels during implementation, or using Red-Green-Refactor to guide autonomous coding work. Do not use for risk-focused reviews of an existing test suite or plan; use testing-strategy.
- ▌ UX Accessibility Review · nledfordReview UI and UX quality, visual polish, responsive behavior, interaction states, and WCAG accessibility. Use for focused interface audits of existing products or changes; do not use as the primary styling, frontend implementation, or browser-test workflow.
- ▌ Webassembly Engineering · nledford bundleWebAssembly engineering guidance for Wasm/WAT modules, WASI, WIT and the Component Model, host/guest contracts, runtime and target selection, capability grants, memory/ABI/serialization, lifecycle/errors, testing, packaging, and deployment. Use when a WebAssembly artifact, host embedding, runtime, component, or WASI boundary is being designed, changed, tested, reviewed, packaged, or deployed. Do not use for source-language/compiler mechanics, generic dependency work without a Wasm boundary, or a product comparison without repository and current-doc evidence.
- ▌ Digital Asset Management · nledford bundleDigital asset management (DAM) engineering guidance for photo and video ingest, asset identity, immutable originals, derivatives, metadata, non-destructive edits, organization, smart collections, hierarchies, viewing, sharing, and validation. Use when building, changing, reviewing, or testing a photo/video catalog, media library, asset browser, editing workflow, or related API and data model. Do not use for standalone codec implementation, generic SQL/API/CSS work, or non-media document management without a DAM lifecycle.
- ▌ Security Review Evidence · nledfordCompanion evidence checklist for security-sensitive changes and reviews. Use only with security-review, threat-modeling, or dependency-supply-chain-review to keep evidence sanitized, scoped, and tied to repository policy. Do not use as standalone security analysis.
- ▌ Csharp Dotnet Engineering · nledfordC# and .NET engineering guidance. Use when adding, changing, reviewing, testing, packaging, restoring, building, publishing, or refactoring C# source, SDK-style .csproj projects, Directory.Build.props/targets, global.json, .sln/.slnx solutions, MSBuild, NuGet PackageReference, ASP.NET Core, Blazor, EF Core, or .NET test projects. Do not use for database-native schema/query design, general WebAssembly host/guest/runtime decisions, checked-in CI/release-provider configuration, Docker/OCI/Compose configuration, or a public API contract; use the owning SQL, WebAssembly, CI/release, container, or API skill instead.
- ▌ Data Platform Engineering · nledford bundleData-platform engineering guidance for implementing, changing, reviewing, or testing source-to-landing ingestion, post-landing lakehouse or warehouse transformations, analytical semantic contracts, Power BI semantic models and DAX, and Microsoft Fabric or Power BI operations. Use for CDC, watermarks, replay, Delta tables, medallion layers, analytical grain, governed metrics, TMDL, RLS or OLS, refresh, promotion, gateways, capacity, recovery, and runbooks. Do not use for application domain modeling, physical OLTP database design, generic distributed protocols, generic UX, or final release decisions.
- ▌ Documentation Engineering · nledfordDocumentation engineering guidance. Use when creating, editing, refactoring, or reviewing Markdown docs, README files, API docs, code comments, docstrings, examples, Rustdoc, pydoc, Javadoc, JSDoc/TSDoc, PHPDoc, perldoc/POD, documentation tests, or developer-facing instructions. Do not use for code-only changes unless docs or comments are part of the change. For reusable SKILL.md contracts, use create-agent-skill.
- ▌ Observability Engineering · nledfordObservability, telemetry, and production diagnostics guidance. Use when designing, adding, reviewing, or testing structured logs, metrics, traces, span/context propagation, correlation or request IDs, sampling, labels/cardinality, dashboards, alerts, SLO/SLI/error-budget signals, OpenTelemetry/Prometheus/Grafana/Datadog-style instrumentation, operational runbooks, or incident visibility. Do not use for ordinary language implementation, active debugging without durable instrumentation changes, security review except telemetry leakage or audit controls, BDD/TDD mechanics, or documentation-only edits; load those existing skills instead or alongside this skill when their trigger is primary.
- ▌ Piwigo Plugin Engineering · nledfordPiwigo plugin integration guidance. Use when working on Piwigo plugins, main.inc.php, maintain.inc.php, plugin admin pages, Smarty .tpl files, Piwigo events/actions, language catalogs, plugin upgrades, or plugin-owned PHP, HTML, CSS, JavaScript, or TypeScript. Do not use for generic PHP, frontend, localization, SQL, security, or browser-test mechanics outside a Piwigo host integration; load the owning skill with this one.
- ▌ Prompt Engineering Review · nledfordReview and improve prompts and bounded agent-system instruction interfaces for coding agents. Use for prompt audits, rewrites, multi-agent roles, delegation and handoff contracts, acceptance criteria, and quality gates; do not use for application implementation, runtime architecture audits, or reusable SKILL.md authoring.
- ▌ Postgresql SQL Engineering · nledfordPostgreSQL and SQL engineering guidance. Use with sql-engineering when adding, changing, reviewing, testing, or optimizing PostgreSQL schemas, SQL queries, migrations, transactions, constraints, indexes, views, functions, row-level security, privileges, data behavior, or database performance in any language stack. Do not use for unchanged-SQL ORM or adapter mechanics. Use api-design when migrations or query outputs affect published contracts and observability-engineering for PostgreSQL telemetry signals.
- ▌ Behavior Driven Development · nledfordApply Behavior-Driven Development to clarify user-visible behavior, acceptance criteria, business workflows, and executable examples before or during implementation. Do not use to author formal .feature syntax; use gherkin.
- ▌ Review Verification Protocol · nledfordMandatory evidence gates for review findings. Load with code-review and any specialist review skill before reporting findings, or read/apply manually if the runtime hides this skill.
- ▌ Svelte Sveltekit Engineering · nledford bundleSvelte and SvelteKit engineering guidance. Use when adding, changing, reviewing, or testing .svelte components, Svelte 5 runes, stores, context, SvelteKit routing, load functions, form actions, hooks, adapters, or deciding between standalone Svelte and full SvelteKit. Use javascript-typescript-engineering for generic JS/TS package/build/test mechanics, css-scss-styling for stylesheet and Tailwind decisions, api-design for backend contract shape, and ux-accessibility-review for accessibility audits. Do not use for non-Svelte frontend frameworks.
- ▌ Mysql Mariadb SQL Engineering · nledfordMySQL and MariaDB SQL engineering guidance. Use with sql-engineering when adding, changing, reviewing, testing, or optimizing MySQL or MariaDB schemas, SQL queries, migrations, transactions, constraints, indexes, views, stored routines, replication, privileges, storage engines, connection pooling, or query performance in any language stack. Explicitly name which engine and version a change targets when MySQL and MariaDB diverge. Do not use for unchanged-SQL ORM or adapter mechanics. Use api-design when migrations or query outputs affect published contracts and observability-engineering for MySQL/MariaDB telemetry signals.
- ▌ Dependency Supply Chain Review · nledfordDependency and software supply-chain security review. Use for dependency audits, SBOM/SCA output, CVE/GHSA advisories, package or binary provenance, registry trust, manifests, lockfiles, checksums/signatures, install/postinstall scripts, vendored/generated code, transitive dependency risk, CI actions, container or base-image pinning, or package-manager security policy. Do not use for routine package-manager workflow, language-specific dependency implementation, or third-party API docs without a supply-chain risk question.
- ▌ Internationalization Localization · nledfordInternationalization and localization guidance, including Project Fluent and Fluent Translation List (.ftl) files. Use when adding, changing, reviewing, or testing localized, multilingual, or localization-ready user-facing text, locale negotiation, translation catalogs, plural/select behavior, localized date/number formatting, or Fluent integrations in JavaScript, TypeScript, PHP, Python, Rust, or web UI. Do not use for fixed-language copyediting with no localization surface. Consult current official documentation for Fluent binding APIs and use security-review plus security-review-evidence when localized content crosses trust boundaries.
- ▌ Javascript Typescript Engineering · nledfordJavaScript and TypeScript engineering guidance. Use when adding, changing, reviewing, testing, linting, formatting, dependency-managing, packaging, or refactoring JS/TS source, package.json scripts, lockfiles, workspaces, CLIs, Node/npm, Bun, Deno, pnpm, or Yarn workflows, or project automation. Do not use for checked-in hosted CI/release-provider or Docker/OCI/Compose configuration except the JS/TS commands they invoke; use ci-release-engineering or container-engineering. Use api-design for public service/SDK/CLI contracts, observability-engineering for telemetry/logging signal design, css-scss-styling for CSS/SCSS/CSS-module/CSS-in-JS/utility styling decisions, and svelte-sveltekit-engineering for Svelte/SvelteKit component, routing, and reactivity decisions. Do not use for checked-in Playwright test design; use playwright-e2e.
- ▌ Typescript Javascript Antipatterns · nledfordTypeScript and JavaScript anti-pattern detection and correction guidance. Use when reviewing or refactoring generated or hand-written JS/TS for any, unsafe assertions, missing runtime validation, unawaited promises, framework or UI leakage, singleton service bags, import-time side effects, Math.random misuse, over-mocked tests, brittle E2E tests, dependency sprawl, or architecture boundary violations.
- ▌ Typescript Javascript Design Patterns · nledfordTypeScript and JavaScript design pattern guidance. Use when choosing, implementing, or reviewing patterns such as discriminated unions, branded types, schema validation boundaries, functional core/imperative shell, adapter modules, command/use-case handlers, dependency injection, async orchestration, module boundaries, test builders, or Clean/Hexagonal/Onion expression in JS/TS. Use typescript-javascript-antipatterns for smell-focused audits.