Claude Skills by ncaq

Commit message style guidelines. Use when writing or proposing git commit messages, including direct git commit commands outside the /commit skill.

Generate a commit message from staged changes and let the user review before committing. Use when the user wants to commit changes or create a git commit.

Use bracket or with-style functions to guarantee resource cleanup even on exceptions instead of separate do blocks. Use when writing or reviewing Haskell code that acquires and releases resources.

Update Cabal project index-state to the latest timestamp. Use when it needs to bump the cabal index-state.

Use cabal with --disable-optimization for development builds and tests, and add --enable-tests to avoid rebuilds. Use when running or suggesting cabal build or test commands in Haskell development.

Prefer the convert function from the convertible library over individual conversion functions like pack, unpack, decodeUtf8, and encodeUtf8. Use when writing or reviewing Haskell code that converts between types.

Do not throw exceptions from pure code with error or throw, give exceptions structured types, and never silently swallow errors in IO. Use when writing or reviewing Haskell error handling, exceptions, or IO code.

Explicitly enumerate Haskell module exports instead of exporting everything implicitly, and use re-export sparingly. Use when writing or reviewing Haskell module export lists.

Do not discard a function's final value with return (), pure (), or void; adjust the type to return the value and let the caller discard it when unneeded. Use when writing or reviewing Haskell functions that return unit or discard results.

Prefer MonadIO and MonadUnliftIO type classes over using IO directly, and avoid redundant liftIO. Use when writing or reviewing Haskell IO actions, monad transformers, or type class abstractions.

Haskell language extension and language edition (GHC2024/GHC2021) selection policy. Use when configuring or reviewing Haskell language extensions, cabal default-extensions, or default-language.

Use the lens library, generating accessors with makeFieldsId for NoFieldSelectors records, export accessors together with their type classes, and prefer lens or OverloadedRecordDot over pattern matching. Use when writing or reviewing Haskell code that uses lens, records, or field access.

Avoid mutable variables like IORef, STRef, and ST in Haskell and prefer immutable records. Use STM variables such as TVar for thread communication. Use when writing or reviewing Haskell code that uses mutable state or concurrency.

Avoid partial functions such as head, fromJust, read, and (!!) in Haskell. Prefer total functions, Maybe-returning variants, and other safe alternatives. Use when writing or reviewing Haskell code that accesses lists, parses strings, or handles Maybe.

Prefer Text over String for text data, and use ByteString for binary or non-Unicode data. Use when writing or reviewing Haskell code that handles strings, text, or byte data.

Distinguish mkName and newName in Template Haskell. Use mkName to capture existing names and newName for fresh non-colliding names. Use when writing or reviewing Template Haskell code that generates names.

When testing Either values, compare the value directly with shouldBe instead of checking isLeft, so test failures show the actual value. Use when writing or reviewing Haskell test code that asserts on Either or similar values.

Name Haskell test modules after the module under test with a Spec suffix in the same namespace. Use when writing or reviewing Haskell test module names or test file organization.

Avoid overusing threadDelay because time-dependent code is unstable and unportable. Prefer synchronization variables like TMVar or retry combinators. Use when writing or reviewing Haskell code that delays threads, waits, or polls.

Forbid unsafe Haskell functions such as unsafePerformIO, unsafeCoerce, and other unsafe-prefixed functions. Use when writing or reviewing Haskell code that uses any unsafe-prefixed function.

Do not disable GHC or hlint warnings. Suppress them only per module with OPTIONS_GHC or annotations for justified exceptions. Use when writing or reviewing Haskell code, cabal files, or hlint configuration that disables warnings.

Code review for PRs or local changes. Covers code quality, dependency updates, performance, test coverage, documentation accuracy, and security. Use when reviewing PRs, checking code quality, or running comprehensive code reviews.

Nix naming conventions for files, variables, packages, and NixOS options based on nixpkgs official coding standards. Use when writing or reviewing Nix code.

Nix CLI command guidelines. Use new unified CLI (nix subcommand) instead of legacy commands (nix-build, nix-env, nix-shell, etc.). Use when running or suggesting Nix commands.

nix-fast-build command reference. Parallel Nix evaluation and build tool using nix-eval-jobs. Use when running or configuring nix-fast-build.

treefmt-nix and nix fmt guide. Unified formatting and linting with treefmt. Use when configuring or running nix fmt, treefmt, or adding formatters/linters to a Nix project.

Nix writer functions (writeShellApplication, writeText, etc.) for generating scripts, text files, and data. Use when creating derivations that produce scripts or configuration files.

Pull request style guidelines covering title, body, assignee, and label selection. Use when writing or proposing GitHub pull requests, including direct `gh pr create` invocations outside the /pr skill.

Generate a GitHub pull request title and body from the current branch and let the user review before creation. Use when the user wants to create a pull request.

Guidelines for shell commands. Avoid `cat`, `find`, `grep`, `head`, and `tail`; prohibit `rm` (use `trash` instead). Use when invoking shell commands via Bash.

Prefer left-to-right ascending comparisons with less-than operators over greater-than operators, so values read in number-line order. Use when writing or reviewing comparison or range-check expressions.

How to access GitHub. Avoid direct URL fetches; prefer GitHub MCP tools or the `gh` CLI subcommands. Use when fetching GitHub information or operating on issues, pull requests, or workflows.

General naming rules across programming languages. Avoid meaningless words like `common` or `util`, and prefer singular base forms. Use when creating or reviewing names of files, directories, modules, functions, or variables.

Test code conventions. Modify tests only for genuine spec or architecture changes—never trivialize, skip, or align expected values to a buggy implementation. Avoid implementation branches that depend on specific test data values. Use when writing or modifying test code, or when tests are failing.

When handling errors locally instead of propagating them, include the error data in logs or messages. Never discard caught errors with `_`. Use when writing try/catch, Result handling, or error case branches.

Fix typos, grammar, readability, and notation consistency in Japanese text. Use when the user wants to proofread or edit Japanese text.

Investigate any topic by querying multiple external sources (web, official docs, GitHub, MCP servers). Use whenever a question requires information not already in the working context, including library behavior, API specifications, error diagnostics, version comparisons, or general factual lookup.

Avoid using any type in TypeScript. Use unknown, generics, or proper type definitions instead. Use when writing or reviewing TypeScript type annotations.

WAI-ARIA usage guidelines. Avoid redundant ARIA attributes. No ARIA is better than Bad ARIA. Use when writing or reviewing HTML/JSX with accessibility attributes.

Use `as const` and `as const satisfies Type` for constant definitions in TypeScript. Use when defining constants, config objects, or string union types.

Avoid contradictory state types for async data fetching. Use Suspense or discriminated unions instead. Use when writing or reviewing async data fetching code in React/TypeScript.

Prefer static import over dynamic import() in TypeScript/JavaScript. Use when writing or reviewing import statements.

File and directory naming conventions for TypeScript/JavaScript projects. Use when creating new files or directories.

Do not use non-null assertion operator (!) in TypeScript. Use optional chaining, type guards, or nullish checks instead. Use when writing or reviewing TypeScript code.

Prefer undefined over null in TypeScript/JavaScript. Use == null for nullish checks. Use when writing or reviewing code that handles absent values.

React component file conventions covering structure ordering, one-component-per-file, and splitting bloated components. Use when writing or reviewing React components.

Refactor React components to follow project conventions. Use when reorganizing, splitting, or cleaning up existing React component files.

Rules for useEffect usage in React including when to avoid it and when to extract it into custom hooks. Use when writing or reviewing React components that contain or might need useEffect.

Avoid unnecessary useRef in React. Prefer HTML standard features, declarative libraries, state, or custom hooks. Use when writing or reviewing React components.

Use semantic HTML elements instead of div. Use when writing or reviewing JSX/HTML markup in React or web components.