前回から残った問題は、skill の置き場所だった
ルール共通化の次に手順共有が出てきた
前回 までで、rule.md 1 ファイルを配信元の正本（Source of Truth）にして、deploy.sh で ~/.codex/AGENTS.md と ~/.claude/CLAUDE.md の 2 ターゲットに配信する整理を書きました。これで、両エージェントに同じ指示・ルールを読ませる問題は片付きました。
ところが、もうひとつ残っていた困りごとがありました。Claude Code で「これは毎回同じ手順で進めたいな」と思った作業を skill として定義しておくと便利なのですが、同じ skill を Codex 側でも呼びたい、という場面が出てきます。
rule.md は「両方に常時読ませる指示・ルール」を置く場所です。ここに作業手順まで全部書くと、すぐに膨らんでしまいます。あれ、また置き場所問題です。
rule.md の外にある手順を揃える
今回は、その「再利用したい作業手順 = skill」を両方のエージェントに同じ形で載せる話です。自作の persona-skills-core という別 repository を任意拡張として接続することで、Codex の $ メンション候補と Claude Code の / スラッシュ候補から同じ skill を呼べる形に整理しました。
ここでの分け方は、かなり単純です。
- 指示・ルールは
agent-config-coreのrule.md - 再利用したい作業手順は
persona-skills-coreのskills/ - 登録先の違いは Bootstrap CLI
この3つを混ぜないようにすると、どこを直せばよいかが分かりやすくなります。
skill も片方ずつ書くとズレる
Claude Code だけに置くと Codex から見えない
rule.md で指示・ルールを揃えたあと、しばらくは skill を Claude Code 側にだけ定義して使っていました。文書レビューや設計レビューなど、毎回同じ進め方をしたい作業を ~/.claude/skills/ 配下に置いて、/ スラッシュから呼び出す、という運用です。
1 台の端末の中ではそれで済むと思っていたのですが、Codex も普段使いし始めると話が変わりました。片方では呼べるのに、もう片方では呼べない。地味ですが、何度も起きるとかなり気になります。
Claude Codeの skill 定義はCodexからは見えないCodexの$メンション候補にも出てこない- 仕方なく、同じ手順を
Codex側で文章で書き直して使うことになる - 片方の skill を更新したら、もう片方にも反映する作業が発生する
手順のズレが再発する
rule.md の手書き同期で困ったのと同じ構図が、skill のレイヤーで再発したわけです。前提（指示）は揃ったのに、手順（skill）がエージェントごとに分かれている状態でした。ここを放置すると、また手で揃える生活に戻ります。
自分にとって問題だったのは、skill そのものの数ではありません。片方で直した作業手順を、もう片方にも正しく移す必要があることでした。手作業の同期が戻ってきた時点で、最初に rule.md を共通化した意味が薄くなります。
persona-skills-core から両方へ届ける
書く場所は skills/ に寄せる
整理した結果、skill / persona / workflow を 1 つの公開 repository に集約して、Bootstrap CLI で両方のエージェントに登録する構成にしました。それが自作の persona-skills-core です。
persona-skills-core/
├── skills/ # Codex / Claude Code から見える入口
├── workflows/ # 確認順、担当、成果物、停止条件
├── personas/ # 仮想担当者、チーム
├── tools/ # ポリシー、チェックリスト、テンプレート
├── scripts/ # Bootstrap CLI
└── README.md書き手が触るのは skills/ 配下の SKILL.md と、それが参照する workflows/ personas/ tools/ です。skill の本体はここにしか書きません。
登録先の差は CLI に閉じ込める
登録は Bootstrap CLI に任せます。skill 本体に対して、Codex 側は plugin として、Claude Code 側は ~/.claude/skills/ 配下の skill directory として、それぞれの作法に合わせた登録先に CLI が symlink を張る、という構造です。
書き手側は「skill ディレクトリに 1 つ書く」だけで済みます。新しい skill を書いたあとに CLI を 1 回叩くと、両方の候補に同じ skill が出る。書く場所は 1 つ、登録先は 2 つ、という分担です。
agent-config-core とは、必要なときだけつなぐ
単独利用できる関係にする
persona-skills-core は、前回までで紹介した agent-config-core の任意拡張として位置付けています。ここで大事なのは、両者を強く依存させないことでした。
agent-config-core単独で使ってもよいpersona-skills-core単独で使ってもよい- 両方使う場合は、
agent-config-core側の deploy オプションからpersona-skills-coreの登録もまとめて走らせられる
依存方向を一方通行にしなかったのは、自分のユースケース上、片方だけ欲しいときがあるからです。たとえば「skill は要らないけど前提だけ揃えたい」端末では agent-config-core 単独で十分ですし、逆に「前提は手で書きたいけど skill 群は使いたい」場面なら persona-skills-core 単独で動かせます。
この形にした理由
最終形を選んだ理由は、3つあります。
1つ目は、skill のリリースサイクルを rule.md 配信から独立させたいからです。rule.md は「両エージェントに常時読ませる前提」を書く場所で、skill は新しい作業パターンが見つかるたびに増えたり直ったりします。
2つ目は、公開 repository として自分で保守する skill を継続改善したいからです。skill は自分の作業手順そのものなので、git history で改善の経緯を追える状態にしておくと後から見直しやすいです。
3つ目は、書き手から登録の作法の違いを切り離したいからです。Codex の $ メンション候補と Claude Code の / スラッシュ候補は登録の作法が違います。その差は Bootstrap CLI に閉じ込めて、書き手は skill 本体に集中できるようにしました。
続きはこちら
次の記事では、persona-skills-core の Bootstrap CLI が Codex と Claude Code の登録先の違いをどう吸収しているかを書きます。設計の話から、実際の登録フローへ進みます。