コーディングエージェントに質問すると、背景説明と注意書きが延々と続き、肝心の「次に何をするか」が最後の1行に埋もれていることがある。これに対して「行動を先に言う」「前置き・要約・結語なし」といった10のルールをスキルとして配るリポジトリが公開された。便利そうだが、全部をそのまま入れてよいのか。自分のスキル群に当てはめて、効くルールと入れてはいけないルールを仕分けた。
10ルールの中身と、効く場面・効かない場面の仕分け。そして、出力スタイルのスキルを入れるときに最も事故りやすい「成果物まで短くなってしまう」問題の避け方。
公開されているのはi-have-adhdという、MITライセンスのスキルだ。エージェントの返答の話し方だけを決める。コードを書く能力を足すものではなく、返答の並べ方を変えるものである。
リポジトリの説明では、ルールは次の10個にまとまっている（要約。正確な文面はSKILL.md側が正）。
公式の対比例も分かりやすい。長い説明を並べる代わりに、npm install jsonwebtoken@latestから始まり、番号つきの手順と次の一手だけが続く、という形だ。
私の運用では、スキルの出力には2種類ある。1つは人間への返答や完了報告（作業中の会話、自動実行の最終レポート）。もう1つは成果物そのもの（ブログ記事、台本、HTML）。ルールは前者にだけ効かせたい。この前提で、各ルールを机上で当てはめて分類した。実測ではなく設計上の判断である点は先に断っておく。
| 区分 | ルール | 理由 |
|---|---|---|
| そのまま入れる | 1・3・10 | 完了報告は「結論→次の一手」で足りる。前置きと結語は読み手の時間を食うだけ。 |
| そのまま入れる | 2・8 | 手順に番号を振る、エラーを淡々と書く、はどの場面でも害がない。 |
| 条件つき | 4・7 | 脱線を抑えすぎると、本当に伝えるべき副作用の警告まで消える。達成の明示は報告では有用。 |
| 入れない | 5・6 | 毎ターンの現在地は、1発完結の自動実行では冗長。AIの時間見積もりは当たらず、数字だけが一人歩きする。 |
| 成果物には使わない | 9 | 5項目制限は、記事のチェックリストや仕様の網羅には足りない。 |
半分と言ったが、実際は「返答には全部効きうるが、成果物に混ざると壊れる」ルールが混在している、というのが正確だ。
出力スタイルを変えるスキルは、1度入れるとすべての出力に効く。記事を書かせたときにも「前置きなし・結語なし・5項目まで」が適用されたら、読み物として成立しなくなる。
これが、私がこの種のスキルを常時入れずにいる理由でもある。ブログ記事のスキルは、導入で課題を示し、本文で構造を示し、最後に点検項目を置く、という前置きと結語を含んだ構成そのものが成果物だからだ。「前置きが悪」ではなく、返答の前置きと文章の導入は別物である。
ポイント。スタイル規則には適用範囲を書く。「ユーザーへの返答と完了報告にのみ適用。ファイル・成果物の中身には適用しない」の1文があるかどうかで、安全性がまるで変わる。
# スタイル系スキルの冒頭に足す一文（例）
適用範囲: チャット返答と完了報告のみ。
生成するファイル・記事・台本の本文には適用しない。私のスキル群には、生成が終わったときのメッセージを決めた箇所がある。たとえば「ファイルを生成しました」と3行並べたあと、操作の案内が続く形だ。これをルール1・3・10で見直すと、次のようになる。
# 見直し前の型（抜粋）
ファイルを生成しました。予約投稿キューに追加済みです。
投稿は毎日9時のタスクが順番に行います。
今すぐ出したい場合は…、キュー確認は…
# 見直し後の型
queue/NN_slug に記事一式を生成。公開は明朝9時の自動実行に任せる。
次の一手: 内容を確認し、直したい箇所があれば指示する。情報量は変わらず、先頭の1行で結論が分かり、最後に次の一手が残る。無人で回す定期実行の最終報告では、人間が数秒で読めることが特に効く。この用途なら、ルールを全部入れなくても、1・3・10の3つだけで十分だと判断した。
なお、これは文面を見直した設計判断であり、読みやすさを数値で測ったわけではない。効果を確かめるなら、同じ依頼に対して導入前後の返答を並べ、結論に至るまでの行数を比べるのが手軽だ。
ルールを丸ごと借りるより、自分の出力のどの場面が読みにくいかを先に特定して、必要なルールだけ抜き出すほうが事故が少ない。元のスキルはMITライセンスなので、読んで参考にし、自分の運用に合わせて削るのが現実的だ。
本記事は公開リポジトリの説明と筆者の運用を踏まえた設計検討で、効果の実測は含まない。ルールの正確な文面は元リポジトリを参照してほしい。