bobo-ai-cli 3.0.0 → 3.0.3

package/bundled-skills/webapp-testing/SKILL.md

@@ -1,111 +0,0 @@
----
-id: "webapp-testing"
-title: "Web Application Testing"
-category: "dev-tools"
-tags: ["web application testing", "common pitfall", "best practices", "reference files"]
-triggers: []
-dependencies: []
-source: "E:/Bobo's Coding cache/.claude/skills/webapp-testing"
----
-
----
-name: webapp-testing
-description: Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.
-license: Complete terms in LICENSE.txt
----
-
-# Web Application Testing
-
-To test local web applications, write native Python Playwright scripts.
-
-**Helper Scripts Available**:
-
-- `scripts/with_server.py` - Manages server lifecycle (supports multiple servers)
-
-**Always run scripts with `--help` first** to see usage. DO NOT read the source until you try running the script first and find that a customized solution is abslutely necessary. These scripts can be very large and thus pollute your context window. They exist to be called directly as black-box scripts rather than ingested into your context window.
-
-## Decision Tree: Choosing Your Approach
-
-```
-User task → Is it static HTML?
-    ├─ Yes → Read HTML file directly to identify selectors
-    │         ├─ Success → Write Playwright script using selectors
-    │         └─ Fails/Incomplete → Treat as dynamic (below)
-    │
-    └─ No (dynamic webapp) → Is the server already running?
-        ├─ No → Run: python scripts/with_server.py --help
-        │        Then use the helper + write simplified Playwright script
-        │
-        └─ Yes → Reconnaissance-then-action:
-            1. Navigate and wait for networkidle
-            2. Take screenshot or inspect DOM
-            3. Identify selectors from rendered state
-            4. Execute actions with discovered selectors
-```
-
-## Example: Using with_server.py
-
-To start a server, run `--help` first, then use the helper:
-
-**Single server:**
-
-```bash
-python scripts/with_server.py --server "npm run dev" --port 5173 -- python your_automation.py
-```
-
-**Multiple servers (e.g., backend + frontend):**
-
-```bash
-python scripts/with_server.py \
-  --server "cd backend && python server.py" --port 3000 \
-  --server "cd frontend && npm run dev" --port 5173 \
-  -- python your_automation.py
-```
-
-To create an automation script, include only Playwright logic (servers are managed automatically):
-
-```python
-from playwright.sync_api import sync_playwright
-
-with sync_playwright() as p:
-    browser = p.chromium.launch(headless=True) # Always launch chromium in headless mode
-    page = browser.new_page()
-    page.goto('http://localhost:5173') # Server already running and ready
-    page.wait_for_load_state('networkidle') # CRITICAL: Wait for JS to execute
-    # ... your automation logic
-    browser.close()
-```
-
-## Reconnaissance-Then-Action Pattern
-
-1. **Inspect rendered DOM**:
-
-   ```python
-   page.screenshot(path='/tmp/inspect.png', full_page=True)
-   content = page.content()
-   page.locator('button').all()
-   ```
-
-2. **Identify selectors** from inspection results
-
-3. **Execute actions** using discovered selectors
-
-## Common Pitfall
-
-❌ **Don't** inspect the DOM before waiting for `networkidle` on dynamic apps
-✅ **Do** wait for `page.wait_for_load_state('networkidle')` before inspection
-
-## Best Practices
-
-- **Use bundled scripts as black boxes** - To accomplish a task, consider whether one of the scripts available in `scripts/` can help. These scripts handle common, complex workflows reliably without cluttering the context window. Use `--help` to see usage, then invoke directly.
-- Use `sync_playwright()` for synchronous scripts
-- Always close the browser when done
-- Use descriptive selectors: `text=`, `role=`, CSS selectors, or IDs
-- Add appropriate waits: `page.wait_for_selector()` or `page.wait_for_timeout()`
-
-## Reference Files
-
-- **examples/** - Examples showing common patterns:
-  - `element_discovery.py` - Discovering buttons, links, and inputs on a page
-  - `static_html_automation.py` - Using file:// URLs for local HTML
-  - `console_logging.py` - Capturing console logs during automation

package/bundled-skills/wide-research/SKILL.md

@@ -1,191 +0,0 @@
----
-id: "wide-research"
-title: "Wide Research（Claude Code 版）多实例编排提示 / prompt.md"
-category: "research"
-tags: ["任务目标", "交付标准", "详细流程（claude code 语义）", "呈现与引用", "失败隔离、重试与覆盖率", "思考与写作准则（应用在每一轮输出）", "conclusion", "key evidence", "retrieval scope"]
-triggers: []
-dependencies: []
-source: "E:/Bobo's Coding cache/.claude/skills/wide-research"
----
-
-# Wide Research（Claude Code 版）多实例编排提示 / prompt.md
-
-当用户在会话中提及 “Wide Research” 或引用此文件时，即表示你应加载本指令集。你是主控（Orchestrator），在 **Claude Code** 工作空间中编排可复用的多代理并行流程。任务可能涉及网页调研、代码检索、API 采样、数据清洗与成稿聚合。遵循安全与合规，优先最小化权限与最少外部调用。
-
-**重要：保持 Claude Code 的默认模型与底层配置不变；默认不开启 reasoning（或使用极低预算的 reasoning）。仅在得到用户明确授权时才提高推理档位与预算；且无论是否启用 reasoning，都不要在对外结果中暴露内部推理过程，只提供可验证的结论与证据。**
-
----
-
-## 任务目标
-
-第一步从用户的高层目标出发，推导需要并行处理的子目标集合（如主链接列表、数据集分片、模块清单）。  
-随后为每个子目标在 Claude Code 内部创建独立的“子代理执行单元”，控制权限与工具调用，并行产出结构化 Markdown。  
-将子结果按序聚合为统一成稿，对聚合结果做一次理智检查与最小化修复，返回最终 artefact 路径与要点摘要。
-
----
-
-## 交付标准
-
-成品是结构化、洞察驱动的整体，而不是子结果的机械拼接。子任务原文若需保留，单独写入 `aggregated_raw.md`，在成品中仅吸收关键洞察。  
-润色须逐段进行，每次修改都核对引用与上下文；交付前做双重体检：其一确认是分章节、多轮整合产物，而非一次性生成；其二评估细致程度，若单薄，则判断是素材不足还是统稿压缩过度，对应地补充调研或扩写润色。
-
----
-
-## 详细流程（Claude Code 语义）
-
-0. 预执行规划与摸底（必做）  
-   主控亲自完成首轮摸底，明确目标、风险、约束与核心维度（主题簇、人物、地域、时间切片等）。若有公开目录/索引（标签页、API 列表），用最小化抓取取样；否则做案头调研拿到真实样本，并记录来源、时间与要点。  
-   如工作区提供 Tavily MCP（或等价搜索 MCP），摸底阶段必须优先调用以获得至少一条直接相关样本；若不可用，记录原因并选择替代方案（例如轻量 `http(s)` 抓取）。  
-   形成“草拟清单”：列出维度、已识别选项与样本、规模估算、缺口与不确定性。基于此给出可执行计划（子任务拆分、工具与脚本、输出格式、权限、软超时策略等），用用户语言汇报并待“执行/开始”的明确指令后继续。
-
-1. 初始化与规划  
-   在工作区新建不重复目录 `runs/<日期>-<任务摘要>-<随机后缀>/`，用于脚本、日志、子输出与聚合结果。明确目标、输出格式与评价标准。默认不开 reasoning；若获授权再以低预算开启。
-
-2. 子目标识别  
-   从素材或用户输入构造子目标列表。若源数据稀少，照实处理并记录原因；必要时由主控直接补位完成关键子目标。
-
-3. 子目标并行执行（Claude Code 原生方式）
-
-**Claude Code 并行执行模型**：
-Claude Code 不支持生成独立子代理实例（不像多进程 CLI 工具），而是通过以下方式实现并行：
-
-- **单消息多工具调用**：在一条消息中同时调用多个 MCP 工具（如 `tavily_search`, `reddit__fetch_reddit_hot_threads`）
-- **分批队列执行**：将大量子目标分成多批，每批执行 4-6 个工具调用
-- **Task tool 代理**：对于大规模任务（>20 子目标），使用 Task tool 创建 Explore agents
-
-**并行执行决策树**：
-
-| 子目标数量 | 推荐方案            | 单批并行度    | 批次数 | 预期耗时   | 适用场景                    |
-| ---------- | ------------------- | ------------- | ------ | ---------- | --------------------------- |
-| 1-5        | 单批 MCP 调用       | 4-6 个/批     | 1 批   | 2-5 分钟   | 快速调研、单一维度探索      |
-| 6-15       | 分批 MCP 调用       | 4-6 个/批     | 2-3 批 | 10-20 分钟 | 中等规模 subreddit/页面采样 |
-| 16-30      | Task tool (Explore) | 3-5 agents    | 1-2 轮 | 20-40 分钟 | 大规模网页抓取、多维度研究  |
-| 30+        | Task tool + 分批    | 5-8 agents/批 | 2-4 批 | 40-90 分钟 | 行业全景扫描、竞品矩阵      |
-
-**执行约束**：
-
-- 单条消息 MCP 调用上限：**建议 4-6 个**（实测稳定）
-- 每个子目标工具交互轮次：**≤10 轮**
-- 软超时：小任务 5 分钟，大任务 15 分钟
-
-**输出规范**：
-
-- 每个子目标的结果写入 `child_outputs/<id>.md`
-- 原始数据缓存到 `raw/` 目录（避免重复请求）
-- 如需日志可写入 `logs/<id>.log`（可选）
-
-所有联网需求优先使用 **MCP 搜索/抽取工具（如 tavily_search / tavily_extract）**；仅在无法使用 MCP 时才退回最小化的 `http(s)` 抓取。禁止过度并发、越权访问，遵守 robots 与版权。
-
-4. 子代理产出规范（Markdown，自然语言）  
-   先给出清晰结论与边界，再列关键证据，**就近附链接**（每个要点后给出来源），随后写明检索范围、调用轮次与缺口。遇到失败或超时，新增“失败原因/后续建议”小节，避免聚合阶段出现空白。  
-   若涉及 PDF，优先使用可读性抽取工具；若工具不支持，再选择轻量抓取或手动要点化。
-
-5. 并行执行与监控  
-   记录每个子目标的开始/结束时间、耗时与状态。失败或超时的子任务要标记并在最终报告说明；如必要，对单个子任务重试，避免整体重跑。  
-   遵循“缓存优先”，复用 `raw/` 中已存在的同源数据。
-
-6. 数据聚合与报告生成
-
-**小规模任务（<10 child_outputs）- 手动聚合**：
-逐个 Read `child_outputs/` 中的 Markdown 文件，提取关键信息并按预设结构组织。生成 `final_report.md`（精炼版）和 `aggregated_raw.md`（完整审计追溯）。在"基础稿"层面做去重、去噪，保留就近引用。
-
-**大规模任务（>10 child_outputs）- 结构化聚合**：
-
-方案 A - 使用统一 Schema（推荐）：在 child_outputs 生成阶段就使用标准化 YAML frontmatter，包含关键字段与数据置信度标签。聚合时可选择性使用 Python 脚本解析 frontmatter 并生成 CSV/JSON 汇总表。
-
-方案 B - 分批聚合（当无法使用 Schema 时）：每完成 5-10 个 child_outputs，立即生成"中间聚合稿"（如 `partial_report_01.md`）。最后做"总聚合"，而非一次性处理所有文件。好处：避免 context window 爆炸，降低信息遗漏风险。
-
-7. 结构设计与章纲  
-   通读 `final_report.md` 与关键子输出，设计精修大纲 `polish_outline.md`：目标受众、章节顺序与每章核心论点、素材映射。
-
-8. 分章润色与出稿  
-   新建精修稿 `polished_report.md`，按大纲逐章撰写。每完成一章立即自查事实、引用与语言一致性；对重复信息、引用格式与待确认条目统一整理，同时保留核心事实与量化数据。避免一次性整篇重写，保持可追溯性。
-
-9. 产出与交付  
-   确认精修稿满足正式交付标准（结构完整、语气统一、引用准确）。对外交付以精修稿为准，并附路径与要点摘要；必要时补充后续跟进方式。不对外附带中间稿或内部笔记。
-
----
-
-## 呈现与引用
-
-在最终汇总中，每条要点后直接以 Markdown 链接形式附上来源，便于就地跳转查证，而不是把链接集中到文末。  
-对日期敏感的事实，优先写明**具体日期**（如 2025-10-23），避免“今天/最近/上周”导致歧义。  
-当多观点并存时，分别给出各自的高质量来源，并明示分歧点与证据等级。
-
----
-
-## 失败隔离、重试与覆盖率
-
-并行运行时若有子任务失败，先记录失败 ID 与日志，优先对单个子任务重试。重试前先检查 `child_outputs/<id>.md` 是否已存在合法结果，已存在则跳过，以节省配额并避免重复命中站点。  
-批量结束后，用轻量统计脚本或人工检查清单，确认缺失条目、空字段或引用缺口，确保在报告前被发现并补救。
-
----
-
-## 思考与写作准则（应用在每一轮输出）
-
-要有深度，有独立思考，给我惊喜（但是回答里别提惊喜）。  
-在行动前先判断：我为什么要问这个问题？背后隐藏的假设是什么？是否存在更优设定能带来更根本的解？  
-在动手前先定义**成功标准**：什么样的成品对用户真正有用，而非只是在单点上看起来“正确”。输出时紧扣这些标准。  
-开放性讨论时，以协作心态**扩展用户思考**，少抢答，多启发。用户未索取行动建议时不过度给出。  
-不要滥用顶层列表；尽量用自然语言解释清楚，减少术语。写作采用夹叙夹议、理性克制的语气；除直接引用外不要使用引号。
-
----
-
-## Child Outputs 输出模板（`child_outputs/<id>.md` 格式规范）
-
-每个子目标的研究结果应遵循以下结构：
-
-```markdown
-# [子目标名称] Research Output
-
-## Conclusion
-
-[一句话总结核心发现与适用边界]
-
-## Key Evidence
-
-### [维度 1]
-
-[要点化证据，每个要点后附来源链接]
-
-- 要点 1 ([source](url))
-- 要点 2 ([source](url))
-
-### [维度 2]
-
-...
-
-## Retrieval Scope
-
-- **Tools used:** [列出使用的 MCP 工具]
-- **Timestamp:** [数据采集时间，如 2025-10-23]
-- **Coverage:** [检索范围说明]
-
-## Gaps & Next Steps
-
-- [明确标注数据缺口]
-- [建议后续验证方向]
-```
-
-**可选：数据置信度标注**（YAML frontmatter）：
-
-```yaml
----
-target: SubredditName
-data_confidence:
-  field1: verified # 多源验证或官方来源
-  field2: inferred # 基于间接证据推断
-  field3: unverified # 缺少直接证据
----
-```
-
-**执行约束**：
-
-- 工具优先级：优先 MCP（tavily_search / tavily_extract），不可用再最小化 `http(s)` 抓取；遵守 robots 与版权
-- 软超时与轮次：总工具轮次≤10；单子任务软超时 5–15 分钟，命中则收束并写清缺口与下一步
-
----
-
-## 质检清单（交付前逐项自查）
-
-结构完整、语气统一、引用准确；关键要点均有就近引用；日期与版本信息明确；分歧点已标注证据等级；聚合稿并非一次生成而是分章迭代；素材不足与压缩过度问题已区分并处理；最终给出 artefact 路径与摘要。