konoka

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.

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.

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.

himari is ncaq's rio-like custom Haskell Prelude. Import it with a single `import Himari`, never `import Himari.Prelude` or other submodules directly. Use when writing or reviewing Haskell code in a project that depends on the himari package.

Prefer the most specific built-in method over general-purpose ones in TypeScript/JavaScript. Use includes over indexOf, some over filter().length, find over filter()[0], flatMap over map().flat(), at(-1) over length-based access, startsWith/endsWith/includes over indexOf on strings, structuredClone over JSON round-trip. Use when writing or reviewing code that searches, tests, transforms arrays, objects, or strings.

Avoid for loops (C-style, for...of, for...in) in TypeScript/JavaScript. Prefer higher-order Array methods like map, filter, find, some, every, reduce. Use when writing or reviewing loops or iteration over arrays, objects, Map, Set, or String.

Variable naming conventions for TypeScript/JavaScript. Prefer camelCase even for constants and avoid UPPER_SNAKE_CASE. Use when naming or reviewing variables or constants.

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

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

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.

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.

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

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 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.

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.

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.

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.

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

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.

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.

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.

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.

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