@pencil-agent/nano-pencil 2.0.1 → 2.0.2

package/dist/extensions/builtin/discipline/skills/verification-before-completion/SKILL.md

@@ -1,27 +1,27 @@
----
-name: verification-before-completion
-description: Use before saying work is complete, fixed, passing, implemented, ready, or safe to merge.
----
-
-# Verification Before Completion
-
-Evidence must precede completion claims.
-
-## Gate
-
-Do not claim success from intent, plausibility, previous output, or another agent's report. Verify against the current state.
-
-## Process
-
-1. Identify each claim you are about to make.
-2. Identify the command, file inspection, diff, runtime check, or rendered artifact that would prove it.
-3. Run or inspect that evidence freshly.
-4. Read the output, exit code, or artifact carefully.
-5. Report the actual state:
-   - If verified, name the evidence.
-   - If not verified, say what remains unverified.
-   - If failed, report the failure and continue work.
-
-## Evidence Matching
-
-Use focused checks for narrow claims and broader checks for broad claims. A passing unit test does not prove a full build, and a successful build does not prove the requested behavior unless the behavior is covered.
+---
+name: verification-before-completion
+description: Use before saying work is complete, fixed, passing, implemented, ready, or safe to merge.
+---
+
+# Verification Before Completion
+
+Evidence must precede completion claims.
+
+## Gate
+
+Do not claim success from intent, plausibility, previous output, or another agent's report. Verify against the current state.
+
+## Process
+
+1. Identify each claim you are about to make.
+2. Identify the command, file inspection, diff, runtime check, or rendered artifact that would prove it.
+3. Run or inspect that evidence freshly.
+4. Read the output, exit code, or artifact carefully.
+5. Report the actual state:
+   - If verified, name the evidence.
+   - If not verified, say what remains unverified.
+   - If failed, report the failure and continue work.
+
+## Evidence Matching
+
+Use focused checks for narrow claims and broader checks for broad claims. A passing unit test does not prove a full build, and a successful build does not prove the requested behavior unless the behavior is covered.

package/dist/extensions/builtin/discipline/skills/writing-plans/SKILL.md

@@ -1,26 +1,26 @@
----
-name: writing-plans
-description: Use when a task needs multiple implementation steps, multiple files, handoff to another agent, or careful verification sequencing.
----
-
-# Writing Plans
-
-Create an implementation plan that can be executed without rediscovering context.
-
-## Required Sections
-
-- Goal: one sentence describing the user-visible outcome.
-- Context: what the codebase currently does and why the change is needed.
-- Architecture: the recommended approach and why it fits existing boundaries.
-- Files: exact files to create or modify and each file's responsibility.
-- Tasks: small ordered steps with verification after meaningful changes.
-- Test plan: exact commands and expected evidence.
-- Documentation impact: P1/P2/P3 or user docs that must change.
-
-## Task Quality
-
-Each task should be independently understandable. Include exact paths, APIs, data shapes, and expected behavior. Avoid placeholders such as "handle edge cases" or "add tests"; state the actual edge cases and tests.
-
-## Handoff
-
-When the plan is approved, execute it directly or use `executing-plans` for inline execution. Use subagents when tasks are independent and reviewable.
+---
+name: writing-plans
+description: Use when a task needs multiple implementation steps, multiple files, handoff to another agent, or careful verification sequencing.
+---
+
+# Writing Plans
+
+Create an implementation plan that can be executed without rediscovering context.
+
+## Required Sections
+
+- Goal: one sentence describing the user-visible outcome.
+- Context: what the codebase currently does and why the change is needed.
+- Architecture: the recommended approach and why it fits existing boundaries.
+- Files: exact files to create or modify and each file's responsibility.
+- Tasks: small ordered steps with verification after meaningful changes.
+- Test plan: exact commands and expected evidence.
+- Documentation impact: P1/P2/P3 or user docs that must change.
+
+## Task Quality
+
+Each task should be independently understandable. Include exact paths, APIs, data shapes, and expected behavior. Avoid placeholders such as "handle edge cases" or "add tests"; state the actual edge cases and tests.
+
+## Handoff
+
+When the plan is approved, execute it directly or use `executing-plans` for inline execution. Use subagents when tasks are independent and reviewable.

package/dist/extensions/builtin/goal/README.md

@@ -1,67 +1,67 @@
-# Goal Extension
-
-Long-running task management for nanoPencil. Set a goal with `/goal <objective>` and the
-agent will auto-continue working on it across turns until the objective is achieved,
-the token budget runs out, or you pause/clear it.
-
-This extension mirrors the Codex `/goal` command semantics: a per-thread goal, persisted
-to disk, with idle-continuation prompts, token accounting, and budget enforcement.
-
-## Usage
-
-```
-/goal                  Show current goal summary menu
-/goal <objective>      Set or replace the goal
-/goal clear            Clear the goal
-/goal edit             Open the editor to change the objective
-/goal pause            Pause auto-continuation
-/goal resume           Resume auto-continuation
-/goal help             Show usage help
-```
-
-## LLM Tools
-
-The extension registers three LLM-facing tools:
-
-| Tool | Purpose | Who can call |
-|------|---------|--------------|
-| `get_goal` | Read the current goal | LLM |
-| `create_goal` | Create a new goal (only when the user explicitly asks) | LLM |
-| `update_goal` | Mark the goal `complete` or `blocked` | LLM |
-
-The LLM is only allowed to set the goal's status to `complete` or `blocked`. Pause /
-resume / budget limits are user-driven and happen exclusively through `/goal`.
-
-## Lifecycle
-
-The extension subscribes to `turn_start`, `turn_end`, `message_end`, `tool_execution_end`,
-and `agent_end` to track token usage and time per turn. When a turn ends with an
-`active` goal, the extension injects a follow-up user message containing the
-continuation prompt so the agent keeps working on the objective.
-
-When a turn causes the goal to cross its token budget, the extension injects a
-budget-limit steering prompt and marks the goal `budget_limited`. Once budget-limited,
-auto-continuation stops and the goal is terminal.
-
-## Persistence
-
-Goals are stored as JSON files under `<agentDir>/goals/<threadId>.json`. They survive
-session restarts and are keyed by the active session ID.
-
-## Status
-
-`Status: active` shows in the footer while a goal is running.
-
-## Architecture
-
-| File | Responsibility |
-|------|----------------|
-| `goal-types.ts` | `ThreadGoalStatus`, `ThreadGoal`, helper predicates |
-| `goal-store.ts` | Atomic JSON-file persistence (replace / insert / update / delete / account_usage) |
-| `goal-format.ts` | Time/token formatting, summary lines, status indicator, validators |
-| `goal-prompts.ts` | Continuation / budget-limit / objective-updated prompt templates |
-| `goal-controller.ts` | Per-thread runtime: mutex, turn accounting, idle continuation |
-| `goal-tools.ts` | `get_goal`, `create_goal`, `update_goal` LLM tool definitions |
-| `goal-parser.ts` | `/goal` slash-command argument parsing |
-| `goal-command.ts` | `/goal` slash-command handler (UI + controller dispatch) |
-| `index.ts` | Extension entry: tools, command, lifecycle hooks, status indicator |
+# Goal Extension
+
+Long-running task management for nanoPencil. Set a goal with `/goal <objective>` and the
+agent will auto-continue working on it across turns until the objective is achieved,
+the token budget runs out, or you pause/clear it.
+
+This extension mirrors the Codex `/goal` command semantics: a per-thread goal, persisted
+to disk, with idle-continuation prompts, token accounting, and budget enforcement.
+
+## Usage
+
+```
+/goal                  Show current goal summary menu
+/goal <objective>      Set or replace the goal
+/goal clear            Clear the goal
+/goal edit             Open the editor to change the objective
+/goal pause            Pause auto-continuation
+/goal resume           Resume auto-continuation
+/goal help             Show usage help
+```
+
+## LLM Tools
+
+The extension registers three LLM-facing tools:
+
+| Tool | Purpose | Who can call |
+|------|---------|--------------|
+| `get_goal` | Read the current goal | LLM |
+| `create_goal` | Create a new goal (only when the user explicitly asks) | LLM |
+| `update_goal` | Mark the goal `complete` or `blocked` | LLM |
+
+The LLM is only allowed to set the goal's status to `complete` or `blocked`. Pause /
+resume / budget limits are user-driven and happen exclusively through `/goal`.
+
+## Lifecycle
+
+The extension subscribes to `turn_start`, `turn_end`, `message_end`, `tool_execution_end`,
+and `agent_end` to track token usage and time per turn. When a turn ends with an
+`active` goal, the extension injects a follow-up user message containing the
+continuation prompt so the agent keeps working on the objective.
+
+When a turn causes the goal to cross its token budget, the extension injects a
+budget-limit steering prompt and marks the goal `budget_limited`. Once budget-limited,
+auto-continuation stops and the goal is terminal.
+
+## Persistence
+
+Goals are stored as JSON files under `<agentDir>/goals/<threadId>.json`. They survive
+session restarts and are keyed by the active session ID.
+
+## Status
+
+`Status: active` shows in the footer while a goal is running.
+
+## Architecture
+
+| File | Responsibility |
+|------|----------------|
+| `goal-types.ts` | `ThreadGoalStatus`, `ThreadGoal`, helper predicates |
+| `goal-store.ts` | Atomic JSON-file persistence (replace / insert / update / delete / account_usage) |
+| `goal-format.ts` | Time/token formatting, summary lines, status indicator, validators |
+| `goal-prompts.ts` | Continuation / budget-limit / objective-updated prompt templates |
+| `goal-controller.ts` | Per-thread runtime: mutex, turn accounting, idle continuation |
+| `goal-tools.ts` | `get_goal`, `create_goal`, `update_goal` LLM tool definitions |
+| `goal-parser.ts` | `/goal` slash-command argument parsing |
+| `goal-command.ts` | `/goal` slash-command handler (UI + controller dispatch) |
+| `index.ts` | Extension entry: tools, command, lifecycle hooks, status indicator |

package/dist/extensions/builtin/grub/README.md

@@ -1,112 +1,112 @@
-# Grub Extension
-
-`/grub` runs one autonomous long-running task until the agent reports it
-complete, reports it is blocked, the user stops it, or a safety limit is
-reached. The harness design follows the pattern described in Anthropic's
-[Effective harnesses for long-running agents](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents):
-a structured on-disk state lets coding agents pick up where they left off
-even across fresh context windows and full process restarts.
-
-## Commands
-
-- `/grub <goal> [--max-iter N] [--max-fail N]` — start one autonomous task
-- `/grub status [--json]` — show the active or last finished grub task
-- `/grub resume` — resume dispatch for an adopted/persisted task
-- `/grub stop` — stop the active grub task
-
-## Harness artifacts
-
-Each task owns a directory at `.grub/<task-id>/`:
-
-| File | Purpose | Who may write |
-|------|---------|---------------|
-| `feature-list.json` | Structured list of end-to-end features | Initializer writes the whole file once; coding agents may only flip `passes` and set `evidence` |
-| `progress-log.md` | Dated notes describing each iteration | Agent, append-only |
-| `init.sh` | Get-bearings + project smoke script run at the start of every iteration | Initializer; later agents may add project-specific smoke commands |
-| `state.json` | Durable `GrubTaskState` snapshot for cross-session resume | Controller, atomic writes |
-
-`feature-list.json` schema (version 1):
-
-```json
-{
-  "version": 1,
-  "goal": "<user goal>",
-  "features": [
-    {
-      "id": "kebab-slug",
-      "category": "functional|verification|polish",
-      "description": "observable behavior",
-      "steps": ["actionable", "verification", "steps"],
-      "passes": false,
-      "evidence": "optional git sha or short proof"
-    }
-  ]
-}
-```
-
-The controller validates every mutation: changing `description`, `steps`,
-`category`, `id`, list length, or reordering counts as a violation. Agents
-are told up front that the only permitted edits are toggling `passes` and
-setting `evidence`.
-
-## How it works
-
-- Each grub iteration is tagged with a `[GRUB:<id>:<n>]` prompt prefix so
-  the extension can recognise its own injected turns.
-- On start, grub creates the harness directory and writes the initial
-  artifacts without creating a git commit. The harness keeps durable state on
-  disk and leaves source changes visible in the working tree, avoiding noisy
-  `grub(...)` commits unless the user explicitly asks for them.
-- Two phase-specialized system prompts are injected via
-  `before_agent_start`:
-  - **Initializer prompt** (first successful turn): expand
-    `feature-list.json` into 15-40 concrete features, harden `init.sh`,
-    seed `progress-log.md`. No broad implementation yet.
-  - **Coding prompt** (remaining turns): run `init.sh`, pick exactly one
-    pending feature, implement + verify end-to-end, flip `passes` +
-    `evidence`, and append to `progress-log.md`.
-- At the end of every grub turn the assistant must emit a single
-  `<loop-state>{"status":"continue|complete|blocked", "summary":"...", "nextStep":"..."}</loop-state>`
-  block. The extension parses it and dispatches the next iteration or
-  stops with a terminal status.
-- **Initializer sanitize-not-fail**: while in the initializer phase, only
-  genuinely unfixable structural problems (feature count out of 15-40,
-  unreplaced placeholder, non-kebab ids, duplicate ids) fail the turn and
-  force a retry. Recoverable hygiene issues are auto-corrected instead of
-  killing the task: a wrong `goal` is restored to the authoritative task goal,
-  pre-marked `passes:true` are reset to `false`, and stray `evidence` is
-  dropped. The sanitized list is written back to disk and becomes the baseline,
-  so the phase always advances once the structure is valid.
-- **Phase-aware failure budget**: the initializer gets a more forgiving budget
-  (default 5) than execution (default 3, via `--max-fail`), because standing up
-  a valid harness is a distinct, retry-friendly activity from execution work.
-- **Mutation guard**: after the initializer creates the first real
-  `feature-list.json`, each subsequent turn is diffed against the persisted
-  baseline. Rewriting feature ids, descriptions, categories, steps, count, or
-  order is rejected and retried; only `passes` and `evidence` may change.
-- **Completion guard**: if the decision says `complete` but
-  `feature-list.json` still has `passes:false` entries, the controller
-  rewrites the decision to `continue` with a synthetic `nextStep`
-  pointing at the first pending feature. The harness will not allow
-  premature "done".
-- **Cross-session resume**: `GrubTaskState` is written atomically to
-  `state.json` on every transition. On the next session, `session_start`
-  calls `discoverActiveTasks()` and adopts the most recent running task
-  without auto-dispatching — the user types `/grub resume` to continue.
-- **Safety limits**: 25 iterations and 3 consecutive failures by default;
-  override with `--max-iter` / `--max-fail`.
-- **Stale harness cleanup**: on extension load, terminal harnesses older
-  than 30 days are pruned from `.grub/`.
-
-## Legacy migration
-
-Earlier versions wrote `feature-checklist.md` (markdown checkboxes). When a
-new iteration starts and `feature-list.json` is missing but the legacy file
-exists, its checkbox items are migrated into the JSON format (category
-defaults to `functional`; `steps` start empty so the initializer can refine
-later).
-
-## Related
-
-For the recurring scheduler that runs prompts or slash commands on an
-interval, see the sibling [`loop` extension](../loop/README.md).
+# Grub Extension
+
+`/grub` runs one autonomous long-running task until the agent reports it
+complete, reports it is blocked, the user stops it, or a safety limit is
+reached. The harness design follows the pattern described in Anthropic's
+[Effective harnesses for long-running agents](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents):
+a structured on-disk state lets coding agents pick up where they left off
+even across fresh context windows and full process restarts.
+
+## Commands
+
+- `/grub <goal> [--max-iter N] [--max-fail N]` — start one autonomous task
+- `/grub status [--json]` — show the active or last finished grub task
+- `/grub resume` — resume dispatch for an adopted/persisted task
+- `/grub stop` — stop the active grub task
+
+## Harness artifacts
+
+Each task owns a directory at `.grub/<task-id>/`:
+
+| File | Purpose | Who may write |
+|------|---------|---------------|
+| `feature-list.json` | Structured list of end-to-end features | Initializer writes the whole file once; coding agents may only flip `passes` and set `evidence` |
+| `progress-log.md` | Dated notes describing each iteration | Agent, append-only |
+| `init.sh` | Get-bearings + project smoke script run at the start of every iteration | Initializer; later agents may add project-specific smoke commands |
+| `state.json` | Durable `GrubTaskState` snapshot for cross-session resume | Controller, atomic writes |
+
+`feature-list.json` schema (version 1):
+
+```json
+{
+  "version": 1,
+  "goal": "<user goal>",
+  "features": [
+    {
+      "id": "kebab-slug",
+      "category": "functional|verification|polish",
+      "description": "observable behavior",
+      "steps": ["actionable", "verification", "steps"],
+      "passes": false,
+      "evidence": "optional git sha or short proof"
+    }
+  ]
+}
+```
+
+The controller validates every mutation: changing `description`, `steps`,
+`category`, `id`, list length, or reordering counts as a violation. Agents
+are told up front that the only permitted edits are toggling `passes` and
+setting `evidence`.
+
+## How it works
+
+- Each grub iteration is tagged with a `[GRUB:<id>:<n>]` prompt prefix so
+  the extension can recognise its own injected turns.
+- On start, grub creates the harness directory and writes the initial
+  artifacts without creating a git commit. The harness keeps durable state on
+  disk and leaves source changes visible in the working tree, avoiding noisy
+  `grub(...)` commits unless the user explicitly asks for them.
+- Two phase-specialized system prompts are injected via
+  `before_agent_start`:
+  - **Initializer prompt** (first successful turn): expand
+    `feature-list.json` into 15-40 concrete features, harden `init.sh`,
+    seed `progress-log.md`. No broad implementation yet.
+  - **Coding prompt** (remaining turns): run `init.sh`, pick exactly one
+    pending feature, implement + verify end-to-end, flip `passes` +
+    `evidence`, and append to `progress-log.md`.
+- At the end of every grub turn the assistant must emit a single
+  `<loop-state>{"status":"continue|complete|blocked", "summary":"...", "nextStep":"..."}</loop-state>`
+  block. The extension parses it and dispatches the next iteration or
+  stops with a terminal status.
+- **Initializer sanitize-not-fail**: while in the initializer phase, only
+  genuinely unfixable structural problems (feature count out of 15-40,
+  unreplaced placeholder, non-kebab ids, duplicate ids) fail the turn and
+  force a retry. Recoverable hygiene issues are auto-corrected instead of
+  killing the task: a wrong `goal` is restored to the authoritative task goal,
+  pre-marked `passes:true` are reset to `false`, and stray `evidence` is
+  dropped. The sanitized list is written back to disk and becomes the baseline,
+  so the phase always advances once the structure is valid.
+- **Phase-aware failure budget**: the initializer gets a more forgiving budget
+  (default 5) than execution (default 3, via `--max-fail`), because standing up
+  a valid harness is a distinct, retry-friendly activity from execution work.
+- **Mutation guard**: after the initializer creates the first real
+  `feature-list.json`, each subsequent turn is diffed against the persisted
+  baseline. Rewriting feature ids, descriptions, categories, steps, count, or
+  order is rejected and retried; only `passes` and `evidence` may change.
+- **Completion guard**: if the decision says `complete` but
+  `feature-list.json` still has `passes:false` entries, the controller
+  rewrites the decision to `continue` with a synthetic `nextStep`
+  pointing at the first pending feature. The harness will not allow
+  premature "done".
+- **Cross-session resume**: `GrubTaskState` is written atomically to
+  `state.json` on every transition. On the next session, `session_start`
+  calls `discoverActiveTasks()` and adopts the most recent running task
+  without auto-dispatching — the user types `/grub resume` to continue.
+- **Safety limits**: 25 iterations and 3 consecutive failures by default;
+  override with `--max-iter` / `--max-fail`.
+- **Stale harness cleanup**: on extension load, terminal harnesses older
+  than 30 days are pruned from `.grub/`.
+
+## Legacy migration
+
+Earlier versions wrote `feature-checklist.md` (markdown checkboxes). When a
+new iteration starts and `feature-list.json` is missing but the legacy file
+exists, its checkbox items are migrated into the JSON format (category
+defaults to `functional`; `steps` start empty so the initializer can refine
+later).
+
+## Related
+
+For the recurring scheduler that runs prompts or slash commands on an
+interval, see the sibling [`loop` extension](../loop/README.md).

package/dist/extensions/builtin/link-world/agent-workspace/README.md

@@ -1,16 +1,16 @@
-# Link-world Workspace
-
-This directory is copied to:
-
-```text
-.nanopencil/link-world-workspace/
-```
-
-Use it to store project-local, reusable internet-access knowledge for NanoPencil.
-
-Suggested layout:
-
-- `domain-skills/<site>/...` for durable site-specific notes
-- `notes/` for broader task or provider observations that should not live in the shipped extension
-
-Keep public-safe content only. Do not store secrets, cookies, tokens, or user-specific private data here.
+# Link-world Workspace
+
+This directory is copied to:
+
+```text
+.nanopencil/link-world-workspace/
+```
+
+Use it to store project-local, reusable internet-access knowledge for NanoPencil.
+
+Suggested layout:
+
+- `domain-skills/<site>/...` for durable site-specific notes
+- `notes/` for broader task or provider observations that should not live in the shipped extension
+
+Keep public-safe content only. Do not store secrets, cookies, tokens, or user-specific private data here.

package/dist/extensions/builtin/link-world/internet-search/internet-search.md

@@ -1,65 +1,65 @@
----
-name: internet-search
-description: 当用户需要联网搜索最新信息、新闻、在线内容时使用此技能。包括搜索 Twitter、YouTube、Bilibili、知乎、微博、小红书等平台。
----
-
-# 互联网搜索
-
-## 触发条件
-
-当用户请求以下内容时使用此技能：
-- 搜索互联网、联网搜索、网络搜索
-- 查找最新新闻、资讯、信息
-- 搜索 YouTube、Bilibili、Twitter、小红书、微博等内容
-- 查找某个话题的最新讨论
-- 获取实时信息或热点内容
-
-## 执行步骤
-
-### 步骤 1：检查 agent-reach 是否安装
-
-运行以下命令检查 agent-reach 是否可用：
-
-```bash
-agent-reach --version
-```
-
-### 步骤 2：如果未安装
-
-如果 agent-reach 命令不可用，告知用户需要先安装：
-
-> link-world (agent-reach) 未安装。请先运行 `/link-world` 安装 agent-reach 以支持联网搜索功能。
-
-### 步骤 3：如果已安装
-
-根据用户需求，使用 linkworld.md 中定义的工具进行搜索。
-
-**完整命令参考请查阅：extensions/link-world/linkworld.md**
-
-| 场景 | 推荐工具 | 示例命令 |
-|------|----------|----------|
-| 搜索 Twitter/X 推文 | xreach | `xreach search "关键词" --json` |
-| 解析 YouTube 视频 | yt-dlp | `yt-dlp --dump-json "视频URL"` |
-| 解析 Bilibili 视频 | yt-dlp | `yt-dlp --dump-json "视频URL"` |
-| 搜索 Reddit 帖子 | curl | `curl -s "https://reddit.com/r/xxx/search.json?q=关键词"` |
-| 搜索 GitHub 仓库 | gh | `gh search repos "关键词" --limit 5` |
-| 读取网页内容 | curl + Jina | `curl -s "https://r.jina.ai/网页URL"` |
-| 通用搜索引擎 | Exa (MCP) | `mcporter call 'exa.web_search_exa(query: "关键词", num_results: 5)'` |
-| 搜索小红书笔记 | 小红书 (MCP) | `mcporter call 'xiaohongshu.search_feeds(keyword: "关键词", limit: 5)'` |
-| 解析抖音视频 | 抖音 (MCP) | `mcporter call 'douyin.parse_douyin_video_info(url: "视频URL")'` |
-
-### 步骤 4：返回结果
-
-将搜索结果整理后返回给用户，包括：
-- 来源平台
-- 标题
-- 内容摘要
-- 链接
-
-## 注意事项
-
-1. 遵守平台的 API 使用规范
-2. 如需登录平台的搜索功能，确保用户已配置认证信息
-3. 如果搜索失败，尝试其他平台或告知用户可能的错误原因
-4. YouTube/Bilibili 需要提供具体的视频 URL，不能直接搜索关键词
-5. 详细的配置说明（Cookie、代理等）请参考 linkworld.md
+---
+name: internet-search
+description: 当用户需要联网搜索最新信息、新闻、在线内容时使用此技能。包括搜索 Twitter、YouTube、Bilibili、知乎、微博、小红书等平台。
+---
+
+# 互联网搜索
+
+## 触发条件
+
+当用户请求以下内容时使用此技能：
+- 搜索互联网、联网搜索、网络搜索
+- 查找最新新闻、资讯、信息
+- 搜索 YouTube、Bilibili、Twitter、小红书、微博等内容
+- 查找某个话题的最新讨论
+- 获取实时信息或热点内容
+
+## 执行步骤
+
+### 步骤 1：检查 agent-reach 是否安装
+
+运行以下命令检查 agent-reach 是否可用：
+
+```bash
+agent-reach --version
+```
+
+### 步骤 2：如果未安装
+
+如果 agent-reach 命令不可用，告知用户需要先安装：
+
+> link-world (agent-reach) 未安装。请先运行 `/link-world` 安装 agent-reach 以支持联网搜索功能。
+
+### 步骤 3：如果已安装
+
+根据用户需求，使用 linkworld.md 中定义的工具进行搜索。
+
+**完整命令参考请查阅：extensions/link-world/linkworld.md**
+
+| 场景 | 推荐工具 | 示例命令 |
+|------|----------|----------|
+| 搜索 Twitter/X 推文 | xreach | `xreach search "关键词" --json` |
+| 解析 YouTube 视频 | yt-dlp | `yt-dlp --dump-json "视频URL"` |
+| 解析 Bilibili 视频 | yt-dlp | `yt-dlp --dump-json "视频URL"` |
+| 搜索 Reddit 帖子 | curl | `curl -s "https://reddit.com/r/xxx/search.json?q=关键词"` |
+| 搜索 GitHub 仓库 | gh | `gh search repos "关键词" --limit 5` |
+| 读取网页内容 | curl + Jina | `curl -s "https://r.jina.ai/网页URL"` |
+| 通用搜索引擎 | Exa (MCP) | `mcporter call 'exa.web_search_exa(query: "关键词", num_results: 5)'` |
+| 搜索小红书笔记 | 小红书 (MCP) | `mcporter call 'xiaohongshu.search_feeds(keyword: "关键词", limit: 5)'` |
+| 解析抖音视频 | 抖音 (MCP) | `mcporter call 'douyin.parse_douyin_video_info(url: "视频URL")'` |
+
+### 步骤 4：返回结果
+
+将搜索结果整理后返回给用户，包括：
+- 来源平台
+- 标题
+- 内容摘要
+- 链接
+
+## 注意事项
+
+1. 遵守平台的 API 使用规范
+2. 如需登录平台的搜索功能，确保用户已配置认证信息
+3. 如果搜索失败，尝试其他平台或告知用户可能的错误原因
+4. YouTube/Bilibili 需要提供具体的视频 URL，不能直接搜索关键词
+5. 详细的配置说明（Cookie、代理等）请参考 linkworld.md