open-websearch

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

Audit 0.4.1 · source sha 058bda64be17 · 20 Oct 2026Report an issue or request a re-scan

• Publisheraas-ee GitHub userOwner of the repository this skill is read from
• Source folderaas-ee/open-websearch/skills/open-websearchThe exact folder we audited
• LicenceApache-2.0As the repository states it
• Commit pinned for this verdict058bda64be17A new audit runs when the source changes
• Repository statusNot archivedLast push 12 days ago
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: Single entry skill for open-websearch setup and focused live retrieval, preferring local CLI/daemon paths while remaining compatible with workspace-exposed MCP tools.

---
name: open-websearch
description: Single entry skill for open-websearch setup and focused live retrieval, preferring local CLI/daemon paths while remaining compatible with workspace-exposed MCP tools.
version: 1.4.0
version_note: Prefer local CLI/daemon onboarding and retrieval when available, while preserving MCP-compatible setup, activation, and focused web research guidance.
allowed-tools:
  - search
  - fetchWebContent
  - fetchGithubReadme
---

# Open WebSearch

Use this as the single user-facing entry skill for `open-websearch`.

Assumption:
- The preferred low-friction path is a working local `open-websearch` CLI/daemon setup.
- A workspace that already exposes the `open-websearch` MCP tools such as `search`, `fetchWebContent`, and `fetchGithubReadme` is also a valid path and should continue to work.
- If neither path is available, treat that as a missing `open-websearch` capability in the current workspace, not as a broken skill.
- If the workspace tool exposure or current MCP configuration differs from this skill, trust the actually available tools and current workspace configuration.

## Entry behavior

1. First determine whether `open-websearch` is already usable through a local CLI/daemon path or through workspace-exposed MCP tools.
2. If either path is available, use the retrieval rules below and prefer the smallest working path.
3. If neither path is available, explain the missing capability, state the consequence, ask whether the user wants to continue with setup or enablement, and then follow the smallest matching setup path.
4. Keep the line clear between `not configured`, `setup completed but not active in this runtime`, and `already searched`; do not imply live retrieval happened when it did not.
5. Treat `open-websearch --help` as the primary CLI reference. When command names, daemon flags, spawn behavior, or action parameters are unclear, check `--help` before guessing.

## Setup and activation workflow

When capability is missing, follow this order:

1. Detect the current state.
   - First determine whether the user needs local CLI/daemon setup, local MCP configuration, HTTP connection setup, source/build reuse, or only validation/reconnection.
2. Choose the smallest matching path.
   - Prefer the path that reuses what already exists instead of installing a second path.
3. Collect required inputs before doing work.
   - Confirm the target path: local CLI/daemon, existing MCP, local source/build reuse, or existing HTTP endpoint.
   - Confirm whether the environment needs npm proxy, npm mirror, or runtime proxy settings.
   - Confirm whether there is already a reusable local command, checkout, daemon, endpoint, or client config.
   - If browser-assisted mode may be needed, confirm whether Playwright, a browser binary, or a remote browser endpoint already exists.
4. Confirm risky actions before executing them.
   - Ask before installing packages, downloading Playwright or browser binaries, editing MCP/client config, starting a long-lived daemon, or writing endpoint-related config.
5. Perform the chosen path only after the required inputs and confirmations are in place.
   - local CLI/daemon mode when the runtime can launch `open-websearch` directly
   - existing MCP mode when the workspace already exposes the tools and only needs validation or reconnection
   - local source/build mode when the user already has a working local checkout
   - existing HTTP endpoint mode when the user already has a reachable `open-websearch` server
6. Validate before claiming success.
   - Do not silently skip validation, and do not treat package installation or config changes as success by themselves.
7. Report the final state explicitly.
   - capability active
   - setup completed but activation pending reload/reconnect
   - setup incomplete or failed
8. Do not bring up Playwright or browser setup by default for ordinary search or page fetch; only escalate to browser-assisted guidance when the user explicitly wants Bing Playwright mode, browser fallback is expected, or the failure strongly suggests missing browser support.
9. When the goal is to start or validate the local daemon path, use explicit commands: `open-websearch serve` to start it and `open-websearch status` to check it. Do not treat bare `open-websearch` as the recommended daemon start command.
10. During setup, when package installation is required, ask about proxy or npm mirror needs before long-running install steps in restricted networks. If installation repeatedly hangs, times out, or fails on package download, treat that as an environment or network issue first, not as an `open-websearch` core failure.
11. If the next step after daemon startup is expected to perform live network actions such as `search`, `fetch-web`, or other public-page retrieval, ask about runtime proxy needs before starting `open-websearch serve`. If the goal is only minimal local validation such as `serve` followed by `status`, runtime proxy can wait until a real networked action is planned.

## Default behavior

- Start with the smallest useful action.
- Prefer the shortest path that can answer the request correctly.
- Do not search multiple engines by default.
- Do not fetch full pages unless the answer needs more detail than search snippets provide.
- Do not fetch many pages for a simple factual answer; by default, deepen only the top 1-2 most relevant results.
- Stop once the available evidence is enough to answer the user correctly.
- Expand the search only when the first pass is insufficient, ambiguous, or clearly low quality.

## Decision rules

- First priority: if the user gives a specific public URL, fetch that URL directly instead of searching first.
- Second priority: if the user asks for current information, broad discovery, or comparisons, start with a single focused `search`.
- Third priority: if a search result looks promising but the snippet is insufficient, use `fetchWebContent` on that result URL.
- Repository priority: if th

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

git clone https://github.com/aas-ee/open-websearch
git -C open-websearch checkout 058bda64be17

Works in

1. 2026-10-20
   ✓SAFE B 89 / 100

   first audit · source 058bda64be17

Questions about open-websearch

• github.com/aas-ee/open-websearch/tree/main/skills/open-websearch — the audited source at commit 058bda64be17 and every finding aboveObserved · 20 Oct 2026

Spotted something wrong? Report a correction · Methodology