Menu
.claude/rules/ 配下のルールファイル (*.md) を新規作成・編集するときに、適切なメカニズム選択と paths スコープを保証する。ルールを書く前・書いた後に必ず適用する。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | create-rule |
| description | .claude/rules/ 配下のルールファイル (*.md) を新規作成・編集するときに、適切なメカニズム選択と paths スコープを保証する。ルールを書く前・書いた後に必ず適用する。 |
| when_to_use | .claude/rules/ にルールファイルを新規作成するとき、既存のルールファイルを編集するとき、「ルールを追加して」「規約を書いて」と言われたとき、ルールが全タスクで常時注入されていることに気づいたとき。 |
.claude/rules/ のルールはコンテキストに注入される指示。書き方を誤ると無関係な作業でトークンを浪費し、モデルの判断を曇らせる。作成・編集のたびに次の手順を踏む。
書こうとしている内容を、まず置き場所で振り分ける。rules に何でも書かない。
| 内容 | 置き場所 |
|---|---|
| 全セッションで常に効かせたい事実 (ビルドコマンド・プロジェクト構成・全体規約・応答トーン) | CLAUDE.md |
| 特定のファイル種別・ディレクトリにだけ効かせたい指示 | .claude/rules/ (paths スコープ) |
| 手順もの・呼び出し時だけ要る重い知識 (デプロイ・コミット・コード生成) | skill (/en/skills) |
| Claude の判断に関係なく確実にブロック/強制したい挙動 | PreToolUse hook (/en/hooks-guide) |
rules と CLAUDE.md は context であって enforcement ではない — 「決して X するな」を確実に止めたいなら hook にする。
testing.md, api-design.md, security.md)。frontend/・backend/ 等のサブディレクトリに分けてよい (再帰探索される)。paths の無いルールは 全タスクで無条件ロード (.claude/CLAUDE.md と同優先度)。範囲が「全ファイル共通」でない限り、必ず paths フロントマターをファイル先頭に置く。
---
paths:
- "**/*.{ts,tsx,js,jsx,mjs,cjs}"
---
** = 任意階層、* = 単一階層。拡張子は brace expansion {ts,tsx,...} で 1 行にまとめる (1 拡張子 1 行に分けない)。| 適用範囲 | paths |
|---|---|
| TS/JS 全般 | **/*.{ts,tsx,js,jsx,mjs,cjs} |
| Web 系言語 + SQL (セキュリティ系) | **/*.{ts,tsx,js,jsx,mjs,cjs,py,rb,go,php,sql} |
| API ハンドラ等の限定領域 | src/api/**/*.ts **/*.handler.ts のようにディレクトリ/命名で絞る |
| Python のみ | **/*.py |
| 全ファイル共通 (規約・トーン等) | paths を付けない |
z.object・console.log 禁止など TS/JS 前提なのに paths が空、といった不整合がないこと。paths を確認 — 無ければ常時注入が妥当か判断し、不要なら追加する。/memory でロード状況を確認 (デバッグには InstructionsLoaded hook も使える)。ln -s ~/shared-claude-rules .claude/rules/shared
ln -s ~/company-standards/security.md .claude/rules/security.md
~/.claude/rules/ は全プロジェクトに効くユーザーレベルルール (プロジェクトルールより先にロードされ、プロジェクト側が優先)。プロジェクト非依存の個人設定向け。Generic thinking protocol for deriving optimal solutions through iterative self-checking. Invoke BEFORE searching within the given problem space whenever the user asks for advice, judgment, evaluation, or choice. Reframes the problem, generates options, evaluates trade-offs, runs a self-answer check (does this answer the user's actual question at the right granularity, reach upstream, match expectations, offer non-obvious value?), and loops back to upstream tracing or same-level reframing if the check fails — until convergence. Applies across any domain — technical, process, organizational, decision-making, career. Triggers when the user uses evaluation or reconsideration language ("which is best", "root cause", "is this really needed", "sustainable long-term", "ほんとうに", "そもそも", "最善は", "根本は", "筋が良い"), when validating the soundness of someone's proposal from multiple perspectives, when the problem spans multiple layers (tech / process / org / regulation / UX / cost), or when clear trade-offs exist.
Review the local diff with flat-perspective sub-agents, fix findings in a loop, then create a PR via the create-pr skill once the review is clean
計画や設計について、ユーザーを徹底的に問い詰めて一緒に詰める。実装・着手の前に計画をストレステストしたいとき、または「詰めて」「グリルして」「問い詰めて」「ツッコんで」「設計レビューして」「ほんとうにこれでいい?」などのトリガー表現が出たときに必ず使う。
Orchestrate Epic issue as team leader. Delegate sub-issues to member agents in isolated worktrees. Members run in background and communicate via SendMessage.
Fetch a GitHub issue with its sub-issues, walk up to the parent Epic, list sibling issues under that Epic, fetch the body of each sibling issue, attach the implementing PR for each closed sibling with body and diff summary, gather related code, and present as a Japanese summary so the reader can grasp the whole task context including the actual contents of siblings and their PRs
Summarize GitHub Epic issue with sub-issues and related PRs. Use when reviewing epic progress or getting implementation overview.