メニュー
スキル (SKILL.md) の新規作成・編集の進め方の正本。 ユーザーが Claude Code で /skill、Codex で $skill と入力したとき、またはスキルの追加・変更を依頼したとき、 または home/.agents/skills/ 配下の SKILL.md を変更する前に使用する。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
claude.ai の cloud 環境の init_script を内部 API で更新し、 環境スナップショットの再構築を発火させる。 Claude Code で /cloud-bump、Codex で $cloud-bump と入力したとき、または dotfiles の main にマージした変更が cloud 配信対象 (cloud-setup.yaml の paths) に触れていたときに使用する。 dotfiles を変更する PR を作成するときも、マージ後の bump の要否判定と予告のために使用する。
ドキュメント・記録の運用の正本 (置き場判定・原則・ADR の作法)。 issue / ADR / docs / brain ノートに振り分けて保存まで実行する。 Claude Code で /doc、Codex で $doc と入力したとき、「これ残しておきたい」「どこに書くべき?」と言ったとき、 設計ドキュメント・仕様・README などドキュメントを書く・編集する前、 および実装が完了して PR を作る前の残し漏れ確認に使用する。
repo をまたぐタスクの切り出し方、セッションの作り直し方、git worktree を用意する手順。 Claude Code で /wt、Codex で $wt と入力したとき、セッション開始ディレクトリ以外の repo を変更するとき、 コンテキストが増えたセッションを作り直したいと言ったとき、 またはスキルや作業フローが作業用 worktree を必要とするときに使用する。
現在のブランチに紐づく PR の CI 失敗・レビュー指摘・main との conflict を修復し、 mergeable な状態まで持っていく。Claude Code で /pr、Codex で $pr と入力したときに使用する。
会話やプランの内容をもとに、ブランチ作成・コミット・プッシュ・PR 作成を一括実行する。 Claude Code で /tha、Codex で $tha と入力したときに使用する。
新しいリポジトリを作るフローの正本。 Claude Code で /new-repo、Codex で $new-repo と入力したとき、 または「新しいリポジトリを作りたい」「リポジトリを切り出したい」と言ったとき、 または nozomiishii 配下に新しいリポジトリを作る作業を始める前に使用する。
| name | skill |
| description | スキル (SKILL.md) の新規作成・編集の進め方の正本。 ユーザーが Claude Code で /skill、Codex で $skill と入力したとき、またはスキルの追加・変更を依頼したとき、 または home/.agents/skills/ 配下の SKILL.md を変更する前に使用する。 |
スキルをドキュメントの TDD で作る。読者となる将来の agent が失敗するのを見てから書き、読ませて直るのを見てから確定する。設計の判断は ADR、経緯は dotfiles#1292。
依頼の一言から要件を推測で埋めない。依頼が詳しく見えても、前提と発動場面はズレていることがある。RED の前に、1 ターン 1 問でユーザーに確認する。
依頼と会話から答えが一意に読み取れる項目は聞かない。全項目が読み取れるときだけ、インタビューなしで RED に進んでよい。
スキルが対象とするタスクを、スキルを与えない subagent に投げて失敗を観察する。
編集のときも同じ。直したい失敗が現行版で再現するのを先に見る。
観察された失敗だけに対処する。観察されていない失敗への対策は書かない。書き方は AGENTS.md の「AGENTS.md・CLAUDE.md・skill・docs・実装コメントなどの書き方」に従う。
形式は失敗のタイプに合わせる:
latest または同等の指定を既定にする。スキルの CLI バージョンを人手で更新し続ける運用にしないlatest を選ぶことと、外部コードの取得・実行を許可することは別の判断。latest を理由に暗黙実行を許可せず、そのスキルに必要な承認・信頼境界を定めるlatest を固定版へ変更しない。ユーザーが版を指定した場合、または特定版が必要な互換性・セキュリティ上の失敗を RED で再現した場合だけ固定し、理由と更新条件を書くdescription には、いつ使うか (ユーザーの発話・状況・対象パス) を書く。何をするかは 1 文まで。第三人称で書く。
SKILL.md を読ませた subagent に RED と同じタスクを投げ、意図どおり動くことを確認する。
本文の読者テストに通っても、description の発動は別に壊れる。確定前に検証する。
両ホストで使うスキルは、REFACTOR の後に互換性を検証する。構文を同じにするのではなく、目的・入力・出力・ユーザーの決定権・安全策・停止条件が同等ならよい。ホスト固有の機能には条件分岐か代替手段を用意する。
対象 surface を先に決める。Claude Code local・cloud、Codex CLI・App・IDE などを一括りにせず、配置と利用場面から実際の対象だけを選ぶ。
チェックリストを先に固定しない。検証のたびに、Agent Skills、Claude Code、Codex の公式ドキュメントの最新取得を試み、対象機能の記述を確認してから今回のチェックリストを作る。同じセッションで鮮度を検証済みの公式キャッシュは再利用してよい。Agent Skills を共通の基準、各ホストの文書をその surface の拡張として読み、基準と拡張の差だけで矛盾扱いしない。
過去のチェックリストやモデルの記憶だけで判定しない。参照した URL、取得時刻、鮮度確認の結果、該当箇所、確認したホストとバージョンをテスト記録に残す。現在の公式情報を取得できない、同じ surface・バージョンの情報が解消不能に食い違う、対象機能が未記載の場合は未確認とする。編集内容は検証待ちとして引き渡せるが、両ホスト同等と判定しない。
公式ドキュメントを確認した後、現在のホストで対象機能を読み取り専用で確認する。利用可能なツールの schema、CLI の --help、skill selector、実際に読み込まれたファイルパスなどを使う。公式ドキュメントによる静的判定と、実装・実動による判定を分けて記録する。食い違う場合は両方を残し、実動結果は確認したホストとバージョンだけの根拠として扱う。
今回のスキルが使う機能だけをチェックする。少なくとも次の観点から該当項目を選ぶ。
各項目を対象 surface に分け、実動合格・静的合格（実動未確認）・該当なし・未確認のいずれかと根拠を書く。ホスト固有の語や手順を共通手順として要求していないことも確認する。
利用できる各ホストで、同じ現実的な依頼を使って読者テストする。使い捨て profile・skill root の新しいセッションで対象の作業コピーだけを探索させ、host trace や invocation metadata から読み込み元の canonical path を親が記録する。外部書き込みは mock・fixture・一時 repo・一時 remote へ向ける。本物の push・投稿・送信は、ホストごとの明示承認なしに検証で実行しない。
片方を実行できない場合や安全に隔離できない場合は、公式ドキュメントに基づく静的検証まで行い、静的合格（実動未確認）と記録する。実行していない surface まで実動確認済みと扱わない。