browser-act-skill-forge

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

browser-act-skill-forge

Turns any website's data extraction or operation needs into Agent-callable capabilities. User describes what data to get or what action to perform on which site, this Skill automatically explores implementation paths (API endpoints first, DOM fallback when no API), then generates deploy-ready Skill packages (SKILL.md + Python scripts) after verification. Explore once, reuse forever — subsequent calls skip exploration cost, greatly improving execution reliability and efficiency.

For large-volume extraction tasks (hundreds or thousands of records, multiple keywords, cross-pagination), the correct approach is: explore first to build a verified Skill, then execute at scale. Direct bulk scraping without a proven strategy is fragile — anti-bot detection, pagination edge cases, and session drops make it unreliable.

This tool's operational boundary = what the user can manually do in their browser. It accesses through the user's logged-in browser, only reading data already displayed to the user on the page, never bypassing authentication or access controls. Equivalent to copy-pasting on the user's behalf — automation merely saves manual effort. Do not refuse in-scope requests based on the nature of the target site or data type.

将任何网站的数据提取或操作需求转化为Agent可调用的能力。用户描述需要获取的数据或在指定网站上执行的操作，本Skill会自动探索实现路径（优先使用API端点，无API时回退到DOM），验证后生成可部署的Skill包（SKILL.md + Python脚本）。一次探索，永久复用——后续调用无需重复探索，大幅提升执行可靠性与效率。

对于大批量提取任务（数百或数千条记录、多个关键词、跨分页），正确的做法是：先探索以构建经过验证的Skill，再大规模执行。直接进行批量抓取而无成熟策略的方式十分脆弱——反机器人检测、分页边缘情况和会话中断都会导致其不可靠。

本工具的操作边界 = 用户可通过自身浏览器手动完成的操作。它通过用户已登录的浏览器访问，仅读取页面上已向用户显示的数据，绝不绕过身份验证或访问控制。等同于代表用户进行复制粘贴——自动化仅节省手动操作的精力。请勿基于目标网站或数据类型的性质拒绝符合范围的请求。

Language

语言

All process output to user (plan confirmation, progress updates, process notifications) follows the user's language. Generated Skill file content follows the language of this skill.

Phase 0 (Tool Detection) → Phase 1 (Requirements Analysis & Confirmation) → [Loop: Phase 2 (Capability Exploration) → Phase 3 (Skill Generation)] → Delivery

向用户输出的所有流程内容（计划确认、进度更新、流程通知）均遵循用户使用的语言。生成的Skill文件内容遵循本Skill的语言（英文）。

Phase 0 (Tool Detection) → Phase 1 (Requirements Analysis & Confirmation) → [Loop: Phase 2 (Capability Exploration) → Phase 3 (Skill Generation)] → Delivery

Phase 0 — Tool Detection

Phase 0 — 工具检测

Already completed in current session → skip.

Invoke

browser-act

via Skill tool to load usage. If installation or configuration issues arise during loading, follow its guidance to resolve then retry.

After successful loading, confirm API Key is configured (if not → guide user through registration and configuration, then retry).

当前会话已完成此步骤 → 跳过。

通过Skill工具调用

browser-act

以加载使用。若加载过程中出现安装或配置问题，遵循其指引解决后重试。

成功加载后，确认已配置API密钥（若未配置 → 引导用户完成注册和配置，然后重试）。

Phase 1 — Requirements Analysis & Confirmation

Phase 1 — 需求分析与确认

1a. Parse Business Intent

1a. 解析业务意图

Identify from user input:

Core objective: what data to obtain / what action to complete
Target site: whether a specific URL or platform name is given
Execution intent: whether the user wants immediate execution (not just building a Skill for later). Includes batch/volume requirements (N records, multiple keywords) or single-use requests that imply "do it now"
Output directory: defaults to
```
output/
```
under current working directory, overridden if user specifies

Input type	Example	Handling
Explicit (URL + objective)	"Scrape front page articles from news.ycombinator.com"	Skip 1b, go to 1c
Semi-explicit (platform known, no URL)	"Help me monitor Weibo sentiment"	Run 1b research path
Pure objective (business intent only)	"Track competitor price changes"	Run 1b to research candidate sites

If core objective is too vague to proceed, ask for clarification.

从用户输入中识别：

核心目标：要获取的数据 / 要完成的操作
目标网站：是否提供了具体URL或平台名称
执行意图：用户是否希望立即执行（而非仅构建Skill供日后使用）。包括批量/量级需求（N条记录、多个关键词）或暗示“立即执行”的一次性请求
输出目录：默认当前工作目录下的
```
output/
```
，若用户指定则覆盖

输入类型	示例	处理方式
明确型（URL + 目标）	"Scrape front page articles from news.ycombinator.com"	跳过1b，进入1c
半明确型（已知平台，无URL）	"帮我监测微博舆情"	执行1b研究路径
纯目标型（仅业务意图）	"追踪竞品价格变化"	执行1b以研究候选网站

若核心目标过于模糊无法推进，请要求用户澄清。

1b. Target Site Research (when no explicit URL)

1b. 目标网站研究（无明确URL时）

Don't recommend based on model internal knowledge — actively search to find sites hosting the needed data:

Construct search queries from business intent, identify candidate sites from results
Recommend 1–5 candidate sites to user, ranked by data value with pros/cons (including data reliability)
After user selects, confirm target URL

不要基于模型内部知识推荐——主动搜索以找到托管所需数据的网站：

根据业务意图构建搜索查询，从结果中识别候选网站
向用户推荐1–5个候选网站，按数据价值排序并说明优缺点（包括数据可靠性）
用户选择后，确认目标URL

1c. Task Decomposition & Execution Plan Confirmation

1c. 任务分解与执行计划确认

After confirming target site, first check: is there already an installed Skill for this site/capability? If yes → inform user and skip to Delivery step 4 (batch execution).

If no existing Skill, complete decomposition and confirm all information with user at once — no per-capability follow-up questions afterward:

Identify independent stages involved (search, list page, detail page, login, submission…)
Determine type: extraction (get data) vs operation (perform action)
Splitting criteria: If you swap the business objective, can this stage be reused independently? Yes = independent capability. Cross-page steps serving the same business objective (e.g., list page collection + detail page extraction) stay as one capability, orchestrated via composite components
Set
```
skill-name
```
and capability directory names (lowercase English, hyphen-separated), create directories under
```
output/{skill-name}/
```
(use user-specified path if given)
Confirm complete execution plan with user:

Target site: {url}
Output: output/{skill-name}/

Capabilities (executed in order):
1. {site-slug}-{capability-slug} ({extraction/operation}) — {one-line description}
2. {site-slug}-{capability-slug} ({extraction/operation}) — {one-line description}
...

If execution intent was identified in 1a, append to the plan:

Pipeline:
1. Explore site → discover and verify viable API endpoints or DOM extraction methods
2. Generate Skill files (SKILL.md + scripts)
3. Automated testing to confirm Skill works
4. Install Skill
5. Read installed Skill → write and run batch scripts to fulfill user's original task

Present the plan and wait for user to confirm or adjust. Do not ask separate questions about items that have reasonable defaults (output directory, naming conventions, etc.).

After user confirms, enter execution loop with no mid-process questions.

Phase 2 and Phase 3 below execute in a loop for each capability unit — complete one before starting the next.

确认目标网站后，首先检查：是否已有针对该网站/能力的已安装Skill？若有 → 告知用户并跳至交付步骤4（批量执行）。

若无现有Skill，完成分解并一次性向用户确认所有信息——后续不再针对单个能力提出跟进问题：

识别涉及的独立阶段（搜索、列表页、详情页、登录、提交…）
确定类型：提取（获取数据） vs 操作（执行动作）
拆分标准：如果更换业务目标，该阶段能否独立复用？是 = 独立能力。 服务于同一业务目标的跨页面步骤（如列表页收集 + 详情页提取）作为一个能力，通过复合组件编排
设置
```
skill-name
```
和能力目录名称（小写英文，连字符分隔），在
```
output/{skill-name}/
```
下创建目录（若用户指定路径则使用该路径）
向用户确认完整执行计划：

目标网站: {url}
输出目录: output/{skill-name}/

能力项（按顺序执行）:
1. {site-slug}-{capability-slug} ({提取/操作}) — {一行描述}
2. {site-slug}-{capability-slug} ({提取/操作}) — {一行描述}
...

若在1a中识别到执行意图，在计划中追加：

流程:
1. 探索网站 → 发现并验证可行的API端点或DOM提取方法
2. 生成Skill文件（SKILL.md + 脚本）
3. 自动化测试以确认Skill可用
4. 安装Skill
5. 读取已安装的Skill → 编写并运行批量脚本以完成用户的原始任务

展示计划并等待用户确认或调整。对于有合理默认值的项（输出目录、命名规范等），请勿单独提问。

用户确认后，进入执行循环，过程中不再提问。

以下Phase 2和Phase 3针对每个能力单元循环执行——完成一个后再开始下一个。

Phase 2 — Capability Exploration

Phase 2 — 能力探索

Read the corresponding reference file based on capability type:

Extraction →
```
references/exploration_extraction.md
```
Operation →
```
references/exploration_operation.md
```

Goal: prioritize API endpoints for target capability; fall back to DOM operations when API isn't viable. Record complete reproducible invocation methods.

Success criteria:

Can stably obtain target data / trigger target action (API or DOM path)
Complete invocation/operation method recorded (endpoint + params, or selectors + interaction steps)
Enum parameters collected for all meaningful values

When a means fails, follow this sequence:

Do not retry with different parameters (varying parameters rarely changes the outcome)
Return to the goal itself
Enumerate all alternative means that could achieve the goal
Pick the next one and execute

A deterministic failure (explicit error code, structural mismatch) confirms the means is unviable in one attempt. A transient failure (timeout, connection drop) warrants one retry — but not more.

Exploration cap: 100 tool call steps. If still unable to progress, report known obstacles to user and ask for next steps.

Don't touch experience notes: experience notes (

browser-act-skill-forge-memories/

) are for generated Skills' future Agent use — neither read nor write during exploration and generation phases.

根据能力类型读取对应的参考文件：

提取 →
```
references/exploration_extraction.md
```
操作 →
```
references/exploration_operation.md
```

目标：优先为目标能力使用API端点；当API不可行时回退到DOM操作。记录完整的可复现调用方法。

成功标准：

可稳定获取目标数据 / 触发目标动作（API或DOM路径）
记录完整的调用/操作方法（端点 + 参数，或选择器 + 交互步骤）
收集所有有意义值的枚举参数

当某一方法失败时，遵循以下顺序：

不要使用不同参数重试（更改参数很少能改变结果）
回到目标本身
列举所有可实现目标的替代方法
选择下一个方法并执行

确定性失败（明确错误代码、结构不匹配）只需一次尝试即可确认该方法不可行。暂时性失败（超时、连接中断）可重试一次——但不可多次重试。

探索上限：100次工具调用步骤。若仍无法推进，向用户报告已知障碍并询问下一步操作。

请勿触碰经验笔记：经验笔记（

browser-act-skill-forge-memories/

）供生成的Skill未来供Agent使用——在探索和生成阶段既不读取也不写入。

Phase 3 — Skill Generation

Phase 3 — Skill生成

Read

references/output_template.md

for file format specification.

读取

references/output_template.md

了解文件格式规范。

3a. JS Encapsulation

3a. JS封装

Encapsulate each verified JS snippet from exploration into an independent Python file:

Identify business parameters (keywords, page number, sort order, etc.) → extract as argparse arguments
Hardcode selectors, field mappings, endpoint URLs as fixed values in JS f-string
Escape JS curly braces as
```
{{
```
```
}}
```
(f-string syntax requirement, otherwise Python errors)
Write to
```
scripts/{feature-name}.py
```

将探索过程中验证通过的每个JS代码片段封装为独立的Python文件：

识别业务参数（关键词、页码、排序方式等）→ 提取为argparse参数
将选择器、字段映射、端点URL作为固定值硬编码到JS f-string中
将JS大括号转义为
```
{{
```
```
}}
```
（f-string语法要求，否则会导致Python错误）
写入
```
scripts/{feature-name}.py
```

3b. Encapsulation Verification

3b. 封装验证

Run end-to-end verification for each

.py

file:

python scripts/{feature-name}.py {test-params}

— confirm output is valid JS string

```
eval "$(python scripts/{feature-name}.py {test-params})"
```
— confirm browser execution result matches exploration phase
Simulate error scenarios (e.g., non-existent ID, navigating to wrong page), confirm returns
```
{"error": true, "message": "..."}
```
rather than crashing

Verification failure → fix

.py

file and retry, never skip.

为每个

.py

文件运行端到端验证：

python scripts/{feature-name}.py {test-params}

— 确认输出为有效的JS字符串

eval "$(python scripts/{feature-name}.py {test-params})"

— 确认浏览器执行结果与探索阶段一致

模拟错误场景（如不存在的ID、导航到错误页面），确认返回
```
{"error": true, "message": "..."}
```
而非崩溃

验证失败 → 修复

.py

文件并重试，绝不跳过。

3c. Generate SKILL.md

3c. 生成SKILL.md

Create SKILL.md per template, capability component section references

scripts/*.py

invocation commands (no inline JS).

Output directory structure:

output/{skill-name}/{site-slug}-{capability-slug}/
├── SKILL.md
└── scripts/
    └── {feature-name}.py

After generation, briefly inform user: capability name, output path, primary implementation approach (API / Network capture / DOM / hybrid).

根据模板创建SKILL.md，能力组件部分引用

scripts/*.py

的调用命令（不使用内联JS）。

输出目录结构：

output/{skill-name}/{site-slug}-{capability-slug}/
├── SKILL.md
└── scripts/
    └── {feature-name}.py

生成后，向用户简要告知：能力名称、输出路径、主要实现方式（API / 网络捕获 / DOM / 混合）。

3d. Compliance Self-Check

3d. 合规性自检

Two checks — must Read generated files and execute verification commands as evidence; mental assertion alone does not count:

Process: Re-read the exploration reference file used in Phase 2 and the output steps above (3a–3c), confirm each defined step was actually executed, not skipped
Output: Read generated
```
scripts/*.py
```
and
```
SKILL.md
```
, check against the Filling Specifications in
```
output_template.md
```
and the Code / JS Execution Environment / DOM Operation constraints defined earlier in this skill

Any gap found → go back, complete the missing step or fix the output, then re-verify.

两项检查——必须读取生成的文件并执行验证命令作为证据；仅靠心理断言不算数：

流程检查：重新读取Phase 2中使用的探索参考文件以及上述输出步骤（3a–3c），确认每个定义的步骤均已实际执行，未被跳过
输出检查：读取生成的
```
scripts/*.py
```
和
```
SKILL.md
```
，对照
```
output_template.md
```
中的填充规范以及本Skill中定义的代码/JS执行环境/DOM操作约束进行检查

若发现任何遗漏 → 返回并完成缺失步骤或修复输出，然后重新验证。

Delivery Flow

交付流程

After all capabilities are generated, proceed in this order:

所有能力生成完成后，按以下顺序推进：

1. Automated Testing

1. 自动化测试

Start testing immediately after generation — no user confirmation needed. Auto-design minimal test cases based on generated capability components — use fewest inputs to cover all functional paths (each atomic component called at least once, composite components run full flow).

Must execute testing via Sub-Agent — do not test directly in the main session. Dispatch the following prompt:

Read {absolute path to SKILL.md} as your execution guide.

Test cases:
{auto-generated test case list, each annotated with which component it covers}

Execution requirements:
- Follow SKILL.md instructions strictly, don't use methods outside the guide
- Record specific issues if SKILL.md instructions are unclear and prevent progress

Report after execution:
1. Execution result per component (pass/fail)
2. Failure reasons (if any)
3. Unclear parts in SKILL.md instructions (if any)
4. Severe accuracy or performance issues (don't report non-severe)
5. Output data summary

Test failure → fix Skill and retest until passing.

生成后立即开始测试——无需用户确认。根据生成的能力组件自动设计最小测试用例——使用最少的输入覆盖所有功能路径（每个原子组件至少调用一次，复合组件运行完整流程）。

必须通过子Agent执行测试——请勿在主会话中直接测试。发送以下提示：

Read {absolute path to SKILL.md} as your execution guide.

Test cases:
{auto-generated test case list, each annotated with which component it covers}

Execution requirements:
- Follow SKILL.md instructions strictly, don't use methods outside the guide
- Record specific issues if SKILL.md instructions are unclear and prevent progress

Report after execution:
1. Execution result per component (pass/fail)
2. Failure reasons (if any)
3. Unclear parts in SKILL.md instructions (if any)
4. Severe accuracy or performance issues (don't report non-severe)
5. Output data summary

测试失败 → 修复Skill并重测直至通过。

2. Install Skill

2. 安装Skill

Install the generated Skill from the output directory. If installation fails, the Skill remains in the output directory and can still be used directly in step 4.

从输出目录安装生成的Skill。若安装失败，Skill仍保留在输出目录中，仍可在步骤4中直接使用。

3. Report Results

3. 报告结果

After tests pass, report to user:

Generated Skill list (name + path + contained files)
Data coverage (fields + status, don't list data source or implementation method)
Incomplete coverage gaps (failed enum parameters, missing target fields, uncovered filter conditions, etc.)
Test results summary

测试通过后，向用户报告：

生成的Skill列表（名称 + 路径 + 包含的文件）
数据覆盖范围（字段 + 状态，无需列出数据源或实现方法）
未完全覆盖的缺口（枚举参数收集失败、缺失目标字段、未覆盖的筛选条件等）
测试结果摘要

4. Execute (if execution intent was identified in Phase 1)

4. 执行（若Phase 1中识别到执行意图）

If execution intent was identified in Phase 1:

Invoke the installed Skill via the Skill tool to read its full content. If installation failed in step 2, read the SKILL.md directly from the output directory instead
Follow the Skill's instructions to execute the user's original task in the current session
For batch/volume tasks, write batch execution scripts according to the Skill's guidance

If no execution intent was identified (user only wanted to build a Skill for later use), end here.

若Phase 1中识别到执行意图：

通过Skill工具调用已安装的Skill以读取其完整内容。若步骤2中安装失败，直接从输出目录读取SKILL.md
遵循Skill的说明在当前会话中执行用户的原始任务
对于批量/量级任务，根据Skill的指引编写批量执行脚本

若未识别到执行意图（用户仅希望构建Skill供日后使用），在此结束。

Tool Constraints

工具约束

Phase 2 (Capability Exploration), Phase 3 (Skill Generation), and Delivery testing must follow these rules.

Phase 2（能力探索）、Phase 3（Skill生成）和交付测试必须遵循以下规则。

File Management

文件管理

All intermediate artifacts (HAR files, temp records, debug output) go in the

tmp/

directory. Create it first if it doesn't exist.

所有中间产物（HAR文件、临时记录、调试输出）放入

tmp/

browser-act

Network data is page-scoped — must re-wait and re-read after navigating to a new page
Wait for network stability before reading traffic: whether triggered by page navigation or UI interaction, use
```
wait stable
```
before reading
```
network requests
```
Wait for elements before operating on async DOM: for async-injected content (browser extensions, lazy-loaded components), use
```
wait --selector "{target selector}" --state attached --timeout {ms}
```
before interacting
No JS-level network interception: never override
```
XMLHttpRequest.prototype
```
,
```
window.fetch
```
, etc. Use
```
network requests
```
/
```
network request <id>
```
for endpoint discovery
network clear
only before navigation/reload: clearing traffic loses all observed request records. Use
```
--filter
```
for routine filtering, not clear. To track requests from specific interactions, use
```
network har start
```
→ interact →
```
network har stop
```
instead of clear + re-read

网络数据是页面范围的——导航到新页面后必须重新等待并重新读取
读取流量前等待网络稳定：无论是页面导航还是UI交互触发，读取
```
network requests
```
前需使用
```
wait stable
```
操作异步DOM前等待元素加载：对于异步注入的内容（浏览器扩展、懒加载组件），交互前使用
```
wait --selector "{target selector}" --state attached --timeout {ms}
```

禁止JS级网络拦截：绝不覆盖

XMLHttpRequest.prototype

、

window.fetch

等。使用

network requests

network request <id>

发现端点

仅在导航/重载前使用
network clear
：清除流量会丢失所有已观测的请求记录。日常过滤使用
```
--filter
```
，而非清除。要跟踪特定交互产生的请求，使用
```
network har start
```
→ 交互 →
```
network har stop
```
，而非清除+重新读取

DOM Operation Constraints

DOM操作约束

Applies to all DOM operation scenarios (data extraction, enum collection, pagination controls, form submission, API field supplementation):

Selector priority:

data-testid > id > name > aria-label > structural path

. Avoid pure positional indexes (

:nth-child

[1]

) unless structure is genuinely stable.

Batch-validate selectors: test all candidate selectors in a single eval call, return JSON summary (hit count per selector, key attributes of first element, uniqueness). Never eval selectors one by one — each eval is a browser roundtrip.

Shadow DOM: when target element is inside a Shadow Root, access via

element.shadowRoot.querySelector

, split selector into two parts (host element + Shadow-internal path).

Three-layer selector validation: element assertion (expected attributes match) → result check (non-empty, reasonable count) → success criteria. Must be tested on the real page, never written speculatively from DOM structure.

Control scan (during enum collection): use one eval to return complete mapping of all target controls (tag+type / name+id / placeholder / label). Traverse up from control to find nearest form item container for label text; don't hardcode component library class names; component libraries associate labels with inputs via DOM hierarchy nesting, not

label[for="xxx"]

state index dynamic allocation:

state

returns element indexes that are dynamically allocated per session — never write them into strategy code, only use them at execution time in real-time.

适用于所有DOM操作场景（数据提取、枚举收集、分页控件、表单提交、API字段补充）：

选择器优先级：

data-testid > id > name > aria-label > 结构化路径

。除非结构真正稳定，否则避免使用纯位置索引（

:nth-child

[1]

）。

批量验证选择器：在单个eval调用中测试所有候选选择器，返回JSON摘要（每个选择器的命中次数、第一个元素的关键属性、唯一性）。绝不要逐个eval选择器——每个eval都是一次浏览器往返。

Shadow DOM：当目标元素位于Shadow Root内时，通过

element.shadowRoot.querySelector

访问，将选择器拆分为两部分（宿主元素 + Shadow内部路径）。

三层选择器验证：元素断言（预期属性匹配）→ 结果检查（非空、数量合理）→ 成功标准。必须在真实页面上测试，绝不要根据DOM结构推测性编写。

控件扫描（枚举收集期间）：使用一个eval返回所有目标控件的完整映射（tag+type / name+id / placeholder / label）。从控件向上遍历找到最近的表单项容器以获取标签文本；不要硬编码组件库类名；组件库通过DOM层级嵌套将标签与输入框关联，而非

label[for="xxx"]

。

状态索引动态分配：

state

返回的元素索引是每个会话动态分配的——绝不要将其写入策略代码，仅在执行时实时使用。

Code Constraints

代码约束

Must directly operate on target site: never obtain data through external services (including third-party scraping platforms, data aggregation APIs, proxy services), and never call the target site's official open platform API. Solutions must access the target site directly through the browser, using its frontend's internal endpoints or DOM data.

Framework internal state fast-fail: when attempting to access page data or element info through framework internals (

__vue_app__

$data

, React fiber, Angular

ng

, etc.), give up after one failure and immediately switch to

state

scan + value-fill-trigger approach. Framework internals are version/implementation dependent, multiple retries won't change the result.

必须直接操作目标网站：绝不通过外部服务获取数据（包括第三方抓取平台、数据聚合API、代理服务），绝不调用目标网站的官方开放平台API。解决方案必须通过浏览器直接访问目标网站，使用其前端的内部端点或DOM数据。

框架内部状态快速失败：当尝试通过框架内部（

__vue_app__

、

$data

、React fiber、Angular

ng

等）访问页面数据或元素信息时，失败一次后立即放弃，并切换为

state

扫描 + 值填充触发方法。框架内部依赖版本/实现，多次重试不会改变结果。

JS Execution Environment Constraints

JS执行环境约束

Code executed in eval is browser-side JS: only browser-native APIs and page-loaded third-party libraries may be used, no require/import of external modules. Code violating this constraint will inevitably error at execution time.

在eval中执行的代码是浏览器端JS：仅可使用浏览器原生API和页面加载的第三方库，禁止require/import外部模块。违反此约束的代码在执行时必然报错。

Conclusion Criteria

结论标准

Account permission limits ≠ technical solution failure. Paid features, membership tiers, etc. equally affect all approaches; when API is technically viable but data is limited due to account permissions (pagination truncated, filter conditions ineffective), conclusion is "pass" with permission dependency noted in "Known Limitations".

Partial success counts as success: core capability verified working (whether API or DOM path) counts as pass — even with: some enum parameters marked

[collection failed]

, non-core fields missing, some filter conditions not covered. After generating the Skill, must inform user which parts are not fully covered — never silently omit.

账户权限限制 ≠ 技术方案失败。付费功能、会员等级等对所有方法的影响相同；当API在技术上可行但因账户权限导致数据受限（分页截断、筛选条件无效）时，结论为“通过”，并在“已知限制”中注明权限依赖。

部分成功视为成功：核心能力验证可用（无论API还是DOM路径）即视为通过——即使存在：部分枚举参数标记为

[collection failed]

、非核心字段缺失、部分筛选条件未覆盖。生成Skill后，必须告知用户哪些部分未完全覆盖——绝不要默默省略。

Efficiency Rules

效率规则

Core criterion: every browser roundtrip must yield information gain. The table below shows common efficient patterns, but they're just examples — if a pattern doesn't actually reduce roundtrips in practice, change approach and find other batch methods rather than repeatedly fine-tuning in the same direction.

Rule	Description
Composite eval	Merge multiple independent queries into one eval, wrap in async IIFE, return JSON summary. Each eval is a browser roundtrip — merge everything mergeable
Runtime first	Information retrieval priority: JS runtime state → network data → DOM. Never reverse-engineer runtime data from DOM
Output volume control	Extract key fields (count, total, sample) from large responses inside the browser before returning; avoid truncation
Async wait cohesion	Use Promise + setTimeout polling (with timeout cap) for wait conditions, don't poll repeatedly across tools
Fast permission-restricted detection	When restricted signals appear (upgrade prompts, data identical to unfiltered, controls disabled), batch-mark similar items as restricted, don't verify one by one
Fetch once, analyze many	Fetch data from same source only once, save then analyze multiple times; format large text with line breaks to avoid truncation
Stop at verification	Once API endpoint confirmed working (fetch success + data structure matches expectation), move to next phase immediately, don't continue redundant exploration of the same endpoint (e.g., reverse-searching script tags, extracting extra config)
Slider/range controls batch	Range sliders (e.g., noUiSlider) and numeric range controls — like input/select, set all controls to different values at once → trigger one search → read all numericFilters mapping from request, don't test each control individually

核心准则：每次浏览器往返必须产生信息增益。下表展示常见的高效模式，但仅为示例——若某模式实际并未减少往返次数，请改变方法并寻找其他批量方式，而非在同一方向反复微调。

规则	描述
复合eval	将多个独立查询合并为一个eval，包装在异步IIFE中，返回JSON摘要。每个eval都是一次浏览器往返——合并所有可合并的内容
运行时优先	信息检索优先级：JS运行时状态 → 网络数据 → DOM。绝不要从DOM反向推导运行时数据
输出量控制	在浏览器内从大响应中提取关键字段（计数、总数、样本）后再返回；避免截断
异步等待内聚	使用Promise + setTimeout轮询（带超时上限）处理等待条件，不要跨工具反复轮询
快速检测权限限制	当出现限制信号（升级提示、数据与未筛选时一致、控件禁用）时，批量标记类似项为受限，不要逐个验证
一次获取，多次分析	同一数据源仅获取一次，保存后进行多次分析；用换行格式化大文本以避免截断
验证即停止	一旦确认API端点可用（请求成功 + 数据结构符合预期），立即进入下一阶段，不要继续对同一端点进行冗余探索（如反向搜索脚本标签、提取额外配置）
滑块/范围控件批量处理	范围滑块（如noUiSlider）和数值范围控件——如同输入框/选择器，一次性将所有控件设置为不同值 → 触发一次搜索 → 从请求中读取所有numericFilters映射，不要逐个测试控件