new-terraform-provider

new-terraform-provider スキルの概要

new-terraform-provider でできること

new-terraform-provider スキルは、Plugin Framework を使って新しい Terraform provider のひな形を作るためのスキルです。バックエンド開発者やインフラ開発者向けで、理屈の説明ではなく、すぐ動かせる出発点を用意することを目的としています。

どんな人に向いているか

新しい provider workspace を作り、Go module を初期化し、main.go を接続し、最初の build/test ループまで確認したいときに new-terraform-provider スキルを使ってください。すでに作りたい provider は決まっていて、セットアップだけを正しい順序で進めたい場合に特に有効です。

何が役立つのか

このスキルは意思決定を重視します。新しい workspace を作る前に確認すべきタイミングを agent に示し、場当たり的なブレストではなく、実用的なセットアップ手順を順番に進めるよう促します。その結果、new-terraform-provider の導入でよくある「別のディレクトリにファイルを生成してしまう」「build と test の確認を飛ばしてしまう」といったつまずきを減らせます。

new-terraform-provider スキルの使い方

インストールして有効化する

まず agent 環境で new-terraform-provider install の流れを実行し、そのうえで作成・初期化したい Terraform provider プロジェクトをこのスキルに指定します。すでに既存の provider repo の中にいる場合は、まず本当に新しい workspace が必要かどうかを確認するべきです。

スキルに具体的な対象を与える

new-terraform-provider usage を最大限に活かすには、provider 名、想定する registry address、module path、そして新規作成か既存 repo の拡張かを明示してください。弱い依頼は「Terraform provider をセットアップして」です。より強い依頼は「terraform-provider-acme という新しい provider workspace を作成し、registry.terraform.io/acme/widgets を使い、当面は build target を最小限に保ってください」のような形です。

repo ファイルは順番に読む

まず SKILL.md を読み、次に assets/main.go を見て、期待される provider のエントリポイントの形を確認します。このサンプル main.go は最重要の補助資料です。debug flag、provider server の wiring、そしてどの TODO を実際の値に置き換える必要があるかが示されているからです。

スキルは完成品ではなく、ひな形として使う

このスキルの役割は、きれいな初期構築の流れを作ることです。つまり、新しい Go module、framework dependency、provider entrypoint、go mod tidy、go build -o /dev/null、go test ./... までを整えます。ただし、schema 設計、CRUD 実装、認証戦略、acceptance test の準備といった provider 設計そのものを代替するものではありません。

new-terraform-provider スキル FAQ

new-terraform-provider は新規 repo 専用ですか？

いいえ。最も向いているのは新しい workspace ですが、大きな mono-repo の中で Terraform 専用の module boundary をきれいに切りたい場合にも役立ちます。すでに provider workspace に入っているなら、別の workspace を作る前にスキルが確認を求めるはずです。

通常のプロンプトと何が違いますか？

通常のプロンプトは、重要なセットアップ手順を落としがちで、Plugin Framework のパターンに合わない main.go を生成してしまうことがあります。new-terraform-provider スキルは、より信頼できる導入フローと、空ディレクトリから provider バイナリをコンパイルできる状態まで進むための明確な順序を与えてくれます。

初心者向けのスキルですか？

はい、ガイド付きで provider プロジェクトを始めたいなら向いています。Terraform provider のアーキテクチャを学ぶ代わりにはなりませんが、最初のセットアップでの摩擦を下げ、module や build の基本ステップを落とすリスクを減らせます。

使わないほうがよいのはどんなときですか？

すでに確立した provider codebase があり、resource の追加、schema の修正、既存 binary のリファクタリングだけをしたい場合は new-terraform-provider を使わないでください。そうしたケースでは、必要のない workspace scaffolding の手順が増えるだけです。

new-terraform-provider スキルを改善するには

足りない値は最初に埋める

new-terraform-provider skill の出力をよくするには、provider address、module path、package layout、debug support が必要かどうかを最初から指定するのが効果的です。空欄のままだと、agent は example.org/terraform-provider-demo のような値や仮の registry address を推測することになり、たいてい後で手直しが必要になります。

プレースホルダーはすぐ置き換える

repo のサンプルには、特に provider address や release 時の version wiring まわりに、assets/main.go の TODO ベースのプレースホルダーが残っています。最初のパスが終わったら、scaffold が完成したと判断する前にそれらを更新してください。そうしないと、build は通っても binary がまだ demo の identity を指したままになる可能性があります。

スキルと同じ方法で scaffold を検証する

go mod tidy、go build -o /dev/null、go test ./... が新しい workspace で通って初めて、ワークフローは完了です。どれかが失敗したら、resource や acceptance test を追加する前に、module path、provider import path、package layout を修正してください。

scaffold から実際の provider 設計へ段階的に進める

workspace が安定したら、次は provider schema、authentication、resource layout、documentation generation を依頼してください。ここで new-terraform-provider for Backend Development が最も価値を発揮します。土台を正しく作り、その後の実装詳細は次の集中した段階に任せられるからです。