temps-plugin

Temps プラグインの作成と公開

TypeScript/Bun を使用して、動作する外部プラグイン、インストール可能なソースリポジトリ、および検証内容の証拠を用意します。既存のプロジェクトが提供されている場合は、それを引き継ぎ、プロジェクトの個性、ストレージ、ユーザーによる変更を維持します。公開は、ビルドやインストールとは別の成果です。

ここでの Rust サポートは、開発とローカルシミュレーターでのテストに限られます。Rust の配布には、別途、署名付きのネイティブ npm パッケージ／カタログのパイプラインが必要ですが、このスキルでは扱いません。Cargo リポジトリを TypeScript の GitHub インストーラーに通したり、ホストのプラグインディレクトリにバイナリをコピーしたり、シンボリックリンクを作成したりしないでください。Rust での公開を依頼された場合は、エンドツーエンドの計画を提示する前に、サポート対象のネイティブリリース手順を確認してください。ユーザーの実装言語を黙って変更してはいけません。

1. 要件を明確にする

プラグインの目的、対象ユーザー、Temps 内でのエントリーポイント、入出力、永続化データ、必要なホスト権限、リソース制限、サポート対象のホスト／SDK バージョンを記録します。実装に影響する未決事項のみを確認します。GitHub からインストール可能な新規プラグインには TypeScript + Bun を優先し、既存の Rust プラグインや明示的に指定された場合は Rust を維持します。

適用されるリポジトリの指示を読みます。別のリリースのコマンドが使えると思い込まず、インストール済み CLI の plugin --help と SDK のエクスポートを確認します。TypeScript の正式なスターターテンプレートは gotempsh/temps-plugin-template です。 テンプレートの最新の README、マニフェスト、ロックファイル、CI を使用します。テンプレートは npm CLI より先に更新される場合があります。CLI にコマンドがないからといって、存在しないコマンドを作り上げてはいけません。

Temps のチェックアウトで確認できる現在の情報源：

• apps/temps-cli/src/commands/plugin/：init、build、install、update、grants、dev simulator。
• crates/temps-external-plugins/src/repository.rs：ソースインストーラーの実際のビルド要件。
• crates/temps-core/src/external_plugin/：プロトコル、権限、マニフェスト、イベント。
• sdks/node/packages/plugin-sdk/src/ および crates/temps-plugin-sdk/src/：SDK API。
• ルートの DESIGN.md、web/src/components/ui/、web/src/globals.css：現在のコンソールデザイン。

スキャフォールディングやランタイムの動作変更には development.md を、UI 作業には design.md を、配布可能なリポジトリの準備には publishing.md を参照してください。

2. 独立してビルド可能なプロジェクトをスキャフォールディングする

GitHub テンプレートを使用するか、インストール済み CLI が対応している場合は次を実行します。

bunx --bun @temps-sdk/cli plugin init my-plugin --name @your-scope/my-plugin

このコマンドはローカルファイルをスキャフォールディングするものであり、公開はしません。生成されたファイルを確認してから作業を続けます。プレースホルダーになっている識別情報、作成者、リポジトリ、バージョン、説明を置き換え、パッケージメタデータとランタイムマニフェストの整合性を保ちます。テスト済みのプラットフォームのみを追加します。ロックファイルをコミットします。認証情報、ローカルデータベース、ログ、認証関連データ、シミュレーターのセッションファイルは Git に含めないでください。

GitHub からインストールする場合は、リポジトリのルート、または --path で指定する自己完結型のプラグインサブディレクトリのどちらかを選択します。ブランチ、タグ、コミットには --ref を使用します。クリーンなチェックアウトから、ホストのインストーラー経由でコンパイルできることを確認します。ライフサイクルスクリプトや独自の UI ビルドコマンドは自動では実行されません。埋め込みアセットへの影響については、公開のリファレンスを参照してください。

3. 製品を構築する

プロトコルのハンドシェイクとトランスポートは SDK に任せてください。プロトコルの標準出力をクリーンに保ち、診断情報は標準エラー出力に記録してください。認可には検証済みの呼び出し元コンテキストを使用し、型付きエラーと、割り当てられたデータディレクトリ内のプラグイン専用ストレージを使ってください。ホストのデータとホストが仲介する AI は SDK 経由で取得し、ホストからコピーしたデータベースやプロバイダーの認証情報は使わないでください。

必要最小限のホスト権限を宣言し、設定がない場合や付与済みの権限が取り消された場合には、それが明確に分かるように処理してください。マニフェストの宣言は権限を要求し、管理者が付与します。権限で保護されるのはホスト API です。ネイティブプラグインは、引き続きホスト OS アカウントの権限で実行されます。インストール済みプラグインをサンドボックス化されていると説明してはいけません。

UI プラグインには、検出可能なナビゲーションを登録してください。選択した Temps のデザイン標準に従い、アセットを埋め込み、実際のプロキシ経路をテストしてください。デプロイの自動化では、deployment.succeeded を購読し、イベント受信処理をすばやく完了させ、上限のある永続ジョブ、冪等性、キャンセル、明示的な環境／プロジェクト設定を使用してください。

4. TypeScript のライフサイクルを 3 段階で検証する

1. ユニットテストと統合テスト： 成功、検証、失敗、永続化／再起動、処理量の上限、関連するセキュリティ事例を確認します。実際のバイナリを型チェックし、コンパイルします。
2. ローカルプラグインシミュレーター： 実際のバイナリ＋SDK プロトコル＋モックホストを使用します。サイドバー UI、イベント配信、重複、拒否／付与／取り消しされた権限、ロール制限を確認します。
3. インストール済み Temps インスタンス： レビュー済みのリポジトリリビジョンをインストールし、Temps からプラグインを開き、想定されるユーザーワークフローを実行して、権限を変更し、同じソースを更新します。対応している場合は、永続化と関連する実行者／監査の帰属を確認します。

シミュレーターのコマンドは development.md を参照してください。認証のない単独の UI プレビューで確認できるのはレイアウトだけです。シミュレーターやモック AI の結果は、実際のプロバイダー呼び出しでもホストへの完全なインストールでもありません。イベントを受信しただけでは、ジョブが完了した証拠になりません。インストール済み環境でワークフローを実行していない限り、エンドツーエンド検証が完了したと記載してはいけません。その環境を利用できない場合は、具体的な制約を記録してください。

5. TypeScript プラグインを配布、登録、保守する

標準のワークフローは GitHub リポジトリ → レビュー済みソースのインストール → カタログ PR です。この経路では、npm への公開、クラウドパブリッシャートークン、レジストリ署名鍵は必要ありません。正確なメタデータとインストール例は publishing.md を参照してください。plugin publish はネイティブな npm／署名付きカタログの別個のフローであり、GitHub リポジトリを登録することの略称ではありません。この配布経路が明示的に依頼された場合に限り使用してください。

外部公開の手順に進む前に、すべての成果物を準備し、検証してください。ユーザーがすでに与えている承認の範囲を尊重してください。スキルの作成やプラグインの構築だけで、npm への一般公開、リリースタグの作成、本番環境へのインストールを依頼されたことにはなりません。公開を依頼された場合は、具体的なリポジトリ／バージョン／権限を示し、その範囲だけを実行してください。認証情報をチャットに貼り付けるようユーザーに求めてはいけません。

最後に、ソースの場所、プレビュー／インストール手順、宣言した権限、検証の証拠、配布／カタログの状態、残っている制約を示してください。更新時は安定した ID を維持し、バージョンを慎重に設定し、ストレージを安全に移行して、同じソースからのアップグレードをテストしてください。コミットをプッシュしても、インストール済みプラグインが自動的に更新されるわけではありません。