私はAIエージェントを日々扱っていて、コンテキストスイッチを最小限に抑え、開発中に通常使っているすべてのツールをエージェントが使えるようにするよう非常に気を配っています。最近は、エージェントがそれらのツール自体を見つけ出すのが得意なので、これはかなりうまくいっています。ですが、私の仕事ではClickUpが必要なので、ステータス更新、コメント、タスクの説明のたびにalt+タブでClickUpに切り替えるのにうんざりしていました。そこで、それをコンテキストとして渡すために、CLIをプロンプトして作り、さらにスキルも一緒に用意しました。そうすれば、エージェントが自動でそれを拾うはずです。
プロジェクト全体はClaude Opus 4で作られ、OpenCode () によってHighモードに設定されました。手書きした行は1行もありません。
ビルドプロセスを共有したいです。というのも、このパターンは、独自のCLIツールでvibe-codeしたい人なら誰にでも再利用可能だと思うからです。私は、これを大きなAI生産性のブーストとしておすすめします。
哲学：CLI + SKILL.md
エージェントと一緒に働いて得た最大の収穫は、スキルファイルと組み合わせたCLIツールは、MCPサーバーやブラウザベースのワークフローよりも、必要トークン数がずっと少ないということです。エージェントはシェルコマンドを実行し、構造化された出力を得て、必要ならパイプし、その後すぐ次へ進みます。つまり、プロトコルのオーバーヘッドなし、サーバープロセスなし、大量のコンテキスト投入なし、ただデータがまっすぐ流れるだけです。
これは「圧縮」が少なくて済むことを意味します。エージェントが何をしているかを見失うことなく、より長いセッションを進められます。スキルファイルは小さく（数百行のマークダウン）、CLIの出力もコンパクトです（パイプしたときはマークダウン、代替としてJSON）。さらに、エージェントは保持すべき状態をあまり必要としません。
このパターン――CLIを作り、SKILL.mdを書き、エージェントに渡す――は、APIがあるがエージェント統合がうまくできていないほぼあらゆるサービスで機能しうると思います。社内ツール、CRM、デプロイパイプライン。RESTクライアントを書いて、それを使う方法を説明するマークダウンファイルさえ用意できれば、エージェントはそれを学べます。
ビルドプロセス
私はエージェントのワークフローに obra superpowers を使っています。これは、Claudeに対して、コードを構造化された形で計画し、実装し、レビューし、そして出荷する方法を教えるための一連のスキルです。Ralphのような完全なループ型フレームワークで回すのは大げさで、単純なプロンプトを書くのも物足りない、そのちょうど良い甘いポイントだと言えるでしょう。複雑なオーケストレーションシステムの複雑さなしに、構造化された計画と並列実行が得られます。
初期セットアップ（repo、npm、Homebrew、CI、タグベースのリリース。これもエージェントが実施）以降は、新機能ごとに、だいたい同じプロンプトを使い、superpowersのスキルセットに強く依存します。
``` ブレインストーミングスキルを使って<task>の実装に向けた準備をする // 1 必要なだけ質問する
アプローチ<A/B/C>でいこう // 2
ライティングプランスキルを使って<task>向けの完全な計画を .md ファイルとして準備する
サブエージェント駆動開発と実行プランスキルを使って、完全な計画を実装し、テストで確認する
自分で開発しない。ディスパッチング・パラレル・エージェントを使ってサブエージェントのオーケストレータとして振る舞う。追加の質問があれば自分で判断して、DECISIONS.mdにその内容を記録する
PROGRESS.mdで進捗を追跡し、それを次のエージェントに引き継ぐ。サブエージェントにはそれらのファイルを指し示し、圧縮サマリーでそれらへリンクする ```
私は、エージェントに「何を作るか」をすでにクリアにしているかどうかで、// 1 または // 1 + 2 を省略することがあります。
これを実際にやるとどうなるか：エージェントがアプローチをブレインストーミングし、1つを選び、詳細な計画を書きます。そして、その計画の各パートを並列に実装するためのサブエージェントを起動します。進捗はマークダウンファイルで追跡するので、コンテキストが長くなったときでも、サマリーが計画と意思決定へリンクしてくれます。各サブエージェントはテストを書き、オーケストレータがレビューします。私は主に承認するか、方向転換を指示するだけです。ブレインストーミング後に質問へ答える必要はほとんどありません。ほぼ「ちょっと機能を追加したい（たとえば“コメント機能を追加しよう”）」といった要望を出したときだけです。
リポジトリ内のAGENTS.mdは、新機能の最後にリリース対応（バージョンの更新、タグ付け、プッシュ）もエージェントが処理するよう指示しています。だから「機能Xを作りたい」から「npmで公開された」までの一連のサイクルに、私の監督はほとんど不要です。私はテストを信頼していますし、正直なところ、ときどき私が見るのはテストだけです。でも、実際にはそれすらあまりしません。
1つの機能（タイムトラッキング――6つのコマンド、完全にテスト済み、ドキュメント付き）では、私の作業時間はだいたい~10〜15分でした。その大半は計画のレビューとアプローチの確認で、他のことはエージェントが全部やりました。ただ率直に言うと、今では小さな機能もレビューしなくて大丈夫だと信じています。
ツールが実際にやっていること
cup はClickUpのCLIです。出力モードは3つ：
- ターミナル上：タスクピッカー付きのインタラクティブなテーブル、カラフルな出力
- パイプ（エージェントが見るもの）：きれいなマークダウンで、コンテキストウィンドウに合わせたサイズ
--json：スクリプト用の構造化データ
```bash
モーニングスタンドアップ
cup summary
エージェントがタスクを読み、作業して、更新する
cup task PROJ-123 cup update PROJ-123 -s "in progress"
...作業する ...
cup comment PROJ-123 -m "Fixed in commit abc1234" cup update PROJ-123 -s "in review" ```
タスク、コメント、スプリント、チェックリスト、タイムトラッキング、カスタムフィールド、タグ、依存関係、添付ファイルを扱う40以上のコマンドがあります。各機能はすべてテスト済みです。リポジトリには、Claude Code、OpenCode、Codex向けのすぐ使えるスキルファイルが含まれています（これらは私が実際にレビューやテストに必要だった数少ないものの一部です）。
GitHub: https://github.com/krodak/clickup-cli npm: https://www.npmjs.com/package/@krodak/clickup-cli
自分のワークフローのためにCLIツールを作ろうと考えているなら、教えてください。CLI + スキルファイルのパターンは、最近私の最大の生産性の解放（ブレイクスルー）でした。
[link] [comments]
