community-publish

Name: community-publish
Author: starchild-ai-agent

github.com/starchild-ai-agentクラウド・DevOps304.0k 回インストール6 日前に更新

community-publish について

community-publishは、プロジェクトの公開URL、ソースコード公開、コミュニティギャラリーやサービスマーケットへの掲載を管理するスキルです。URL公開、ギャラリーでの発見、有料掲載を別々の操作として扱い、それぞれの状態を確認できます。

主な機能

01公開プレビューURLの公開と停止
02プロジェクトコードのGitHubへのプッシュ
03無料プロジェクトの掲載と取り下げ
04有料サービスの作成・審査・公開
05公開・審査・掲載状態の確認
06公開プレビューとオープンソースコードの連携

活用シーン

01稼働中サービスのプレビュー共有
02プロジェクトコードのGitHub公開
03無料プロジェクトのギャラリー掲載
04有料サービスの審査申請と掲載

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/starchild-ai-agent/official-skills --skill community-publish

インストール後、Claude Code で/community-publishを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

__init__.py

exports.py

lib/

gateway.py

install.py

manifest.py

validate.py

詳細

2 つの概念: PUBLISH と LIST — 決して混同しないでください

このスキルは、根本的に異なる 2 つの概念を扱います。これらを混同することが、誤った回答の最大の原因です。

概念	意味	関数
PUBLISH (发布)	何かをアクセス可能にする — URL が機能する、またはコードが GitHub 上にある	`publish_preview`、`unpublish_preview`、`list_published_previews`、`open_source`、`remove_open_source`、`list_open_source`、`get_open_source`、`fork`、`validate_open_source`
LIST (上架)	何かをマーケットプレイス上で発見可能/購入可能にする	無料: `list_in_dashboard`、`unlist_from_dashboard`、`delete_listing`、`get_listing_status` 有料: `create_paid_service`、`submit_for_review`、`get_review_status`、`publish_service`、`unpublish_service`、`list_my_services`、`get_service`、`update_service`、`delete_service`、`restore_service` カバー: `upload_cover_image` 閲覧 + コンシューマー: `explore_services`、`get_service_detail`、`get_service_pricing`、`get_service_reviews`、`write_service_review`、`favorite_service`、`unfavorite_service`、`get_favorite_services`、`get_user_services`、`get_service_earnings`、`get_earnings_summary`、`get_service_tags`、`get_featured_services` プロジェクト照会: `explore_projects`、`my_projects`、`favorite_projects`、`get_tab_counts`、`get_popular_tags`、`get_user_projects`、`favorite_project`、`unfavorite_project`

PUBLISH しても自動的に LIST されるわけではありません。 publish_preview() は URL を割り当てるだけです。open_source() はコードをプッシュするだけです。どちらもプロジェクトをマーケットプレイス上で発見可能にはしません — それには別途、意図的な LIST 呼び出しが必要です。

LIST には 2 つのフローがあります

フロー	使用する場面	レビュー?	価格設定?	関数
無料 LIST	無料プロジェクト、`/projects` ギャラリーに表示	いいえ	いいえ	`list_in_dashboard()`
有料 LIST	x402 経由でアクセスに課金	必須 (6 項目のレビュー、公開前に合格が必要)	はい (プラットフォームネットワーク上の USDC/USDG/USDC(Solana) — デフォルトは Base+Monad+Robinhood+X Layer+Solana、`all` に従う)	`create_paid_service()` → `submit_for_review()` (必須) → `publish_service()`

POST /api/services は service_type: "free_project" を受け付けなくなりました。 無料 LIST は list_in_dashboard() (プロジェクトギャラリーのフロー) で行います。有料 LIST は create_paid_service() + レビュー + 公開 (サービス API のフロー) を使用します。

期間限定無料プロモーション ≠ このスキル

有料サービスが LIST された後、オーナーは期間限定無料プロモーション (free_promo_start / free_promo_end) を実施できます。これはマーケットプレイスの LIST 作業ではなく、ここでは実装されていません。

概念	内容	場所
無料 LIST	`/projects` ギャラリー上の無料プロジェクト	このスキル → `list_in_dashboard()`
`free_trial_count`	課金前の N 回の無料呼び出し (pay_per_use のみ)	このスキル → `create_paid_service(..., free_trial_count=N)`
期間限定無料プロモーション	カレンダー期間: 金額 0 の検証、settle/debit なし	x402 スキル → `skills/x402/references/selling.md` のセクション期間限定無料プロモーション

すでに有料の LIST に対してユーザーが「开限时免费 / free promo / free for N days」を求めた場合: x402 スキルを読んでください (セルフチェック P1–P5、その後 PUT free-promo)。community-publish で API を勝手に作ったり、free_trial_count と混同したりしないでください。

可視性モデル — 「他の人に見えますか？」に答える前にこれを読んでください

プロジェクトの「公開性」は 3 つの直交するスイッチであり、1 つではありません:

スイッチ	オフの状態	オンの状態	切り替えるもの
URL アクセス	URL にアクセスすると 404 が返る	リンクを知っている人は誰でも URL が使える	`publish_preview` / `unpublish_preview`
ギャラリーでの発見可能性	`/projects` ギャラリーに表示されない	ギャラリーに表示される	`list_in_dashboard` / `unlist_from_dashboard`
マーケットプレイスへの掲載	Service Marketplace に表示されない	発見可能 + 購入可能	`create_paid_service` + `publish_service` / `unpublish_service`

プロジェクトはどのような組み合わせにもなり得ます。これらを「もう公開されているか」にまとめてしまわないでください。

ステータスに関する質問は読み取り専用の操作です。 ユーザーが次のように尋ねるたびに:

「もう表示されていますか / 公開されていますか / 発見可能ですか？」
「上架了吗 / 在 dashboard 上吗 / 别人能看到吗」
「掲載は公開されていますか？」

権威ある回答は、新たな get_listing_status(slug)（無料）または get_review_status(service_id)（有料）の呼び出しからのみ得られます。過去の操作から推測しないでください。

プロジェクトの種類 — 3 つのみ

type	それが何か	`publish_preview()` の対象になるか？
`task`	スケジュールされた cron/interval ジョブ	いいえ（HTTP ポートなし）
`service`	長時間実行される HTTP サービス（dashboard、API、ページ）	はい
`script`	ワンショットスクリプト	いいえ（HTTP ポートなし）

ルーティング — ユーザーの意図を適切なアクションに結びつける

A. ステータスの意図 — ユーザーが現在の状態を知りたい

表現例	アクション
「表示されていますか / 公開されていますか / 発見可能ですか / 公開中ですか？」	`get_listing_status(slug)`
「上架了吗 / 在 dashboard 上吗 / 别人能不能看到」	`get_listing_status(slug)`
「公開した URL は何ですか？」 / 「我发布了哪些」	`list_published_previews()`
「何がオープンソースになっていますか？」 / 「都有哪些开源代码」	`list_open_source(...)`
「我的服务」 / 「my services」 / 「我的付费服务」	`list_my_services()`
「审核状态」 / 「审核通过了吗」 / 「review status」	`get_review_status(service_id)`

B. アクションインテント — ユーザーが状態の変更を望んでいる場合

サンプル表現	アクション	備考
「publish」/「share」/「make public」/「公开」/「发布」（修飾子なし）	`publish_preview(preview_id)`	URL を割り当てるのみです。リスト登録は自動では切り替わりません。
「list on the dashboard」/「上架」/「show on community」/「make discoverable」/「发到广场」	`list_in_dashboard(slug)`	無料リスト登録です。プレビューがすでに存在している必要があります。
「上架付费服务」/「make this a paid service」/「上架到服务市场（付费）」	`create_paid_service(...)` → `submit_for_review()`（推奨）→ `publish_service()`	有料リスト登録です。先に x402 の設定が必要です。
「publish AND list」/「发布并上架」	`publish_preview()` の後に `list_in_dashboard()`	順番に 2 つの個別呼び出しを行います。
「remove from dashboard」/「下架」/「unlist」/「hide from gallery」	`unlist_from_dashboard(slug)`	無料リスト登録のみです。ソフト非公開（`is_public=false`、`review_status='unlisted'` を設定し、統計は保持）。プレビュー URL は有効なままです。
「下架付费服务」/「unpublish service」	`unpublish_service(service_id)`	有料リスト登録のみです。
「open source」/「open-source the code」/「开源代码」	`open_source(project_dir)`	コードを GitHub にプッシュします。リスト登録は行いません。
「unpublish the URL」/「take down the link」/「停止服务」	`unpublish_preview(slug)`	プレビューのコンテナサービスのみを停止します。リスト登録の状態（`is_public`/`review_status`）には影響しません。URL はアクセス不能になります（404）。
「remove the open source」/「delete from GitHub」	`remove_open_source(slug)`
「fork」/「install someone's project」	`fork(source)`
「提交审核」/「submit for review」	`submit_for_review(service_id)`	有料のみです。必須 — 公開前に通過する必要があります
「发布服务」/「publish my service」	`publish_service(service_id)`	有料のみで、承認済みまたは非公開の状態が必要です
「更新服务」/「update service」	`update_service(service_id, ...)`	有料のみです
「删除服务」/「delete service」	`delete_service(service_id)`	有料のみです
「删除项目」/「delete listing」/「permanently remove from marketplace」	`delete_listing(slug)`	無料リスト登録のみです。リスト登録の行と `community_slugs` レコードを完全に削除します。URL はアクセス不能になります（404）。explore と my-projects の両方から削除されます。削除せずに非表示にするには `unlist_from_dashboard()` を使用してください。
読み直しても曖昧な場合	質問を 1 つ行う	「你是要 (a) 发布公开 URL，(b) 免费上架到广场，(c) 付费上架到服务市场，还是 (d) 开源代码？」

`publisher:` バインディングによる相互リンク

同じプロジェクトが公開 URL とオープンソース化されたコードの両方を持つ場合、それらをペアにして、フロントエンドがリスト登録カードに「View Source」を、コードカードに「Visit Live Demo」を表示できるようにしたいはずです。このスキルは、project.yaml 内の 1 つの明示的なバインディングを通じてそのペアリングを実現します。

バインディングの宣言方法

project.yaml に publisher: ブロックを追加します:

name: my-app
type: service
version: 1.0.0
publisher:
  code_slug: my-app               # OPTIONAL — defaults to manifest.name
  public_slug: my-app-pub         # OPTIONAL — URL suffix; defaults to code_slug

両方のフィールドは任意です。省略した場合、両方ともデフォルトで manifest.name になります。

どちらの側を先に公開してもかまいません

ゲートウェイは、2 つ目の側が到着するまで保留エントリを保持します。順序の要件はなく、手動のリンク手順もありません。

順序	何が起こるか
`open_source` が先 → `publish_preview` が後	open_source が保留エントリを記録し、publish_preview がそれを消費してリンクします
`publish_preview` が先 → `open_source` が後	publish_preview が保留エントリを記録し（`publisher_code_slug` 引数が必要）、open_source がそれを消費してリンクします

手動修復（まれ）

ペアリングが誤って接続された場合（例: リネーム後）は、次を使用します:

link_to_listing(listing_slug="2004-my-app-pub", code_slug="my-app")

アーキテクチャ

                community.iamstarchild.com (single gateway domain)
                              │
            ┌─────────────────┼─────────────────────┐
            │                 │                     │
   ┌────────▼─────────┐  ┌───▼────────────┐  ┌─────▼──────────┐
   │  /api/register   │  │/api/code-      │  │ /api/services  │
   │  /api/unregister │  │ projects/*     │  │ /api/projects- │
   │  /api/list       │  │ (GitHub-backed)│  │ query/*        │
   └────────┬─────────┘  └───┬────────────┘  └─────┬──────────┘
            │                │                     │
   ┌────────▼─────────┐  ┌───▼────────────┐  ┌─────▼──────────┐
   │ DB: route table  │  │ GitHub:        │  │ DB:            │
   │ + project_       │  │ community-     │  │ service_       │
   │   listings       │  │ projects repo  │  │ listings       │
   └──────────────────┘  └────────────────┘  │ (paid services)│
     publish_preview()    open_source()      └────────────────┘
                                              list_in_dashboard()
                                              create_paid_service()

PUBLISH: `publish_preview()` — 公開 URL

publish_preview(preview_id, slug="", title="", publisher_code_slug="")

実行中のサービスを https://community.iamstarchild.com/{user_id}-{slug} にマッピングします。

preview_id: preview(action='serve') から取得します。status=running である必要があります。
slug: URL のサフィックスのみ（小文字の英数字 + ハイフン、3〜50 文字）。user_id プレフィックスは自動的に追加されます。
title: リスティングの表示名。
publisher_code_slug: コードプロジェクトの slug へのクロスリンクを任意で紐付けます。

{"ok": True, "url": "...", "publisher": {...}, "hint": "...", "x402_detected": bool} を返します — さらに、x402_detected が true の場合には next_step の警告が付きます（有料リスティングのチェーンを完了してください）。

制約:

publish_preview は有料リスティングを作成しません。 エンドポイントが x402 経由で課金する場合（402 を返す場合）、create_paid_service → submit_for_review（推奨）→ publish_service も実行するまで公開フローは INCOMPLETE です — そうでなければ、マーケットプレイスには何も表示されないか「無料」と表示されます。課金が検出されると、戻り値がこれを示します（x402_detected: true + next_step）。
ユーザーごとの公開プレビューは最大 20 件です（超過するとゲートウェイが 429 を返します）。
サービスが実行中である必要があります。コンテナが停止すると動作しなくなります。
Starchild Fly コンテナ内でのみ動作します（FLY_MACHINE_ID が必要です）。
リスティングの可視性のデフォルトは is_public=false です。 publish_preview が成功すると URL は割り当てられますが、発見可能にはなりません。発見可能にするには、別途 list_in_dashboard() の呼び出しが必要です。

コンパニオン:

unpublish_preview(slug) — プレビューコンテナのサービスを停止します。URL はアクセス不可になります（404）。リスティングの状態には影響しません（is_public/review_status は変更されません）。
list_published_previews() — このユーザーの現在公開されているすべてのプレビュー URL。

PUBLISH: `open_source()` — GitHub へコードをプッシュする

open_source(project_dir, version_bump="patch", message="")

プロジェクトのソースを GitHub の community-projects/projects/{user_id}/{slug}/ にプッシュします。

project_dir: 例: output/projects/my-task
version_bump: patch | minor | major | none
message: このバージョンで何が変わったかを説明するコミットメッセージの本文。 あなた（エージェント）は、このセッションで行った実際のコード変更に基づいて、常にこれを書くべきです — 何が変わったかを把握しているなら、決して空のままにしないでください。ユーザーに見える変更を説明する 1〜3 行程度を目安にしてください。

これは PUBLISH アクションのみです — マーケットプレイスには何もリストしません。 プロジェクトを発見可能にするには、公開後に別途 list_in_dashboard()（無料）または create_paid_service()（有料）を呼び出してください。

コンパニオン:

fork(source, dest_dir=None) — 他の誰かがオープンソース化したプロジェクトをローカルにインストールする
list_open_source(type=None, tag=None, user=None, q=None) — GitHub カタログを閲覧する
get_open_source(source) — 1 つのプロジェクトの完全なメタデータを取得する
remove_open_source(slug) — GitHub カタログからプロジェクトディレクトリを削除する（オーナーのみ）
validate_open_source(project_dir) — 公開前の事前チェック

プロジェクト構造

output/projects/{slug}/ 配下のすべてのプロジェクト:

project.yaml      # metadata (name, version, type, env_required, sc_proxy, publisher)
PROJECT.md        # required sections: What / Required env / How to start / Outputs / Troubleshooting
.env.example      # all env vars with placeholder values
.gitignore        # secrets blacklist
src/
  ├── run.py       # for type=task (must start: # -*- task-system: v3 -*-)
  ├── index.html   # for type=service (or app.py + frontend)
  └── main.py      # for type=script

LIST (FREE): `list_in_dashboard()` — /projects ギャラリーに表示します

list_in_dashboard(slug, name=None, description="", cover_url=None, tags=None)

公開されたプレビューを https://community.iamstarchild.com/projects の公開ギャラリーで見つけられるようにします。これを行わないと、プレビューの URL は機能しますが、すでに URL を知っている人以外には見えません。

slug: publish_preview() が返す完全なスラッグ（つまり {user_id}-{suffix}）。
name: ギャラリーカードの表示名。デフォルトは slug です。
description: 500 文字以内。
cover_url: storage.googleapis.com、image.thum.io、または api.microlink.io 上のものである必要があります。ユーザーが提供した画像をアップロードするには、まず upload_cover_image(slug, file_path) を呼び出してください — これは presign → GCS アップロード → 公開 URL の返却を処理します。以下のカバー画像のアップロードを参照してください。
tags: 5 個以内のタグ、各 20 文字以内。

{"ok": True, "listing": {...}, "url": "...", "dashboard_url": "..."} を返します。

制約:

同じスラッグに対して publish_preview() が先に実行されている必要があります — そうでない場合は 404 を返します。
冪等です。異なる name/tags で再度呼び出すと、既存のリスティングが更新されます。
レビューなし、価格設定なし — これは無料リスティングのフローです。

コンパニオン:

unlist_from_dashboard(slug) — ギャラリーからソフト非公開にします（is_public=false、review_status='unlisted' を設定し、閲覧数/お気に入り数を保持します）。URL は有効なままです。再リスティングするには、list_in_dashboard() を再度呼び出します。
delete_listing(slug) — リスティング行と community_slugs レコードを完全に削除します（閲覧数/お気に入り数を削除します）。URL はアクセス不能になります（404）。explore と my-projects の両方から削除されます。削除せずに非表示にするには unlist_from_dashboard() を使用してください。
get_listing_status(slug) — 読み取り専用チェック: {ok, exists, is_public, listing} を返します。

LIST (PAID): サービスマーケットプレイスでの有料サービスリスティング

有料サービスは、x402 を通じてアクセスに課金します（プラットフォームで有効になっているネットワーク上でのオンチェーン USDC/USDG 決済 — デフォルトでは all モードに従い Base + Monad + Robinhood + X Layer + Solana）。公開前に自動 6 項目チェックのレビューが必要です — publish_service() が機能するには、サービスがすべてのチェック（承認）を通過する必要があります。API 呼び出しの例は任意ですが推奨されます。

マルチチェーン決済ネットワーク（plans-280）

すべての有料サービスには networks_mode があり、購入者がどのチェーンで支払えるかを決定します。

`networks_mode`	動作	使用する場面
`"all"`（デフォルト）	すべてのプラットフォームメインネット（現在は Base + Monad + Robinhood + X Layer + Solana。新しいチェーンはコード変更なしで自動的に追加されます）での支払いを受け付けます。ゲートウェイは `supported_networks` を NULL として保存し、読み取り時に展開します。	一般的なケース — 何も渡さない、または `networks_mode="all"` を指定します。
`"custom"`	`supported_networks` にリストされたチェーン（CAIP-2 ID の空でないリスト、例: `["eip155:8453"]`）のみでの支払いを受け付けます。プラットフォームの自動展開には追随しません。	ユーザーが明示的に「Base のみ」/「Monad のみ」/ 特定のサブセットを指定した場合。

ルール:

デフォルトは all です。 ['eip155:8453'] のような単一チェーンをデフォルトとしてハードコードしないでください — それは以前の Base のみの動作を再導入することになります。
custom には空でない supported_networks が必要です。空のリストは拒否されます。
provider_wallet は 有効なすべてのチェーンで使用される EVM アドレスです（Starchild ファシリテーターは各チェーンで同じアドレスに決済します）。Base 専用ではありません。
購入者には 402 の accepts 配列（有効なチェーンごとに 1 エントリ、同じ価格）が表示され、支払いごとに 1 つのチェーンを選択します — これは標準的な x402 のマルチ accepts であり、プロトコルの変更ではありません。
決済のガス代はプラットフォーム（Starchild ファシリテーター）が支払い、プロバイダーは支払いません。
既存のサービスを all に戻すには: update_service(service_id, networks_mode="all")。
サブセットに制限するには: update_service(service_id, networks_mode="custom", supported_networks=["eip155:8453"])。

これは x402 スキルの monetize のデフォルト（all）と整合しています。2 つのスキルは同じリリーストレイン上にあります — ゲートウェイの 402 accepts とマーケットプレイスのリスティングで異なるチェーンが表示される場合、一方が custom に設定され、もう一方が all のままになっています。

サービスのライフサイクルとレビュー状態（レビューは ADVISORY）

  create ──▶ published ──▶ submit_for_review ─▶ pending ─▶ approved / rejected
                │            (required before publishing — must pass to go live)
                │                                    │ fix via update_service(), re-check
                ▼                                    ▼
           publish_service() ─────────────────▶ listed ◀─▶ unlisted (owner takedown / re-list)
                                                     │
                                                     ▼
                                          unavailable ──▶ restore ──▶ listed

レビューはセルフチェックであり、ゲートではありません: submit_for_review() は 5 つの自動チェック（api_reachable、pricing_consistency、x402_payment、response_match、doc_completeness、examples_provided）を実行し、オーナー向けにレポートを保存します。 publish_service() はサービスが approved 状態（または再リスティングの場合は unlisted）であることを要求します。公開前にレビューに合格する必要があります — まず submit_for_review() を実行して、壊れたエンドポイントが購入者の支払い前に検出されるようにしてください。rejected レポートはリスティングをブロックしません。すでに listed のサービスに対して実行されたチェックが、そのサービスを非リスティングにすることは決してありません。

⚡ シナリオ選択の決定木 — 有料サービスを作成する前に必ず従ってください

ステップ 1: そのサービスには Starchild プロジェクトページがありますか（publish_preview() で公開されますか）？

はい、そしてそのページは無料で閲覧できます → フロー D。service_type="paid_project" + project_slug を使用します。無料ページは publish_preview() で公開され、有料 API は /api/* ルートで x402 の背後に配置されます。アップストリームアプリは / で無料の紹介ページを提供し、/api/* で有料 API を提供します。
はい、しかしページ全体に支払いが必要です → フロー B（フォーム 1）。service_type="paid_project" + project_slug を使用します。ユーザーは独自のアクセス制御（ペイウォール + 認証情報の検証）を実装します。x402 スキルの「有料プロジェクト: 2 つの形式」セクションを参照してください。
いいえ（スタンドアロン API、プロジェクトページなし） → フロー C または E。project_slug なしで service_type="paid_api" を使用します。index.html を作成したりプレビューを公開したりしないでください — 無料ページは存在しません。公開 URL のルートには x402 の 402 チャレンジまたはゲートウェイ情報が表示されます。

ステップ 2: ユーザーは異なる価格の複数の API エンドポイントを希望していますか？

はい → 1 回の create_paid_service() 呼び出しで api_endpoints 配列を使用します（フロー E）。複数の個別サービスを作成しないでください。
いいえ → 単一エンドポイントなので、api_endpoint のみを使用します。

ステップ 3: 回答を組み合わせます:

ユーザーの希望	無料ページ？	マルチエンドポイント？	フロー	service_type	project_slug	api_endpoints
有料サブスクリプションプロジェクト（サイト全体がペイウォールの背後）	はい	いいえ	B	`paid_project`	必須	—
スタンドアロン有料 API（ウェブページなし）	いいえ	いいえ	C	`paid_api`	省略	—
無料紹介ページ + 有料 API	はい	いいえ	D	`paid_project`	必須	—
無料紹介ページ + 複数の有料 API	はい	はい	D+E	`paid_project`	必須	必須
複数の有料 API（ウェブページなし）	いいえ	はい	E	`paid_api`	省略	必須

⚠️ よくある Flow の混乱による誤り（実際のインシデントより）

誤り	何が問題になるか	正しい対応
ユーザーが「紹介ページ AND 有料 API を書いて」と言ったのに、エージェントが `paid_api` を使い、さらに別のプロジェクトプレビューを作成する	サービスとプロジェクトが分断される — マーケットプレイスに 2 つの項目が表示され、1 つは無料（空）、1 つは有料になる	`paid_project` + `project_slug` を使います（Flow D）。紹介ページと API は 1 つのサービスです。
ユーザーが「純粋な有料 API」と言ったのに、エージェントが index.html を作成してプレビューを公開する	不要な無料プロジェクトページがマーケットプレイスを散らかします。紹介ページが空または JSON を表示する可能性があります	index.html を作成したり publish_preview を実行したりしないでください。`paid_api` を使います（Flow C）。x402 ゲートウェイの 402 レスポンスが API の自己記述そのものです。
ユーザーが「複数の API エンドポイント」と言ったのに、エージェントが N 個の別々のサービスを作成する	1 枚ではなく N 枚のマーケットプレイスカードができ、ポートが競合し、アップストリームが混乱します	`api_endpoints` 配列を持つ 1 つのサービスを作成します（Flow E）。
エージェントが、別のサービスによってすでに使用されているアップストリームポートを再利用する	ゲートウェイが誤ったアップストリームにプロキシし、レスポンスが別のサービスからのものになります	各サービスは一意のアップストリームポートを持たなければなりません。`.x402/services.json` で競合を確認してください。
エージェントが start.py に `/docs` ルートを作成し、アップストリームの `/docs` と競合する	Flask の `AssertionError: View function mapping is overwriting an existing endpoint` が発生します	start.py とアップストリームアプリの両方で `/`、`/docs`、`/index.html` ルートを定義しないでください — 定義は 1 か所だけで行います。

重要なルール:

スタンドアロンの有料 API では project_slug を渡さないでください。 project_slug は paid_project にのみ属します — 「無料 Web ページ + 有料 API」パターン（paid_project を使う Flow D）も含みます。スタンドアロンの paid_api にプレビューの slug や存在しない slug を渡すと、幻の関連付けが作成されます — バックエンドはそれを黙ってクリアしますが、そもそも渡すべきではありませんでした。
ルーティングルール: プロジェクトページに紐づくサービス → paid_project、paid_api はプロジェクトページを持たないスタンドアロン API 専用です。 ユーザーが無料で閲覧できる公開済みの Starchild プロジェクト（ランディングページ／ダッシュボード）がある API の場合は、service_type="paid_project" + project_slug を使います — これにより、マーケットプレイスでサービスがプロジェクトカードに統合されます。無料のプロジェクトページが存在しない場合は、paid_api を使い、project_slug を設定しないでください。paid_api + project_slug を渡すと、create_paid_service() によって自動的に paid_project へアップグレードされます（レスポンスに project_slug_warning が含まれます） — 最終的なリスティングは常に paid_project になります。
project_slug は、ユーザープレフィックス付きの完全な公開済み slug（例: 33-my-app）でなければならず、project_listings 内の既存の行に対応している必要があります（つまり、先に publish_preview() + list_in_dashboard() が呼ばれている必要があります）。
api_endpoints は、異なる価格の複数のエンドポイントを持つサービス向けです。各エンドポイントは独自の path、price、および任意の label を持ちます。
project_slug が設定されたプロジェクトは「Free」タブには表示されません — 「All」タブと「Paid」タブに移動します。
プロジェクトカードへの統合による表示: リスティング済みのサービスが PUBLIC プロジェクトを指す project_slug を持つ場合、統合マーケットプレイスビューではそのプロジェクトのカードに折り込まれます。結果として、そのサービスは explore_services() や list_my_services() にスタンドアロンの項目として表示されません — これは仕様によるもので、リスティングの失敗ではありません。それでも、プロジェクトカード、get_service(service_id)、get_user_services(user_id) を通じて公開・購入可能であり、explore_marketplace()（統合フィード）で発見できます。統合されたサービスがリスティングされていることを確認するには、explore_services() の結果ではなく、get_service() → review_status == "listed" を確認してください。
ユーザーが複数の API を求めた場合は、api_endpoints を持つ 1 つのサービスを作成してください — 複数の別々のサービスを作成しないでください。Flow E を参照してください。

タグ付け — マーケットプレイスのフィルタリング用に定義済みのタグスラッグ

有料サービスを作成する際は、以下の定義済みリストから1〜3個のタグスラッグを tags に渡してください。エージェントは、サービスの名前と説明に基づいて最も関連性の高いタグを選択する必要があります。タグはマーケットプレイスのフィルタリングとディスカバリーに使用され、以前の category フィールドを置き換えるものです。

定義済みのタグスラッグ（最も関連性の高いものを1〜3個選択）:

ドメイン	タグ
DeFi & トレーディング	`defi`, `trading`, `dex`, `dex-swap`, `lending`, `lending-yield`, `yield`, `staking`, `derivatives`, `bridge`
オンチェーンデータ	`onchain-data`, `token-analytics`, `price-feed`, `wallet`, `wallet-portfolio`, `nft`
AI & ML	`ai-inference`, `llm-inference`, `text-analysis`, `image-generation`, `text-to-speech`, `video-transcription`, `translation`
Web & データ	`web-search`, `web-scraping`, `screenshot-pdf`, `news-feed`, `seo`, `data-service`, `data-storage`, `analytics`
セキュリティ & コンプライアンス	`aml-sanctions`, `security`, `privacy`, `threat-detection`, `agent-safety`, `agent-trust`
インフラストラクチャ	`smart-contract`, `oracle`, `zk-proofs`, `layer2`, `mev`, `compute`, `storage`, `developer-tools`, `identity`, `payment`, `payments`
ソーシャル & メディア	`social`, `social-media`, `gaming`, `metaverse`
ファイナンス（ TradFi ）	`stock-equity`, `sec-edgar`, `real-estate`, `insurance`, `prediction-market`
その他	`dao`, `governance`, `email-sms`, `weather`, `geolocation`, `healthcare`, `agriculture`, `astrology-fortune`, `rwa`, `research-academic`, `legal-gov`, `launchpad`

例: DeFi 価格 API → tags=["defi", "price-feed", "trading"]

フロー B — 有料プロジェクトの掲載

有料プロジェクトはアクセスに対して課金します。2 つの形態があり、どちらも service_type="paid_project" + project_slug を使用します:

形態 1: ページ全体がペイウォールの背後にある — ページ自体が支払いを要求します。ユーザーが独自のアクセス制御(認証情報の検証を伴うログインのようなコンポーネント)を実装します。プラットフォームが x402 支払いプロトコルを提供し、ユーザーがペイウォールの UI と認証情報のロジックを実装します。実装の詳細については x402 スキルの「Paid Project: two forms」セクションを、ドキュメントテンプレートについては「How to pay with Agent」を参照してください。

形態 2: 無料ページ + 有料 API — ページは無料で閲覧でき、API 呼び出しには料金がかかります。これはフロー D(以下)です。アップストリームアプリは無料の紹介ページを / で、有料 API を /api/* で提供します。

どちらの形態も同じパターンです — 唯一の違いはユーザーが実装するもの(形態 1 ではペイウォールインターセプター、形態 2 では追加実装なし)です。

公開 URL を持つ実行中のプロジェクトを用意する(publish_preview() 経由)。
x402 スキルを使用して、プロジェクトのアクセスエンドポイントに x402 課金を設定する。エンドポイントは未払い時に 402 Payment Required を返し、支払い後に 200 + データを返す必要があります。
サービスレコードを作成する:

create_paid_service(
    name="Premium Trading Signals",
    description="Real-time trading signals with on-chain confirmation.",
    service_type="paid_project",
    tags=["trading", "onchain-data"],
    project_slug="33-premium-signals",  # FULL published slug WITH user prefix (the URL path segment)
    api_endpoint="https://community.iamstarchild.com/33-premium-signals",
    provider_wallet="0xAbC...yourEvmWallet",  # EVM address for Base/Monad/Robinhood/X Layer; Solana address auto-fetched from Privy wallet
    pricing_model="monthly",
    price=10,
    service_description="Subscribers get a dashboard with live trading signals.",
)

有料プロジェクトの必須フィールド: name、description、service_type、 project_slug、api_endpoint、provider_wallet、pricing_model、price、 service_description。推奨: tags(マーケットプレイスのフィルタリング用の事前定義タグスラッグを 1〜3 個)。

⚠️ project_slug は、ユーザープレフィックスを含む完全な公開済みスラッグでなければなりません (例: 33-premium-signals。プロジェクト URL https://community.iamstarchild.com/<slug>/ のパスセグメントと完全に一致)。 api_endpoint が設定されていない場合、ゲートウェイは API エンドポイントを publicUrl + "/" + project_slug として導出するため、プレフィックスのない、または誤ったスラッグはエンドポイントの導出とプロジェクト↔サービスの関連付けを壊します。既存のレコードは update_service(service_id, project_slug="<full-slug>") で修正できます — 再掲載は不要です。

必須: 自動レビューを実行する — 有料サービスは公開前にレビューに合格する必要があります。マーケットプレイスに掲載された壊れたエンドポイントは、気づく前に購入者からお金を引き出す可能性があります:

submit_for_review(service_id)   # kicks off 6 automated checks asynchronously
get_review_status(service_id)   # poll until no longer pending, then show the
                                # report to the user — THEY decide what to fix

rejected レポートは公開をブロックします。review_feedback + latest_task.checks を読み、update_service() で修正し、承認されるまで submit_for_review() を再実行してください。

レビューに合格したら(承認済み)公開する:

publish_service(service_id)

このチェックは、掲載済みのサービスに対して後から再度実行することもできます — それによって掲載が解除されることはありません。

フロー C — 有料 API の掲載

有料 API は、すでに x402 課金を実装している外部 API サービスです。

⚠️ 単独の有料 API には project_slug を渡さないでください。 project_slug は paid_project(必須)または「無料 Web ページ + 有料 API」パターン(フロー D、公開済みの Starchild プロジェクトページが存在する場合)専用です。関連する無料プロジェクトページがない単独の paid_api の場合は、project_slug を完全に省略してください。バックエンドは project_slug を project_listings に対して検証し、存在しないスラッグは黙ってクリアしますが、そもそも渡すべきではありません。

⚠️ API が公開済みの Starchild プロジェクトに属する場合は paid_project を選択してください。 API に publish_preview() 経由で公開されたランディングページ / ダッシュボードがある場合(つまり、 community.iamstarchild.com 上にプロジェクトとして存在する場合)は、service_type="paid_project"

project_slug=<ユーザープレフィックスを含む完全な公開済みスラッグ>(フロー B)を使用してください — paid_api ではありません。project_slug はサービスをプロジェクトカード(価格バッジ、相互ナビゲーション)にリンクするものです。paid_api の掲載にはプロジェクトの関連付けがないため、プロジェクトカードは「Free」を表示し続けます。 paid_api は、Starchild プロジェクトを持たない真に外部/単独の API にのみ使用してください。リンクを忘れましたか? project_slug を指定してサービスレコードを update してください — 再掲載は不要です。

x402 対応の API を用意する — エンドポイントは、未払いの場合は 402 を返し、有効な X-PAYMENT ヘッダーを受け取った後は 200 + データを返す必要があります。必要に応じて、これを実装するために x402 スキルを使用してください。

Starchild で購入が記録されるようにする

Starchild マーケットプレイスで購入、収益、使用状況の統計を追跡するには、ファシリテーターの設定に応じて以下の 2 つのアプローチのいずれかを選択してください:

オプション A — Starchild ファシリテーターを使用する（推奨）

x402 ミドルウェアのファシリテーター URL を次のように設定します:
```
https://starchild-x402-facilitator.fly.dev
```
決済が成功すると、Starchild ファシリテーターが自動的に community-gateway をコールバックして購入を記録します。追加の設定は不要です — デフォルトの create_paid_service() 呼び出しでステップ 2 に進んでください。

オプション B — 独自のファシリテーター + プロキシモードを使用する

独自のファシリテーター（またはサードパーティのもの）を使用する場合、Starchild は決済コールバックを受け取ることができません。代わりに、サービスレコードを作成するときに source="manual" を渡してください（ステップ 2）:
```
create_paid_service(
    ...,
    source="manual",   # ← enables proxy mode
)
```
これにより、マーケットプレイスはあなたの API 用のプロキシ URLを生成します:
```
https://community.iamstarchild.com/proxy/{service_id}/...
```
ユーザーはこのプロキシ URL を通じてあなたの API にアクセスします。プロキシはリクエストを透過的に実際の api_endpoint に転送し、決済が成功すると（HTTP 200 かつ payment-signature ヘッダー付き）、Starchild のデータベースに購入を自動的に記録します。ファシリテーター URL を変更したり、コールバックを設定したりする必要はありません。

402 レスポンスの要件（レビュー時にチェックされます）:
- 402 レスポンスのボディには、pricingModel フィールド（プラットフォーム形式）を必ず含める必要があります。
- payTo は、実際の受取用 EVM ウォレットアドレスでなければなりません（有効なすべてのチェーンで使用されます）。
- accepts 配列には、有効なチェーンごとに 1 つのエントリが含まれます（マルチ accepts）。購入者は支払いごとに 1 つのチェーンを選択します。各エントリの amount は同じです（USDC、小数点以下 6 桁）— このリリースでは、プラットフォームはチェーンごとの価格設定をサポートしていません。
- レスポンスは、クライアントが解析できる有効な x402 チャレンジでなければなりません。
サービスレコードを作成する（service_type = "paid_api"）:

create_paid_service(
    name="On-chain Whale Tracker API",
    description="REST API returning real-time whale wallet movements across 12 chains.",
    service_type="paid_api",
    tags=["onchain-data", "wallet-portfolio", "trading"],
    api_endpoint="https://api.example.com/v1/whales",
    provider_wallet="0xAbC...yourEvmWallet",  # EVM address for Base/Monad/Robinhood/X Layer; Solana address auto-fetched from Privy wallet
    pricing_model="pay_per_use",
    price=0.01,
    free_trial_count=3,
    api_documentation="# Whale Tracker API\n\n## GET /v1/whales\n\nReturns recent whale transactions.\n\n### Parameters\n| name | type | required | description |\n|---|---|---|---|\n| chain | string | no | Filter by chain id (default: all) |\n| limit | int | no | Max results (default: 50, max: 200) |\n\n### Response\n```json\n[{\"hash\":\"0x...\",\"from\":\"0x...\",\"to\":\"0x...\",\"value\":\"1000000\",\"token\":\"USDC\",\"chain\":\"base\",\"ts\":1700000000}]\n```",
    example_request="curl https://api.example.com/v1/whales?chain=base&limit=10",
    example_response='[{"hash":"0xabc...","from":"0x111...","to":"0x222...","value":"5000000","token":"USDC","chain":"base","ts":1700000000}]',
)

必須の有料 API フィールド: name、description、service_type、api_endpoint、provider_wallet、pricing_model、price、api_documentation。推奨（任意）: example_request、example_response（購入者の体験が向上します）。任意: free_trial_count（pay_per_use の場合のみ）、 source（プロキシモードの場合は "manual" — 上記ステップ 1 のオプション B を参照。デフォルトの Starchild ファシリテーターモードの場合は省略）、 cover_url（カスタムカバー画像 URL — storage.googleapis.com またはその他の許可されたドメイン上にある必要があります。指定しない場合、エージェントはサービス名と説明に基づいて適切なカバー画像を自動生成し、画像アップロードサービス経由でアップロードして、その結果の URL を渡す必要があります）。

有料サービスのカバー画像

有料サービスはカバー画像を自動生成しません（自動でスクリーンショットが取得される無料プロジェクトとは異なります）。create_paid_service() で cover_url を渡してください — storage.googleapis.com（または image.thum.io / api.microlink.io）上にある必要があります。

**⚠️ 必須: ユーザーが画像を提供した場合、またはカバーを設定する必要がある場合は、upload_cover_image(slug, file_path) を呼び出してください。**この関数はフロー全体を処理します: presign URL → 圧縮 → GCS へのアップロード → storage.googleapis.com の公開 URL を返す。imgur、データ URI、その他のホスティングを使用しないでください — ゲートウェイがドメインを検証します。

ユーザーが画像を提供しない場合は、画像を生成し（たとえば画像生成スキルを使用）、ローカルに保存してから upload_cover_image() を呼び出してください。

後で update_service(cover_url=...) を使用してカバーを変更することもできます。

完全なリファレンスについては、カバー画像のアップロードを参照してください。

レビューを実行する → フロー B のステップ 4 と同じです（公開前に必須）。
公開する → フロー B のステップ 5 と同じです（承認済みステータスが必要）。

フロー D — 無料 Web ページ + 有料 API（ハイブリッド）

あなたのプロジェクトには無料のランディングページ（publish_preview() で公開）と、有料の API エンドポイントの両方があります。ユーザーはプロジェクトページを無料で閲覧できますが、API 呼び出しには料金がかかります。マーケットプレイスには「プロジェクトを見る」と「API を呼び出す」の両方のボタンを備えた、統合された 1 枚のカードが表示されます。

プロジェクトを公開する — publish_preview() を使用します。これにより無料のランディングページが作成されます。
x402 課金を構成する — API エンドポイントに設定します（例: /api/random が 402 を返す）。
サービスレコードを作成する — service_type="paid_project" + project_slug を指定します。

create_paid_service(
    name="Random9 API",
    description="Random 9-digit number API. Free docs page + paid API calls.",
    service_type="paid_project",
    tags=["developer-tools"],
    project_slug="33-random9-api",  # FULL slug WITH user prefix — links to the free project page
    api_endpoint="https://community.iamstarchild.com/33-random9-api/api/random",
    provider_wallet="0xAbC...yourEvmWallet",  # EVM address for Base/Monad/Robinhood/X Layer; Solana address auto-fetched from Privy wallet
    pricing_model="pay_per_use",
    price=0.01,
    service_description="Paid access to the Random9 API endpoint; the docs page stays free.",  # required for paid_project
    api_documentation="# Random9 API\n## GET /api/random\nReturns a random 9-digit number.",
    example_request="curl https://community.iamstarchild.com/33-random9-api/api/random",
    example_response='{"random":"482917365","digits":9}',
)

project_slug はこのサービスをプロジェクトカードに統合します。プロジェクトページ（/）は無料のままですが、支払いが必要なのは API エンドポイント（/api/random）のみです。

注意: service_type="paid_api" を project_slug と一緒に渡した場合、 create_paid_service() はそれを自動的に paid_project にアップグレードし、 project_slug_warning を返します。保存されるリスティングは常に paid_project です。上記のように paid_project を直接渡すのが正規の形式です。

公開 + 任意のセルフチェック — フロー B の手順 4〜5 と同じです。

フロー E — マルチエンドポイント API

あなたのサービスには、価格の異なる複数の API エンドポイントがあります（例: ベーシック $0.01、プレミアム $0.10）。各エンドポイントはマーケットプレイスの詳細ビューに個別に表示されます。

⚠️ ユーザーが複数の API を求めた場合は、api_endpoints を使って 1 つのサービスを作成してください — 複数の個別サービスではありません。 たとえば、ユーザーが「3 つの有料 API を開発してリストに登録して」と言った場合、 create_paid_service() を 3 回呼び出してはいけません。代わりに、3 つのエンドポイントすべてを含む api_endpoints 配列を指定して、単一のサービスを作成してください。これにより、ユーザーは統合されたマーケットプレイスカードで個々のエンドポイントを確認し、購入できるようになります。複数のサービスを作成するのは、API が本当に無関係な場合（異なるドメイン、異なる対象ユーザー、異なる価格モデル）のみです。

x402 課金を構成する — ルートごとの価格設定を行います:

# Default networks_mode is "all" (Base + Monad). Omit --networks to follow
# the platform mainnet set; pass --networks eip155:8453 only if the user
# explicitly wants to restrict to a single chain.
python3 skills/x402/scripts/monetize.py --name my-api --upstream-port 5173 \
  --mode pay_per_use --price 0.01 \
  --route "GET /api/basic=$0.01" --route "GET /api/premium=$0.10" \
  --route "POST /api/batch=$0.50" \
  --facilitator $FAC

サービスレコードを作成する — api_endpoints を指定します:

create_paid_service(
    name="Data API Service",
    description="Multiple API endpoints at different prices.",
    service_type="paid_api",
    tags=["data-service"],
    api_endpoint="https://example.com/api/basic",  # primary endpoint for review
    api_endpoints=[
        {"path": "GET /api/basic", "price": 0.01, "label": "Basic Query"},
        {"path": "GET /api/premium", "price": 0.10, "label": "Premium Query"},
        {"path": "POST /api/batch", "price": 0.50, "label": "Batch Process"},
    ],
    provider_wallet="0xAbC...yourEvmWallet",  # EVM address for Base/Monad/Robinhood/X Layer; Solana address auto-fetched from Privy wallet
    pricing_model="pay_per_use",
    price=0.01,  # price of the primary/default endpoint
    api_documentation="# Data API\n## GET /api/basic\nBasic data.\n## GET /api/premium\nPremium analytics.",
    example_request="curl https://example.com/api/basic",
    example_response='{"data":"basic market info"}',
)

フロー D + フロー E を組み合わせることができます。service_type="paid_project" + project_slug を api_endpoints と一緒に使用して、無料のプロジェクトページとマルチエンドポイントの価格設定をリンクさせます。マーケットプレイスには、詳細ビューにエンドポイントリストを備えた統合プロジェクトカードが表示されます。

公開 + 任意のセルフチェック — フロー B の手順 4〜5 と同じです。

レビューチェック (6 つの自動チェック — 公開に必須)

submit_for_review() は api_endpoint に対してこれらのチェックを実行します。サービスが公開承認されるには、すべてのチェックに合格する必要があります。すでに掲載されているサービスに対して実行されたチェックで、掲載が解除されることはありません。

#	チェック	検証内容
1	`api_reachable`	`X-PAYMENT` ヘッダーを送信しない場合に、エンドポイントが `402 Payment Required` を返す
2	`pricing_consistency`	402 レスポンスの `accepts` 内の `amount` が、宣言した `price` と一致する (USDC 基本単位)。マルチチェーンの `accepts` (有効なチェーンごとに 1 エントリ) の場合、各エントリが同じ `amount` を持つ必要があります — 本リリースではチェーンごとの価格設定はサポートされていません。
3	`x402_payment`	有効な x402 支払い後、エンドポイントが `200` + データを返す
4	`response_match`	実際のレスポンスの主要フィールドが `example_response` と一致する
5	`doc_completeness`	`api_documentation` にパラメータの説明、レスポンス形式、少なくとも 1 つの例が含まれている

チェック #5 はキーワードマッチングです。ドキュメントには、見出しの下に実際の本文テキストを伴う "Response" (または "响应格式") セクションが含まれている必要があります — 空のセクションはレビューに失敗します。 service_description (paid_project) および api_documentation / example_request / example_response (paid_api) は、呼び出し時に create_paid_service() によって強制され、レビュー不可能なレコードを作成する前にエラーとなります。

よくある却下理由:

402 レスポンスの amount が宣言した price と一致しない (小数点以下の桁数や単位の誤り)。
エンドポイントが 402 をまったく返さない (x402 が組み込まれていない、または未認証リクエストに 200 を返す)。
example_response が、支払い後に API が実際に返す内容と一致しない。
ドキュメントにパラメータテーブルまたはレスポンススキーマが欠けている。

価格モデル

すべての有料サービスは、x402 の exact 支払いスキームを使用します (プラットフォームで有効なネットワーク上でのオンチェーン USDC/USDG 決済 — デフォルトでは networks_mode="all" に従い Base + Monad + Robinhood + X Layer + Solana)。決済のガス代はプロバイダーではなく、Starchild ファシリテーターが支払います。

`pricing_model`	意味	x402 の動作	一般的な用途
`pay_per_use`	呼び出しごとの課金	有効な `X-PAYMENT` を伴うすべてのリクエスト → 決済 (課金)	API 呼び出し
`lifetime`	一度限りの買い切り	最初の支払いで決済。以降のリクエストは過去の決済を検証し、再課金なし	一度限りの購入
`monthly`	月額サブスクリプション	請求月ごとに 1 回決済。有効期限後に再課金	Web サブスクリプション、API 月額プラン
`weekly`	週額サブスクリプション	7 日ごとに 1 回決済。有効期限後に再課金	短期サブスクリプション
`quarterly`	四半期サブスクリプション	90 日ごとに 1 回決済。有効期限後に再課金	四半期プラン
`yearly`	年額サブスクリプション	365 日ごとに 1 回決済。有効期限後に再課金	年間プラン (多くの場合割引あり)
`prepaid`	プリペイド残高	ユーザーが `deposit-settle` で入金 (1 回のオンチェーン tx)。その後、各呼び出しはオフチェーンで残高から引き落とし (ガスゼロ)	高頻度のマイクロペイメント

free_trial_count は pay_per_use でのみ有効です — 課金前に N 回の無料呼び出しを可能にします。これはカレンダー上の無料プロモではありません。期間限定無料 (free_promo_*) → x402 スキル (selling.md → 期間限定無料プロモーション)。

マルチプラン (複数の料金オプション)

1 つのサービスが同時に複数の料金プランを提供できます (例: 週払い + 月払い + 年払い)。サービス作成時に pricing_options 配列を渡します:

create_paid_service(
    ...,
    pricing_options=[
        {"pricing_model": "weekly", "price": 3, "is_default": True, "label": "Weekly"},
        {"pricing_model": "monthly", "price": 10, "label": "Monthly"},
        {"pricing_model": "yearly", "price": 90, "label": "Yearly (Save 42%)"},
    ],
)

ルール:

pay_per_use は他の料金モデルと組み合わせることはできません。
サブスクリプションモデル (週払い/月払い/四半期払い/年払い) は自由に組み合わせられます。
lifetime と prepaid はサブスクリプションモデルと組み合わせられます。
1 つのオプションを is_default: True としてマークする必要があります (マークしない場合は最初のオプションが自動的にマークされます)。
サービスの pricing_model フィールドと price フィールドは、デフォルトオプションに自動的に同期されます。

マルチプランの 402 要件: サービスの x402 ミドルウェアは X-Pricing-Model ヘッダーをサポートする必要があります。クライアントが X-Pricing-Model: yearly を送信した場合、402 レスポンスは年払いプランの価格を返す必要があります。レビューでは各プランの 402 金額が個別に検証されます。

参考: 完全な仕様については x402-facilitator/docs/pricing-models.md を参照してください。

支払いを特定のチェーンに制限する (カスタムネットワーク)

デフォルトの networks_mode="all" はプラットフォームのメインネットセット (Base + Monad + Robinhood + X Layer + Solana) に従います。ユーザーが明示的に要求した場合 (「Base のみ受け付ける」「Monad での支払いは受け付けない」など) にのみ、サブセットに制限してください:

# Create a service that ONLY accepts Base USDC (not Monad)
create_paid_service(
    ...,
    networks_mode="custom",
    supported_networks=["eip155:8453"],   # CAIP-2 chain id; non-empty required
)

# Switch an existing service from all → custom (only Monad)
update_service(service_id, networks_mode="custom", supported_networks=["eip155:143"])

# Switch back to all (follow platform mainnets; clears the custom list)
update_service(service_id, networks_mode="all")

デフォルトで custom + ['eip155:8453'] にしないでください。 それでは以前の Base のみの動作が再導入されてしまいます。デフォルトは all です。ユーザーが明示的に制限した場合にのみ custom を使用してください。

サービスの例 (API 呼び出しの例) — 推奨だが任意

API 呼び出しの例は任意ですが、強く推奨されます。これらは購入者に API が何を返すかを示すもので、サービス詳細ページに折りたたみ式のリクエスト/レスポンスのペアとして表示されます。例のないサービスもレビューには合格しますが、レビューレポートに例が欠けている旨が記載されます。

推奨される掲載順序:

1. create_paid_service(...)                     → creates the service
2. set_service_examples(service_id, examples)   → recommended (improves buyer experience)
3. submit_for_review(service_id)                → required before publishing
4. publish_service(service_id)                  → go live (requires approved)

例の追加:

set_service_examples("service-uuid", [
    {
        "title": "Query BTC Price",
        "description": "Get current Bitcoin price in USD",
        "request": 'curl -X GET "https://api.example.com/v1/price?symbol=BTC"',
        "response": '{"symbol": "BTC", "price": 67234.56, "currency": "USD"}'
    },
    {
        "title": "Query ETH Price",
        "request": 'curl -X GET "https://api.example.com/v1/price?symbol=ETH"',
        "response": '{"symbol": "ETH", "price": 3456.78, "currency": "USD"}'
    }
])

例のクリア (ほとんど不要です — set_service_examples はすべてを置き換えます):

clear_service_examples("service-uuid")

ベストプラクティス:

最も一般的なユースケースをカバーする 2〜5 個の例を追加する
シナリオを説明する説明的なタイトルを使用する
現実的なリクエストパラメータとレスポンスデータを含める
シンプルな使用パターンと複雑な使用パターンの両方を示す
set_service_examples() はすべての例を置き換えます — 毎回完全なリストを渡してください

これは create_paid_service() で渡される従来の単一の example_request / example_response フィールドに取って代わります。従来のフィールドを持つサービスもレビューには合格します (後方互換性があります) が、新しいサービスではより豊富なマルチシナリオのデモンストレーションのために set_service_examples() を使用するべきです。

有料サービス管理関数

関数	目的
`create_paid_service(...)`	サービスのレコードを作成する (公開状態)
`set_service_examples(service_id, examples)`	API 呼び出しの例を設定する (任意、推奨) — すべての例を置き換えます
`clear_service_examples(service_id)`	すべての API 呼び出しの例を削除する
`submit_for_review(service_id)`	6 項目の自動レビューを実行する (公開前に必須)
`get_review_status(service_id)`	レビューの進捗 + 項目ごとの詳細をポーリングする
`publish_service(service_id)`	公開する (承認済みまたは非公開の状態が必要)
`unpublish_service(service_id)`	取り下げる (掲載中 → 非公開)
`list_my_services(cursor, limit)`	自分のサービスを一覧表示する (ページネーション)
`get_service(service_id)`	ID で 1 つのサービスを取得する
`update_service(service_id, **fields)`	サービスのフィールドを更新する (例: 却下後の修正)
`delete_service(service_id)`	サービスを完全に削除する
`restore_service(service_id)`	利用不可のサービスを掲載中に復元する

マーケットプレイスの閲覧とコンシューマー機能

これらの機能により、エージェントは Web フロントエンドと同様に、サービスマーケットプレイスの閲覧、レビューの読み取り、レビューの書き込み、お気に入りの管理、収益の確認を行うことができます。

機能	目的
`explore_marketplace(search, paid_only, ...)`	⭐ 統合閲覧 — 有料サービス/API を見つけるには、まずこれを使用してください。プロジェクトカードとスタンドアロンサービスを1つのフィードにまとめて表示します（Web の All/Paid タブと同じ）。公開プロジェクトカードに統合されたサービスを表示できる唯一の検索パスです。アイテムには `type` があり、`service`（`id` を使用）または `project`（有料カードには `service_id` が付属）のいずれかです — `get_service_detail()` に渡してください
`explore_services(search, sort, tags, ...)`	スタンドアロンのサービスアイテムのみを閲覧します（services API）。⚠️ 公開プロジェクトカードに統合されたサービスはここには表示されません — 完全に網羅するには `explore_marketplace()` を使用してください
`get_service_detail(service_id)`	公開されたサービスの公開詳細（ドキュメントを含み、閲覧数を増加させます）
`get_service_pricing(service_id)`	リアルタイムの x402 チェックによる検証済みの価格
`get_service_reviews(service_id, sort)`	サービスのレビュー一覧を表示します（公開）
`write_service_review(service_id, rating, comment)`	レビューを送信/更新します（先に購入または使用している必要があります）
`get_user_services(user_id)`	ユーザーが公開している有料サービスを取得します（公開、プロフィール表示用）
`favorite_service(service_id)`	サービスをお気に入りに追加します
`unfavorite_service(service_id)`	サービスをお気に入りから削除します
`get_favorite_services(cursor, limit)`	現在のユーザーのお気に入りサービスを一覧表示します
`get_service_purchase_status(service_id)`	現在のユーザーがサービスを購入/使用したかどうかを確認します
`get_service_earnings(service_id)`	単一サービスの収益統計（オーナーのみ）
`get_earnings_summary()`	すべてのサービスにわたる収益サマリー（オーナーのみ）
`get_service_onchain_records(service_id)`	オンチェーンの USDC 決済記録（オーナーのみ）

bash ブロックからの使用

python3 - <<'EOF'
import sys
# Prefer the registered skill tools (read this SKILL.md via read_file to
# load them) over hand-written imports of exports.py. If you DO need a
# direct import: the directory name has a HYPHEN, so dotted imports
# (`from skills.community_publish import ...`) raise ModuleNotFoundError.
# Use this sys.path pattern (or importlib.util.spec_from_file_location).
sys.path.insert(0, "/data/workspace/skills/community-publish")
from exports import (
    # PUBLISH: public URL
    publish_preview, unpublish_preview, list_published_previews,
    # PUBLISH: open source code
    open_source, remove_open_source, fork,
    list_open_source, get_open_source, validate_open_source,
    # LIST: free (project gallery)
    list_in_dashboard, unlist_from_dashboard, get_listing_status,
    # LIST: paid (service marketplace)
    create_paid_service, submit_for_review, get_review_status,
    publish_service, unpublish_service,
    list_my_services, get_service, update_service, delete_service,
    restore_service, set_service_examples, clear_service_examples,
    # MARKETPLACE: browse + consumer actions
    explore_marketplace, explore_services, get_service_detail,
    get_service_pricing, get_service_reviews, write_service_review,
    get_user_services, favorite_service, unfavorite_service,
    get_favorite_services, get_service_purchase_status,
    get_service_earnings, get_earnings_summary, get_service_onchain_records,
    # Manual repair (rare)
    link_to_listing,
)

# Step 1: Publish the URL
print(publish_preview(preview_id="my-app-a3f1", slug="my-app"))

# Step 2a: Free listing — show on gallery
print(list_in_dashboard(slug="33-my-app", name="My App", description="A cool app"))

# OR Step 2b: Paid listing — create service + review + publish
res = create_paid_service(
    name="My Paid App",
    description="Premium features",
    service_type="paid_project",
    tags=["developer-tools"],
    project_slug="33-my-app",  # full published slug WITH user prefix
    api_endpoint="https://community.iamstarchild.com/33-my-app",
    provider_wallet="0xAbC...",
    pricing_model="monthly",
    price=5,
    service_description="Subscribers get premium features.",
)
print(res)
# Then: publish_service(res["service_id"]) — optionally submit_for_review() first for a self-check report
EOF

動作ルール

open_source() の前に diff を表示します。validate_open_source の後、プッシュされようとしている内容を要約し、確認を求めます。例外: 明示的な「確認なしで公開」または既知の正常なプロジェクトの再公開。
fork 時に setup.sh を自動実行しないでください。コマンドを表示し、ユーザーに確認してもらいます。
fork 時は常に env を 1 回のバッチで収集します。プロジェクトの env_required を読み、workspace/.env と差分を取り、不足しているキーを指定して request_env_input を 1 回だけ呼び出します。
公開にはレビューが必須です。publish_service() には approved ステータスが必要です — 必ず最初に submit_for_review() を実行してください。レポートをユーザーに表示し、却下された場合は update_service() で修正して submit_for_review() を再実行します。すでに掲載されているサービスに対して実行したチェックが、そのサービスを掲載解除することはありません。
api_endpoint は x402 の課金エンドポイントでなければなりません。有料プロジェクトの場合、これはプロジェクトの公開 URL です。有料 API の場合は外部 API の URL です。レビュアーはこの URL にアクセスし、402 を期待します。
価格の単位は USDC です。402 レスポンスの accepts.amount はベース単位です（USDC は 6 桁の小数）。$0.01 の価格 → amount: "10000"。ここでの不一致がレビュー失敗の最大の原因です。
レビュー結果を捏造しないでください。必ず get_review_status() を呼び出して確認します — 提出したからといってレビューに合格したと決して思い込まないでください。
公開と掲載を混同しないでください。publish_preview() は URL を割り当てます。list_in_dashboard() / create_paid_service() はそれを発見可能にします。これらは別個の、意図的なステップです。
スラッグの規則: 小文字の英数字 + ハイフン、3〜50 文字、先頭と末尾にハイフン不可。
バージョンの規則（open_source）: 厳密な semver。同じバージョンの再公開は拒否されます。
URL ≠ コード ≠ 掲載: 公開 URL がダウンしても、オープンソースコードやマーケットプレイスの掲載は削除されません。またその逆も同様です。これらは独立しています。
スタンドアロンの paid_api サービスには project_slug を渡さないでください。 project_slug は paid_project にのみ属します — 「無料 Web ページ + 有料 API」パターン（paid_project を使用するフロー D。paid_api + project_slug を渡すと、project_slug_warning とともに paid_project へ自動アップグレードされます）も含みます。スタンドアロン API に対してプレビューのスラッグや存在しないスラッグを渡すと、幻の関連付けが作成されます。バックエンドは存在しないスラッグを黙ってクリアしますが、ユーザーが無料プロジェクトページと有料 API を明示的にリンクしたい場合を除き、project_slug を渡すべきではありません。
ユーザーが複数の API を求めた場合、api_endpoints を使って 1 つのサービスを作成します。 関連する API に対して create_paid_service() を複数回呼び出さないでください。api_endpoints 配列を使って、すべてのエンドポイントを 1 つのサービスに列挙します（フロー E）。API が本当に無関係な場合（異なるドメイン、異なる対象者、異なる価格モデル）にのみ、複数のサービスを作成してください。
支払いネットワークのデフォルトは all です。 単一のチェーン（例: ['eip155:8453']）をデフォルトとしてハードコードしないでください — それは古い Base のみの動作を再導入することになります。networks_mode / supported_networks を省略する（または networks_mode="all" を渡す）ことで、サービスはプラットフォームのメインネットセット（Base + Monad + Robinhood + X Layer + Solana。新しいチェーンは自動的に取り込まれます）に従います。ユーザーが明示的にサブセットへの制限を求めた場合（「Base のみ」、「Monad のみ」など）にのみ、networks_mode="custom" + 空でない supported_networks を使用してください。
provider_wallet は、有効なすべての EVM チェーンで使用される EVM アドレスです。 Starchild ファシリテーターは各 EVM チェーンで同じアドレスに決済します。Base 専用ではありません。ユーザーに対してこれを「Base ウォレット」と説明しないでください。Solana 支払いの場合、プラットフォームは自動的にユーザーの Privy Solana ウォレットアドレス（provider_sol_wallet）を使用します。ユーザーが Solana アドレスを明示的に提供していない場合、create_paid_service() が Privy ウォレットから自動取得します。Solana アドレスのないサービスは Solana 支払いを受け付けません（Solana は 402 の accepts リストから除外されます）。
決済のためのガスはプラットフォームが支払います、プロバイダーではありません。プロバイダーに、決済者のガス用に ETH/MON を用意する必要があると伝えないでください。

Common gotchas

症状	原因	修正
`publish_preview`: `Preview not found`	preview_id が間違っている、またはサービスが停止している	`/data/previews.json` を確認し、`preview(action='serve')` で再起動します
`publish_preview`: `429 Too many published previews`	ユーザーごとのゲートウェイ上限 20 件に達した	先に古いものを `unpublish_preview()` します
`publish_preview`: `FLY_MACHINE_ID not set`	ローカルで実行されており、Starchild コンテナ内ではない	URL 公開は本番コンテナでのみ動作します
`list_in_dashboard`: `404 No preview found`	この slug に対して `publish_preview()` がまだ実行されていない	先に `publish_preview()` を呼び出します
`open_source`: `400 Validation failed: env names not in .env.example`	`env_required` に `MY_KEY` を記載したが、`.env.example` を忘れている	不足しているキーを `.env.example` に追加します
`open_source`: `400 Possible secret detected`	シークレットスキャナーが本物らしい API キーを検出した	環境変数に移動します。`.env.example` の値は `your-key-here` にします
公開後にマーケットプレイスでサービスが無料として表示される / 表示されない	`publish_preview()` のみが実行されている — URL 公開 ≠ 有料リスティング	チェーンを完了させます: `create_paid_service` → `publish_service`
`create_paid_service`: `400 Free services should be published through the Project publish flow`	`service_type: "free_project"` を試した	無料プロジェクトには `create_paid_service()` ではなく `list_in_dashboard()` を使用します
`publish_service`: `400 not in a publishable state`	サービスがすでにリスティング済み、利用不可、または削除済み	`get_service()` で状態を確認します。`unavailable` → `restore_service()`
`submit_for_review`: `400 Free services do not require review`	サービスレコードが FREE タイプとして作成された — 有料ペイロードが `create_paid_service()` を経由せず手作業で構築された（`service_type`/ウォレット/価格設定が欠落）	それを削除し、`create_paid_service()` で再作成します（有料フィールドはすべて必須の位置引数であるため、この関数を通せばこの問題は発生しません）
レビュー却下: `pricing_consistency` 失敗	402 レスポンスの `amount` が宣言された `price` と一致しない	`amount` = `price * 1000000`（USDC は小数点以下 6 桁）であることを確認します
レビュー却下: `api_reachable` 失敗	エンドポイントが 402 を返さない	先にエンドポイントで x402 の課金を設定します
`create_paid_service` のレスポンスに `project_slug_warning` がある	`paid_api` に対して `project_slug` を渡したが、その slug が `project_listings` に存在しない	バックエンドが自動的にクリアしました。これがスタンドアロンの API であれば、`project_slug` を渡さないでください。Flow D を意図していた場合は、先にプロジェクトを `publish_preview()` + `list_in_dashboard()` し、その後、正しい slug で `update_service()` を実行します。
`create_paid_service`: 同じ名前で削除→作成を繰り返した後の `500 Failed to create service`	削除されたサービスは slug を保持し（ソフト削除）、slug 生成は限られた数のサフィックスのみを試す — 同じ名前で削除/再作成を繰り返すとそれを使い果たす	待って再試行しないでください — その名前では失敗が永続的です。別のサービス名を使用するか、削除+再作成の代わりに `restore_service(service_id)` + `update_service()` を使用します
ユーザーが「複数の API」を求めたのに複数のサービスが作成された	`api_endpoints` を使用せず、API ごとに `create_paid_service()` を 1 回呼び出した	Flow E を使用します: `api_endpoints=[...]` 配列を指定した 1 回の `create_paid_service()` 呼び出しです。API が本当に無関係な場合のみ、複数のサービスに分割します。
外部 API（独自のファシリテーター）の購入が記録されない	サービスが `source="manual"` なしで作成されたため、プロキシ URL が生成されず、Starchild が支払いを観測する方法がない	Starchild ファシリテーターに切り替える（オプション A）か、`source="manual"` でサービスを再作成します（オプション B）
`source="manual"` サービスのプロキシ URL が 502 を返す	`api_endpoint` の URL が Starchild サーバーから到達できない	外部 API が公開アクセス可能で、ファイアウォールの背後にないことを確認します
マーケットプレイスに表示されるチェーンが 402 の `accepts` にない（またはその逆）	サービスの `networks_mode` と x402 ゲートウェイの `accepts` が同期しなくなっている — 例えば、リスティングが `all`（Base+Monad）なのに、x402 ゲートウェイが `--networks eip155:8453`（カスタム、Base のみ）で収益化されている	x402 スキルの `monetize` を `--networks` なしで再実行する（`all` に従う）か、ゲートウェイに合わせて `update_service(service_id, networks_mode="custom", supported_networks=[...])` を実行します。両者は一致している必要があります。
`create_paid_service` / `update_service` が「supported_networks must be a non-empty list」で拒否される	`networks_mode="custom"` を渡したが、`supported_networks` が欠落、空、または `None` だった	CAIP-2 ID の空でないリスト（例: `["eip155:8453"]`）を渡すか、`networks_mode="all"`（デフォルト）に切り替えてすべてのプラットフォームメインネットを受け入れます。
buyer が Monad で支払えない（402 に Monad の `accepts` がない）のにリスティングには Monad が表示される	x402 ゲートウェイがマルチチェーンリリース前に収益化されたか、`--networks eip155:8453` で収益化された	`monetize` を `--networks` なしで再実行し、402 の `accepts` 配列にすべてのプラットフォームメインネットが含まれるようにします。リスティングの `all` モードは正しく、ゲートウェイ側が古い状態です。
あるチェーンでは決済が失敗するが、別のチェーンでは成功する	Starchild ファシリテーターのセトラーがそのチェーンでガス切れになっている（Base には ETH、Monad には MON）	プラットフォーム側の問題です（ガスは補助されています）。もう一方のチェーンは動作し続けます。運用担当に報告してください — プロバイダーにガスの資金提供を求めないでください。

カバー画像アップロードフロー

⚠️ 必須 — カバー画像を設定または変更する必要があるときは、必ずこのセクションを読んでください。

ゲートウェイは cover_url のドメインを検証します。受け入れられるのは storage.googleapis.com、image.thum.io、api.microlink.io のみです。imgur、データ URI、その他のホスティングを一切使用しないでください。

クイックパス: `upload_cover_image()`

from skills.community_publish.exports import upload_cover_image

result = upload_cover_image("my-slug", "/path/to/image.png")
# result = {"ok": True, "public_url": "https://storage.googleapis.com/..."}

# Then use the URL:
list_in_dashboard("my-slug", name="My Project", cover_url=result["public_url"])
# or:
create_paid_service(..., cover_url=result["public_url"])
# or:
update_service(service_id, cover_url=result["public_url"])

`upload_cover_image()` が内部で行うこと

Presign — slug、content_type、file_size を指定して POST /api/projects/cover/presign を呼び出します（コンテナ JWT を Authorization: Bearer $CONTAINER_JWT で渡します）
Upload — 生の画像バイトを GCS V4 署名付き URL に PUT します
Returns — storage.googleapis.com 上の public_url を返します

対応フォーマット

image/png、image/jpeg、image/webp
最大 2MB — 必要な場合はアップロード前に圧縮してください

ユーザーが大きな画像を提供した場合

# Compress first (PIL example)
from PIL import Image
import io

img = Image.open("/path/to/large.png")
img.thumbnail((1200, 630))  # reasonable cover dimensions
buf = io.BytesIO()
img.save(buf, format="JPEG", quality=85)
buf.seek(0)

# Save compressed version
compressed_path = "/tmp/cover_compressed.jpg"
with open(compressed_path, "wb") as f:
    f.write(buf.getvalue())

# Upload
result = upload_cover_image("my-slug", compressed_path)

よくある間違い

間違い	失敗する理由	修正方法
imgur の URL を `cover_url` として使用する	ドメインが許可リストに含まれていない（プロジェクト/内部ルートが 400 で拒否します）	`upload_cover_image()` → GCS URL を使用してください
データ URI を `cover_url` として渡す	ゲートウェイが 500 を返します（URL が長すぎる / 有効な URL ではない）	ファイルに保存してから `upload_cover_image()` を実行してください
thum.io を使ってプレビューページのスクリーンショットを撮る	内部ポート上のプレビューページは公開アクセスできません	実際の画像ファイルを指定して `upload_cover_image()` を使用してください
ナレッジドキュメントを読んでいない	GCS 設定、パスの規則、ドメインルールに関するコンテキストが欠落します	常に `starchild-knowledge/starchild-community-gateway/service-cover-upload.md` を確認してください

フロントエンド表示 — プロジェクトとサービス

Web フロントエンドには、コミュニティコンテンツ用の2 つの別々のモーダルがあります。

モーダル	コンテンツタイプ	表示内容	クエリ関数
ProjectMarketplaceModal	無料プロジェクト	カードグリッド: カバー画像、名前、説明、タグ、閲覧数、お気に入り	`explore_projects()`、`my_projects()`、`favorite_projects()`、`get_tab_counts()`、`get_popular_tags()`、`get_user_projects()`、`favorite_project()`、`unfavorite_project()`
MarketplaceModal	有料サービス（x402）	サービスカード: 価格、評価、購入ボタン	`explore_services()`、`list_my_services()`、`get_service_detail()`、`get_service_tags()`、`get_featured_services()`

どちらも AgentProfile（Projects タブ / Services タブ）とランディングページにも表示されます。

各プロジェクトには直接 URL（パスベースの /{slug} またはサブドメイン {slug}.community.iamstarchild.com）があります。/projects ページと /services ページは、フロントエンドでレンダリングされる閲覧ページです。

プロジェクトのクエリ関数

関数	データスコープ	目的
`explore_projects(search, tag, sort, limit, cursor)`	公開	すべての公開プロジェクトを閲覧します。ソート: `all`（新しい順）または `trending`。
`my_projects(tag)`	個人	現在のユーザーが公開したプロジェクトを統計情報とともに一覧表示します。
`favorite_projects(tag, limit, cursor)`	個人	現在のユーザーがお気に入り登録したプロジェクトを一覧表示します。
`get_tab_counts()`	個人	タブの件数を取得します（explore、mine、favorites、purchased、services_mine、services_favorites）。
`get_popular_tags()`	公開	フィルタリング用の人気プロジェクトタグを取得します。
`get_user_projects(user_id, limit)`	公開	特定のユーザーによる公開プロジェクトを取得します（プロフィールページ用）。
`favorite_project(slug)`	個人	現在のユーザーのお気に入りにプロジェクトを追加します。
`unfavorite_project(slug)`	個人	現在のユーザーのお気に入りからプロジェクトを削除します。

サービス照会関数

関数	データ範囲	目的
`explore_services(search, sort, tags, ...)`	公開	単体の有料サービスのみを閲覧します。
`list_my_services(cursor, limit)`	個人	現在のユーザーの有料サービスを一覧表示します。
`get_service_detail(service_id)`	公開	公開済みサービスの公開詳細情報です。
`get_service_pricing(service_id)`	公開	検証済みの価格情報（リアルタイムの x402 検証）。
`get_service_reviews(service_id, sort, cursor, limit)`	公開	サービスに対するレビューを一覧表示します。
`write_service_review(service_id, rating, comment, is_anonymous)`	個人	レビューを投稿または更新します（upsert）。
`get_service_tags()`	公開	i18n 名を含む定義済みのサービスタグを取得します。
`get_featured_services()`	公開	ホームページ表示用の注目サービスを取得します。
`get_user_services(user_id, limit)`	公開	特定のユーザーによる公開済みの有料サービスを取得します。
`favorite_service(service_id)`	個人	サービスをお気に入りに追加します。
`unfavorite_service(service_id)`	個人	サービスをお気に入りから削除します。
`get_favorite_services(cursor, limit)`	個人	現在のユーザーのお気に入りサービスを一覧表示します。
`get_service_purchase_status(service_id)`	個人	ユーザーがサービスを購入・利用したかどうかを確認します。
`get_service_earnings(service_id)`	個人	サービスの収益統計を取得します（オーナーのみ）。
`get_earnings_summary()`	個人	すべてのサービスにわたる収益サマリーを取得します。
`get_service_onchain_records(service_id, cursor, limit)`	個人	オンチェーンのトランザクション記録を取得します（オーナーのみ）。

参考資料

lib/manifest.py — project.yaml のパーサー／ライター + semver ヘルパー
lib/validate.py — ローカルの公開前検証（ゲートウェイ側のチェックを反映）
lib/install.py — タイプ別のインストールハンドラー（task/service/script）
lib/gateway.py — /api/register（URL）、/api/code-projects/*（code）、/api/projects-query/*（無料一覧 + 閲覧）、/api/services/*（有料一覧）、/api/projects/cover/presign（カバーアップロード）用の HTTP クライアント

Markdown 対応

ログインしてコメント

基本情報

作者: starchild-ai-agent
リポジトリ: starchild-ai-agent/official-skills
カテゴリ: クラウド・DevOps
インストール数: 4,032
GitHub スター: 30

問題を報告

community-publish

community-publish について

主な機能

活用シーン

インストール

同梱ファイル

詳細

2 つの概念: PUBLISH と LIST — 決して混同しないでください

LIST には 2 つのフローがあります

期間限定無料プロモーション ≠ このスキル

可視性モデル — 「他の人に見えますか？」に答える前にこれを読んでください

プロジェクトの種類 — 3 つのみ

ルーティング — ユーザーの意図を適切なアクションに結びつける

A. ステータスの意図 — ユーザーが現在の状態を知りたい

B. アクションインテント — ユーザーが状態の変更を望んでいる場合

publisher: バインディングによる相互リンク

バインディングの宣言方法

どちらの側を先に公開してもかまいません

手動修復（まれ）

アーキテクチャ

PUBLISH: publish_preview() — 公開 URL

PUBLISH: open_source() — GitHub へコードをプッシュする

プロジェクト構造

LIST (FREE): list_in_dashboard() — /projects ギャラリーに表示します

LIST (PAID): サービス マーケットプレイスでの有料サービス リスティング

マルチチェーン決済ネットワーク（plans-280）

サービスのライフサイクルとレビュー状態（レビューは ADVISORY）

⚡ シナリオ選択の決定木 — 有料サービスを作成する前に必ず従ってください

⚠️ よくある Flow の混乱による誤り（実際のインシデントより）

タグ付け — マーケットプレイスのフィルタリング用に定義済みのタグスラッグ

フロー B — 有料プロジェクトの掲載

フロー C — 有料 API の掲載

Starchild で購入が記録されるようにする

有料サービスのカバー画像

フロー D — 無料 Web ページ + 有料 API（ハイブリッド）

フロー E — マルチエンドポイント API

レビューチェック (6 つの自動チェック — 公開に必須)

価格モデル

マルチプラン (複数の料金オプション)

支払いを特定のチェーンに制限する (カスタムネットワーク)

サービスの例 (API 呼び出しの例) — 推奨だが任意

有料サービス管理関数

マーケットプレイスの閲覧とコンシューマー機能

bash ブロックからの使用

動作ルール

Common gotchas

カバー画像アップロードフロー

クイックパス: upload_cover_image()

upload_cover_image() が内部で行うこと

対応フォーマット

ユーザーが大きな画像を提供した場合

よくある間違い

フロントエンド表示 — プロジェクトとサービス

プロジェクトのクエリ関数

サービス照会関数

参考資料

コメント

`publisher:` バインディングによる相互リンク

PUBLISH: `publish_preview()` — 公開 URL

PUBLISH: `open_source()` — GitHub へコードをプッシュする

LIST (FREE): `list_in_dashboard()` — /projects ギャラリーに表示します

LIST (PAID): サービスマーケットプレイスでの有料サービスリスティング

クイックパス: `upload_cover_image()`

`upload_cover_image()` が内部で行うこと