Hikizanを作っていたころは、AIに仕事を任せるための手順をかなり書いていた。調査、設計、実装、レビュー、提出、文章。六つのスキルに役割を分け、どこで考え、どこで止まり、何を確認してから次へ進むかを整えようとしていた。
指示を少しずつ減らしていくと、最後まで残したかったものが見えてきた。返答を読みやすくすること。次に何をすればいいかを選べること。自分が欲しかったものは、対話のUIに集まっていた。
手順を任せられるほど、自分の好みが見えた
モデルに任せられる範囲が広がるにつれ、Hikizanで決めていた進め方を、自分で維持する理由は薄れていった。依頼と今ある実装を読めば、必要な調査や検証をその場で組み立てられる。先回りして書いた手順が、目の前の仕事に合っているかを気にすることも増えた。
一方で、仕事を進められることと、その返答が自分にとって使いやすいことは別だった。
長い説明のどこに結論があるかを探す。専門用語を読み直す。次に進めてほしいだけなのに、また文章を考えて入力する。一つひとつは小さいが、何度もやりとりするうちに、この手間のほうが気になる。
頼みたいことをそのまま渡せて、返ってきたものを理解できて、次へ進める。手順を削っても、ここは残したかった。
読むことと、返事をすること
たとえば、返答の冒頭に絵文字とひと言が独立していれば、確認の報告なのか、変更が終わったのかをつかみやすい。作業が続くときは、数えられる進み具合だけをそこへ添えてほしい。何件中何件まで終わったかが分かれば、続きを待ちやすい。本文が平易な言葉なら、こちらが判断するために読み直す回数を減らせる。
返答の最後には、次に取れる行動を選択肢で置いてほしい。「このまま進める」「文章を直す」といった行動を選べれば、そのたびに依頼を書き直さずに済む。専用の選択UIがあるならそれを使い、テキストなら「あ」「い」の一文字でも返せるようにする。
途中の報告まで毎回選ばせる必要はない。作業が進んでいる間は状況が分かればよく、こちらへ判断が戻ってきたところで選べればいい。
こうした好みは、見た目の装飾だけではない。読む場所を決め、入力を短くし、仕事の続きを渡すための操作になる。会話が作業の窓口なら、文章の並び方や返事のしかたもUIなのだと思う。
会話のための約束をminimへ残した
今は、その好みをminimという小さなプラグインにまとめている。本体は一つのMarkdownに書いた短い約束だ。
依頼の目的から逸れていないか確かめる。既存の実装や仕組みを確認し、使えるものは使う。Gitの履歴で分かる変更経緯をコードのコメントへ書かない。足りない判断を推測で補わない。そして、平易な説明、進み具合を添えた冒頭のひと言、最後の選択肢。
Hikizanにあった六つの作業スキルを、そのまま小さくした構成ではない。日々の仕事で繰り返し伝えたくなることを残している。進め方についての好みも少し残っているが、中心は読むことと返事をすることにある。
Codexでは、フックがこの本文を会話へ渡す。Cursorでは同じ本文を常時適用のルールとして読み込む。どちらも使うたびにスキルを選ぶ必要はない。接続の実装はHikizanの対話UIの試作から引き継ぎ、追加のスキルやMCPサーバーは持たせていない。
作ったから、削る場所が分かった
Hikizanは過去の試作としてAgent Pluginsに残している。作って使ったことで、任せたい部分と自分の好みとして残したい部分を分けられた。
最初からこの短い約束にたどり着けたとは思わない。手順を作り、使い、不要になったものを外す過程で、自分がどこに手間を感じているかが分かった。
これからもモデルやアプリに任せられることが増えれば、minimに書くことは減るかもしれない。それでも、仕事の状態をひと目でつかみ、内容を理解し、少ない入力で続きを渡したいという好みは残る。
Hikizanを削っていった先に、自分のために残ったのは、そのやりとりの形だった。
補足：作法を整えるなら
実装や検証の作法をプラグインで整えたいなら、Ponytailかpstackがよさそうだと思う。
Ponytailは、既存のコードや標準ライブラリ、プラットフォームの機能を先に確かめ、必要な分だけ実装することを促す。作りすぎを抑える作法を足したいときに合う。pstackはCursor向けに、コードの理解から設計、実装、検証、レビューまでのスキルと原則をまとめている。仕事の進め方を一通り整えたいときの候補になる。
そうした作法は、自分に合う既存のものを選べばいい。自分で残しておきたい好みが、今はminimの小さな対話UIだった。