dibbla

Dibbla CLI

dibbla CLI は、Dibbla プラットフォーム上でプロジェクトのひな形を作成し、アプリケーション、データベース、シークレット、ワークフローを管理します。デプロイされたアプリには、https://<alias>.dibbla.com からアクセスできます。

前提条件

ユーザーの PATH にまだ含まれていない場合は、CLI をインストールしてください。

プラットフォーム	コマンド
macOS（Homebrew）	brew install dibbla-agents/tap/dibbla
macOS / Linux（シェルインストーラー）	curl -fsSL https://install.dibbla.com/install.sh | sh
Windows（PowerShell）	powershell -NoProfile -ExecutionPolicy Bypass -Command "irm https://install.dibbla.com/install.ps1 | iex"
確認	dibbla --version

シェルインストーラーはバイナリを ~/.local/bin に配置し、必要に応じて PATH を調整します。タスクファイル内で、同じインストーラー URL を使って自己更新できます。

デプロイするには、dibbla deploy に渡すディレクトリのルートに Dockerfile が必要です。 CLI は言語を自動検出したり、Dockerfile を生成したりしません。Dockerfile がない場合、バックエンドはログ出力とともにビルドを拒否します。dibbla-agents/dibbla-public-templates に含まれるすべてのテンプレートには、コピーして使える Dockerfile が用意されています（通常は、Node → JS ビルド → Go → バイナリ → 小さなランタイムイメージというマルチステージ構成で、EXPOSE 80 を指定します）。

コマンド一覧

領域	コマンド
実行	run [path|url]、run --preview、run --env KEY=VAL、run --env-file <file>、run --work-dir <dir>、run --format plain|gh
テンプレート	template list [--refresh] [-v]、template install <id> [<dir>] [--force]
スキル	skills list、skills install <id>（--user、--force、--no-agents） — AI エージェント向けガイダンスを .claude/skills/ + AGENTS.md + GEMINI.md にインストールします
セットアップ	init（対話型セットアップウィザード：update → login → dibbla スキルのインストール）、update [--check] [--version vX.Y.Z]（セルフアップデート。バイナリを管理しているパッケージマネージャーがある場合は brew/apt/rpm/scoop/choco に処理を委ねます）、uninstall [--dry-run] [--keep-config] [--keep-skills] [--skill-only]（スクリプトでインストールした場合はバイナリ、キーチェーンの認証情報、~/.config/dibbla/、~/.dibbla/、記録されているすべてのインストール先のスキルファイルを削除します。パッケージマネージャーでインストールした場合は、バイナリに手を加えず、ネイティブのアンインストールコマンドを表示します）
ログイン	login [api_url]、login --browser、login --api-key <token>、login --api-url <url>、login --write-env、login --no-keychain、logout
フィードバック	feedback <message>、feedback list、feedback delete <id>
デプロイ	deploy [path] -m "<msg>" [--alias name] [--update] [--require-login] [--access-policy] [--google-scopes] [--target-env <env>] [--profile <p>] — ディレクトリからデプロイします。-m は VCS のコミットメッセージになります。--target-env / --profile / --no-public は、デプロイのルートに dibbla.yaml がある場合にのみ適用されます
マニフェスト	manifest validate [path] — dibbla.yaml のローカルスキーマチェック（ネットワーク接続なし）
プレビュー	preview [path] [--target-env <env>] [--profile <p>] [--no-public] — サーバー側で実行するドライラン。環境を考慮した完全な解決とクォータチェックを行いますが、ビルドも適用も行いません
アプリ	apps list、apps update <alias>、apps delete <alias>、apps restart <alias> --service <name>（サービス単位のローリング再起動）
ログ	logs <app>（過去15分間）、logs <app> --since 24h、logs <app> -f（追跡）、logs <app> -n 200（末尾から表示）、logs <app> --grep <regex>、logs <app> --json — Loki からランタイムログを取得します。logs <app> --service <name> は1つのサービスに絞り込みます。Loki が利用できない場合、logs <app> --service <name> --pod-stream は K8s API 経由でポッドログをストリーミングします
データベース	db list、db create、db delete、db dump、db restore、db connect
シークレット	secrets list、secrets set、secrets get、secrets delete（グローバル、デプロイ全体の場合は -d <alias>、サービス単位の場合は -d <alias> --service <name>）
管理	admin reconcile — deploy-api インスタンスで孤立リソースのスイープを1回強制実行します（DIBBLA_ADMIN_TOKEN による制限あり）
ワークフロー	workflows list、get、create、update、delete、validate、execute [--async|--follow]、url、api-docs、logs <runId> [-f]
実行履歴	wf runs list [--workflow <name>] [--limit <N>]、wf runs output <runId> — 過去の実行を一覧表示し、完了した実行の api_response ペイロードを取得します
ノード	nodes add <wf>、nodes remove <wf> <id>
エッジ	edges add <wf> "<edge>"、edges remove、edges list
入力	inputs set <wf> <node> <input> <value>
ツール	tools add <wf> <agent> <tool>、tools remove
リビジョン	revisions list <wf>、revisions create、revisions restore
関数	functions list、functions get <server> <name>

エージェント向けガイドライン

対話型プロンプト： 次のコマンドは確認を求めるため、非対話型で実行すると処理が停止します。エージェントとして実行する場合は、必ず --yes（または -y）を指定してください。

• dibbla apps delete <alias> --yes
• dibbla db delete <name> --yes
• dibbla secrets delete <name> --yes
• dibbla workflows delete <name> --yes
• dibbla nodes remove <wf> <id> --yes
• dibbla feedback delete <id> --yes アプリを初めてデプロイする場合：

1. アプリがすでに存在するか確認します：dibbla apps list
2. 存在しない場合は、必要なすべての環境変数をデプロイコマンドに含めてデプロイします。まだ環境変数を設定するアプリが存在しないためです：

   dibbla deploy . --alias my-app -m "feat: initial deploy" \
     -e DATABASE_URL=postgres://... -e API_KEY=secret -e NODE_ENV=production
   

3. すでに存在する場合は、ダウンタイムのないローリングアップデートを行うために --update を使用します：

   dibbla deploy . --alias my-app -m "fix: resolve 500 on /search" --update
   

   既存のアプリの環境変数を変更するには、代わりに apps update を使用します：

   dibbla apps update my-app -e NEW_VAR=value
   

主なルール：

• すべての dibbla deploy に -m "<message>" を含めてください。 値は、アプリの Dibbla 管理 VCS 履歴（設定されている場合は GitHub ミラーにも）の Git コミットの件名になります。Git コミットと同様に、変更内容と理由を示す、現在形の命令形で約 72 文字以内にしてください。例：-m "fix: handle null org in /api/me"、-m "feat: add nightly db backup workflow"、-m "chore: bump node to 20.14"。再試行や機械的な再デプロイの場合も、内容を明示してください：-m "redeploy: retry after CF 524"。最大 500 文字です。-m なしで dibbla deploy を実行しないでください。デプロイ履歴が空なのは既定の動作ではなく、バグです。

• --force はダウンタイムを発生させます（停止してから再デプロイします）。既存アプリには --update を優先してください。

• --force と --update は相互に排他的です。

• deploy -e または apps update -e で設定した環境変数は更新後も保持されるため、一度渡すだけで十分です。

• ログインガード： 認証を必須にするには --require-login を使用してください。招待ユーザーのみに制限するには --access-policy invite_only、組織全体にアクセスを許可するには all_members と組み合わせます。追加の Google OAuth スコープ（例：Drive、Calendar）をリクエストするには --google-scopes を使用してください。

• スクリプトで機械可読な出力を得るには、db list、db delete、db connect で --quiet / -q を使用してください。

• db create --deployment <alias> は、データベースと自動作成されるシークレットを特定のデプロイに紐付けます。スコープ付きシークレットの名前は DATABASE_URL_<UPPERCASED_UNDERSCORED_NAME>（例：データベース my_db の場合は DATABASE_URL_MY_DB）であり、通常の DATABASE_URL ではありません。アプリのコードでは、サフィックス付きの環境変数を読み取る必要があります。

• db connect は、Dibbla データベースプロキシ経由で psql 互換の接続文字列を出力します。スクリプトでは -q を使用してください：psql $(dibbla db connect mydb -q)。

• デプロイ時の 524 は失敗を意味しません。 dibbla deploy はバックエンドのビルド中、単一の HTTP 接続を維持します。ビルドに約 100 秒以上かかると、バックエンドのビルドが成功していても、クライアント側で Cloudflare 524 が返ることがあります。2～5 分待ってから dibbla apps list を実行して確認してください。--force で再試行しないでください。再試行が必要な場合は --update を使用してください。

• 出力モード： stdout が TTY の場合、dibbla deploy は Buildkit 風のステップ表示をリアルタイムでストリーミングします。stdout がパイプ経由の場合や CI 環境では、ISO タイムスタンプ付きのログ行（<ts> [info] build step=N/M …）に切り替わります。スクリプト向けの 1 行の成功／失敗表示には --quiet、stdout に単一の構造化オブジェクトを出力するには --json を追加してください。ビルドが失敗すると、非 TTY モードでは、次の形式の構造化 JSON 行も stderr に 1 行出力されます：{"event":"deploy.failed","step":"go-build","step_index":N,"step_count":M,"errors":[{file,line,col,message}],"retry_cmd":"…","api_error_code":"BUILD_FAILED"}。コーディングエージェントは、読みやすいビルド出力を解析せずに失敗したファイルを特定できるよう、stderr からこの情報を読み取ってください。解析済みのコンパイル診断だけでは不十分な場合は、完全なサーバービルドログを送信するために --verbose-build を追加してください。ビルド失敗時の終了コードは 2、その他のエラーでは 1 です。

• .dibblaignore が制御するのは Dibbla 管理の VCS 履歴であり、Docker ビルドが参照する内容ではありません。 バックエンドは常に .env、node_modules/、dist/、*.pem、*.key などを VCS から除外し、該当するものをそれぞれ警告として DeployResponse.vcs_filtered に報告します。これらのパス（または生成物／大容量ファイル）をデプロイのルートにある .dibblaignore に追加すると、警告を抑制して VCS をクリーンな状態に保てます。ファイル単位およびコミット単位のサイズ上限を超えると、必ず拒否されます。大きなビルド成果物をコミットすると、デプロイは ErrCodeVCSFiltered で失敗します。対処するには、そのパスを .dibblaignore に追加してください。詳しくは reference.md → deploy → .dibblaignore を参照してください。

• マネージド Postgres は 自己署名 TLS 証明書を使用します。アプリのクライアント（pg、psycopg2、Prisma）では、明示的な SSL 処理が必要です。動作するコード例は reference.md の「TLS for application database clients」を参照してください。 複数サービスのマニフェストの設計： dibbla.yaml を作成する前に、次の設計上の質問を検討し、ユーザーと計画を確認してください。設計段階でこの手順を省くと、すべての利用側サービス（環境変数、depends_on、サービス検出の参照）に影響する後付けの修正が必要になるため、最初に60秒かけて確認する価値があります。

• 一部の環境でのみ存在すべきサービスはどれですか？（例：開発環境ではインラインのDBコンテナ、本番環境ではマネージド／外部DB）→ 環境固有のサービスに profiles: [dev] を設定します。これを事前に決めてください。利用側は、そのサービスを指すURL／ホストに環境対応の値が必要になるためです。

• 環境ごとに異なるフィールドはどれですか？（replicas、image、MONGO_URL、LOG_LEVEL など）→ § 6 の manifest.md にある環境対応フィールドマップを使用します。これはプロファイルとは異なる仕組みです。プロファイルはサービスの有無を切り替え、環境対応フィールドは既存のサービスの内容を環境に合わせます。

• 本番環境のデータ層はどこに配置しますか？ マネージド／外部の場合、利用側には環境対応の MONGO_URL／DATABASE_URL（default: → 外部の値、dev: → ${DIBBLA_SVC_*}）が必要で、さらにインラインの複製には profiles: [dev] が必要です。この2つの仕組みはセットで使います。実例は manifest.md の § 7 を参照してください。

• ユーザーはローカルでどのように反復開発しますか？ プラットフォームは dibbla.yaml をローカルで実行しません。dibbla up はありません。開発時に短いサイクルで反復できるよう、マニフェストと同じ場所にある docker-compose.yml に同等の構成を記述してください（examples.md の「docker-compose を使ったローカルでの反復開発」を参照）。細部は異なります（${DIBBLA_SVC_*}、NetworkPolicy、環境対応の解決はありません）が、構成は一致させます。

• 公開サービスのうち、本番環境で機密性が高いものはありますか？（管理UI、デバッグコンソール、メールキャッチャー、内部ダッシュボードなど）→ サービスごとの auth: ブロックで require_login: true と access_policy: を設定するか、profiles: [dev] を使ってサービス全体を制限します。認証なしで管理UIを公開するのは、OWASPの重大な問題の典型例です。guardrails.md のガードレールチェックでこれを検査します。

デプロイ前のガードレール： dibbla deploy を実行する前に、必ずデプロイ前チェックリストを完了し、調査結果をユーザーに提示してください。デプロイや問題の修正を行う前には、必ずユーザーの明示的な確認を待ってください。自律的にデプロイしてはいけません。ガードレールのワークフローでは、プロジェクトのルートに REVIEW.md ファイルも書き込まれます。プラットフォームはこのファイルを読み込み、ダッシュボードにレビュー状況のインジケーターを表示します。チェックリストの全容は guardrails.md を参照してください。

ワークフロー： ワークフローは関数呼び出しを型付きDAGとして表現したものです。ノードはレジストリ内の function を指定し、エッジはポート間でデータを渡します。api ノードと api_response ノードを組み合わせると、HTTP経由で呼び出し可能になります。作成にはスリムYAML（wf get／wf create -f が使用する形式）を使い、冗長なReact-Flow JSONを手書きしてはいけません。最小構成は次のとおりです。

name: my_workflow
nodes:
  - {id: api_input,  type: api,          inputs: [question], outputs: [question]}
  - {id: greet,      type: function,     function: handlebars_template,
     server: go-function-server1,        inputs: {script: "Hello {{question}}!"},
     outputs: [error, output]}
  - {id: api_response, type: api_response, linked_to: api_input, inputs: [response]}
edges:
  - api_input.question -> greet.question
  - greet.output -> api_response.response

複雑なものを作成する前に、dibbla fn list を実行して利用可能な関数を確認し、似たワークフローに対して dibbla wf get <existing> -o yaml を実行して構成を確認してください。信頼すべき情報源はYAMLではなく関数レジストリです。変更規模に合った反復開発の手順を選んでください。小さな変更なら nodes add／edges add／inputs set／tools add でHEADにパッチを適用し、構造的な変更なら wf get … -o yaml → 編集 → wf update -f の順に進めます。どちらの場合も、必ず事前に dibbla revisions create <wf> を実行してください。パッチは自動的にスナップショット化されず、revisions restore はHEADを上書きします（チェックアウトではありません）。ノードタイプの役割、エージェント＋ツールのパターン、13種類すべてのバリデーターエラーとその修正方法、実行／HTTPのセマンティクス、3つの標準的なワークフロー構成（変換、エージェント＋ツール、複数段階のパイプライン）を含むモデルの全容は、workflows.md を参照してください。 一度は直面するワークフローの注意点：

• 新しいエージェントには reasoning_agent_function を選んでください — 現在の Claude モデルでは、reasoning_agent_with_thread が応答を何も返さずに終了することが確認されています。無言の失敗を検知できるよう、必ず agent.error -> api_response.error を接続してください。
• 本番環境の呼び出し元では、wf api-docs が出力する URL ではなく、ゲートウェイ URL を使用してください。 ホストを書き換えます：https://workflow-server.dibbla.net/api/execute/<name>/<urlid>（api-docs に表示される内部用 URL）→ https://api.dibbla.net/api/wf/execute/<name>/<urlid>（ゲートウェイ。Authorization: Bearer ak_<workflow-api-key> を受け付けます）。
• wf update を何度も繰り返した後は、リリース前にワークフローを作り直してください — ゲートウェイ URL の <urlid> が気づかないうちに古くなることがあります（エラーが出ず、呼び出しが約 5 分間ハングします）。wf delete --yes && wf create を実行すると、新しい ID が割り当てられます。
• wf create を実行すると、ノード ID は関数名になります。 カスタム ID は選ばず、関数名でツールを指定してください。
• reasoning_agent_function の結果キャッシュは 1 時間です。 反復テストでは入力を変えるか、*_no_cache バリアントを使用してください。
• ワークフローのフェッチは必ず、30～60 秒のタイムアウトを設定した AbortController でラップし、実行前後にログを記録してください — Node のデフォルトのタイムアウトは 5 分なので、失敗がハングのように見えます。

実行の監視と非同期実行：

• dibbla wf execute はデフォルトで同期実行です — ワークフローの api_response ノードが起動するまで処理をブロックします（サーバー側のタイムアウト：30 分）。長時間実行されるエージェントワークフローや、結果を待たずに実行するバッチでは、--async を使うと、実行がバックグラウンドで続く間に response_metadata がすぐに返されます。後から wf logs <runId> --follow でログを追い、wf runs output <runId> で最終出力を取得してください。
• dibbla wf execute --follow（-f）は、対話的なデバッグ向けのワンライナーです。実行を非同期で開始し、ライブログを標準出力に流した後、サーバーが出力する run_completed センチネルを受け取ってから api_response ペイロードを表示します。完了すると終了コード 0 で終了します。
• dibbla wf logs <runId> は、すべての実行に使用できます。実行中のログは完了までストリーミングされ、完了済みの実行では過去のログとセンチネルが返され、すぐに終了します。永続化ポリシー：WARN／ERROR と run_completed の行は永続化されます。INFO／DEBUG はライブログのみです。そのため、出力の少ない完了済みの実行を追跡すると、基本的に run completed だけが表示されます。完了済みの実行の全ログを確認するには、代わりに wf runs output <runId> を使用してください。
• dibbla wf runs list（絞り込むには -w <name>、ページングには -n <N> を指定。サーバー上限は 500）は、ダッシュボードや DB からコピーせずに最近の実行 ID を見つける方法です。
• 短縮フラグ -f の意味はコマンドによって異なります： dibbla logs（app-logs）と dibbla wf logs では、-f は --follow です。dibbla wf execute でも -f は --follow ですが、--file は短縮形を使えなくなり、代わりに -F を使用します。wf execute で -f payload.json を提案しないでください。--file payload.json または -F payload.json を使用してください。

Go ワーカーの構築（sdk-go）： github.com/dibbla-agents/sdk-go Go SDK は、ワーカーがプラットフォームにカスタム関数とジョブを登録するための SDK です。ワーカーは長時間稼働する gRPC クライアントです：sdk.New(...) → server.RegisterFunction(...) と server.RegisterJob(...) → server.Start()（永久にブロックします）。外部ユーザーモジュールで使用できるのは sdk.NewSimpleFunction[In, Out] に限られます。高度な Function[In, Out] ハンドラーのシグネチャは internal/types と internal/state を公開しますが、Go の internal/ ルールにより、sdk-go 以外のモジュールからはこれらをインポートできないためです。JobHost 抽象化は削除され、ジョブは server.RegisterJob(handler) で直接登録します。ワーカーが接続されると、その関数は dibbla functions list に表示され、(server, function) ペアを使ってワークフロー YAML から呼び出せるようになります（利用側の接続設定については workflows.md を参照してください）。SDK の全体像 — サーバーオプション、関数ビルダー、JobHandler インターフェイス、JobContext の引数ヘルパー、Logger のタスク／進捗 API、gs.OAuth を使った OAuth、注意点 — については、sdk-go.md を参照してください。 非 TTY／エージェントによる実行：

• Claude Code の ! プレフィックス内、エージェントシェル内、ブラウザーを使う CI 内、またはその他の非 TTY コンテキストから実行する場合は、単独の dibbla login ではなく dibbla login --browser を使用してください。対話型フローではアンケートの選択に stdin が必要ですが、--browser を指定するとそれを省略し、localhost コールバック経由のブラウザー OAuth に直接進みます。
• 真のヘッドレス環境（SSH セッション、クラウド VM、ローカルブラウザーのない CI ランナー）では、dibbla login --api-key <token> を使用するか、DIBBLA_API_TOKEN（必要に応じて DIBBLA_API_URL も）環境変数を設定してください。CLI は CI で環境変数を自動的に読み込みます。
• クラウド VM／SSH／Docker（キーリングなし）： dibbla login --api-key=<t> --api-url=<url> --write-env --no-keychain は API に対してトークンを検証し、OS のキーリングに触れずに DIBBLA_API_TOKEN と DIBBLA_API_URL を ./.env に書き込みます（必要に応じて .gitignore を更新します）。libsecret／gnome-keyring／pass がインストールされていない新規の Ubuntu／EC2／GCE／Docker イメージで使用してください。このディレクトリ内で以降に実行するすべての dibbla * コマンドは、.env から認証情報を読み込みます。CLI ≥ v1.2.4 が必要です。
• CWD 内の .env は、login を含むすべてのコマンドで読み込まれます。 DIBBLA_API_TOKEN=… と DIBBLA_API_URL=https://api.dibbla.net を ./.env に記述すると、そのディレクトリから実行するすべての dibbla 呼び出しが、ログイン操作なしでそのサーバーとトークンを使用します。シェルでエクスポートされた変数は .env より優先されます（godotenv は上書きしません）。CLI ≥ v1.2.4 が必要です。
• DIBBLA_AUTH_SERVICE_URL は、dibbla run が起動する子プロセスに steprunner が設定する、DIBBLA_API_URL の内部互換エイリアスです。ユーザーは .env に DIBBLA_API_URL を記述してください。DIBBLA_AUTH_SERVICE_URL は、デスクトップ／steprunner の規約名を介して子プロセスが同じサーバーを認識できるようにするためのものです。

タスクファイルとテンプレートの実行：

• dibbla run <path> は dibbla-task.yaml パイプラインをローカルで実行します。ツールの確認、シェルコマンド、バックグラウンドの開発サーバー、ブラウザーを開く副作用などが発生する可能性があります。タスクファイルは、ユーザーのアカウント権限で実行されるシェルになります。
• dibbla run <https-url> はネットワークから YAML を取得して実行します。これは curl | bash と同等です。ユーザーが信頼するソース（例：github.com/dibbla-agents/*）の YAML のみを実行してください。作業ディレクトリのデフォルトはユーザーがコマンドを実行した CWD なので、初期設定時のクローンは一時ディレクトリではなく、想定されたディレクトリに作成されます。
• dibbla template install <id> は、mkdir ./<template-path> && cd ./<template-path> && dibbla run <bootstrap-url> を簡単に実行するための構文です。保存先ディレクトリが存在する場合は実行されません。再利用するには --force を渡してください。利用可能な ID を確認するには dibbla template list を使用します。
• 実際に実行する前に dibbla run --preview または dibbla template list を使用し、実行される内容をユーザーが確認できるようにしてください。

プロジェクトへのこのスキルのインストール（ほかのエージェントにも認識させるため）：

• dibbla skills install dibbla は、スキルファイルを ./.claude/skills/dibbla/ に書き込み、プロジェクトのルートに AGENTS.md と GEMINI.md のポインターも作成します。これにより、すべての主要なコーディングエージェントがガイダンスを自動的に読み込みます。Claude Code はネイティブのスキルパス経由で、Cursor／Opencode／Codex／Copilot／Windsurf／Aider は AGENTS.md（2026 年のオープン標準）経由で、Gemini CLI は GEMINI.md 経由で読み込みます。
• スキルの内容は CLI バイナリに埋め込まれているため（go:embed）、ネットワークは不要で、スキルのバージョンはインストール済みの CLI のバージョンに固定されます。バージョンを確認するには dibbla --version を実行してください。
• フラグ：--user は現在のディレクトリではなく $HOME にインストールし、マシン全体で利用できるようにします。--no-agents は AGENTS.md と GEMINI.md を省略します（Claude Code のみ）。--force はローカルで編集されたスキルファイルを上書きします。.claude/skills/<id>/ 内の不明なファイルは常に保持されます。
• AGENTS.md／GEMINI.md のポインターブロックはマーカーで区切られているため（…）、マーカー外にある既存の AGENTS.md の内容は、再実行してもバイト単位で保持されます。
• 再実行は冪等です。変更がなければ、ファイルは書き換えられません（mtime も更新されません）。現在の CLI に含まれるスキルを確認するには dibbla skills list を使用してください。

追加リソース

• プラットフォームとの互換性： Dockerfile の契約、ポートの一致、ランタイム環境、マネージド Postgres の TLS 処理、シークレット／環境変数の注入、認証ヘッダーの契約（X-User-* ヘッダーと Google OAuth スコープの仲介）、アップロードの境界、マルチサービスのランタイム契約（§ 8.5）、デプロイ前の互換性チェックリストについては、platform.md を参照してください。Dibbla に接続されたプロジェクトで Dockerfile、.dibblaignore、認証の統合、デプロイ準備に関する質問に取り組む際は、こちらをお読みください。
• マルチサービスのマニフェストスキーマ： dibbla.yaml の完全なスキーマ（サービス、ジョブ、環境対応フィールド、プロファイル、サービス検出（DIBBLA_SVC_*）、expose_to／NetworkPolicy、ボリューム、初期化コンテナ、ヘルスチェック、複数のパブリックサービス、カスタムドメイン、cron、ビルド時のシークレット、クォータ、エラーコード、エンドツーエンドの実例）については、manifest.md を参照してください。ユーザーがマニフェストを作成またはレビューしている場合や、「1 回のデプロイで X と Y を一緒に実行するには？」という質問をしている場合は、こちらをお読みください。
• ワークフロー： スリムな YAML 形式、3 種類のノード、function の役割（エージェント／ツール／スクリプト／データ取得）、エージェントとツールの接続パターン、修正方法付きの 13 種類のバリデーターエラー、エッジとデータフロー、関数レジストリ、慣用的な作成ループ 3 種類、リビジョンのセマンティクス、HTTP 実行、標準的なワークフローの構成、事前チェックリスト、注意点を含む完全なワークフローモデルについては、workflows.md を参照してください。ユーザーから dibbla wf／nodes／edges／inputs／tools／revisions／functions に関わる質問を受けた場合は、こちらをお読みください。
• Go SDK： Dibbla Go SDK（sdk.New によるサーバーの起動とオプション、SimpleFunction と高度な Function[In, Out] の違い、JobHandler インターフェースと server.RegisterJob（古い JobHost は廃止されています）、Logger のタスク／進捗 API、gs.OAuth によるユーザーに代わった OAuth、TLS の自動検出、internal/ のインポートに関する注意点、エンドツーエンドのデプロイ）については、sdk-go.md を参照してください。ユーザーが Go で Dibbla の関数またはジョブを実装している場合は、こちらをお読みください。
• コマンドとフラグの完全なリファレンス： 使用方法、引数、すべてのフラグについては、reference.md を参照してください。
• 使用例： コピーしてすぐ使える例とスクリプトのパターンについては、examples.md を参照してください。
• デプロイ前のガードレール： 必須のデプロイ前セキュリティチェックリスト（チェック 1～4 は常に実施、URL から取得したタスクファイルがある場合はチェック 5、マルチサービスのマニフェストがある場合はチェック 6）については、guardrails.md を参照してください。

dibbla コマンドを提案または生成する際は、正確な構文についてはリファレンスを、一般的なワークフローについては使用例を参照してください。「自分のアプリは Dibbla に対応できる状態ですか？」という質問では、platform.md から確認してください。「ワークフローを構築／反復／デバッグする」質問では、workflows.md から確認してください。「プラットフォーム向けの Go 関数／ジョブを実装する」質問では、sdk-go.md から確認してください。