菜单
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.
用 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 | test |
| description | 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. |
| user-invocable | false |
テストは仕様を表すものであり、実装の正しさを検証するためのものです。 そのためテストコードを変更する時は、 そのテストが何を保証していて、変更後にも同じ保証が維持されるかを意識してください。
実装にバグがあってテストが失敗している場合は、実装側を修正してください。 「実装の出力に合わせて期待値を書き換える」のは、 テストの意味を失わせる典型的な変更で禁止です。
特に以下のような変更は明確に禁止します。
assert(true)や1 == 1のような恒真式に置き換えてテストを通す判断に迷う場合はユーザーに確認してください。 特にテストの期待値を変更する時は、 仕様の理解が合っているかを事前に確認するのが安全です。
以下のような場合はテストの変更が妥当です。 変更する時は、なぜその変更が正しいのかをコミットメッセージや差分の説明で明確にしてください。
アーキテクチャ変更の際は、 旧テストをそのまま無理に通そうとすると、リファクタリングそのものが歪むことがあります。 新しい構造に合ったテストへ書き直す方が健全な場合は、書き直して構いません。 ただし以下を意識してください。
実装コードがテストで使用されている具体的なデータ値を特別扱いすることは禁止です。 具体的なデータ値とは、テストで使われる変数名やテーブル名などのことです。
データに依存した実装は以下のような問題を引き起こします。