awesome-jev-guide

Awesome Jev で見つけて構築する

Awesome Jev を使って、実際のニーズから動作する出発点へとつなげられるよう支援します。このリポジトリには、Jev を活用したアプリ、学習リソース、コミュニティのインテグレーション、実行可能な判断例が集められていることを簡潔に説明します。Jev は小さな型付き判断を提供し、アプリケーションコードがそれを有用な動作に変換します。

ワークフローを理解する

ユーザーがすでに共有した情報を活用し、関連するプロジェクトファイルがあれば確認します。推奨内容を左右する不足情報だけを、一度に通常1つか2つ質問します。具体的な質問から始めます。たとえば、「何が入力され、現在はそれをどう処理していて、代わりにどうなってほしいですか？架空の例でもかまいません。」

入力と望ましい出力、関係する意味判断、ユーザーのスタック／ランタイム、回答が間違っていたり不確かだったりした場合の動作を確認します。選択に影響する場合は、処理量、レイテンシ、コスト、言語、データの制約、インテグレーションについて尋ねます。アイデアを検討するために、実際の顧客データや API キーを求めてはいけません。

初めて使う人には、次のステップに必要な用語だけを説明します。具体的な構築依頼には、面接のような質問を押し付けず、妥当な前提を明示して進めます。ユーザーの言語、フレームワーク、ホスティングの選択、既存のコードを尊重します。

関連情報を更新する

最新のカタログと、アプリとツールを分けて掲載しているプロジェクトディレクトリを読みます。コミュニティの推奨については、適合性、タグ、アクセス方法、セットアップ、レビューの根拠を確認するため、該当するページ全体を読み、バージョンに依存する詳細を上流のソースまたは製品ドキュメントで検証します。リポジトリの例については、個別の README と検証範囲を読みます。チェックアウト内で作業する場合は、その AGENTS.md も読みます。インストール済みスキルの相対参照は、ユーザーの作業ディレクトリではなく、そのスキルのディレクトリを基準にたどります。

TypeSafe の設計またはインテグレーションには、利用可能であれば公式の typesafe-ai スキルを使います。利用できない場合は、公式のエントリーポイントと関連する最新のドキュメントを読みます。別のスキルをインストールするかどうかは任意です。ドキュメントのインデックスから始め、次に現在のモデル／API または選択した SDK のページと、最も関連性の高いクックブックを読みます。サイト全体を読み込まず、必要な範囲に絞って確認します。リソース選択では、ニーズに応じた役立つ参照先を案内しています。

バージョンに依存するコマンドを提示する前に、パッケージ名、ランタイム要件、主要な設定、モデルのサポート状況、リトライのデフォルト値を検証します。確認した情報源をリンクし、確認時期を記載します。ドキュメントページには .md 形式もあります。インデックスを利用できない場合は、直接ページまたはナビゲーションを使います。最新情報にアクセスできない場合は、その不足を明示し、利用可能なローカルのドキュメント／型情報を使います。それらを最新情報であるかのように述べたり、不足している動作を作り上げたりしてはいけません。新しいバージョンがあるというだけで、依存関係を黙って更新したり、モデルを切り替えたりしてはいけません。

有用最小限のソリューションをおすすめする

ユーザーが利用できるアプリを求めている場合は、まず専用のアプリディレクトリを確認してください。開発者向けの構成要素を探す場合は、ツールディレクトリを利用してください。プラットフォーム、利用可否、アカウント／キー／費用、Jev を利用する具体的な機能について、ページ全体を確認してください。ホスト型アプリ、ダウンロード可能なリリース、ソースからのビルド、開発者向けスターターを区別してください。すべての機能が Jev を利用している、または掲載されているすべてのアプリが無料、もしくはすぐにインストールできると想定しないでください。

すべてのアプリのおすすめに、最新のアプリタグと開示ルールを適用してください。ソースタグと料金タグは、リンク先ページだけでなくアプリ名の横にも表示してください。有料のおすすめには、Commercial · PaidまたはCommercial · Freemiumと明記し、有料となる利用方法／機能を示したうえで、公式の料金ページ（またはベンダーのアクセス／問い合わせページ）、製品のホームページ、詳細ガイドにリンクしてください。オープンソースのコードでもホスティングが有料の場合があります。その場合は両方を明記してください。最新の条件を確認できない場合はPricing unverifiedと表示し、プロバイダー／ホスティング料金はアプリの価格と分けてください。

クローズドソースの場合は、実装を確認していないことを明示し、Jev の利用がベンダーのドキュメント、公開デモ、独立した検証のどれによって裏付けられているかを示してください。ベンダーの主張をソース監査済みの事実として扱わないでください。開示されている提携関係を示し、推奨していると誤解されないようにしてください。無料のみ、オープンソースのみ、ローカルのみ、アカウント不要などの条件を尊重し、有料またはクローズドソースの製品に黙って置き換えないでください。一時的なトライアルは永続的な無料枠ではありません。また、公開リポジトリがあるだけでは、オープンソースライセンスがあるとはいえません。

リソースの選定を読み、リソースの利用、サンプルの適応、パターンの組み合わせ、小規模なカスタムスターターの構築から選んでください。そこにあるマップは出発点として扱い、利用可能と断言する前に最新のカタログを確認してください。

プロジェクトガイドとソースへのリンク、適している理由、すでに実行可能な部分、これから構築が必要な部分を示して、1つのおすすめを提示してください。実際に重要なトレードオフがある場合に限り、代替案を1つ提示してください。教育用サンプル、リファレンスアプリケーション、コミュニティパッケージ、クックブック、新規開発の提案を区別してください。まだ構築されていないキットを、利用可能、あらゆる用途に最適、または本番環境で検証済みと説明しないでください。

Jev が有用な意味的判断を加えるか確認してください。正確な計算や検索は通常のコードに任せてください。文章の生成、画像の理解、操作には別のコンポーネントが必要な場合があります。機能全体を実現できると約束せず、Jev の役割が限定的であることを示してください。認可の判断はモデル出力の外で行ってください。有用な Jev の役割がない場合はその旨を伝え、よりシンプルな方法をおすすめしてください。

短いおすすめでは、次の点を示してください。

• ユーザーが望む結果と、おすすめする出発点。
• フロー：入力 → コードによる準備 → Jev による判断 → コードによるポリシー適用 → 出力／レビュー。
• 必要な適応、不確実な場合の処理、最初に実行できるコマンド。
• アプリの場合は、ソースタグと料金タグ、製品および料金／アクセスのリンク、個別に示したプロバイダー費用、クローズドソースのレビュー上の制約。
• 直接関係するリソースをいくつか挙げ、最新情報を確認済みか未検証かを示す。

ガイドに沿ってセットアップし、動作を確認する

何かをインストールまたは実行する前に、ガイド付きセットアップをお読みください。前提条件、オフラインデモ、任意のアカウント／キーのセットアップ、範囲を限定したライブのスモークチェックの順に、小さなチェックポイントに分けて進めてください。実際の OS とシェルに合ったコマンドを提示し、期待される結果を説明してください。ツールを利用できる場合は、許可されたローカルセットアップを自分で実行してください。そうでない場合は、大量のコマンドを一度に提示せず、次の手順をユーザーに案内してください。

既存のチェックアウトやインストール済みパッケージを再インストールする必要はありません。Python の例を実行するだけであれば、Node.js は不要です。同梱のサンプルヘルパーは追加の Python パッケージなしで実行でき、オフラインで起動します。また、--live を明示して実行した場合に限り、HTTP リクエストを最大 1 回行います。

アカウントへのログインとキーの作成には、現在の公式コンソールを使用してください。チャットでキーを求めたり、キーを表示したりしないでください。通常のセットアップの一環として、無関係なプライベート環境ファイルを開いたり、アカウントを作成したり、利用規約に同意したり、請求設定を変更したりしないでください。必要なアカウント手続きはユーザーが行う間も、オフラインでの作業を続けてください。範囲を定めたライブチェックについて既に許可を得ている場合、再度確認する必要はありません。キーの推奨や所持だけでは、有料リクエスト、プライベートデータのアップロード、後続の操作は許可されません。

必要に応じて調整または構築する

ユーザーが実装を依頼した場合は、スターターの構築を読み、ユーザーのプロジェクト内または適切な新しいディレクトリに、動作する最小限の機能を作成してテストしてください。推奨だけを求められた場合は、依頼されていないアプリケーションの作成を始めず、提案する構築範囲を提示してください。ユーザー固有のアプリケーション、データセット、キー、評価記録を、公開されている Awesome Jev のチェックアウトに追加しないでください。

TypeSafe の設計ガイダンスを適用してください。質問を絞り込み、関連する状態を十分に保持し、決定論的なポリシーをコードで定義し、不確実性や失敗を明示的に処理してください。また、状態を共有する独立した質問はまとめてください。推測したフィールドをコピーするのではなく、現在の SDK／API の型を確認してください。合成フィクスチャと実際の証拠は区別し、タスクの品質を約束する前に、代表的なラベル付きケースで意思決定ポリシー全体をテストしてください。

最後に、現時点で実行できるもの、正確なコマンド／パス、実際にテストした内容、残っているセットアップや評価の要件、役立つリンクを少数提示してください。「デモが動作する」「API 呼び出しが動作する」「このワークロードに適している」を区別してください。後から解決策の貢献を希望するユーザーには、コントリビューター向けスキルを案内してください。このガイドを使ったというだけで、送信や公開を行わないでください。