【0:00-0:35】 NDFが何なのかは前回話したので、今日は「で、結局どのスキルに何が書いてあるのか」をやります。 スキルは手順書じゃなくて、判断基準が書いてあるものだと思ってください。何をやるかより、何を重視するかが本体です。 持ち帰ってほしいのは、PRを1本出す流れがスキルを繋ぐだけで終わる、という感覚ひとつです。

【0:35-1:25】 構成はシンプルです。スキルの本体は ndf-shared の1か所。ここを直すと、Claude用・Codex用・Kiro用の配布物がビルドで生成されます。 なので「Claudeでは直ってるけどCodexでは古い」が起きない。地味ですがこれが一番効いてます。 数が違うのは、ランタイムごとに意味のないスキルを外しているからです。Claudeは29、Codexは30、Kiroは28。 MCPプラグインが10個。今日は時間の都合で名前だけにします。

【1:25-2:10】 インストールはこれだけです。marketplace add は初回だけ、あとは install。 入るものは3種類。スラッシュで呼ぶスキル、裏で働くサブエージェント、それとフック。 Stopフックは作業が終わったらSlackに要約を投げてくれます。長時間タスクを回してる人はこれだけでも入れる価値があります。 では本題、スキルの中身に行きます。

【2:10-2:55】 これが今日の地図です。左から、作る前にプランを書き、PRを出し、レビューを回し、最後に仕様書として残す。矢印1本がスキル1個です。 下の3つは順番のどこかに入るものじゃなくて、全工程にかかるルールです。文章を書くとき、調べるとき、バグを直すときに常に効いてくる。 ここからスキルを1個ずつ開けていきます。それぞれ「何が書いてあるか」と「何を重視しているか」の2点で見てください。

【2:55-4:00】 1つめ。implementation-plan は issues/ 配下に実装プランを置くスキルです。 左が中身。プランの雛形が決まっていて、概要・背景・修正対象・タスク分解・影響範囲・テスト計画。埋めるだけです。全部の変更に要るわけじゃなくて、判断基準もスライドの通り書いてあります。 右が思想。重視しているのは「なぜ」を残すこと。コードを見れば「何をやったか」は分かるけど「なぜやったか」は消えるので、そこだけ残す。 なのでプランとPR本文で役割を分けていて、同じ内容をコピーするなと明記されています。 下のブロックが実用上ありがたくて、プランを書かずに実装しちゃっても、PRを作る瞬間に会話履歴とgit logとdiffから逆算して生成してくれます。「あとで書く」が実際にあとで書かれる。

【4:00-5:05】 2つめ、pr。commitしてpushしてPRを作るまで一括です。 引数の解釈が賢くて、--draftならドラフト、ブランチ名っぽい文字列ならベース指定、それ以外はコミットメッセージ。覚えなくても適当に打てば通ります。 既にPRがある状態で叩くと、新しく作らずに本文を今の差分に合わせて書き直します。実装が変わったのに説明文が古いまま、が無くなる。 で、このスキルが一番重視しているのは事故防止です。mainで直接コミットしようとすると止まる。これは何度か救われてます。 もうひとつが下のブロック。qa や staging に feature ブランチから直接PRを出すと、そのブランチをマージしたときに環境固有のコードが main に流れ込む。これを止めて、cherry-pick方式に誘導します。ブランチ運用の事故って気づいたときには手遅れなので、コマンドの側で止めてくれるのはかなり効きます。

【5:05-6:15】 3つめ、review。第二引数でレビュアーをcodexやgeminiに差し替えられます。自分が書いたコードを自分でレビューしても甘くなるので、別のAIに渡すと普通に知らない指摘が出てきます。 中身で面白いのは、観点に優先順位が付いていることです。「いい感じにレビューして」だと指摘が散らかるので、言語慣用性から順に見ろと明示してある。 チェックポイントも具体的で、関数50行・ファイル300行という数字まで書いてあります。ただし「プロジェクトの慣例が優先」と但し書きが付いていて、数字を機械的に当てはめないようになっています。 個人的に効くと思っているのが下の2つ。重複コードはPRの範囲外でもまとめろと書いてある。あとマジックナンバーを見つけたときに、定数にすればいいという話にしないで、DBのマスタやyamlに出せないか考えろと。定数化って一見きれいですが、運用で変わる値を定数にすると次はデプロイが必要になるんですよね。

【6:15-7:20】 同じくreviewですが、こっちは指摘の書式の話です。 先頭に重要度とカテゴリを付ける。これは見やすさのためだけじゃなくて、この重要度が後段の自動修正の判断に直結しています。criticalとmajorは必ず直す、nitは直さないで最後に人間に見せる。つまりラベルが処理の分岐になっている。 なので「過剰なnit量産は避けろ」とも書いてあります。AIにレビューさせると、どうでもいい指摘を大量に出して仕事した感を出しがちなので、そこを抑えにいっています。 もうひとつ、指摘は必ずコード行に紐付けろというルール。総評に「〇〇が気になります」って書かれても、どこの話か探すところから始まるので。総評に書いていいのは設計レベルの話だけです。

【7:20-8:05】 4つめ、cross-review。codexとgeminiの両方にPRレビューを投げて、両者がAPPROVEを返すまでレビューと修正を自動で回し続けます。 片方がAPPROVEでも、もう片方が指摘を出していれば止まらない。 デフォルトは最大12ラウンド、8ラウンドで収束しなければPRをローテーションします。修正はサブエージェントに投げるので、メインの会話ログは汚れません。 このスキルで一番よくできているのが次のページです。

【8:05-9:15】 cross-reviewの本体はここだと思っています。 PRの変更ファイルを全件取って中身で分類し、その種類に効く観点だけを両方のAIに渡します。ドキュメントだけのPRにN+1の話をされても困るし、マイグレーションを含むPRでロールバック手順を聞かれないのも困る。それを自動で切り替えている。 表に出したのは一部で、全部で15分類あります。マイグレーションならbackfillとロールバック、認証まわりならsecretとPIIとCSRF、という具合です。 これに加えて --focus で今回だけの観点を足せます。長いチェックリストを渡したいときはファイルでも渡せる。 重い処理なので、単発の第二意見が欲しいだけなら前のページの /ndf:review でいいです。そこは使い分けてください。

【9:15-10:25】 5つめ。実装が終わったプランを仕様書に変換します。 ポイントは移動じゃなくて書き直しだということ。プランには「まずAをやってからBをやる」みたいな作業順とか、途中でやめた案とか、AI向けの作業指示が入っていて、それは仕様じゃないので全部落とします。 面白いのが語尾の変換ルールまで書いてあることで、「実装する」は「提供する」に、「修正対象」は「構成」に直す。プランは未来形で書かれていて、仕様書は現在形であるべきなので。細かいですが、これがないと「実装する」が残ったまま仕様書として置かれて、読んだ人が「これまだ実装されてないのか」と誤解します。 最後に実コードと照合する手順まで入っています。書いた設定名やファイルパスが本当に存在するか、逆に実装にある重要な挙動が抜けていないか。仕様書が嘘をつかないようにする工程ですね。

【10:25-11:40】 6つめ、markdown-writing。v4.20で体裁ルールから可読性ルールに拡張されたやつです。 一番効くのは1番。説明文にテーブル名やカラム名をそのまま書かせない。例を見てください。上は書いた本人には完璧に伝わるけど、読む側には何ひとつ伝わらない。書いた側が説明した気になるのが厄介なところです。 2番3番は、AIに書かせると必ず出るやつです。「案Aを採用しました」とか「指摘を受けて修正しました」とか。それは文書じゃなくてgitとPRに置け、と。文書には「今何が正しいか」だけ書く。 4番は次のページで詳しくやります。 7番は分量ルールですが、単純な行数制限じゃなくて「分割すると理解が落ちるなら分けるな」と例外が書いてあります。 あと、書き終わったあとに走らせるgrepまで用意されています。案Aとか、以前は、みたいな語を機械的に拾う。人力チェックリストで終わらせてないのが良いところです。

【11:40-12:50】 7つめ。この2つはセットです。 左のinvestigation-rules。「無い」と書くなら実行結果を貼れというルール。AIはコードを読んだだけで「該当なし」と自信満々に断言するので、それを止めるためのものです。実例として、外部テーブルの一部のカラムだけ見て「該当カラムなし」と結論づけたけど、実は別名のカラムにデータがあった、という失敗がスキルの中に書いてあります。 下の一文が個人的に好きで、エビデンスなしで残課題の優先度を「低」にするのは誤判断の典型、と名指しされている。優先度を下げるのって実質「やらない」なので、そこにこそ根拠が要る。 右のproblem-solving。データがおかしいときに、そのデータだけ直して終わりにするな、と。なぜ入ったかを遡って、入口にバリデーションを足してから直す。あとコードの修正とデータの修復を別コミットにしろと。混ぜるとRevertできなくなるので。

【12:50-13:40】 CodexとKiroです。ここは「同じものが使える」ということだけ持って帰ってください。 Codexはマーケットプレイス方式で、Claudeとほぼ同じ2コマンド。セッションに入るとndfコロン付きでスキルが並びます。実際に叩いて30個読み込まれているのを確認済みです。 Kiroだけ方式が違って、リポジトリをcloneしてinstall.shを叩きます。.kiro/skills/ 以下にスキルが並んで、エージェント定義も一緒に作られます。何度実行しても壊れないので、更新したら叩き直せばいいです。

【13:40-14:30】 まとめです。 今日いろいろ見てきましたが、共通しているのは、どのスキルにも「何をやるか」の前に「何を重視するか」が書いてあることです。レビューなら観点の優先順位、文章なら誰に向けて書くか、調査なら何を根拠とするか。 そこって人によってブレるところで、しかも指摘しづらいところなんですよね。それをスキルに落として揃えているのが、このプラグインの一番の中身だと思っています。 まずは次のPRで pr と review を叩いてみてください。質問あればどうぞ。