菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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.
| name | exception |
| description | 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. |
| user-invocable | false |
error関数の禁止純粋関数空間の中で例外を投げられるerror関数の使用は原則として禁止です。
haskell-tasuke:partial-function でも触れましたが、 純粋関数空間で例外を投げてしまうと、 呼び出し側で捕捉するのが困難だからです。
また例外に入っているのがStringという非構造化されたデータであると、
デバッグが難しくなります。
throw(導入されている場合は非純粋であることを明示したimpureThrow)の方が、
例外に型がついているという点ではまだマシですが、
こちらも純粋関数空間で例外を投げているのは同じなのでやはり推奨されません。
呼び出し側にMonadThrowやEitherなどを使ってエラー情報を伝播させてください。
論理的にどう考えても発生しないはずの場所なら許容されます。
そんなおかしなことが起きているなら、 アプリケーション自体を終了させるのが適切なレベルの話です。
それでもなるべく型を作って例外を投げるのが望ましいです。
undefinedはPRを出すときにはクリーンアップしましょうHaskell標準で用意されているundefinedは、
開発中に仮の実装として使うのは便利です。
Rustのtodo!と同じように使えます。
例えばテストファーストで開発をする時に、
とりあえずコンパイルを通すだけの関数シンボルをundefinedで埋めて、
テストコードを書いてから実装を進めるといった使い方ができます。
しかしundefinedは結局は純粋空間でも例外を投げる関数なので、
PRを出すときにはundefinedをクリーンアップしてください。
残っていると警告が出るはずなので見落としはあまりないとは思いますが。
throwStringのような関数を使うより、
ちゃんと例外に型をつけてthrowMなどで型がついた例外を使いましょう。
例外の状況を伝えるデータ型は、
Textなどの文字列型を使うのではなく、
なるべく構造的なデータ型をフィールドとして持ってください。
ただしcycle importが発生する場合は、
呼び出し側でTextに変換するのもやむを得ないでしょう。
IOの文脈などで例外が生じた場合に、
単に握りつぶして何もしない行為は禁止です。
IOは文脈的に既に例外が発生する可能性があることを示しているので、
例外が上位に伝播することは許容されています。
なので握りつぶすぐらいなら、
例外をそのまま上位に任せてしまう方が概ね適切です。
例外が生じた時に、 そこで例外を処理するのが完全に適切なら、 問題の程度に応じたログを出して処理してください。
単にデバッグを楽にするだけで解決は出来ない場合は例外を再送出してください。
例外だけではなくEitherのLeftなども適切に処理してください。
Leftに対してデフォルト値やフォールバック値を使ってください。
想定外で対処不能ならMonadThrowの文脈に載せて上位に任せてください。
IOが既にコンテキストにある状態でMaybeやEitherで包むのは微妙IOは例外が発生する可能性がある文脈を十分に表現しているモナドなので、
その中でMaybeやEitherを使って例外的な状況を示すのは二重にネストしていて混乱を招きます。
素直に例外を投げてしまうのが良いでしょう。
基底モナドなどでIO的な操作をしているがIOそのものではないモナドの場合は、
MonadThrowやMonadIOの型クラスが役に立ちます。
データベースやネットワークと通信してデータを取得するような操作は、 存在しないというケースが頻繁に発生する正常系として扱われます。
その場合はIO (Maybe a)のようなシグネチャを使うことは分かり易く適切です。