메뉴
AI の振る舞いに関する方針・ルールを、将来の会話にも引き継ぐためにドキュメント（CLAUDE.md や me- スキル）へ反映する。ユーザーが「再発防止」「次回から〜しないように」「同じミスを繰り返さないように」「ルール化して」「ドキュメントに残して」「CLAUDE.md に書いて」「今後こう振る舞って」などと指示したときに使用。編集先は「特定ドメイン/タスクに閉じる話は me- スキル、汎用的な方針は適切な階層の CLAUDE.md」という判断ツリーで決める。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when the user wants to open a GitHub pull request with `gh pr create`. Inspects the repository for a PR template under `.github/` and follows it when present; otherwise falls back to a Japanese default template (やったこと / やらないこと / Why・背景 / Before/After / 確認URL / 確認方法 / 観点 / 補足). Keeps each section concise instead of explanatory.
Use when the user wants to fetch GitHub PR review comments and address them. Fetches inline code review comments and general PR comments using gh CLI, evaluates each comment, fixes definitive issues, and handles opinion-based suggestions (imo/nit/consider) by judging validity before acting.
Use when committing staged changes. Splits diff by Conventional Commits category, generates a message per commit, and appends task/project ID from branch name if present.
Use when writing or reviewing CSS or Tailwind CSS code. Provides guidelines for layout, spacing, and class usage to avoid common pitfalls.
Use when writing or editing shell scripts (.sh files). Provides conventions for shebang, safety options, variable declarations, and Bash idioms used in this repository.
| name | me-keep-ai-doc-up-to-date |
| description | AI の振る舞いに関する方針・ルールを、将来の会話にも引き継ぐためにドキュメント（CLAUDE.md や me- スキル）へ反映する。ユーザーが「再発防止」「次回から〜しないように」「同じミスを繰り返さないように」「ルール化して」「ドキュメントに残して」「CLAUDE.md に書いて」「今後こう振る舞って」などと指示したときに使用。編集先は「特定ドメイン/タスクに閉じる話は me- スキル、汎用的な方針は適切な階層の CLAUDE.md」という判断ツリーで決める。 |
AI の誤動作や新しい方針を、将来の会話にも引き継ぐためのドキュメント更新フロー。
メモリ（~/.claude/projects/.../memory/）は個別の会話から学んだ事実を蓄積する場所だが、
開発全般の原則や繰り返し参照するべき規約は、プロジェクトの CLAUDE.md または me- スキルに
記録したほうが、文脈を問わず安定して参照されるので望ましい。
以下を順に当てはめて、当てはまった時点で対応する先を選ぶ:
me- スキルが既に存在するなら、そのスキルの SKILL.md を編集するme-<domain> スキルの作成をユーザーに提案し、合意を得たら skill-creator スキルの使用を促す現在の作業ディレクトリから親ディレクトリを順に遡り、優先度の高い順に判断する:
プロジェクト固有の話か？
CLAUDE.md が該当プロジェクトのものCLAUDE.md が未作成で、プロジェクト固有のルールとして残すべきなら、プロジェクトのルートに新規作成する全プロジェクト共通の話か？
~/dotfiles/unix/.claude/CLAUDE.md を編集する~/.claude/CLAUDE.md は Nix home-manager が管理する symlink（Nix store 配下）なので、直接編集してはいけない（読み取り専用・再ビルドで上書きされる）同じテーマの既存項目があれば、新規追加ではなく既存項目を更新する。重複した記述は将来のメンテ負債になる。
「何をしてはいけないか」だけでなく、理由を書く。LLM は理由を与えられたほうが、想定外のケースでも文脈に沿った判断ができる。
悪い例:
- コミット時は必ず `-m` オプションを使う
良い例:
- コミット時は `-m` オプションで完結させる（エディタ起動を伴う対話入力はこの環境で処理が止まるため）
ALWAYS / NEVER のような強い命令を多用しない。背景・目的・適用条件を説明する書き方の方が、モデルが境界ケースで適切に振る舞える。どうしても譲れない制約に限って強調する。
抽象的なルールだけでなく、悪い例・良い例、あるいは「こういう時はこう」の対比を添えると、モデルがルールの適用範囲を判断しやすくなる。
新しいドメインで再利用したい規約・手順がまとまって出てきた場合、skill-creator スキルを使って me-<domain> として切り出すようユーザーに提案する。作成先は ~/dotfiles/unix/.claude/skills/me-<domain>/SKILL.md。
このスキルを使っている最中に、判断フローや注意点で漏れ・誤りに気づいた場合は、
同じ要領でこのスキル自身も更新する（~/dotfiles/unix/.claude/skills/me-keep-ai-doc-up-to-date/SKILL.md）。