@otto-assistant/bridge 0.4.92

package/skills/new-skill/SKILL.md

@@ -0,0 +1,211 @@
+---
+name: new-skill
+description: >
+  Best practices for creating a SKILL.md file. Covers file structure,
+  frontmatter, writing style, and where to place skills in a repository.
+  Use when the user wants to create a new skill, update an existing
+  skill, write a SKILL.md, or asks how skills work.
+---
+
+# Creating a SKILL.md
+
+A skill is a markdown file that teaches an AI agent a specific workflow, tool, or pattern. Skills are loaded into context when the agent recognizes a task that matches the skill's description.
+
+## File location
+
+Place the skill at the root of your repository:
+
+```
+skills/<skill-name>/SKILL.md
+```
+
+For example: `skills/critique/SKILL.md`, `skills/errore/SKILL.md`.
+
+The folder name should match the skill name in kebab-case. Each skill gets its own folder so it can include companion files if needed (scripts, templates, references).
+
+For personal skills that follow you across all repos and are not meant for distribution in a GitHub repository, place them in:
+
+```
+~/.opencode/skills/<skill-name>/SKILL.md
+```
+
+Personal skills are only available on your machine. Repository skills are shared with everyone who clones the repo.
+
+## Editing skills synced from other repositories
+
+Some projects (like kimaki) sync skills from external GitHub repositories into a local skills folder. If a skill was synced from another repo, **never edit the synced copy**. The synced folder is overwritten on every sync and your changes will be lost.
+
+Instead, find the source repository where the skill originates and edit the SKILL.md there. The sync process will pick up the changes on the next run. If you are unsure which repo a skill comes from, check for a sync script (e.g. `scripts/sync-skills.ts`) or a `source-repo` field in the skill's frontmatter.
+
+## Distribution and installation
+
+When you publish skills in a GitHub repository, other users can install them with the `skills` CLI:
+
+```bash
+npx skills add owner/repo
+```
+
+This downloads the skills from the repo and symlinks them into the user's agent directories. Add this to your repo's README so users know how to install:
+
+```markdown
+## Install skill for AI agents
+
+\`\`\`bash
+npx -y skills add owner/repo
+\`\`\`
+
+This installs [skills](https://skills.sh) for AI coding agents like
+Claude Code, Cursor, Windsurf, and others. Skills teach agents the
+workflows, patterns, and tools specific to this project.
+```
+
+## Frontmatter
+
+Every SKILL.md starts with YAML frontmatter containing two required fields:
+
+```yaml
+---
+name: skill-name
+description: >
+  One to three sentences explaining what this skill does and when to use it.
+  Start with a noun or verb phrase. Include trigger conditions so the agent
+  knows when to load this skill automatically.
+---
+```
+
+- **name**: kebab-case identifier matching the folder name
+- **description**: this is the most important field. The agent reads descriptions of all available skills and decides which to load based on this text. Be specific about when the skill applies. Include keywords the user might say.
+
+Good description example:
+```yaml
+description: >
+  Git diff viewer. Renders diffs as web pages, images, and PDFs
+  with syntax highlighting. Use this skill when working with critique
+  for showing diffs, generating diff URLs, or selective hunk staging.
+```
+
+Bad description example:
+```yaml
+description: A helpful tool for developers.
+```
+
+## File structure
+
+After the frontmatter, write the skill as a normal markdown document. Follow this general structure:
+
+```markdown
+# Skill Title
+
+One paragraph explaining what this skill is and why it exists.
+
+## Key section
+
+Core rules, commands, or patterns. Use code blocks for commands
+and examples. Use numbered lists for sequential steps.
+
+## Another section
+
+More detail, edge cases, gotchas, tips.
+```
+
+There is no rigid template. Structure the content in whatever way communicates the workflow most clearly. Some skills are short (20 lines for a simple CLI tool), others are long (600+ lines for a complex pattern like errore).
+
+## Writing style
+
+**Write for an AI agent, not a human.** The reader is a language model that will follow these instructions while helping a user. This changes how you write:
+
+- **Be direct and imperative.** Say "Always run `tool --help` first" not "You might want to consider running the help command."
+- **Include concrete commands and code.** The agent needs copy-pasteable examples, not abstract descriptions.
+- **State rules as rules.** Use "Never", "Always", "Must" when something is non-negotiable.
+- **Show the right way, not just the wrong way.** After saying what not to do, immediately show what to do instead.
+- **Use code blocks with language hints.** The agent uses these to generate correct code.
+- **Keep prose short between code blocks.** One or two sentences of explanation, then an example.
+- **Call out common mistakes.** If there is a gotcha the agent will likely hit, warn about it explicitly.
+
+## What makes a good skill
+
+A good skill captures **hard-won knowledge** that is not obvious from reading docs or source code alone. Focus on:
+
+- **Correct usage patterns** — the commands and code that actually work, not just what the docs say
+- **Gotchas and edge cases** — things that break in subtle ways (e.g. "libsql transaction() with file::memory: silently uses a separate empty database unless you add ?cache=shared")
+- **Opinionated defaults** — when there are multiple ways to do something, state which way to use and why
+- **Integration context** — how this tool fits into the broader workflow (e.g. "Always use critique when showing diffs to Discord users because they cannot see terminal output")
+
+A bad skill is just a copy of the tool's README or man page. If the agent could figure it out from `--help`, it does not need a skill for it.
+
+## Skills for CLI tools
+
+For CLI tools, put as much documentation as possible into the CLI itself — in command descriptions, option help text, and examples shown by `--help`. The skill file should not duplicate that content. Instead, the skill should instruct the agent to run the help command first:
+
+```markdown
+**Always run `mytool --help` before using this tool.** The help output
+is the source of truth for all commands, options, and examples.
+```
+
+This keeps documentation in one place (the CLI binary) and avoids the skill going stale when the CLI updates.
+
+When running help commands, the agent must read the **full untruncated output**. Never pipe help output through `head`, `tail`, `sed -n`, or any command that strips or truncates lines. Agents do this frequently and it causes them to miss critical options and context. The help output exists to be read in full.
+
+## Examples from real skills
+
+**Simple CLI tool skill** (gitchamber — 93 lines):
+```markdown
+---
+name: gitchamber
+description: CLI to download npm packages, PyPI packages, crates, or GitHub
+  repo source code into node_modules/.gitchamber/ for analysis. Use when you
+  need to read a package's inner workings, documentation, examples, or source
+  code.
+---
+
+# gitchamber
+
+CLI to download source code for npm packages, PyPI packages, crates.io
+crates, or GitHub repos into `node_modules/.gitchamber/`.
+
+Always run `gitchamber --help` first. The help output has all commands,
+options, and examples.
+
+## Fetch packages
+
+\`\`\`bash
+chamber zod
+chamber pypi:requests
+chamber github:owner/repo
+\`\`\`
+```
+
+**Pattern/convention skill** (errore — 647 lines):
+```markdown
+---
+name: errore
+description: >
+  errore is Go-style error handling for TypeScript: return errors instead
+  of throwing them. ALWAYS read this skill when a repo uses the errore
+  "errors as values" convention.
+---
+
+# errore
+
+Go-style error handling for TypeScript. Functions return errors instead
+of throwing them.
+
+## Rules
+
+1. Always `import * as errore from 'errore'` — namespace import
+2. Never throw for expected failures — return errors as values
+3. Use `createTaggedError` for domain errors
+...
+```
+
+Notice both follow the same pattern: minimal frontmatter, clear title, actionable content with code examples. The simple tool skill is short and focused on commands. The pattern skill is long and focused on rules and conventions.
+
+## Checklist
+
+Before saving a new skill:
+
+1. Does the **description** clearly state when to load this skill? Would an agent reading just the description know whether to load it?
+2. Does the **name** match the folder name?
+3. Are there **concrete code examples** for the main workflows?
+4. Did you avoid duplicating content the agent can get from `--help` or standard docs?
+5. Did you capture the **gotchas** — the things that took trial and error to figure out?

package/skills/npm-package/SKILL.md

@@ -0,0 +1,239 @@
+---
+name: npm-package
+description: >
+  Opinionated TypeScript npm package template for ESM packages. Enforces
+  src→dist builds with tsc, strict TypeScript defaults, explicit exports, and
+  publish-safe package metadata. Use this when creating or updating any npm
+  package in this repo.
+version: 0.0.1
+---
+
+<!-- Purpose: canonical checklist for TypeScript npm package layout and publish config. -->
+
+# npm-package
+
+Use this skill when scaffolding or fixing npm packages.
+
+## Package.json rules
+
+1. Always set `"type": "module"`.
+2. Always fill `"description"`.
+3. Always include GitHub metadata:
+   - `repository` with `type`, `url`, and `directory`
+   - `homepage`
+   - `bugs`
+4. Always include meaningful `keywords`.
+5. Always export `./package.json`.
+6. Exports structure must include:
+   - `"."` for runtime entrypoint (`dist`)
+   - `"./src"` and `"./src/*"` pointing to `.ts` source files
+7. In every export object, put `types` first.
+   - For runtime exports (for example `"."`), point `types` to emitted
+     declaration files in `dist`.
+   - For source exports (`"./src"`, `"./src/*"`), point `types` to source
+     files in `src` (not `./dist/*.d.ts`).
+8. Always include `default` in exports.
+9. `files` must include at least:
+   - `src`
+   - `dist`
+   - any runtime-required extra files (for example `schema.prisma`)
+   - docs like `README.md` and `CHANGELOG.md`
+   - if tests are inside src and gets included in dist, it's fine. don't try to exclude them
+10. `scripts.build` should be `rimraf dist "*.tsbuildinfo" && tsc && chmod +x dist/cli.js` (skip the chmod
+     if the package has no bin). No bundling. We remove dist to cleanup old transpiled files. Use `rimraf` here instead of bare shell globs so the script behaves the same in zsh, bash, and Windows shells even when no `.tsbuildinfo` file exists. This also removes the tsc incremental compilation state. Without that tsc would not generate again files to dist.
+     Optionally include running scripts with tsx if needed to generate build artifacts.
+11. `prepublishOnly` must always run `build` (optionally run generation before
+     build when required). Always add this script:
+     ```json
+     { "prepublishOnly": "pnpm build" }
+     ```
+     This ensures `dist/` is fresh before every `npm publish`.
+
+## bin field
+
+Use `bin` as a plain string pointing to the compiled entrypoint, not an object:
+
+```json
+{ "bin": "dist/cli.js" }
+```
+
+The bin file must be executable and start with a shebang. After creating or
+building it, always run:
+
+```bash
+chmod +x dist/cli.js
+```
+
+Add the shebang as the first line of the source file (`src/cli.ts`):
+
+```ts
+#!/usr/bin/env node
+```
+
+`tsc` preserves the shebang in the emitted `.js` file. The `chmod +x` is
+already part of the `build` script, so `prepublishOnly: "pnpm build"` handles
+it automatically.
+
+## Reading package version at runtime
+
+When Node code needs the package version, prefer reading it from `package.json`
+via `createRequire`. This works cleanly in ESM packages without adding a JSON
+import assertion.
+
+```ts
+import { createRequire } from "node:module";
+
+const require = createRequire(import.meta.url);
+const packageJson = require("../package.json") as {
+  version: string;
+};
+
+export const packageVersion = packageJson.version;
+```
+
+- Use a relative path from the current file to `package.json`.
+- Read only the fields you need, usually `version`.
+- Prefer this over hardcoding the version or duplicating it in source files.
+
+## Resolving paths relative to the package
+
+ESM does not have `__dirname`. Derive it from `import.meta.url` with the
+`node:url` and `node:path` modules, then resolve relative paths from there.
+
+```ts
+import url from "node:url";
+import path from "node:path";
+
+const __dirname = path.dirname(url.fileURLToPath(import.meta.url));
+
+// e.g. from src/cli.ts → read SKILL.md at the package root
+const skillPath = path.resolve(__dirname, "../SKILL.md");
+
+// from dist/cli.js (after tsc) → reach back to src/
+const srcFile = path.resolve(__dirname, "../src/template.md");
+```
+
+- Remember that `tsc` compiles `src/` → `dist/`. At runtime the file lives in
+  `dist/`, so one `..` gets you back to the package root.
+- From a file in `src/` during dev (running with `tsx`), `..` also reaches the
+  package root since `src/` is one level deep.
+- Use `path.resolve(__dirname, ...)` instead of string concatenation so it
+  works on all platforms.
+
+## Detecting development mode
+
+Check whether `import.meta.url` ends with `.ts` or `.tsx`. In dev you run
+source files directly (via `tsx` or `bun`), so the URL points to a `.ts` file.
+After `tsc` builds to `dist/`, the URL ends with `.js`.
+
+```ts
+const isDev = import.meta.url.endsWith(".ts") || import.meta.url.endsWith(".tsx");
+```
+
+This is useful for conditionally resolving paths that differ between `src/` and
+`dist/`, or enabling dev-only logging without relying on `NODE_ENV`.
+
+## tsconfig rules
+
+Use Node ESM-compatible compiler settings:
+
+```json
+{
+  "compilerOptions": {
+    "allowImportingTsExtensions": true,
+    "rewriteRelativeImportExtensions": true,
+    "rootDir": "src",
+    "outDir": "dist",
+    "module": "nodenext",
+    "moduleResolution": "nodenext",
+    "target": "ESNext",
+    "lib": ["ESNext"],
+    "declaration": true,
+    "declarationMap": true,
+    "noEmit": false,
+    "strict": true,
+    "noUncheckedIndexedAccess": true,
+    "skipLibCheck": true,
+    "useUnknownInCatchVariables": false
+  },
+  "include": ["src"]
+}
+```
+
+- Always use "rootDir": "src"
+- Add `"DOM"` to `lib` only when browser globals are needed.
+- Use `.ts` and `.tsx` extensions in source imports. `tsc` rewrites them to
+  `.js` in the emitted `dist/` output automatically via
+  `rewriteRelativeImportExtensions`. This means source code works directly in
+  runtimes like `tsx`, `bun`, and frameworks like Next.js that expect `.ts`
+  extensions, while the published `dist/` has correct `.js` imports that Node.js
+  and other consumers resolve without issues.
+  ```ts
+  // source (src/index.ts) — use .ts/.tsx extensions
+  import { helper } from './utils.ts'
+  import { Button } from './button.tsx'
+
+  // emitted output (dist/index.js) — tsc rewrites to .js
+  // import { helper } from './utils.js'
+  // import { Button } from './button.js'
+  ```
+- Only relative imports are rewritten. Path aliases (`paths` in tsconfig) are
+  not supported by `rewriteRelativeImportExtensions` — this is fine since npm
+  packages should use relative imports anyway.
+- Requires TypeScript 5.7+.
+- Install `@types/node` as a dev dependency whenever Node APIs are used.
+- If generation is required, keep generators in `scripts/*.ts` and invoke them
+  from package scripts before build/publish.
+
+> IMPORTANT! always use rootDir src. if there are other root level folders that should be type checked you should create other tsconfig.json files inside those folder. DO NOT add other folders inside src or the dist/ will contain dist/src, dist/other-folder. which breaks imports. the tsconfig.json inside these other folders can be minimal, using noEmit true, declaration false. Because usually these folders do not need to be emitted or compiled. just type checked. tests should still be put inside src. other folders can be things like `scripts` or `fixtures`.
+
+## Preferred exports template
+
+```json
+{
+  "type": "module",
+  "main": "./dist/index.js",
+  "types": "./dist/index.d.ts",
+  "exports": {
+    "./package.json": "./package.json",
+    ".": {
+      "types": "./dist/index.d.ts",
+      "default": "./dist/index.js"
+    },
+    "./src": {
+      "types": "./src/index.ts",
+      "default": "./src/index.ts"
+    },
+    "./src/*": {
+      "types": "./src/*.ts",
+      "default": "./src/*.ts" // or .tsx for packages that export React components. if so all files should end with .tsx
+    }
+  }
+}
+```
+
+
+## tests location
+
+test files should be close with the associated source files. for example if you have an utils.ts file you will create utils.test.ts file next to it. with tests, importing from utils. preferred testing framework is vitest (or bun if project already using `bun test` or depends on bun APIs, rare)
+
+
+## .gitignore
+
+For non-workspace (standalone) packages, always create a `.gitignore` with:
+
+```
+node_modules
+dist
+*.tsbuildinfo
+.DS_Store
+```
+
+Workspace packages inside a monorepo inherit the root `.gitignore`, so this only applies to standalone packages.
+
+
+## common mistakes
+
+- if you need to use zod always use latest version
+- always install packages as dev dependencies if used only for scripts, testing or types only
+- if the package uses `rimraf` in scripts, install it as a dev dependency instead of relying on platform-specific shell behavior

package/skills/playwriter/SKILL.md

@@ -0,0 +1,35 @@
+---
+name: playwriter
+description: Control the user own Chrome browser via Playwriter extension with Playwright code snippets in a stateful local js sandbox via playwriter cli. Use this over other Playwright MCPs to automate the browser — it connects to the user's existing Chrome instead of launching a new one. Use this for JS-heavy websites (Instagram, Twitter, cookie/login walls, lazy-loaded UIs) instead of webfetch/curl. Run `playwriter skill` command to read the complete up to date skill
+---
+
+## REQUIRED: Read Full Documentation First
+
+**Before using playwriter, you MUST run this command:**
+
+```bash
+playwriter skill # IMPORTANT! do not use | head here. read in full!
+```
+
+This outputs the complete documentation including:
+
+- Session management and timeout configuration
+- Selector strategies (and which ones to AVOID)
+- Rules to prevent timeouts and failures
+- Best practices for slow pages and SPAs
+- Context variables, utility functions, and more
+
+**Do NOT skip this step.** The quick examples below will fail without understanding timeouts, selector rules, and common pitfalls from the full docs.
+
+**Read the ENTIRE output.** Do NOT pipe through `head`, `tail`, or any truncation command. The skill output must be read in its entirety — critical rules about timeouts, selectors, and common pitfalls are spread throughout the document, not just at the top.
+
+## Minimal Example (after reading full docs)
+
+```bash
+playwriter session new
+playwriter -s 1 -e 'await page.goto("https://example.com")'
+```
+
+**Always use single quotes** for the `-e` argument. Single quotes prevent bash from interpreting `$`, backticks, and backslashes inside your JS code. Use double quotes or backtick template literals for strings inside the JS.
+
+If `playwriter` is not found, use `npx playwriter@latest` or `bunx playwriter@latest`.

package/skills/proxyman/SKILL.md

@@ -0,0 +1,215 @@
+---
+name: proxyman
+description: >
+  Reverse-engineer HTTP APIs using Proxyman for macOS. Intercept, record, and export
+  network traffic from CLI tools and apps (Node.js, Python, Ruby, Go, curl).
+  Export as HAR (JSON) and analyze with jq. Use this skill when the user wants
+  to capture, inspect, or reverse-engineer HTTP traffic from macOS applications.
+---
+
+# proxyman — HTTP traffic capture and reverse-engineering
+
+Proxyman is a macOS proxy that intercepts HTTP/HTTPS traffic. Use it to
+reverse-engineer APIs: capture what an app sends, inspect headers and bodies,
+and build SDKs or integrations from the captured data.
+
+## Important
+
+**Always run `proxyman-cli --help` and `proxyman-cli <subcommand> --help`
+before using.** The help output is the source of truth for all commands and
+options. The CLI binary lives inside the app bundle:
+
+```
+/Applications/Proxyman.app/Contents/MacOS/proxyman-cli
+```
+
+**Proxyman GUI must be running** for the CLI to work. The CLI talks to the
+running app — it does not work standalone or headless.
+
+```bash
+open -a Proxyman
+```
+
+## Node.js, Python, Ruby, Go, curl do NOT use macOS system proxy
+
+This is critical. Even though Proxyman auto-configures macOS system proxy
+settings, **CLI tools and runtimes ignore them**. You must set env vars so
+traffic routes through Proxyman (default port 9090):
+
+```bash
+HTTPS_PROXY=http://127.0.0.1:9090 \
+HTTP_PROXY=http://127.0.0.1:9090 \
+NODE_TLS_REJECT_UNAUTHORIZED=0 \
+  <your-command-here>
+```
+
+- `HTTPS_PROXY` / `HTTP_PROXY`: route traffic through Proxyman
+- `NODE_TLS_REJECT_UNAUTHORIZED=0`: accept Proxyman's SSL cert for Node.js apps
+- For Python: `REQUESTS_CA_BUNDLE` or `SSL_CERT_FILE` may be needed instead
+- For curl: use `--proxy http://127.0.0.1:9090 -k` or set the env vars
+
+Proxyman also has an "Automatic Setup" feature (Setup menu > Automatic Setup)
+that opens a pre-configured terminal with all env vars set. But for scripting
+and agent use, set the env vars explicitly as shown above.
+
+## CLI reference
+
+```
+proxyman-cli clear-session              Clear current captured traffic
+proxyman-cli export-log [options]       Export captured traffic to file
+proxyman-cli export [options]           Export debug tool rules (Map Local, etc)
+proxyman-cli import --input <file>      Import debug tool rules
+proxyman-cli proxy on|off               Toggle macOS system HTTP proxy
+proxyman-cli breakpoint enable|disable  Toggle Breakpoint tool
+proxyman-cli maplocal enable|disable    Toggle Map Local tool
+proxyman-cli scripting enable|disable   Toggle Scripting tool
+proxyman-cli install-root-cert <file>   Install custom root cert (requires sudo)
+```
+
+### export-log options
+
+```
+-m, --mode <mode>         all | domains (default: all)
+-o, --output <path>       Output file path (required)
+-d, --domains <domain>    Filter by domain (repeatable, only with -m domains)
+-f, --format <format>     proxymansession | har | raw (default: proxymansession)
+```
+
+**Always use `-f har`** for agent workflows. HAR is JSON and works with jq.
+
+### export-log timing bug
+
+The CLI can report "Exported Completed!" before the file is actually written.
+Add `sleep 3` after export-log before reading the file:
+
+```bash
+proxyman-cli export-log -m all -o capture.har -f har
+sleep 3
+jq '.log.entries | length' capture.har
+```
+
+## Reverse-engineering workflow
+
+This is the primary use case. Example: figuring out how Claude Code talks to
+the Anthropic API.
+
+```bash
+# 1. Make sure Proxyman is running
+open -a Proxyman
+
+# 2. Clear previous traffic
+proxyman-cli clear-session
+
+# 3. Run the target app through the proxy
+HTTPS_PROXY=http://127.0.0.1:9090 \
+HTTP_PROXY=http://127.0.0.1:9090 \
+NODE_TLS_REJECT_UNAUTHORIZED=0 \
+  claude -p "say hi" --max-turns 1
+
+# 4. Export captured traffic as HAR
+proxyman-cli export-log -m all -o capture.har -f har
+sleep 3
+
+# 5. Filter for the domain you care about
+jq '[.log.entries[] | select(.request.url | test("anthropic"))]' capture.har
+```
+
+## Analyzing HAR files with jq
+
+### List all domains and request counts
+
+```bash
+jq '[.log.entries[].request.url] | map(split("/")[2])
+  | group_by(.) | map({domain: .[0], count: length})
+  | sort_by(-.count)' capture.har
+```
+
+### Filter by domain
+
+```bash
+jq '.log.entries[] | select(.request.url | test("api.example.com"))' capture.har
+```
+
+### Request summary (method, url, status)
+
+```bash
+jq '[.log.entries[] | select(.request.url | test("api.example.com")) | {
+  method: .request.method,
+  url: .request.url,
+  status: .response.status
+}]' capture.har
+```
+
+### Full request details (headers + body)
+
+```bash
+jq '.log.entries[] | select(.request.url | test("v1/messages")) | {
+  url: .request.url,
+  method: .request.method,
+  status: .response.status,
+  request_headers: [.request.headers[] | {(.name): .value}] | add,
+  request_body: (.request.postData.text | fromjson? // .request.postData.text),
+  response_body: (.response.content.text | fromjson? // .response.content.text)
+}' capture.har
+```
+
+### Request body structure (without full content)
+
+Useful for large payloads — see the shape without the bulk:
+
+```bash
+jq '.log.entries[] | select(.request.url | test("v1/messages"))
+  | .request.postData.text | fromjson
+  | {model, max_tokens, stream,
+     system_count: (.system | length),
+     messages_count: (.messages | length),
+     tools_count: (.tools | length),
+     messages: [.messages[] | {role, content_type: (.content | type)}]
+  }' capture.har
+```
+
+### Extract specific headers
+
+```bash
+jq '.log.entries[] | select(.request.url | test("api.example.com"))
+  | {url: .request.url, auth: (.request.headers[] | select(.name == "authorization") | .value)}' capture.har
+```
+
+### Only failed requests
+
+```bash
+jq '[.log.entries[] | select(.response.status >= 400) | {
+  url: .request.url,
+  status: .response.status,
+  error: .response.content.text
+}]' capture.har
+```
+
+## Domain-filtered export
+
+If you only care about one domain, filter at export time to get a smaller file:
+
+```bash
+proxyman-cli export-log -m domains --domains 'api.anthropic.com' -o anthropic.har -f har
+```
+
+Multiple domains:
+
+```bash
+proxyman-cli export-log -m domains \
+  --domains 'api.anthropic.com' \
+  --domains 'mcp-proxy.anthropic.com' \
+  -o anthropic.har -f har
+```
+
+## SSL proxying
+
+Proxyman needs to decrypt HTTPS to see request/response bodies. For Node.js
+apps, `NODE_TLS_REJECT_UNAUTHORIZED=0` handles this. For system apps and
+browsers, install and trust the Proxyman root certificate:
+
+- Proxyman menu > Certificate > Install Certificate on this Mac
+- Or via CLI: `proxyman-cli install-root-cert <path-to-cert>`
+
+Without SSL proxying enabled for a domain, you'll see the connection but not
+the decrypted body content.