context-mode

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Context Mode: Default for All Large Output

Context Mode：所有大输出场景的默认模式

MANDATORY RULE

强制规则

<context_mode_logic> <mandatory_rule> Default to context-mode for ALL commands. Only use Bash for guaranteed-small-output operations. </mandatory_rule> </context_mode_logic>

Bash whitelist (safe to run directly):

File mutations:
```
mkdir
```
,
```
mv
```
,
```
cp
```
,
```
rm
```
,
```
touch
```
,
```
chmod
```

Git writes:

git add

git commit

git push

git checkout

git branch

git merge

Navigation:
```
cd
```
,
```
pwd
```
,
```
which
```
Process control:
```
kill
```
,
```
pkill
```
Package management:
```
npm install
```
,
```
npm publish
```
,
```
pip install
```
Simple output:
```
echo
```
,
```
printf
```

Everything else →
ctx_execute
or
ctx_execute_file
. Any command that reads, queries, fetches, lists, logs, tests, builds, diffs, inspects, or calls an external service. This includes ALL CLIs (gh, aws, kubectl, docker, terraform, wrangler, fly, heroku, gcloud, etc.) — there are thousands and we cannot list them all.

When uncertain, use context-mode. Every KB of unnecessary context reduces the quality and speed of the entire session.

<context_mode_logic> <mandatory_rule> 默认对所有命令使用context-mode。仅在确定输出内容较小时使用Bash。 </mandatory_rule> </context_mode_logic>

Bash白名单（可直接安全运行）：

文件操作：
```
mkdir
```
,
```
mv
```
,
```
cp
```
,
```
rm
```
,
```
touch
```
,
```
chmod
```

Git写入操作：

git add

git commit

git push

git checkout

git branch

git merge

导航操作：
```
cd
```
,
```
pwd
```
,
```
which
```
进程控制：
```
kill
```
,
```
pkill
```
包管理：
```
npm install
```
,
```
npm publish
```
,
```
pip install
```
简单输出：
```
echo
```
,
```
printf
```

其他所有操作 → 使用
ctx_execute
或
ctx_execute_file
。任何涉及读取、查询、获取、列出、日志查看、测试、构建、差异对比、检查或调用外部服务的命令都包含在内。这涵盖所有CLI工具（gh、aws、kubectl、docker、terraform、wrangler、fly、heroku、gcloud等）——此类工具数量众多，无法全部列出。

若不确定，就使用context-mode。每KB不必要的上下文都会降低整个会话的质量和速度。

Decision Tree

决策树

About to run a command / read a file / call an API?
│
├── Command is on the Bash whitelist (file mutations, git writes, navigation, echo)?
│   └── Use Bash
│
├── Output MIGHT be large or you're UNSURE?
│   └── Use context-mode ctx_execute or ctx_execute_file
│
├── Fetching web documentation or HTML page?
│   └── Use ctx_fetch_and_index → ctx_search
│
├── Using Playwright (navigate, snapshot, console, network)?
│   └── ALWAYS use filename parameter to save to file, then:
│       browser_snapshot(filename) → ctx_index(path) or ctx_execute_file(path)
│       browser_console_messages(filename) → ctx_execute_file(path)
│       browser_network_requests(filename) → ctx_execute_file(path)
│       ⚠ browser_navigate returns a snapshot automatically — ignore it,
│         use browser_snapshot(filename) for any inspection.
│       ⚠ Playwright MCP uses a SINGLE browser instance — NOT parallel-safe.
│         For parallel browser ops, use agent-browser via execute instead.
│
├── Using agent-browser (parallel-safe browser automation)?
│   └── Run via execute (shell) — each call gets its own subprocess:
│       execute("agent-browser open example.com && agent-browser snapshot -i -c")
│       ✓ Supports sessions for isolated browser instances
│       ✓ Safe for parallel subagent execution
│       ✓ Lightweight accessibility tree with ref-based interaction
│
├── Processing output from another MCP tool (Context7, GitHub API, etc.)?
│   ├── Output already in context from a previous tool call?
│   │   └── Use it directly. Do NOT re-index with ctx_index(content: ...).
│   ├── Need to search the output multiple times?
│   │   └── Save to file via ctx_execute, then ctx_index(path) → ctx_search
│   └── One-shot extraction?
│       └── Save to file via ctx_execute, then ctx_execute_file(path)
│
└── Reading a file to analyze/summarize (not edit)?
    └── Use ctx_execute_file (file loads into FILE_CONTENT, not context)

即将运行命令/读取文件/调用API？
│
├── 命令属于Bash白名单（文件操作、Git写入、导航、echo）？
│   └── 使用Bash
│
├── 输出可能较大或你不确定？
│   └── 使用context-mode的`ctx_execute`或`ctx_execute_file`
│
├── 获取Web文档或HTML页面？
│   └── 使用`ctx_fetch_and_index` → `ctx_search`
│
├── 使用Playwright（导航、快照、控制台、网络）？
│   └── 始终使用filename参数保存到文件，然后：
│       browser_snapshot(filename) → ctx_index(path) 或 ctx_execute_file(path)
│       browser_console_messages(filename) → ctx_execute_file(path)
│       browser_network_requests(filename) → ctx_execute_file(path)
│       ⚠ browser_navigate会自动返回快照——忽略该返回结果，
│         如需检查页面，请使用browser_snapshot(filename)
│       ⚠ Playwright MCP使用单个浏览器实例——不支持并行操作。
│         如需并行浏览器操作，请通过execute使用agent-browser：
│
├── 使用agent-browser（支持并行的浏览器自动化）？
│   └── 通过execute（shell）运行——每次调用都会创建独立子进程：
│       execute("agent-browser open example.com && agent-browser snapshot -i -c")
│       ✓ 支持会话隔离的浏览器实例
│       ✓ 适用于并行子代理执行
│       ✓ 轻量级可访问性树，支持基于引用的交互
│
├── 处理其他MCP工具（Context7、GitHub API等）的输出？
│   ├── 输出已来自之前的工具调用并存在于上下文中？
│   │   └── 直接使用，请勿通过ctx_index(content: ...)重新索引
│   ├── 需要多次搜索输出内容？
│   │   └── 通过ctx_execute保存到文件，然后执行ctx_index(path) → ctx_search
│   └── 仅需一次性提取信息？
│       └── 通过ctx_execute保存到文件，然后执行ctx_execute_file(path)
│
└── 读取文件以进行分析/汇总（而非编辑）？
    └── 使用ctx_execute_file（文件内容会加载到FILE_CONTENT，而非上下文）

When to Use Each Tool

各工具的适用场景

Situation	Tool	Example
Hit an API endpoint	`ctx_execute`	`fetch('http://localhost:3000/api/orders')`
Run CLI that returns data	`ctx_execute`	`gh pr list` , `aws s3 ls` , `kubectl get pods`
Run tests	`ctx_execute`	`npm test` , `pytest` , `go test ./...`
Git operations	`ctx_execute`	`git log --oneline -50` , `git diff HEAD~5`
Docker/K8s inspection	`ctx_execute`	`docker stats --no-stream` , `kubectl describe pod`
Read a log file	`ctx_execute_file`	Parse access.log, error.log, build output
Read a data file	`ctx_execute_file`	Analyze CSV, JSON, YAML, XML
Read source code to analyze	`ctx_execute_file`	Count functions, find patterns, extract metrics
Fetch web docs	`ctx_fetch_and_index`	Index React/Next.js/Zod docs, then search
Playwright snapshot	`browser_snapshot(filename)` → `ctx_index(path)` → `ctx_search`	Save to file, index server-side, query
Playwright snapshot (one-shot)	`browser_snapshot(filename)` → `ctx_execute_file(path)`	Save to file, extract in sandbox
Playwright console/network	`browser_*(filename)` → `ctx_execute_file(path)`	Save to file, analyze in sandbox
MCP output (already in context)	Use directly	Don't re-index — it's already loaded
MCP output (need multi-query)	`ctx_execute` to save → `ctx_index(path)` → `ctx_search`	Save to file first, index server-side

场景	工具	示例
调用API端点	`ctx_execute`	`fetch('http://localhost:3000/api/orders')`
运行返回数据的CLI命令	`ctx_execute`	`gh pr list` , `aws s3 ls` , `kubectl get pods`
运行测试	`ctx_execute`	`npm test` , `pytest` , `go test ./...`
Git操作（读取类）	`ctx_execute`	`git log --oneline -50` , `git diff HEAD~5`
Docker/K8s检查	`ctx_execute`	`docker stats --no-stream` , `kubectl describe pod`
读取日志文件	`ctx_execute_file`	解析access.log、error.log、构建输出
读取数据文件	`ctx_execute_file`	分析CSV、JSON、YAML、XML
读取源代码进行分析	`ctx_execute_file`	统计函数数量、查找模式、提取指标
获取Web文档	`ctx_fetch_and_index`	索引React/Next.js/Zod文档，然后进行搜索
Playwright快照（多查询场景）	`browser_snapshot(filename)` → `ctx_index(path)` → `ctx_search`	保存到文件，在服务器端索引，然后查询
Playwright快照（一次性提取）	`browser_snapshot(filename)` → `ctx_execute_file(path)`	保存到文件，在沙箱中处理
Playwright控制台/网络日志	`browser_*(filename)` → `ctx_execute_file(path)`	保存到文件，在沙箱中分析
MCP工具输出（已在上下文中）	直接使用	无需重新索引——内容已加载
MCP工具输出（需多次查询）	`ctx_execute` 保存到文件 → `ctx_index(path)` → `ctx_search`	先保存到文件，再在服务器端索引

Automatic Triggers

自动触发场景

Use context-mode for ANY of these, without being asked:

API debugging: "hit this endpoint", "call the API", "check the response", "find the bug in the response"
Log analysis: "check the logs", "what errors", "read access.log", "debug the 500s"
Test runs: "run the tests", "check if tests pass", "test suite output"
Git history: "show recent commits", "git log", "what changed", "diff between branches"
Data inspection: "look at the CSV", "parse the JSON", "analyze the config"
Infrastructure: "list containers", "check pods", "S3 buckets", "show running services"
Dependency audit: "check dependencies", "outdated packages", "security audit"
Build output: "build the project", "check for warnings", "compile errors"
Code metrics: "count lines", "find TODOs", "function count", "analyze codebase"
Web docs lookup: "look up the docs", "check the API reference", "find examples"

无需额外指令，在以下场景自动使用context-mode：

API调试：「调用该端点」、「调用API」、「检查响应」、「查找响应中的Bug」
日志分析：「查看日志」、「有哪些错误」、「读取access.log」、「调试500错误」
测试运行：「运行测试」、「检查测试是否通过」、「测试套件输出」
Git历史：「显示最近提交记录」、「git log」、「变更内容」、「分支差异对比」
数据检查：「查看CSV文件」、「解析JSON」、「分析配置文件」
基础设施检查：「列出容器」、「检查Pod状态」、「S3存储桶」、「显示运行中的服务」
依赖审计：「检查依赖项」、「过时包」、「安全审计」
构建输出：「构建项目」、「检查警告」、「编译错误」
代码指标：「统计代码行数」、「查找TODO项」、「函数数量」、「分析代码库」
Web文档查询：「查找文档」、「查看API参考」、「查找示例」

Language Selection

语言选择

Situation	Language	Why
HTTP/API calls, JSON	`javascript`	Native fetch, JSON.parse, async/await
Data analysis, CSV, stats	`python`	csv, statistics, collections, re
Shell commands with pipes	`shell`	grep, awk, jq, native tools
File pattern matching	`shell`	find, wc, sort, uniq

场景	语言	原因
HTTP/API调用、JSON处理	`javascript`	原生支持fetch、JSON.parse、async/await
数据分析、CSV、统计	`python`	支持csv、statistics、collections、re库
带管道的Shell命令	`shell`	支持grep、awk、jq等原生工具
文件模式匹配	`shell`	支持find、wc、sort、uniq

Search Query Strategy

搜索查询策略

BM25 uses OR semantics — results matching more terms rank higher automatically
Use 2-4 specific technical terms per query
Always use
source
parameter when multiple docs are indexed to avoid cross-source contamination
- Partial match works:
```
source: "Node"
```
  matches
```
"Node.js v22 CHANGELOG"
```
Always use
queries
array — batch ALL search questions in ONE call:
- ```
ctx_search(queries: ["transform pipe", "refine superRefine", "coerce codec"], source: "Zod")
```
- NEVER make multiple separate ctx_search() calls — put all queries in one array

BM25采用OR语义——匹配更多关键词的结果会自动获得更高排名
每个查询使用2-4个具体的技术术语
始终使用
source
参数：当索引了多个文档时，避免跨文档污染
- 部分匹配有效：
```
source: "Node"
```
  会匹配
```
"Node.js v22 CHANGELOG"
```
始终使用
queries
数组——将所有搜索问题批量放在一次调用中：
- ```
ctx_search(queries: ["transform pipe", "refine superRefine", "coerce codec"], source: "Zod")
```
- 切勿多次单独调用ctx_search()——将所有查询放入一个数组

External Documentation

外部文档处理

Always use
ctx_fetch_and_index
for external docs — NEVER
```
cat
```
or
```
ctx_execute
```
with local paths for packages you don't own

For GitHub-hosted projects, use the raw URL:

https://raw.githubusercontent.com/org/repo/main/CHANGELOG.md

After indexing, use the
```
source
```
parameter in search to scope results to that specific document

**始终使用
```
ctx_fetch_and_index
```
**获取外部文档——对于非你维护的包，切勿使用
```
cat
```
或
```
ctx_execute
```
读取本地路径

对于GitHub托管的项目，使用原始URL：

https://raw.githubusercontent.com/org/repo/main/CHANGELOG.md

索引完成后，在搜索时使用
```
source
```
参数将结果限定到该特定文档

Critical Rules

关键规则

Always console.log/print your findings. stdout is all that enters context. No output = wasted call.
Write analysis code, not just data dumps. Don't
```
console.log(JSON.stringify(data))
```
— analyze first, print findings.
Be specific in output. Print bug details with IDs, line numbers, exact values — not just counts.
For files you need to EDIT: Use the normal Read tool. context-mode is for analysis, not editing.
For Bash whitelist commands only: Use Bash for file mutations, git writes, navigation, process control, package install, and echo. Everything else goes through context-mode.
Never use
ctx_index(content: large_data)
. Use
```
ctx_index(path: ...)
```
to read files server-side. The
```
content
```
parameter sends data through context as a tool parameter — use it only for small inline text.
Always use
filename
parameter on Playwright tools (
```
browser_snapshot
```
,
```
browser_console_messages
```
,
```
browser_network_requests
```
). Without it, the full output enters context.
Don't re-index data already in context. If an MCP tool returned data in a previous response, it's already loaded — use it directly or save to file first.

始终使用console.log/print输出你的发现。只有标准输出会进入上下文。没有输出 = 无效调用。
编写分析代码，而非仅转储数据。不要直接
```
console.log(JSON.stringify(data))
```
——先分析，再输出发现。
输出内容要具体。打印包含ID、行号、精确值的Bug详情——而非仅统计数量。
如需编辑文件：使用常规的Read工具。context-mode仅用于分析，不用于编辑。
仅对Bash白名单命令使用Bash：文件操作、Git写入、导航、进程控制、包安装、echo等使用Bash。其他所有操作都使用context-mode。
切勿使用
ctx_index(content: large_data)
。使用
```
ctx_index(path: ...)
```
在服务器端读取文件。
```
content
```
参数会将数据作为工具参数传入上下文——仅对小型内联文本使用该参数。
调用Playwright工具时始终使用
filename
参数（
```
browser_snapshot
```
、
```
browser_console_messages
```
、
```
browser_network_requests
```
）。如果不使用该参数，完整输出会直接进入上下文。
不要重新索引已在上下文中的数据。如果MCP工具在之前的响应中已返回数据，内容已加载——直接使用或先保存到文件。

Sandboxed Data Workflow

沙箱数据工作流

<sandboxed_data_workflow> <critical_rule> When using tools that support saving to a file: ALWAYS use the 'filename' parameter. NEVER return large raw datasets directly to context. </critical_rule> <workflow> LargeDataTool(filename: "path") → mcp__context-mode__ctx_index(path: "path") → ctx_search() </workflow> </sandboxed_data_workflow>

This is the universal pattern for context preservation regardless of the source tool (Playwright, GitHub API, AWS CLI, etc.).

<sandboxed_data_workflow> <critical_rule> 当使用支持保存到文件的工具时：始终使用'filename'参数。切勿直接返回大型原始数据集到上下文。 </critical_rule> <workflow> LargeDataTool(filename: "path") → mcp__context-mode__ctx_index(path: "path") → ctx_search() </workflow> </sandboxed_data_workflow>

这是无论源工具（Playwright、GitHub API、AWS CLI等）如何，都能保存上下文的通用模式。

Examples

示例

Debug an API endpoint

调试API端点

javascript

const resp = await fetch('http://localhost:3000/api/orders');
const { orders } = await resp.json();

const bugs = [];
const negQty = orders.filter(o => o.quantity < 0);
if (negQty.length) bugs.push(`Negative qty: ${negQty.map(o => o.id).join(', ')}`);

const nullFields = orders.filter(o => !o.product || !o.customer);
if (nullFields.length) bugs.push(`Null fields: ${nullFields.map(o => o.id).join(', ')}`);

console.log(`${orders.length} orders, ${bugs.length} bugs found:`);
bugs.forEach(b => console.log(`- ${b}`));

javascript

const resp = await fetch('http://localhost:3000/api/orders');
const { orders } = await resp.json();

const bugs = [];
const negQty = orders.filter(o => o.quantity < 0);
if (negQty.length) bugs.push(`Negative qty: ${negQty.map(o => o.id).join(', ')}`);

const nullFields = orders.filter(o => !o.product || !o.customer);
if (nullFields.length) bugs.push(`Null fields: ${nullFields.map(o => o.id).join(', ')}`);

console.log(`${orders.length} orders, ${bugs.length} bugs found:`);
bugs.forEach(b => console.log(`- ${b}`));

Analyze test output

分析测试输出

shell

npm test 2>&1
echo "EXIT=$?"

shell

npm test 2>&1
echo "EXIT=$?"

Check GitHub PRs

查看GitHub PR列表

shell

gh pr list --json number,title,state,reviewDecision --jq '.[] | "\(.number) [\(.state)] \(.title) — \(.reviewDecision // "no review")"'

shell

gh pr list --json number,title,state,reviewDecision --jq '.[] | "\(.number) [\(.state)] \(.title) — \(.reviewDecision // "no review")"'

Read and analyze a large file

读取并分析大文件

python

undefined

python

undefined

FILE_CONTENT is pre-loaded by ctx_execute_file

FILE_CONTENT由ctx_execute_file预加载

import json data = json.loads(FILE_CONTENT) print(f"Records: {len(data)}")

... analyze and print findings

... 分析并输出发现

undefined

undefined

Browser & Playwright Integration

浏览器与Playwright集成

When a task involves Playwright snapshots, screenshots, or page inspection, ALWAYS route through file → sandbox.

Playwright

browser_snapshot

returns 10K–135K tokens of accessibility tree data. Calling it without

filename

dumps all of that into context. Passing the output to

ctx_index(content: ...)

sends it into context a SECOND time as a parameter. Both are wrong.

The key insight:

browser_snapshot

has a

filename

parameter that saves to file instead of returning to context.

ctx_index

has a

path

parameter that reads files server-side.

ctx_execute_file

processes files in a sandbox. None of these touch context.

当任务涉及Playwright快照、截图或页面检查时，始终通过「文件 → 沙箱」的流程处理。

Playwright的

browser_snapshot

会返回10K–135K令牌的可访问性树数据。如果不使用

filename

参数调用该方法，所有数据都会直接注入上下文。如果将输出传递给

ctx_index(content: ...)

，数据会作为参数第二次进入上下文。这两种方式都是错误的。

核心要点：

browser_snapshot

有一个

filename

参数，可将内容保存到文件而非返回给上下文。

ctx_index

有一个

path

参数，可在服务器端读取文件。

ctx_execute_file

在沙箱中处理文件。这些操作都不会占用上下文。

Workflow A: Snapshot → File → Index → Search (multiple queries)

工作流A：快照 → 文件 → 索引 → 搜索（多查询场景）

Step 1: browser_snapshot(filename: "/tmp/playwright-snapshot.md")
        → saves to file, returns ~50B confirmation (NOT 135K tokens)

Step 2: ctx_index(path: "/tmp/playwright-snapshot.md", source: "Playwright snapshot")
        → reads file SERVER-SIDE, indexes into FTS5, returns ~80B confirmation

Step 3: ctx_search(queries: ["login form email password"], source: "Playwright")
        → returns only matching chunks (~300B)

Total context: ~430B instead of 270K tokens. Real 99% savings.

步骤1: browser_snapshot(filename: "/tmp/playwright-snapshot.md")
        → 保存到文件，返回约50字节的确认信息（而非135K令牌）

步骤2: ctx_index(path: "/tmp/playwright-snapshot.md", source: "Playwright snapshot")
        → 在服务器端读取文件，索引到FTS5，返回约80字节的确认信息

步骤3: ctx_search(queries: ["login form email password"], source: "Playwright")
        → 仅返回匹配的片段（约300字节）

总上下文占用：约430字节，而非270K令牌。实际减少99%的占用。

Workflow B: Snapshot → File → Execute File (one-shot extraction)

工作流B：快照 → 文件 → 执行文件（一次性提取）

Step 1: browser_snapshot(filename: "/tmp/playwright-snapshot.md")
        → saves to file, returns ~50B confirmation

Step 2: ctx_execute_file(path: "/tmp/playwright-snapshot.md", language: "javascript", code: "
          const links = [...FILE_CONTENT.matchAll(/- link \"([^\"]+)\"/g)].map(m => m[1]);
          const buttons = [...FILE_CONTENT.matchAll(/- button \"([^\"]+)\"/g)].map(m => m[1]);
          const inputs = [...FILE_CONTENT.matchAll(/- textbox|- checkbox|- radio/g)];
          console.log('Links:', links.length, '| Buttons:', buttons.length, '| Inputs:', inputs.length);
          console.log('Navigation:', links.slice(0, 10).join(', '));
        ")
        → processes in sandbox, returns ~200B summary

Total context: ~250B instead of 135K tokens.

步骤1: browser_snapshot(filename: "/tmp/playwright-snapshot.md")
        → 保存到文件，返回约50字节的确认信息

步骤2: ctx_execute_file(path: "/tmp/playwright-snapshot.md", language: "javascript", code: "
          const links = [...FILE_CONTENT.matchAll(/- link \"([^\"]+)\"/g)].map(m => m[1]);
          const buttons = [...FILE_CONTENT.matchAll(/- button \"([^\"]+)\"/g)].map(m => m[1]);
          const inputs = [...FILE_CONTENT.matchAll(/- textbox|- checkbox|- radio/g)];
          console.log('Links:', links.length, '| Buttons:', buttons.length, '| Inputs:', inputs.length);
          console.log('Navigation:', links.slice(0, 10).join(', '));
        ")
        → 在沙箱中处理，返回约200字节的汇总信息

总上下文占用：约250字节，而非135K令牌。

Workflow C: Console & Network (save to file if large)

工作流C：控制台与网络日志（若内容较大则保存到文件）

browser_console_messages(level: "error", filename: "/tmp/console.md")
→ ctx_execute_file(path: "/tmp/console.md", ...) or ctx_index(path: "/tmp/console.md", ...)

browser_network_requests(includeStatic: false, filename: "/tmp/network.md")
→ ctx_execute_file(path: "/tmp/network.md", ...) or ctx_index(path: "/tmp/network.md", ...)

browser_console_messages(level: "error", filename: "/tmp/console.md")
→ ctx_execute_file(path: "/tmp/console.md", ...) 或 ctx_index(path: "/tmp/console.md", ...)

browser_network_requests(includeStatic: false, filename: "/tmp/network.md")
→ ctx_execute_file(path: "/tmp/network.md", ...) 或 ctx_index(path: "/tmp/network.md", ...)

CRITICAL: Why

filename

path

is mandatory

关键：为什么

filename

path

是必须的

Approach	Context cost	Correct?
`browser_snapshot()` → raw into context	135K tokens	NO
`browser_snapshot()` → `ctx_index(content: raw)`	270K tokens (doubled!)	NO
`browser_snapshot(filename)` → `ctx_index(path)` → `ctx_search`	~430B	YES
`browser_snapshot(filename)` → `ctx_execute_file(path)`	~250B	YES

方式	上下文成本	是否正确
`browser_snapshot()` → 直接返回上下文	135K令牌	否
`browser_snapshot()` → `ctx_index(content: raw)`	270K令牌（翻倍！）	否
`browser_snapshot(filename)` → `ctx_index(path)` → `ctx_search`	约430字节	是
`browser_snapshot(filename)` → `ctx_execute_file(path)`	约250字节	是

Key Rule

核心规则

ALWAYS use
filename
parameter when calling
browser_snapshot
,
browser_console_messages
, or
browser_network_requests
. Then process via
ctx_index(path: ...)
or
ctx_execute_file(path: ...)
— never
ctx_index(content: ...)
.
Data flow: Playwright → file → server-side read → context. Never: Playwright → context → ctx_index(content) → context again.

调用
browser_snapshot
、
browser_console_messages
或
browser_network_requests
时，始终使用
filename
参数。然后通过
ctx_index(path: ...)
或
ctx_execute_file(path: ...)
处理——切勿使用
ctx_index(content: ...)
。
数据流：Playwright → 文件 → 服务器端读取 → 上下文。绝对不要：Playwright → 上下文 → ctx_index(content) → 再次进入上下文。

Subagent Usage

子代理使用说明

Subagents automatically receive context-mode tool routing via a PreToolUse hook. You do NOT need to manually add tool names to subagent prompts — the hook injects them. Just write natural task descriptions.

子代理会通过PreToolUse钩子自动接收context-mode工具路由。你无需手动在子代理提示中添加工具名称——钩子会自动注入。只需编写自然的任务描述即可。

Anti-Patterns

反模式

Using
```
curl http://api/endpoint
```
via Bash → 50KB floods context. Use
```
ctx_execute
```
with fetch instead.
Using
```
cat large-file.json
```
via Bash → entire file in context. Use
```
ctx_execute_file
```
instead.
Using
```
gh pr list
```
via Bash → raw JSON in context. Use
```
ctx_execute
```
with
```
--jq
```
filter instead.
Piping Bash output through
```
| head -20
```
→ you lose the rest. Use
```
ctx_execute
```
to analyze ALL data and print summary.
Running
```
npm test
```
via Bash → full test output in context. Use
```
ctx_execute
```
to capture and summarize.

Calling

browser_snapshot()

WITHOUT

filename

parameter → 135K tokens flood context. Always use

browser_snapshot(filename: "/tmp/snap.md")

Calling
```
browser_console_messages()
```
or
```
browser_network_requests()
```
WITHOUT
```
filename
```
→ entire output floods context. Always use the
```
filename
```
parameter.
Passing ANY large data to
```
ctx_index(content: ...)
```
→ data enters context as a parameter. Always use
```
ctx_index(path: ...)
```
to read server-side. The
```
content
```
parameter should only be used for small inline text you're composing yourself.
Calling an MCP tool (Context7
```
query-docs
```
, GitHub API, etc.) then passing the response to
```
ctx_index(content: response)
```
→ doubles context usage. The response is already in context — use it directly or save to file first.
Ignoring
```
browser_navigate
```
auto-snapshot → navigation response includes a full page snapshot. Don't rely on it for inspection — call
```
browser_snapshot(filename)
```
separately.

通过Bash使用
```
curl http://api/endpoint
```
→ 50KB内容涌入上下文。改用
```
ctx_execute
```
和fetch。
通过Bash使用
```
cat large-file.json
```
→ 整个文件进入上下文。改用
```
ctx_execute_file
```
。
通过Bash使用
```
gh pr list
```
→ 原始JSON进入上下文。改用
```
ctx_execute
```
并配合
```
--jq
```
过滤。
通过Bash管道使用
```
| head -20
```
→ 丢失剩余内容。改用
```
ctx_execute
```
分析所有数据并输出汇总。
通过Bash运行
```
npm test
```
→ 完整测试输出进入上下文。改用
```
ctx_execute
```
捕获并汇总。
调用
```
browser_snapshot()
```
时不使用
```
filename
```
参数 → 135K令牌涌入上下文。必须使用
```
browser_snapshot(filename: "/tmp/snap.md")
```
。
调用
```
browser_console_messages()
```
或
```
browser_network_requests()
```
时不使用
```
filename
```
参数 → 完整输出涌入上下文。必须使用
```
filename
```
参数。
将任何大型数据传递给
```
ctx_index(content: ...)
```
→ 数据作为参数进入上下文。必须使用
```
ctx_index(path: ...)
```
在服务器端读取。
```
content
```
参数仅应用于你自己编写的小型内联文本。
调用MCP工具（Context7的
```
query-docs
```
、GitHub API等）后，将响应传递给
```
ctx_index(content: response)
```
→ 翻倍上下文占用。响应已在上下文中——直接使用或先保存到文件。
忽略
```
browser_navigate
```
的自动快照 → 导航响应包含完整页面快照。不要依赖该快照进行检查——单独调用
```
browser_snapshot(filename)
```
。

Reference Files

参考文件

JavaScript/TypeScript Patterns
Python Patterns
Shell Patterns
Anti-Patterns & Common Mistakes

JavaScript/TypeScript 模式
Python 模式
Shell 模式
反模式与常见错误

context-mode

Original

Translation

Context Mode: Default for All Large Output

Context Mode：所有大输出场景的默认模式

MANDATORY RULE

强制规则

Decision Tree

决策树

When to Use Each Tool

各工具的适用场景

Automatic Triggers

自动触发场景

Language Selection

语言选择

Search Query Strategy

搜索查询策略

External Documentation

外部文档处理

Critical Rules

关键规则

Sandboxed Data Workflow

沙箱数据工作流

Examples

示例

Debug an API endpoint

调试API端点

Analyze test output

分析测试输出

Check GitHub PRs

查看GitHub PR列表

Read and analyze a large file

读取并分析大文件

FILE_CONTENT is pre-loaded by ctx_execute_file

FILE_CONTENT由ctx_execute_file预加载

... analyze and print findings

... 分析并输出发现

Browser & Playwright Integration

浏览器与Playwright集成

Workflow A: Snapshot → File → Index → Search (multiple queries)

工作流A：快照 → 文件 → 索引 → 搜索（多查询场景）

Workflow B: Snapshot → File → Execute File (one-shot extraction)

工作流B：快照 → 文件 → 执行文件（一次性提取）

Workflow C: Console & Network (save to file if large)

工作流C：控制台与网络日志（若内容较大则保存到文件）

CRITICAL: Why filename + path is mandatory

关键：为什么filename + path是必须的

Key Rule

核心规则

Subagent Usage

子代理使用说明

Anti-Patterns

反模式

Reference Files

参考文件

CRITICAL: Why
`filename`
+
`path`
is mandatory

关键：为什么
`filename`
+
`path`
是必须的