site-memory

Persistent memory for repeated browser work. Use when an agent revisits the same sites or flows and should load a few relevant notes up front, then save dura...

Security Scan

The skill's code, scripts, and instructions are consistent with a small persistent note store for browser automation; it bundles a Chrome CDP helper (optional) which coheres with the stated purpose but has access to sensitive local browser state and should be used only with explicit user approval.

Purpose & Capability

The name/description (persistent site memory for repeated browser work) matches the files and scripts: they read and write a memory root (default ~/.site-memory) and provide recall/distill flows. The inclusion of a Chrome CDP helper in vendor/ is coherent because the skill explicitly targets browser workflows and documents pairing with a browser control tool.

Instruction Scope

SKILL.md directs running local node scripts that only read/write files inside the declared memory root and to use the bundled CDP proxy for browser actions. The instructions repeatedly warn not to save secrets and to verify live pages before relying on notes. One caveat: the SKILL.md tells agents to 'deny' other tools during the after-action pass — that is an instruction to the agent, not an enforcement mechanism in the codebase, so platform/tooling must enforce any tool restrictions.

Install Mechanism

No install spec (instruction-only plus shipped JS files). No downloads from external URLs and no extract step. Files run as local Node scripts; risk is limited to local execution. This is a low-risk install pattern, though it does execute Node scripts on the host.

Credentials

The skill requests no environment variables or credentials. However, it bundles a Chrome CDP skill that can connect to your running browser (via DevToolsActivePort) and thus can read pages you are logged into. That capability is proportionate to a browser-memory skill but carries privacy/security implications — the skill itself does not ask for unrelated secrets or cloud credentials.

Persistence & Privilege

always is false and the skill is user-invocable (defaults). It creates and uses a per-user runtime directory (~/.site-memory) and does not attempt to modify other skills or system-wide agent settings. The ability to be invoked autonomously is the platform default and not, by itself, a coherence problem.

Scan Findings in Context

[system-prompt-override] expected: The SKILL.md and accompanying scripts build LLM prompts (selector policy, distill guide, etc.). These look like legitimate prompt templates the skill uses to pick and write notes; the scanner flagged 'system-prompt-override' because the skill embeds system-style prompts. This is expected given the skill's design, but review prompts carefully before granting autonomous execution.

Assessment

What to consider before installing: - This skill will create and use a persistent directory (default ~/.site-memory) and read/write markdown notes there; run the provided init script to create it if you accept that. - The package bundles a Chrome DevTools Protocol helper that can connect to your running Chrome and interact with open tabs (including pages where you are logged in). That is coherent with a browser-memory tool but is sensitive — only enable/use it when you explicitly approve the agent to inspect your browser session. - The SKILL.md contains prompt templates and directs the agent to run 'after-action' LLM passes; those are normal for this skill but mean you should restrict which agent tools are allowed during those passes (platform enforcement is separate). - The code enforces that reads/writes stay inside the memory root; it does not exfiltrate data to remote hosts. Still, avoid storing secrets or session tokens in notes (the skill itself warns this). - If you do not want browser access, remove or ignore the vendor/chrome-cdp-skill directory or do not run the cdp scripts. If you plan to allow Chrome access, inspect vendor/chrome-cdp-skill/README.md and the cdp daemon code to understand prompts and the Allow-debugging modal behavior. If you'd like, I can produce a short checklist of actions to safely evaluate or sandbox this skill before granting it access (for example: review vendor cdp code paths, run the scripts in a temporary user account, or configure SITE_MEMORY_HOME to a non-default path).

This skill adds a reusable note loop to browser automation.

Its job is intentionally narrow:

• load a small number of high-value notes before acting
• write back reusable lessons after the task completes

It does not define business schemas. It does not own the browser driver. Pair it with whatever browser control tool you already trust.

Runtime location

Memory is global and shared across all projects. Notes about a website learned in one project are automatically available in every other project.

The default location is ~/.site-memory/. Override with SITE_MEMORY_HOME or --runtime-base <path>.

Resolve it with:

node ./scripts/resolve-runtime-root.mjs

Initialize it with:

node ./scripts/init-memory-root.mjs

Memory shape

The runtime root contains:

• INDEX.md as a compact index
• topic files with frontmatter and reusable details

Supported note kinds:

• operator
• guidance
• context
• reference

Use them this way:

• operator: collaboration preferences, pause points, tolerance for automation
• guidance: reusable rules, warnings, and tactics
• context: surrounding deadlines or constraints that matter across runs
• reference: stable selectors, URL patterns, routes, and site structure

Lookup workflow

1. Build the lookup inputs:

node ./scripts/build-recall-input.mjs --task "<current task>"

2. Use the generated selector prompt to choose only the notes that are likely to save real exploration time.

3. Open only the chosen files:

node ./scripts/read-recalled-files.mjs --files "reference/foo.md,guidance/bar.md"

4. Treat recalled notes as leads, not ground truth. Re-check selectors, button labels, URLs, and flows against the live page before relying on them.

Capture workflow

After the browser task ends, build the write-back prompt:

node ./scripts/build-distill-input.mjs --message-count <n>

The output contains a prompt field. You MUST execute that prompt as an after-action pass. This pass can:

• read memory files
• search memory files
• update files only inside the memory root

That pass should:

• update an existing topic file when possible
• create a new topic file only when the lesson is genuinely new
• keep INDEX.md short
• avoid storing one-off outputs, secrets, or temporary task state

Design rules

• Keep notes generic and reusable.
• Save only information that should make a future visit cheaper or safer.
• Prefer revising topic notes over appending session logs.
• Load only a few notes per task; too much memory becomes noise.
• If a remembered selector or route may be stale, verify it before use.

Browser automation

A CDP-based browser control skill is bundled at ./vendor/chrome-cdp-skill/. Read its instructions before first use:

cat ./vendor/chrome-cdp-skill/skills/chrome-cdp/SKILL.md

Use node ./scripts/cdp-proxy.mjs <command> [args] for browser interaction.

Commands

All commands use ./scripts/cdp-proxy.mjs. The <target> is a unique targetId prefix from list.

list                              List open pages
shot <target> [file]              Viewport screenshot
snap <target>                     Accessibility tree snapshot
nav  <target> <url>               Navigate and wait for load
click <target> <selector>         Click by CSS selector
clickxy <target> <x> <y>          Click at CSS pixel coordinates
type <target> <text>              Type text at current focus
eval <target> <expr>              Evaluate JavaScript
html <target> [selector]          Full page or element HTML
open [url]                        Open new tab

Coordinates

shot saves at native resolution: image pixels = CSS pixels x DPR. CDP input events use CSS pixels: CSS px = screenshot px / DPR.

Tips

• Prefer snap --compact over html for page structure
• Use type (not eval) to enter text in cross-origin iframes
• Chrome shows an "Allow debugging" modal once per tab on first access

Browser task workflow

For repeated browser work, follow these phases in order:

1. Prepare the runtime

node ./scripts/init-memory-root.mjs

2. Load likely-helpful notes

node ./scripts/build-recall-input.mjs --task "<url> <objective>"

Read the manifest from the output, choose the strongest matches, then open only those notes:

node ./scripts/read-recalled-files.mjs --files "file1.md,file2.md"

3. Browse and verify

Use the browser tool to accomplish the objective. If notes mention selectors or routes, verify them on the live page before depending on them.

4. Capture durable findings

After the task, save only the parts that should help a future visit. For site knowledge, a reference note often benefits from a body structure like:

## What this site is
## How the site works
## Verified selectors
## Pitfalls
## Successful paths

Update INDEX.md after writing. If the task produced no durable lesson, skip the write-back.