mcpField
N
nimble-agent-builder

nimble-agent-builder

github.com/nimblewayデータ・データベース6163 回インストール2 日前に更新
リポジトリ

nimble-agent-builder について

Nimble プラットフォームで再利用可能な抽出エージェントを作成、改善、検証、公開するためのスキルです。Nimble CLI または MCP ツールを使う手順に、既存エージェントの検索とスキーマ確認を組み込んでいます。

主な機能

  1. 01抽出エージェントの作成と更新
  2. 02既存エージェントの検索
  3. 03出力の検証
  4. 04再利用可能なエージェントの公開
  5. 05CLI または MCP の利用
  6. 06入力 URL に対するエージェント実行

活用シーン

  1. 01特定分野の抽出エージェントの作成
  2. 02既存エージェントへのフィールド追加
  3. 03検証済み抽出テンプレートの公開
  4. 04複数 URL に対するエージェント実行

MCP 対応

CLI が利用できない場合に Nimble MCP ツールを使えます。実行前に接続と認証を確認し、セッション開始時に CLI または MCP を選ぶ手順です。

インストール

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

$npx skills add https://github.com/nimbleway/agent-skills --skill nimble-agent-builder

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

同梱ファイル

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

README.md
references/
agent-api-reference.md
batch-patterns.md
error-recovery.md
generate-update-and-publish.md
rest-api-patterns.md
sdk-patterns.md
rules/
nimble-agent-builder.mdc
setup.md

詳細

Nimble Agent Builder

Nimble プラットフォームで、再利用可能な抽出エージェントを構築、改良、公開します。必ず実行結果または実行可能なコードで完了してください。

ユーザーのリクエスト:$ARGUMENTS

前提条件

セッション開始時に CLI または MCP を選択します。同じスキルを 2 種類のトランスポートで利用できます。トランスポートを選択したら、セッション中はそのまま使い続け、コマンドごとに再確認しないでください。

まず CLI を試してください(すべてのフラグ、一括操作、ファイル I/O など、全機能を利用できます)。

nimble --version && echo "${NIMBLE_API_KEY:+API key: set}"
  • CLI のバージョンと API key: set の両方が表示されたら、nimble ... コマンドを使って進めてください。

CLI がない場合は MCP に切り替えてください。

claude mcp list 2>/dev/null | grep -q "nimble" && echo "MCP: connected" || echo "MCP: not connected"
  • MCP が接続されている場合は、CLI の代わりに mcp__plugin_nimble_nimble__* ツールを使って進めてください。

どちらも利用できない場合は、rules/setup.md を読み込んでください。インストール方法はホストによって異なります。

  • Claude 製品(Code、Cowork、claude.ai)→ /plugin install nimble(コマンド 1 つで、MCP をコネクターとして自動登録し、認証は OAuth で行います)。
  • Codex CLI またはその他のターミナル専用エージェント → npm i -g @nimble-way/nimble-cli と API キー。
  • Cursor/VS Code/汎用 MCP クライアント → rules/setup.md の mcp.json スニペットを貼り付けます。

プラグインはインストール済みでも、コネクターが未接続の場合(Cowork/claude.ai でよくあります):mcp__plugin_nimble_nimble__* ツールが表示される場合は、作業を始める前に、読み取り専用の mcp__plugin_nimble_nimble__nimble_agents_list プローブを 1 回実行して確認してください。認証エラーや未接続エラー、または OAuth 認証 URL が返された場合は、未接続です。rules/setup.md に記載されている接続手順をそのまま提示して、そこで停止してください。WebFetch、WebSearch、curl、その他のツールで代用しないでください。

ツールがデータではなく OAuth の「Authorize」リンクを返した場合は、表示されたとおりに提示して停止してください。「URL を貼り戻してください」や「接続を完了します」といった手順を作り出してはいけません。そのような手順は存在しません。また、「ツールが有効になります」と伝えた後、同じターン内でツールを呼び出してはいけません。


スキルの連携

nimble-agent-builder と nimble-web-expert は、Nimble ツールキットの連携スキルです。

スキル最適な用途主なコマンド
nimble-agent-builder(このスキル)再利用可能なエージェントの構築 — 固定スキーマを持つ名前付き抽出テンプレートの作成、改良、公開CLI:generate、get-generation、publish
nimble-web-expertリアルタイムのデータアクセス — 任意の URL の取得、検索、マッピング、クロール、公開済みエージェントの実行extract、search、map、crawl、agent run
次の場合は nimble-agent-builder を使ってください
  • あるドメイン向けに新しいエージェントを生成する
  • 既存のエージェントを改良または更新する(フィールドの追加、セレクターの修正、スキーマの変更)
  • エージェントを公開する
  • nimble agent run(CLI)を使って公開済みエージェントを実行する
  • エージェントの出力品質を検証する
  • 「構築」「改良」「更新」「フィールドの追加」「公開」といった依頼
nimble-web-expert に切り替える場合

エージェントの公開後は、ここで nimble agent run(CLI)を使って直接実行してください。このスキルにないツールがワークフローで必要な場合に限り、nimble-web-expert に切り替えてください。

  • エージェントに渡す入力 URL の一覧が必要な場合 → nimble-web-expert に切り替え、nimble map --url <site> を実行してクロールし、入力リストを生成した後、ここに戻って大規模に実行します。
  • 入力パラメーターを検索する必要がある場合 → nimble-web-expert に切り替えて nimble search を実行し、結果を持ってここに戻ります。

エージェント構築が目的ではないタスクの場合:

  • URL の単発取得、ウェブ検索、サイトマッピング、一括クロール → nimble-web-expert
  • ユーザーに次のように伝えてください:「これはエージェント構築タスクではなく、直接的なデータアクセスのタスクです。nimble-web-expert をお使いください。」
サイトの調査が必要なエージェント生成

サイトのデータ構造が不明なため(セレクターの誤り、XHR パターンの欠落、想定外の JS レンダリングなど)、nimble_agents_generate または nimble_agents_update_from_agent で動作するエージェントを生成できない場合:

ステップ 1 — 事前に伝える: 「まず実際のページを調査しないと、信頼性の高いエージェントを生成できません。サイト調査を開始します……」

ステップ 2 — Task エージェントを起動する(Task(subagent_type="general-purpose", run_in_background=False)):

Investigate {url} to find CSS selectors and/or XHR API endpoints needed to extract: {fields_needed}.

Use Playwright to probe the live page:
python3 << 'EOF'
from playwright.sync_api import sync_playwright
with sync_playwright() as p:
    browser = p.chromium.launch(headless=True)
    page = browser.new_page()
    api_calls = []
    page.on("request", lambda req: api_calls.append(req) if req.resource_type in ("xhr","fetch") else None)
    page.goto("{url}")
    page.wait_for_timeout(5000)
    for sel in ["[data-price]",".price","h1","[data-testid*=title]","[data-testid*=price]",".product-title"]:
        el = page.query_selector(sel)
        if el: print(f"SELECTOR: {sel!r} -> {el.inner_text()[:80]!r}")
    for req in api_calls[:20]:
        print(f"XHR: {req.method} {req.url[:120]}")
    browser.close()
EOF

Also run a quick nimble extract to check raw rendered HTML:
nimble extract --url "{url}" --render --format markdown | head -100

Return a structured report:
- SELECTORS: working CSS selectors for each required field
- XHR_URLS: any relevant API endpoints found
- RENDER_REQUIRED: yes/no
- SUGGESTED_EXTRACT_COMMAND: the nimble extract command that would work
- NOTES: login walls, pagination, lazy loading, or anything unusual

Do NOT use AskUserQuestion.

ステップ 3 — レポートを使う:nimble_agents_update_session 呼び出しでセレクター/XHR の情報と推奨される抽出コマンドを渡し、エージェント生成を再試行します。

ステップ 4 — 調査も失敗した場合: ユーザーに次のように伝えます:「このサイトには複雑なブラウザー自動化が必要ですが、現時点ではエージェントに取り込めません。--browser-action または --network-capture を指定して nimble-web-expert の Tier 4/5 コマンドを使い、データに直接アクセスしてください。」


基本原則

  • 最短でデータにたどり着く。 デフォルトの手順:エージェントを見つける → スキーマを取得する → 実行する → 結果を表示する。計画と生成は、必要に応じて選ぶ手段です。
  • 必ず最初に既存のエージェントを検索する。 生成を検討する前に、nimble agent list --limit 100 --search "<domain or vertical>"(CLI)を実行します。これは必須ルールです。
  • 必ず生成より更新を優先する。 近い候補のエージェント(同じドメイン/タイプで、フィールドが不足していたり、対象範囲が異なったりする場合も含む)がある場合は、ゼロから生成するのではなく更新します。更新すれば、実績のある抽出ロジックを維持でき、より速く、低コストで、信頼性も高くなります。対象ドメインに対する --search クエリの結果が 0 件の場合に限り、新しいエージェントを生成します。近い候補がある場合は、推奨する選択肢として「新しいエージェントを作成」を提示してはいけません。
  • フォアグラウンドでの意思決定時には、例外なく毎回 AskUserQuestion を使う。 各ステップに示されている標準の AskUserQuestion プロンプトを必ず提示します。省略したり、確認を取らずに次へ進めたりしてはいけません。選択肢を単なる番号付きリストとして提示してはいけません。制約:選択肢は 2~4 個、ヘッダーは最大 12 文字、ラベルは 1~5 語です。推奨する選択肢を最初に置き、「(Recommended)」を付けます。注:Task エージェントは AskUserQuestion を決して使いません。Task の起動前に、すべての判断を済ませておきます。
  • 必ず実行前にスキーマを確認する。 nimble agent run の前に、nimble agent get --template-name <name>(CLI)を実行します。入力パラメーターと出力フィールドは、Markdown の表で提示します。エージェントを切り替える場合も同様です。
  • スクリプト生成(ステップ 2B)は、大規模かつ大量の処理に限る。 通常の対話型リクエストでは、コードを生成してはいけません。スクリプトモードを使うには、50 件を超える規模であることと、ユーザーがコード/スクリプト/CSV/バッチ出力を明示的に求めていることのすべてを満たす必要があります。複数ソースのリクエスト、データセットのリクエスト、比較のリクエストだけでは、自動的にスクリプトモードには移行しません。まず対話形式で実行します。デフォルトの手順は常に「見つける → 実行する → 結果を表示する」です。
  • スクリプトを生成する前に、レスポンスの構造を確認する。 nimble agent get --template-name(CLI)から skills と entity_type を確認し、REST API のレスポンスのネスト構造を判断します。references/agent-api-reference.md の「Response shape inference」と references/sdk-patterns.md の「Response structure verification」を参照してください。
  • google_search は汎用の検索ツールではありません。 ランク追跡と SEO 分析のための SERP 分析エージェントです。情報を探す場合は、nimble search(CLI)を使います。references/error-recovery.md を参照してください。
  • すべてのウェブ検索には、必ず nimble search(CLI)を使う。 WebSearch、WebFetch、curl、wget は決して使いません。ガードレールを参照してください。
  • エージェントの作成/更新は、バックグラウンドの Task エージェントで実行する。 生成には 1~3 分かかるため、ユーザーを待たせないよう、生成 → ポーリング → 公開の一連の処理を Task エージェントとして実行します。委譲モデルを参照してください。

委任モデル

フォアグラウンドの会話がオーケストレーションを行い、結果を提示します。タスクエージェントは、時間のかかる処理(生成、検出、スクリプト生成)を担当します。

フォアグラウンド — Bash 経由の直接的な CLI 呼び出し:

CLI コマンド目的最大呼び出し回数
nimble agent list --limit 100 --search "<domain>"既存のエージェントに振り分けるドメインごとに1回
nimble agent get --template-name実行前にスキーマを表示エージェントごとに1回
nimble agent run --agent --paramsインタラクティブな実行(≤5項目)項目ごとに1回
nimble searchウェブ検索/検出必要に応じて

タスクエージェント — 時間のかかる処理:

フェーズタスクエージェントフォアグラウンドの処理
検出(nimble search + nimble map)Step 1D起動してレポートを提示
エージェントの作成/更新(nimble agent generate → get-generation ポーリング → publish)Step 3起動してレポートを提示
スクリプト生成(既存のエージェントを呼び出すコードを記述)Step 2B起動してスクリプトを提示

生成に1~3分かかるため、エージェントの作成はタスクエージェントで実行します(ポーリングループ)。 タスクエージェントは Bash 経由で CLI コマンドを使用します。CLI を利用できない場合は、MCP ツールにフォールバックします。

複数のソースを扱うワークフローでは、タスクエージェントを順番に起動します(ソース/フェーズごとに1つ)。レポートを収集してから、統合した計画を提示します。

タスクエージェント用の CLI コマンド

サブエージェントが使用可能なコマンドを把握できるよう、すべてのタスクエージェントのプロンプトに次のブロックを含めてください。

**CLI tools (use via Bash):**
- `nimble agent list --limit 100 --search "<domain or vertical>"` — search agents by domain/vertical
- `nimble agent get --template-name <name>` — get agent schema
- `nimble agent run --agent <name> --params '{...}'` — run an agent
- `nimble agent generate --agent-name <name> --prompt "<prompt>" --url "<url>"` — create/refine agent
- `nimble agent generate --agent-name <name> --from-agent <name> --prompt "<prompt>"` — iterate on existing agent
- `nimble agent get-generation --generation-id <id>` — poll generation status
- `nimble agent publish --agent-name <name> --version-id <id>` — publish agent
- `nimble search --query "<query>"` — web search (deep by default)
- `nimble map --url <url> --limit 50` — discover URL patterns on a site

**MCP fallback (only if CLI is not installed):**
| CLI command | MCP tool |
|---|---|
| `nimble agent generate` | `mcp__plugin_nimble_nimble__nimble_agents_generate` |
| `nimble agent get-generation` | `mcp__plugin_nimble_nimble__nimble_agents_status` |
| `nimble agent publish` | `mcp__plugin_nimble_nimble__nimble_agents_publish` |

**CRITICAL: Prefer CLI for all operations. Use MCP only when CLI is unavailable. NEVER use WebSearch, WebFetch, curl, or wget. NEVER construct MCP endpoint URLs manually.**

レスポンスの形式

レイヤーパス形式使用時
CLI(nimble agent run)— SERPdata.parsinglist(配列)インタラクティブ実行(Step 2A)
CLI(nimble agent run)— PDPdata.parsingdict(フラット)インタラクティブ実行(Step 2A)
REST API — E コマース SERPdata.parsinglist(配列)スクリプト生成(Step 2B)
REST API — 非 E コマース SERPdata.parsing.entities.{Type}ネストした配列を含む dictスクリプト生成(Step 2B)
REST API — PDPdata.parsingdict(フラット)スクリプト生成(Step 2B)

REST のレスポンスを反復処理する前に、必ず typeof/isinstance を確認してください。

Step 1: ルーティング

$ARGUMENTS から、次の3つを判定します。

1. 明確さ — clear(デフォルト)または needs-planning

次のすべてが欠けている場合に限り、needs-planning にします。対象のURL/サイト/ドメイン、抽出するデータの明確な指定、範囲が明確な単一のタスク。ほとんどのリクエストは clear です。

2. エージェントの適合性 — nimble agent list --limit 100 --search "<domain or vertical>" を実行します(CLI、Bash)。検索語には、ユーザーが指定したドメイン/サイトを使います(例:--search "amazon"、--search "jobs"、--search "ecommerce")。これが必ず最初のアクションです。複数のソースを対象とするリクエスト(例:「Amazon と Walmart の価格を比較」)では、ソースごとに1回検索します。ソースに一致するものが見つからない場合は、Discovery(Step 1D)に振り分けます。

結果ルート
完全一致スキーマの概要を示し、AskUserQuestion を提示します:「このエージェントを使う」(推奨)/「新しいエージェントを作成」→ Step 3
近い一致(同じドメイン/タイプで、フィールドが不足しているか範囲が異なる)スキーマの不足点を示し、AskUserQuestion を提示します:「このエージェントを更新」(推奨)/「新しいエージェントを作成」。必ず更新を推奨してください。既存の抽出ロジックを維持でき、ゼロから生成するより速いためです。
有力な候補が2つ以上表を示し、上位候補と「最も近いエージェントを更新」(推奨)を含む AskUserQuestion を提示します。フィールドの重複が最も多いエージェントを選びます。
一致するものが0件Discovery Task agent(Step 1D)を起動します → 結果を Step 3 に反映します。新しいエージェントの生成が適切なのは、この場合だけです。

3. 実行モード — interactive(デフォルト)または script

対話形式が必ずデフォルトです。 スクリプト生成(Step 2B)に振り分けるのは、次の両方の条件を満たす場合に限ります:(a)規模が明示的に50項目を超えているか、ユーザーがバッチ入力ファイルを提供している。(b)ユーザーがコード、スクリプト、CSV エクスポート、またはバッチ処理を明示的に求めている。「データセット」「比較」「複数ソース」「2つのソース」といった語だけでは、スクリプトモードに切り替えません。これらは対話形式で実行します。スクリプト生成では、既存のエージェントを呼び出すコードを作成します。新しいエージェントは作成しません。エージェントがまだ存在しない場合は、スクリプトを生成する前に Step 3 で解決します。

Step 1P: プランモード(まれ — needs-planning の場合のみ)
  1. 確認 — 重要な不明点を解決するために AskUserQuestion を使います(質問は最大2つ)。対象サイト、データフィールド、出力形式を重点的に確認します。
  2. 調査 — nimble agent list --limit 100 --search "<domain>" を実行します(CLI、ドメインごとに1回)。不慣れなドメインについては、Discovery Task agent を起動します(Step 1D)。
  3. 計画を提示 — ギャップ分析表を示します。
#サイト/データソースエージェントステータス
1amazon.com の商品amazon-product-details既存
2walmart.com の商品—生成
  1. 実行 — 既存のエージェントには Step 2 を、生成する場合は Task agent として Step 3 を実行します。
Step 1D: Discovery(Task agent — 不慣れなドメイン向け)

nimble agent list --limit 100 --search "<domain>" を実行して対象ドメインに一致する結果が 0 件で、調査が必要な場合に起動します。Task(subagent_type="general-purpose", run_in_background=False) として実行します。フォアグラウンドでは、ユーザーに次のように伝えます。「利用可能なデータを把握するため、{domain} を調査しています…」

タスクプロンプトのテンプレート:

Explore {domain} for {user_intent}.

Use the Nimble CLI to discover the site structure and available data:

1. **Map the site** (understand URL patterns and sections):
   ```bash
   nimble map --url "https://{domain}" --limit 50

これにより、一覧ページ、詳細ページ、サイトのセクション、URL パターンが明らかになります。

  1. 実際の例を検索する(コンテンツを深く抽出):
    nimble search --query "{domain} {keywords}" --max-results 5
    
    これにより、各検索結果のページ全体のコンテンツを取得して抽出し、商品一覧、フィールド構造、データの例を確認できます。

構造化レポートを返します:

  • DOMAIN: {domain}
  • ESTIMATED_ITEMS: クエリに一致する件数
  • LISTING_URL_PATTERN: 例:/category/filter?color=green
  • DETAIL_URL_PATTERN: 例:/p/{slug}-{SKU}.html
  • AVAILABLE_FIELDS: 抽出可能なフィールドの一覧(名前、価格、説明、素材など)
  • MISSING_FIELDS: ユーザーが必要としているものの、サイトにないフィールド(例:評価、レビュー)
  • RECOMMENDED_APPROACH: カスタムエージェントを生成する/{alternative} の既存エージェントを使用する/複数のソースを組み合わせる
  • SAMPLE_URLS: エージェント生成用の URL の例(2~3 件)
  • LIMITATIONS: ログイン制限、ページネーションの制限、JS レンダリングなど

AskUserQuestion は使用しないでください。nimble_find_search_agent、nimble_run_search_agent、nimble_url_extract は使用しないでください。 WebSearch、WebFetch、または Nimble CLI 以外の検索・取得方法は使用しないでください。


On receiving the report, the foreground conversation:

1. Presents key findings to the user.
2. If data gaps exist (e.g., missing ratings), asks the user via `AskUserQuestion` how to proceed.
3. Routes to Step 3 (generate) with the discovery context, or Step 2 if existing agents cover the need.

## Step 2: Run existing agent

Two sub-paths based on execution mode.

### 2A: Interactive (small scale, display output)

**2A-1.** Run `nimble agent get --template-name <name>` (CLI). Present schema in markdown tables:

- **Input parameters:** name, required, type, description, example
- **Output fields:** key fields from `skills` dict

See **`references/agent-api-reference.md`** > "Input Parameter Mapping" for the full `input_properties` format and mapping rules.

**2A-2.** Always confirm before running via `AskUserQuestion`:

question: "これらのパラメーターで {agent_name} を実行しますか?" header: "確認" options:

  • label: "エージェントを実行(推奨)" description: "{推定されたパラメーターの概要} を使用して {agent_name} を実行"
  • label: "パラメーターを変更" description: "実行前に入力パラメーターを調整"
  • label: "新しいエージェントを作成" description: "代わりにカスタムエージェントを作成(ステップ 3)"

**2A-3.** Run `nimble agent run --agent <name> --params '{...}'` (CLI). Present results as markdown table. Always ask what to do next:

question: "次に何をしますか?" header: "次のステップ" options:

  • label: "完了" description: "この結果で終了"
  • label: "再実行" description: "異なるパラメーターで再実行"

Do NOT offer script generation as a next step unless the user explicitly mentions needing large-scale extraction (>50 items) or batch processing. Script generation is not a natural follow-up to interactive runs.

**Bulk (2–5 URLs):** Run per URL, aggregate results, handle individual failures without aborting. See **`references/batch-patterns.md`** > "Interactive batch extraction".

### 2B: Script generation (ONLY for large-scale, high-volume tasks)

**This step is ONLY reached when the user explicitly needs to process >50 items at scale or requests batch code/script generation.** Normal requests — even multi-source or "dataset" requests — are handled interactively via Step 2A. Writes a runnable script that calls an existing Nimble agent at scale via the SDK/REST API. This does NOT create new agents — the agent must already exist. Runs as a Task agent. The foreground infers language, launches the agent, and presents the generated script for confirmation.

**2B-1.** Infer language from project context (foreground, before launching):

| Project file                                 | Language          |
| -------------------------------------------- | ----------------- |
| `pyproject.toml`, `requirements.txt`, `*.py` | Python            |
| `package.json`, `tsconfig.json`              | TypeScript/Node   |
| `go.mod`                                     | Go (REST API)     |
| None of the above                            | Default to Python |

**2B-2.** Launch script generation Task agent: `Task(subagent_type="general-purpose", run_in_background=False)`.

**Task prompt template:**

既存の Nimble エージェントを SDK/REST API 経由で大規模に呼び出す {language} スクリプトを作成してください。

Nimble CLI を使用してエージェントのスキーマを調べてください(MCP ではなく Bash 経由):

nimble agent get --template-name <agent_name>

これにより、エージェントの完全な入力/出力スキーマが返されます。

重要:Nimble のすべての操作には CLI(Bash)を使用してください。WebSearch、WebFetch、curl、wget は絶対に使用しないでください。MCP エンドポイントの URL を手動で組み立てないでください。

呼び出す既存のエージェント: {agent_names} ユーザーの意図: {user_prompt} 出力形式: {csv/json/etc} 規模: {件数/クエリ数}

これはスクリプトの生成であり、既存のエージェントを呼び出すコードを記述します。新しいエージェントは作成しないでください (nimble_agents_generate/update/publish)。上記のエージェントはすでに存在します。

手順:

  1. 各エージェントについて nimble agent get --template-name <agent>(CLI)を実行し、input_properties と skills を調べます。
  2. 参考ファイルを読みます:
    • references/sdk-patterns.md(Python の場合)または references/rest-api-patterns.md(その他の言語の場合)
    • references/batch-patterns.md(複数ストアの正規化を行う場合)
  3. 次の内容を含む、完全でそのまま実行できるスクリプトを作成します:
    • 最初にスモークテストを実施し、全バッチの前に単一のクエリを検証します。失敗した場合は中止します。
    • 進捗報告:各ポーリングサイクルの後に、簡潔な 1 行のステータスを表示します。
    • 大規模な結果セットのページネーション処理。
    • 複数ストアのフィールド正規化(該当する場合)。
    • {format} への出力。
    • 大規模なパイプライン(ジョブ数 50 件以上)では、ファイルに逐次書き込みます。

スクリプト全体と、以下の簡潔な概要を返します:

  • 使用したエージェントのスキーマ(入力パラメーター、主な出力フィールド)
  • 正規化マッピング(複数ストアの場合)
  • API 呼び出しの推定総数 Do NOT use AskUserQuestion. Do NOT use nimble_find_search_agent or nimble_run_search_agent. Do NOT call nimble_agents_generate, nimble_agents_update_from_agent, nimble_agents_update_session, or nimble_agents_publish. Do NOT use WebSearch, WebFetch, bash curl, or any non-MCP search/fetch method.

**2B-3.** Present the generated script and confirm execution via `AskUserQuestion` (foreground):

question: "このスクリプトを実行しますか?" header: "確認" options:

  • label: "スクリプトを実行(推奨)" description: "生成されたスクリプトを実行します"
  • label: "先に編集" description: "実行前にスクリプトを確認して変更します"

**No agent validation step here.** The 50-input validation flow (Step 3) is only for agent creation/update. Script generation uses an existing, already-validated agent — just write the script and run it.

## Step 3: Update existing agent or create new (on the Nimble platform)

Updates an existing agent (preferred) or creates a new one on Nimble's platform. **Default to update** when a close-match agent was found in Step 1 — pass the existing agent name to the Task agent so it uses `nimble_agents_update_from_agent` instead of `nimble_agents_generate`. Only create a new agent when Step 1 returned 0 matches. This is NOT code/script generation — it creates/modifies an extraction definition callable via Step 2A or 2B. ALWAYS runs as a Task agent (`run_in_background=False`).

### 3-1. Create a stable `session_id` (UUID v4).

### 3-2. Ask the user ONCE (foreground only — agent creation/update ONLY, never for script generation):

question: "公開前に refinement-validation を実行しますか?" header: "検証" options:

  • label: "はい、検証する(推奨)" description: "検出 → 生成 → 50 件の入力を検証(合格率 80%)→ 公開します。不合格の場合は自動で再試行します。"
  • label: "いいえ、生成のみ" description: "検証テストを行わず、生成後すぐに公開します"

### 3-3. Launch Task agent

Set `refine_validate` to the user's choice. Launch `Task(subagent_type="general-purpose", run_in_background=False, max_turns=50)` using the prompt template from **`references/generate-update-and-publish.md`** (includes MCP tool registry, lifecycle phases, and all rules). Tell the user: "Agent generation started. I'll report results when complete."

The Task agent executes a closed-loop lifecycle: Discovery → Create/Update → Poll → Validate → Publish → Report. On failure, it auto-triggers an update loop (max 2 cycles, 15-minute wall-clock timeout). See the reference file for complete details.

### 3-4. Present report

When the Task agent completes, present the report. On success, route to Step 2A or 2B. On failure after max cycles, offer:

question: "エージェントの検証で合格率が 80% に達しませんでした。どのように進めますか?" header: "次のステップ" options:

  • label: "そのまま公開" description: "現在の合格率({rate}%)で公開します"
  • label: "エージェントを更新" description: "エージェントを改善するための具体的な指示を入力します"

## Step 4: Final response

End with a concise summary table:

| Field             | Value                      |
| ----------------- | -------------------------- |
| Agent(s) used     | `agent_name`               |
| Source            | Existing / Generated       |
| Records extracted | count                      |
| Output            | Displayed / `filename.csv` |

Include the extraction results (or top N if large).

## Additional references

Load reference files **only during large-scale script generation (Step 2B)** or agent creation (Step 3). Do NOT load these for interactive runs (Step 2A) — MCP tool schemas are sufficient.

**For script generation (Step 2B) only:**

- **`references/sdk-patterns.md`** — Running agents, async endpoint, batch pipelines, incremental file writes.
- **`references/rest-api-patterns.md`** — REST API patterns for TypeScript, Node, curl, and other non-Python languages.
- **`references/batch-patterns.md`** — Multi-store comparison, normalization, interactive batch, codegen walkthrough.

**For agent creation/update (Step 3) only:**

- **`references/generate-update-and-publish.md`** — Full agent creation/update lifecycle: discovery, creation, polling, SDK validation (50 inputs, 80% threshold), publish, reporting, update loop.

**General (any step, load as needed):**

- **`references/agent-api-reference.md`** — MCP tools reference plus input parameter mapping.
- **`references/error-recovery.md`** — Error handling and recovery patterns.

## Guardrails

- **Agent creation/update runs in Task agents.** Generation takes 1-3 minutes — use a background Task agent for the generate → poll → publish loop. See [Delegation model](#delegation-model).
- **All operations use CLI (Bash).** MCP tools are a fallback only when CLI is unavailable.
- **All web search MUST use `nimble search` (CLI).** NEVER use `WebSearch`, `WebFetch`, `curl`, or `wget` — in foreground or Task agents.
- **Every Task agent prompt MUST include the CLI commands block** (see [Delegation model](#delegation-model)).
- **Never** use `nimble_find_search_agent`, `nimble_run_search_agent`, or any WSA template tools.
- **Update state machine:** use `nimble agent generate --from-agent` to iterate on existing agents. Each iteration creates a new generation to poll.
- **Hard 429 rule.** On quota errors: stop, report exhaustion. Do not retry or switch tools.
- Published agents are automatically forked when updated. UBCT-based agents cannot be updated — generate a new one instead.
- **Never load SDK/batch references for interactive runs (Step 2A).** CLI output from `nimble agent get --template-name` is sufficient. Load references only for Step 2B (script generation) and Step 3 (agent creation).
- Present results in markdown tables. Never show raw JSON.

コメント