nimble-agent-builder

Nimble Agent Builder

在 Nimble 平台上构建、优化并发布可重复使用的提取 Agent。始终以已执行的结果或可运行的代码结束。

用户请求：$ARGUMENTS

前提条件

在会话开始时选择 CLI 或 MCP——它们是同一技能的两种传输方式。选定传输方式后，本次会话中始终使用该方式，不要在每条命令前重复探测。

优先尝试 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 已连接 → 使用 mcp__plugin_nimble_nimble__* 工具而不是 CLI 继续操作。

两者均不可用 → 加载 rules/setup.md。安装方式取决于宿主环境：

• 任何 Claude 产品（Code、Cowork、claude.ai）→ /plugin install nimble（一条命令，自动将 MCP 注册为连接器，并通过 OAuth 处理身份验证）。
• Codex CLI 或其他仅限终端的 Agent → 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 探测进行验证。如果出现身份验证错误、未连接错误或 OAuth 授权 URL，表示尚未连接——原样提供 rules/setup.md 中的连接步骤，然后停止。绝不使用 WebFetch、WebSearch、curl 或任何其他工具替代。

如果工具返回 OAuth「Authorize」链接而不是数据，请按原样提供该链接并停止。绝不要编造「把 URL 粘贴回来」/「我会完成连接」之类的步骤——实际上不存在此类步骤；也绝不要声称工具「即将启用」，然后在同一轮中调用它们。

---

技能生态

nimble-agent-builder 和 nimble-web-expert 在 Nimble 工具包中配合使用：

技能	最适合的用途	关键命令
nimble-agent-builder（本技能）	构建可重复使用的 Agent——创建、优化并发布具有固定架构的命名提取模板	CLI：generate、get-generation、publish
nimble-web-expert	实时数据访问——获取任意 URL、搜索、映射、爬取、运行已发布的 Agent	extract、search、map、crawl、agent run

以下情况请留在 nimble-agent-builder 中

• 为某个领域生成新的 Agent
• 优化或更新现有 Agent（添加字段、修正选择器、更改架构）
• 发布 Agent
• 通过 nimble agent run（CLI）运行已发布的 Agent
• 验证 Agent 输出质量
• 任何表述为「构建」「优化」「更新」「添加字段」或「发布」的任务

以下情况请转到 nimble-web-expert

发布 Agent 后——在此处直接通过 nimble agent run 运行。仅当工作流需要本技能不具备的工具时，才转到 nimble-web-expert：

• 需要网址列表作为 Agent 的输入？→ 切换到 nimble-web-expert，运行 nimble map --url <site> 进行爬取并生成输入列表，然后返回此处进行大规模运行。
• 需要搜索输入参数？→ 切换到 nimble-web-expert，运行 nimble search，然后带着结果返回此处。

任务与构建 Agent 无关时：

• 一次性获取 URL、网页搜索、站点映射、批量爬取 → nimble-web-expert
• 告诉用户：“这是直接的数据访问任务，而不是构建 Agent 的任务。请使用 nimble-web-expert。”

需要调查网站时生成 Agent

如果 nimble_agents_generate 或 nimble_agents_update_from_agent 因为未知的网站数据结构（选择器错误、缺少 XHR 模式、意外的 JS 渲染）而无法生成可用的 Agent：

步骤 1 — 宣告： “我无法在不先调查实时页面的情况下生成可靠的 Agent。正在启动网站调查……”

步骤 2 — 启动 Task Agent（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 — 使用报告重试 Agent 生成：在 nimble_agents_update_session 调用中传入选择器/XHR 上下文和建议的提取命令。

步骤 4 — 如果调查也失败： 告知用户：“此网站需要复杂的浏览器自动化，目前无法通过 Agent 实现。请使用 nimble-web-expert 的 Tier 4/5 命令，并添加 --browser-action 或 --network-capture，以直接访问数据。”

---

核心原则

• 以最快方式获取数据。 默认路径：发现 Agent → 获取架构 → 运行 → 显示结果。规划和生成是升级处理路径。
• 始终先搜索现有 Agent。 考虑生成之前，先运行 nimble agent list --limit 100 --search "<domain or vertical>"（CLI）。这是硬性规则。
• 始终优先更新，而非生成。 如果存在高度匹配的 Agent（相同域名/类型，即使缺少字段或范围不同），应更新它，而不是从头生成。更新可以保留经过验证的提取逻辑，而且更快、更省成本、更可靠。只有当目标域名的 --search 查询没有返回任何匹配项时，才生成新 Agent。存在高度匹配项时，绝不要推荐“创建新 Agent”。
• 前台每个决策点都必须使用 AskUserQuestion — 无一例外。 始终展示每个步骤中列出的标准 AskUserQuestion 提示。绝不跳过，也绝不在未询问的情况下自动进入下一步。绝不要将选项作为普通编号列表呈现。限制：2–4 个选项，标题最多 12 个字符，标签为 1–5 个单词。推荐选项放在首位，并标注“（推荐）”。注意：Task Agent 绝不使用 AskUserQuestion — 启动 Task 前须预先做出所有决定。
• 始终先获取架构，再运行。 运行 nimble agent get --template-name <name>（CLI），然后再运行 nimble agent run。以 Markdown 表格展示输入参数和输出字段。切换 Agent 时也适用。
• 代码生成（步骤 2B）仅适用于大规模、高流量任务。 普通交互式请求绝不生成代码。脚本模式必须同时满足以下所有条件：规模 >50 项，且用户明确要求代码/脚本/CSV/批量输出。多来源请求、数据集请求和比较请求不会自动触发脚本模式 — 应先以交互方式运行。默认路径始终是：发现 → 运行 → 显示结果。
• 生成脚本前验证响应结构。 检查 nimble agent get --template-name（CLI）返回的 skills 和 entity_type，以确定 REST API 响应的嵌套结构。参见 references/agent-api-reference.md > “响应结构推断”以及 references/sdk-patterns.md > “响应结构验证”。
• google_search 不是通用搜索工具。 它是用于排名跟踪和 SEO 分析的 SERP 分析 Agent。查找信息时，请使用 nimble search（CLI）。参见 references/error-recovery.md。
• 所有网页搜索都必须使用 nimble search（CLI）。 绝不要使用 WebSearch、WebFetch、curl 或 wget。参见防护措施。
• Agent 的创建/更新须在后台 Task Agent 中运行。 生成需要 1–3 分钟 — 将生成 → 轮询 → 发布的流程作为 Task Agent 运行，以免阻塞用户。参见委派模式。

委派模型

前台对话负责协调并呈现结果。任务 Agent 负责耗时较长的工作（生成、发现、脚本生成）。

前台 — 通过 Bash 直接调用 CLI：

CLI 命令	用途	最多调用次数
nimble agent list --limit 100 --search "<domain>"	路由到现有 Agent	每个领域 1 次
nimble agent get --template-name	运行前显示架构	每个 Agent 1 次
nimble agent run --agent --params	交互式执行（≤5 个项目）	每个项目 1 次
nimble search	网络搜索 / 发现	按需

任务 Agent — 耗时较长的操作：

阶段	任务 Agent	前台负责的事项
发现（nimble search + nimble map）	第 1D 步	启动、呈现报告
创建 / 更新 Agent（nimble agent generate → get-generation 轮询 → publish）	第 3 步	启动、呈现报告
脚本生成（编写调用现有 Agent 的代码）	第 2B 步	启动、呈现脚本

Agent 创建由任务 Agent 执行，因为生成需要 1-3 分钟（轮询循环）。 任务 Agent 通过 Bash 使用 CLI 命令。如果 CLI 不可用，则改用 MCP 工具。

对于多来源工作流，按顺序启动任务 Agent（每个来源 / 阶段启动一个）。收集报告后，再呈现整合后的计划。

任务 Agent 的 CLI 命令

所有任务 Agent 提示词都应包含此代码块，让子 Agent 了解可用命令：

**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）— SERP	data.parsing	list（数组）	交互式运行（第 2A 步）
CLI（nimble agent run）— PDP	data.parsing	dict（扁平）	交互式运行（第 2A 步）
REST API — 电商 SERP	data.parsing	list（数组）	脚本生成（第 2B 步）
REST API — 非电商 SERP	data.parsing.entities.{Type}	带嵌套数组的 dict	脚本生成（第 2B 步）
REST API — PDP	data.parsing	dict（扁平）	脚本生成（第 2B 步）

遍历 REST 响应前，务必检查 typeof / isinstance。

第 1 步：路由

从 $ARGUMENTS 中检测 3 项内容：

1. 清晰度 — clear（默认）或 needs-planning

只有在以下内容全部缺失时，才选择 needs-planning：目标 URL／网站／域名、明确要提取的数据、范围明确的单一任务。大多数请求都属于 clear。

2. Agent 匹配 — 运行 nimble agent list --limit 100 --search "<domain or vertical>"（CLI、Bash）。使用用户指定的域名／网站作为搜索词（例如 --search "amazon"、--search "jobs"、--search "ecommerce"）。这始终是第一项操作。对于多来源请求（例如“比较 Amazon 和 Walmart 的价格”），每个来源分别搜索一次。如果某个来源没有匹配项，则将其路由到 Discovery（第 1D 步）。

结果	路由
完全匹配	显示架构摘要 + AskUserQuestion：“使用此 Agent”（推荐）／“创建新 Agent” → 第 3 步
接近匹配（相同领域／类型，但缺少字段或范围不同）	显示架构差异 + AskUserQuestion：“更新此 Agent”（推荐）／“创建新 Agent”。始终推荐更新——这样可以保留现有提取逻辑，而且比从头生成更快。
有 2 个或更多可能的匹配项	显示表格 + 使用最匹配项和“更新最接近的 Agent”（推荐）进行 AskUserQuestion。选择字段重叠最多的 Agent。
0 个匹配项	启动 Discovery Task agent（第 1D 步）→ 结果用于第 3 步。只有这种情况适合生成新 Agent。

3. 执行模式 — interactive（默认）或 script

交互模式始终是默认选项。 只有同时满足以下两个条件时，才路由到脚本生成（第 2B 步）：(a) 明确要求处理超过 50 个项目，或用户提供了批量输入文件；且 (b) 用户明确要求代码、脚本、CSV 导出或批处理。“数据集”“比较”“多来源”或“2 个来源”等词语不会触发脚本模式——应以交互方式执行。脚本生成会编写调用现有 Agent 的代码——不会创建新 Agent。如果尚无 Agent，先在第 3 步解决此问题，再生成脚本。

第 1P 步：计划模式（少见——仅在 needs-planning 时使用）

1. 澄清 — 使用 AskUserQuestion 解决关键未知项（最多 2 个问题）。重点询问：哪些网站、哪些数据字段、输出格式。
2. 探索 — 运行 nimble agent list --limit 100 --search "<domain>"（CLI，每个域名运行一次）。对于不熟悉的领域，启动 Discovery Task agents（第 1D 步）。
3. 呈现计划 — 差异分析表：

#	网站／数据源	Agent	状态
1	amazon.com 产品	amazon-product-details	已有
2	walmart.com 产品	—	生成

4. 执行 — 对现有 Agent 执行第 2 步，对新 Agent 生成执行第 3 步（作为 Task agents）。

第 1D 步：发现（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 模式。

2. 搜索实际示例（深度内容提取）：

   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：生成自定义 Agent / 使用来自 {alternative} 的现有 Agent / 合并来源
• SAMPLE_URLS：用于生成 Agent 的 2–3 个示例 URL
• 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: "运行 Agent（推荐）" description: "使用推断出的参数执行 {agent_name}：{summary of inferred parameters}"
• label: "更改参数" description: "调整输入参数后再运行"
• label: "创建新 Agent" description: "改为创建自定义 Agent（第 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:**

编写一个 {language} 脚本，通过 SDK/REST API 批量调用现有 Nimble Agent。

使用 Nimble CLI 检查 Agent 架构（通过 Bash，而非 MCP）：

nimble agent get --template-name <agent_name>

这会返回 Agent 的完整输入/输出架构。

重要：所有 Nimble 操作都必须使用 CLI（Bash）。绝不要使用 WebSearch、WebFetch、curl 或 wget。绝不要手动构造 MCP 端点 URL。

要调用的现有 Agent：{agent_names} 用户意图：{user_prompt} 输出格式：{csv/json/etc} 规模：{number of items/queries}

这是脚本生成任务——编写调用现有 Agent 的代码。不要创建新 Agent （不使用 nimble_agents_generate/update/publish）。上面列出的 Agent 已经存在。

步骤：

1. 对每个 Agent 运行 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. 编写完整且可直接运行的脚本，包含：
   • 先进行冒烟测试——在完整批处理中验证单个查询。失败时中止。
   • 进度报告——每个轮询周期后输出简洁的单行状态。
   • 大型结果集的分页处理。
   • 多店铺字段标准化（如适用）。
   • 输出为 {format}。
   • 大型流水线（50+ 个任务）采用增量文件写入。

返回完整脚本，并简要总结：

• 使用的 Agent 架构（输入参数、关键输出字段）
• 标准化映射（如涉及多个店铺）
• 预计 API 调用总次数 请勿使用 AskUserQuestion。请勿使用 nimble_find_search_agent 或 nimble_run_search_agent。 请勿调用 nimble_agents_generate、nimble_agents_update_from_agent、nimble_agents_update_session 或 nimble_agents_publish。 请勿使用 WebSearch、WebFetch、bash curl 或任何非 MCP 搜索／抓取方法。

**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: "Agent 验证未达到 80% 的通过率。如何继续？" header: "下一步" options:

• label: "仍然发布" description: "以当前通过率（{rate}%）发布"
• label: "更新 Agent" description: "提供具体指示以改进 Agent"

## 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.