Menu
コードの実装・修正・リファクタリングを行うすべての作業で必ず使う skill。書き始める前に「正しい置き場所」「既存の同種実装」「本質的な解決策」を確認し、フォールバック、ハードコード、スタブ、名前文字列による分岐、指示されていない互換レイヤーといった対症療法を検知して排除する。責務分離、命名、ファイル分割、破壊的変更の要否など設計判断にも使う。read-only の調査・説明だけで完結するときは使わない。
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
日本語の応答を、明瞭・簡潔・LLM 口調なしで書くための規範。会話、説明、提案、相談のすべてで適用する。
説明的な文章に緩急を設計するための規範。緩急を装飾ではなく認知モードの切替（観察→逡巡→断定→再観察）と未回収の緊張の管理として扱い、文の拍、段落の密度波形、節の入り方、緩みと駄文の判別、執筆後の機械的な点検手順を定める。読み物として読ませたい章・記事・解説文を生成するとき、または「密度はあるが平坦でおもしろくない」文章を診断・修正するときに使用する。
Web アプリの E2E テストを「計画 → 実行 → エビデンス保存 → 後始末」まで自律的に進めるための skill。グローバルの agent-browser CLI を headless で使い、quality-mind の共通品質観点（正常系、境界値、ドメイン外値、悪意ある異常系、状態整合性、リグレッション）に沿ってブラウザ操作と検証を行い、確認結果をスクリーンショットとして ./tmp/e2e/ 配下にエビデンスとして残す。認証が必要なアプリの動作確認、フォーム投入・バリデーションの検証、リリース前の通し確認をするときに使う。単体テストや read-only のコード調査だけで完結するとき、ブラウザ操作を伴わないときは使わない。
UI・フロントエンドの実装・修正・レビューで必ず使う skill。画面、コンポーネント、フォーム、ダイアログ、スタイル、文言、状態管理、UX を扱うときに、既存デザインシステムの再利用、i18n、操作性の定番作法、再レンダリング、日本語入力(IME)の観点で判断する。バックエンドのみ・CLI のみの作業では使わない。
Final pre-commit, pre-push, or pre-merge verification for implementation work. Use when Codex needs to confirm the change satisfies the user's request before committing, pushing, opening, updating, or merging a PR; when asked for a final check; or when PR-linked context such as issues, review comments, CI checks, changed files, and acceptance criteria must be verified against the implementation.
仕様を決める・機能を切る・UX を判断する・優先順位を提案する・仕様の妥当性をレビューするときに必ず使う skill。実装依頼に仕様の曖昧さが含まれるとき、エラー時の振る舞いを決めるとき、フェーズやスコープを切るとき、機能提案を求められたときに使う。仕様が完全に確定していて実装するだけのときは軽く通す。
| name | implementation-mind |
| description | コードの実装・修正・リファクタリングを行うすべての作業で必ず使う skill。書き始める前に「正しい置き場所」「既存の同種実装」「本質的な解決策」を確認し、フォールバック、ハードコード、スタブ、名前文字列による分岐、指示されていない互換レイヤーといった対症療法を検知して排除する。責務分離、命名、ファイル分割、破壊的変更の要否など設計判断にも使う。read-only の調査・説明だけで完結するときは使わない。 |
「動く」ではなく「正しい構造で動く」を完了条件にするための実装判断の skill。 quality-mind が「どう壊れるか」を見る skill なら、これは「どう作るべきか」を決める skill。
以下のシグナルは「動かすための誤魔化し」の兆候。書く前に本質的な解決を探し、どうしても必要な場合のみ、理由・削除条件・テストでの保証を明示して入れる。
?? デフォルト値、catch して握りつぶし、空配列返却)で不整合を隠すname.includes(...)、特定 ID・ファイル名のハードコード、instanceof 具象クラス例:
const price = item.price ?? 1000 → ○: price が欠損したデータは境界で拒否し、なぜ欠損するかを直すif (accountName.includes("売上")) → ○: 勘定の属性(区分・タイプ)から導出するcommon / shared / utils への吸い込みで責務を曖昧にしない。isDefault というフラグが「削除不可」という別の意味を持ってはいけない)。