CreateCLI

カスタマイズ

実行する前に、ユーザーによるカスタマイズを次の場所で確認してください： ~/.claude/LIFEOS/USER/CUSTOMIZATIONS/SKILLS/CreateCLI/

このディレクトリが存在する場合は、そこにある PREFERENCES.md、設定、リソースを読み込み、適用してください。これらはデフォルトの動作より優先されます。ディレクトリが存在しない場合は、スキルのデフォルト設定を使用してください。

🚨 必須：音声通知（実行前に必須）

このスキルが呼び出されたら、ほかの何かを行う前に必ずこの通知を送信してください。

1. 音声通知を送信：

   curl -s -X POST http://localhost:31337/notify \
     -H "Content-Type: application/json" \
     -d '{"message": "Running the WORKFLOWNAME workflow in the CreateCLI skill to ACTION"}' \
     > /dev/null 2>&1 &
   

2. テキスト通知を出力：

   Running the **WorkflowName** workflow in the **CreateCLI** skill to ACTION...
   

これは任意ではありません。このスキルの呼び出し時に、直ちにこの curl コマンドを実行してください。

CreateCLI

概要

本番環境に対応した TypeScript CLI を生成します。すべての CLI には、完全な実装、README と QUICKSTART、Bun の package.json、厳格な tsconfig、JSON 出力、適切な終了コードが含まれます。3 段階のテンプレートシステムが、適切な複雑さを選択します。Tier 1 は依存関係なしの手動引数解析（ほとんどの場合）、Tier 2 はサブコマンド用の Commander.js、Tier 3 はエンタープライズ規模の参考例としての oclif です。

課題

同じ CLI を何度も一から作ることになります。最初は bash スクリプトとして始まり、次にエラー処理が必要になり、ヘルプテキストが必要になり、型安全性が必要になり、最後にはドキュメントを後付けした TypeScript に書き直すことになります。毎回、同じ定型コードと同じミスが繰り返されます。このスキルは、その一連の作業全体を引き受け、用途に合ったティアで、クリーンで型付けされ、ドキュメントが整った CLI を一度に生成します。

仕組み

ドキュメント、型安全性、エラー処理、CLI ファーストアーキテクチャの原則を備えた、本番環境に対応した TypeScript CLI を生成します。

---

ワークフローの振り分け

リクエストに応じて、適切なワークフローに振り分けてください。

ワークフローを実行するときは、この通知を直接出力してください：

Running the **WorkflowName** workflow in the **CreateCLI** skill to ACTION...

ワークフロー	トリガー	ファイル
CreateCli	新しい CLI ツールを一から作成する	Workflows/CreateCli.md
AddCommand	既存の CLI に新しいコマンドを追加する	Workflows/AddCommand.md
UpgradeTier	CLI をより上位のティアにアップグレードする	Workflows/UpgradeTier.md

---

🚀 このスキルを有効にするタイミング

次のようなパターンが見られたら有効にしてください。

直接的なリクエスト

• 「[API／サービス／ツール] 用の CLI を作成して」
• 「X 用のコマンドラインインターフェースを構築して」
• 「Y を実行する CLI を作って」
• 「TypeScript CLI を生成して」
• 「Z 用の CLI ツールが必要です」

文脈からの手がかり

• ユーザーが繰り返し発生する API 呼び出しについて説明している → CLI を提案する
• ユーザーが「このコマンドを何度も入力している」と述べている → CLI ラッパーを提案する
• ユーザーが複雑な処理を行う bash スクリプトを使っている → TypeScript CLI への置き換えを提案する
• ユーザーが公式 CLI のない API を扱っている → CLI の作成を提案する

例

• ✅ 「GitHub API 用の CLI を作成して」
• ✅ 「CSV ファイルを処理するコマンドラインツールを構築して」
• ✅ 「データベースのマイグレーション用 CLI を作って」
• ✅ 「この API をラップする CLI を生成して」
• ✅ 「Notion API 用の llcli のようなツールが必要です」

---

💡 主な機能

3 段階のテンプレートシステム

Tier 1：llcli スタイル（デフォルト — 80% のユースケース）

• 手動の引数解析（process.argv）
• フレームワークの依存関係なし
• Bun + TypeScript
• 型安全なインターフェース
• 合計約 300～400 行
• 最適な用途： API クライアント、データ変換ツール、シンプルな自動化

Tier 1 を使用する場合：

• ✅ コマンド数が 2～10 個
• ✅ シンプルな引数（フラグ、値）
• ✅ JSON 出力
• ✅ サブコマンドなし
• ✅ 高速な開発

Tier 2：Commander.js（拡張 — 15% のユースケース）

• フレームワークベースの解析
• サブコマンドとネストされたオプション
• ヘルプを自動生成
• プラグイン対応
• 最適な用途： 複雑な複数コマンドのツール

Tier 2 を使用する場合：

• ❌ グループ化が必要なコマンドが 10 個以上
• ❌ 複雑なネストされたオプション
• ❌ プラグインアーキテクチャ
• ❌ 複数の出力形式

Tier 3：oclif（参考のみ — 5% のユースケース）

• ドキュメントのみ（テンプレートなし）
• エンタープライズグレードのプラグインシステム
• 最適な用途： Heroku CLI、Salesforce CLI 規模（まれ）

生成されるすべての CLI に含まれるもの

1. 完全な実装

• 完全な型安全性を備えた TypeScript ソース
• すべてのコマンドが機能し、テスト済み
• 適切な終了コードを伴うエラー処理
• 構成管理

2. 包括的なドキュメント

• 設計思想、使用方法、例を記載した README.md
• 一般的なパターン向けの QUICKSTART.md
• インラインヘルプテキスト (--help)
• API レスポンスのドキュメント

3. 開発環境のセットアップ

• package.json (Bun 構成)
• tsconfig.json (strict モード)
• .env.example (構成テンプレート)
• ファイル権限の設定

4. 品質基準

• 全体を通じて型安全
• 決定的な出力 (JSON)
• コンポーザブル (jq、grep へのパイプ)
• コンテキストを含むエラーメッセージ
• 終了コードの準拠

---

🏗️ LifeOS との統合

テクノロジースタックの整合性

生成される CLI は LifeOS 標準に従います:

• ✅ ランタイム: Bun (Node.js ではない)
• ✅ 言語: TypeScript (JavaScript や Python ではない)
• ✅ パッケージマネージャー: Bun (npm/yarn/pnpm ではない)
• ✅ テスト: Vitest (テストを追加する場合)
• ✅ 出力: 決定的な JSON (コンポーザブル)
• ✅ ドキュメント: README + QUICKSTART (llcli パターン)

リポジトリの配置

生成される CLI の配置先:

• ~/.claude/LIFEOS/TOOLS/[cli-name]/ - 個人用 CLI (llcli など)
• ~/Projects/[project-name]/ - プロジェクト固有の CLI
• ${PROJECTS_DIR}/LIFEOS/Examples/clis/ - サンプル CLI (公開リポジトリ)

安全性: git 操作の前に必ずリポジトリの場所を確認してください

CLI ファーストアーキテクチャの原則

生成されるすべての CLI は以下に従います:

1. 決定的 - 同じ入力 → 同じ出力
2. クリーン - 単一責任
3. コンポーザブル - JSON 出力を他のツールにパイプ
4. ドキュメント化 - 包括的なヘルプと例
5. テスト可能 - 予測可能な動作

---

📚 拡張コンテキスト

詳細については、以下のファイルをお読みください:

ワークフローのドキュメント

• Workflows/CreateCli.md - メインの CLI 生成ワークフロー (決定木、10 ステップのプロセス)
• Workflows/AddCommand.md - 既存の CLI へのコマンド追加
• Workflows/UpgradeTier.md - シンプル → 複雑への移行

リファレンスドキュメント

• FrameworkComparison.md - 手動 vs Commander vs oclif (調査付き)
• Patterns.md - 一般的な CLI パターン (llcli の分析より)
• TypescriptPatterns.md - 型安全性パターン (tsx、vite、bun の調査より)

---

📖 例

例 1: API クライアント CLI (ティア 1)

ユーザーリクエスト: 「リポジトリの一覧表示、issue の作成、コード検索ができる GitHub API 用の CLI を作成して」

生成される構造:

~/.claude/LIFEOS/TOOLS/ghcli/
├── ghcli.ts              # 350 lines, complete implementation
├── package.json          # Bun + TypeScript
├── tsconfig.json         # Strict mode
├── .env.example          # GITHUB_TOKEN=your_token
├── README.md             # Full documentation
└── QUICKSTART.md         # Common use cases

使用方法:

ghcli repos --user exampleuser
ghcli issues create --repo myrepo --title "Bug fix"
ghcli search "typescript CLI"
ghcli --help

---

例 2: ファイルプロセッサー (ティア 1)

ユーザーリクエスト: 「frontmatter の抽出を伴って markdown ファイルを HTML に変換する CLI を構築して」

生成される構造:

~/.claude/LIFEOS/TOOLS/md2html/
├── md2html.ts
├── package.json
├── README.md
└── QUICKSTART.md

使用方法:

md2html convert input.md output.html
md2html batch *.md output/
md2html extract-frontmatter post.md

---

例 3: データパイプライン (ティア 2)

ユーザーリクエスト: 「複数のフォーマット、バリデーション、分析コマンドを備えたデータ変換用の CLI を作成して」

生成される構造:

~/.claude/LIFEOS/TOOLS/data-cli/
├── data-cli.ts           # Commander.js with subcommands
├── package.json
├── README.md
└── QUICKSTART.md

使用方法:

data-cli convert json csv input.json
data-cli validate schema data.json
data-cli analyze stats data.csv
data-cli transform filter --column=status --value=active

---

✅ 品質基準

生成されるすべての CLI はこれらのゲートを通過する必要があります:

1. コンパイル

• ✅ TypeScript がエラーゼロでコンパイルされる
• ✅ strict モードが有効
• ✅ 正当化される場合を除き any 型を使用しない

2. 機能性

• ✅ すべてのコマンドが指定どおりに動作する
• ✅ エラー処理が包括的
• ✅ 終了コードが正しい (0 は成功、1 はエラー)

3. ドキュメント

• ✅ README が設計思想と使用方法を説明している
• ✅ QUICKSTART に一般的な例がある
• ✅ --help テキストが包括的
• ✅ すべてのフラグ/オプションがドキュメント化されている

4. コード品質

• ✅ 全体を通じて型安全
• ✅ 明確な関数の分離
• ✅ 実行可能なエラーメッセージ
• ✅ 外部化された構成

5. 統合

• ✅ LifeOS テックスタック (Bun、TypeScript) に従っている
• ✅ CLI ファーストアーキテクチャの原則
• ✅ 決定的な出力 (JSON)
• ✅ 他のツールとコンポーザブル

---

🎯 設計思想

このスキルが存在する理由

開発者は API やツール向けの CLI を繰り返し作成します。そのたびに：

1. bash スクリプトから始めます
2. エラー処理が必要だと気づきます
3. ヘルプテキストが必要だと気づきます
4. 型安全性が必要だと気づきます
5. TypeScript で書き直します
6. ドキュメントを追加します
7. 本番環境で使える CLI が完成します

このスキルは手順 1〜7 を自動化します。

llcli パターン

llcli CLI（Limitless.ai API。バックエンドが Bee に移行した 2026-07-15 に提供終了。このパターンの有効性はここで受け継がれています）によって、このパターンが有効であることが実証されました：

• TypeScript 327 行
• 依存関係ゼロ（フレームワークなし）
• 完全なエラー処理
• 包括的なドキュメント
• すぐに本番環境で使用可能

このスキルは、その成功を再現します。

設計原則

1. シンプルに始める - デフォルトは Tier 1（llcli スタイル）です
2. 必要に応じて段階を上げる - Tier 2 は正当な理由がある場合にのみ使用します
3. 足場ではなく完成品を作る - すべての CLI は本番環境で使用可能な状態にします
4. ドキュメントを優先する - README では「方法」だけでなく「理由」も説明します
5. 型安全性を確保する - 常に TypeScript の strict モードを使用します

---

🔗 関連スキル

• development - 複雑な機能開発向け（CLI に限定されません）
• mcp - ウェブスクレイピング CLI 向け（Bright Data、Apify のラッパー）
• a lifelog skill - 公式ベンダー CLI（bee）を基盤に構築されたスキルの例

---

このスキルを使えば、「X 用の CLI が必要」という要望から、llcli と CLI-First Architecture の実証済みパターンに基づいた、本番環境で使えるツールを数分で作成できます。

注意点

• 必ず bun を使用し、npm/npx は使用しないでください。 システムプロンプトに従い、例外はありません。
• TypeScript のみを使用してください。 ユーザーが明示的に承認しない限り、Python の CLI は生成しないでください。
• 3 階層システム： 条件に合う最もシンプルな階層から始めてください。Tier 1 で十分な場合に、必要以上に複雑な Tier 3 の CLI を作らないでください。

実行ログ

ワークフローの完了後は、単一の JSONL エントリを追記してください：

echo '{"ts":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'","skill":"CreateCLI","workflow":"WORKFLOW_USED","input":"8_WORD_SUMMARY","status":"ok|error","duration_s":SECONDS}' >> ~/.claude/LIFEOS/MEMORY/SKILLS/execution.jsonl

WORKFLOW_USED は実行したワークフローに、8_WORD_SUMMARY は入力の簡潔な説明に、SECONDS はおおよその実時間に置き換えてください。ワークフローが失敗した場合は、status: "error" を記録してください。