Cursor に Custom Package ガイドを書いてもらった。
----
# Custom Package ガイド

Cursor の Custom Package で AI アシスタントに独自機能を追加するための実践手順をまとめます。パッケージを自作し、`.cursor/packages` 配下に配置することを前提にしています。

## 1. Custom Package とは
- AI アシスタントに追加ツール（コマンド）を提供するプラグイン。
- プロジェクト直下の `.cursor/packages/<package-name>/` に置く。
- `package.json` にメタ情報と提供ツールを列挙し、`tools/` 配下で実装する。

## 2. 配置と仕組み
- 参照先: `<project>/.cursor/packages/<package-name>/`
- UI の「Add Custom Package」でローカルパスまたはリポジトリ URL を登録すると有効化される。
- ツールの入出力は、定義した関数（例: `run`）やエクスポートを通して AI に返却される。

## 3. 典型ディレクトリ構成
```
.cursor/
packages/
my-package/
package.json # 名前・バージョン・ツール定義
https://t.co/u7KW6gPXyM # 使い方・依存・注意点
tools/
callApi.ts # ツール実装
schemas/
callApi.json # 入力の JSON Schema（任意）
assets/ # 必要なら補助データ
```

## 4. 最小サンプル
### package.json の例
```json
{
"name": "my-package",
"version": "0.1.0",
"description": "社内APIを叩く補助ツール群",
"tools": [
{
"name": "callInternalApi",
"description": "社内のRESTエンドポイントを呼び出す",
"entry": "tools/callInternalApi.js",
"schema": "schemas/callInternalApi.json"
}
]
}
```

### ツール実装例（Node/TypeScript）
```ts
// tools/callInternalApi.ts
import fetch from "node-fetch";

export async function run({ path, method = "GET", body }) {
const baseUrl = process.env.INTERNAL_API_BASE;
if (!baseUrl) throw new Error("INTERNAL_API_BASE is not set");

const res = await fetch(`${baseUrl}${path}`, {
method,
headers: {
"Content-Type": "application/json",
"Authorization": `Bearer ${process.env.INTERNAL_API_TOKEN || ""}`
},
body: method !== "GET" ? JSON.stringify(body ?? {}) : undefined
});

if (!res.ok) {
const text = await res.text();
throw new Error(`API error ${res.status}: ${text}`);
}
return await res.json(); // AI に返るレスポンス
}
```

### 入力スキーマ例
```json
{
"type": "object",
"properties": {
"path": { "type": "string" },
"method": { "type": "string", "enum": ["GET", "POST", "PUT", "DELETE"] },
"body": { "type": "object" }
},
"required": ["path"]
}
```

## 5. 追加・有効化手順
- UI: `Tools & MCP` → Packages → 「Add Custom Package」→ ローカルパス（例: `<project>/.cursor/packages/my-package`）またはリポジトリ URL を指定。
- 手動配置のみの場合でも、同パスに置いた後 UI から登録すれば利用可能。

## 6. 開発フローの目安
1. 要件整理: どんなコマンドを提供するか、入力と出力の形を決める。
2. スキーマ設計: JSON Schema で必須項目・型・制約を定義する。
3. 実装: `tools/` に関数を実装（`run` などエントリポイントをエクスポート）。
4. シークレット管理: API キー等は環境変数・`.env`（コミットしない）で渡す。
5. テスト: ローカルで単体／スモークテストを行い、想定レスポンスとエラーを確認。
6. ドキュメント: https://t.co/u7KW6gPXyM に使い方・引数・依存・例外ケースをまとめる。

## 7. ベストプラクティス
- スキーマで入力を厳格化し、エラーはユーザに分かりやすく返す。
- タイムアウト・リトライ・HTTP ステータス別のメッセージを用意する。
- ログ／出力は「概要」と「詳細」を分け、AI が読みやすい形式にする。
- 依存パッケージは最小限にし、バージョンを固定またはレンジを狭く保つ。
- セキュリティ: 秘密情報を平文で同梱しない。内部 API の権限を絞る。

## 8. 動作確認チェックリスト
- UI でパッケージが一覧に表示されるか。
- ツール名（例: `callInternalApi`）が候補に出るか、呼び出し結果が返るか。
- 必須パラメータ欠落時に適切なエラーメッセージが出るか。
- ネットワーク異常時にタイムアウト・再試行・原因表示ができているか。

## 9. トラブルシュートのヒント
- 読み込まれない: `package.json` のパスや `entry` が正しいか確認。
- 依存エラー: パッケージ内に必要な依存を含める、または軽量な実装に置き換える。
- 権限エラー: API トークンやベース URL の環境変数設定を再確認。
- 返却形式のズレ: 実装の戻り値がシリアライズ可能か（JSON 化）を確認。

## 10. 追加で役立つテンプレ
- REST 以外に GraphQL, gRPC, DB クエリなどもツール化可能。
- 反復処理やテンプレ生成など、純粋ロジックのヘルパーもパッケージ化できる。

以上をベースに、自分たちのワークフローに合わせてパッケージを拡張してください。 December 12, 2025

もちふぃった〜完全に理解した‼︎
blender側はblender作業パスのjsonをunity側はeditor パスを読むから、この二つのファイルを一致させないと生成されるプロファイルがズレるんだ！たぶん！ December 12, 2025