デモ
公開または申告されたデモと、自動キャプチャによるプレビュー。
ビルダー向け
AIで作ったソフトウェアを、試せて再利用できる掲載にする。
buildsfor は厳選したビルドと招待制のビルダーから始めます。実物を見せ、何を再利用できるかを説明し、セットアップや調整の相談を掲載に紐づけます。
ビルダー基準
ビルドそのものが、最初のプロダクト面です
良い掲載は、何が生成され、何を試せて、ソースアクセスに何が含まれ、どこで支援を受けられるかを説明します。
- ビルドはデモ、プロダクト、実績、スターターキットになり得る
- 検査は保証ではなく、確認結果として記録する
- ソースアクセスは、セットアップ情報が見えるほど扱いやすい
- チームはゼロから作る前に、近いビルドを比較できる
- プロジェクトルームはビルドに紐づいたまま残す
判断材料
確認できる掲載に含まれるもの
6つの判断材料がそろうと、利用者は相談の前に適合を判断できます。
パッケージ情報
提供形式、同梱物、外部サービス、環境変数、セットアップ手順。
検査ノート
何をスキャンし、何を確認し、どの検出結果が出たかの記録。
由来
使用ツール、モデル文脈、リポジトリコミット、ビルダー確認。
再利用条件
ライセンス、商用利用、再配布の扱い、バージョン範囲。
支援範囲
提供できるセットアップや調整と、範囲外にすること。
流れ
生成されたビルドを、確認できる掲載にする
まずは分かりやすい掲載を作ります。ソースアクセスや支援は、提供条件が理解できる状態になってから追加します。
01
掲載ドラフトを作る
ビルドの内容を説明し、スクリーンショットやデモリンク、バージョン、提供形式を登録します。
02
ビルド情報を追加する
外部サービス、環境変数、セットアップ手順、ライセンス条件、既知の制限を整理します。
03
検査ノートを追加する
何をスキャンし、何を確認し、どの検出結果が出たかを記録します。
04
提供条件を決める
ソースパックやスターターキットは、提供物と支援範囲が明確なときだけ掲載します。
掲載ルール
ビルドを掲載し、判断材料もそろえる。
魅力的な掲載でも、過度な約束は不要です。利用者が受け取るもの、確認したこと、報告されたこと、範囲外のことを明確にします。
まず掲載から
提供条件を整える前に、ビルドを掲載する。
ビルドは後からソースパック、スターターキット、セットアップ案件になります。最初の役割は、何が存在し、何を再利用できるかを見せることです。