[FEATURE] Bundle a `/browse` skill that delegates browser MCP work to a subagent — prevents per-call context bloat in main session
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet — closest adjacent issues are #43057 (
scopefield in.mcp.json) and #52142 (per-agent MCP toggles). Both address tool definitions loading; this proposal is about per-call tool results, which is a separate cost. - [x] This is a single feature request (not multiple features)
Problem Statement
Browser MCP tool calls (mcp__claude-in-chrome__*, mcp__playwright__*) return very large results. A single browser_snapshot, read_page, or browser_take_screenshot can consume 5–50K tokens of HTML, accessibility tree, or image data per call. After 2–3 browser interactions, the main session's context is rotted with raw page content the model doesn't actually need to reason over.
Existing related proposals (#43057, #52142) address the tool definition side of MCP context bloat — keeping unused tool schemas out of main. Neither addresses per-call result bloat, which is the dominant cost for browser-heavy workflows. Both layers are needed.
Proposed Solution
Ship a community-validated workflow pattern as an official Claude Code feature.
A bundled /browse skill at ~/.claude/skills/browse/SKILL.md (or built-in) auto-triggers on web/browser language. Instead of letting main call browser MCPs directly, the skill instructs main to delegate to a general-purpose subagent named browser with worker rules baked into the spawn prompt. The worker does the browser work in isolated context, returns a short structured summary, and uses a documented handoff folder for visual escalation when stuck on UI ambiguity.
Concrete components Anthropic could ship:
- Bundled
/browseskill — auto-triggering, instructs delegation, includes tuned worker rules - Handoff folder convention — documented file names (
latest.png,ref.png,state.txt) for worker↔main visual communication - Worker rule defaults — live narration discipline (terse final reply, verbose live reasoning so the user can follow and interrupt), MCP choice heuristics (claude-in-chrome for auth, playwright for ad-hoc), escalation contract for ambiguous UI
- Optional bundled
browser-workersubagent — for users who prefer agent definition over skill orchestration
Alternative Solutions
- Custom subagent .md files — works but requires user setup and a Claude Code restart whenever the agent definition changes
- Ad-hoc
Agentspawns from main — works but rules need re-forwarding every spawn, easy to forget - Wait for #43057 / #52142 — those address definition-bloat at config level but do not solve per-call result bloat from the browser MCPs
Priority
Medium — would significantly expand what users can do without burning through their context window on routine web work, and the pattern is already proven via existing primitives.
Feature Category
Skills / subagent orchestration
Use Case Example
User asks: "log into google.com and change my profile pic"
Without delegation: main calls 10–20 browser tools, each returning 5–30K tokens of page state. By task completion, main context is at 60–80% of window full of raw HTML, before any follow-up conversation.
With this pattern: main spawns the browser subagent. User watches the worker's reasoning live in the UI as it logs in, navigates, picks the right element. Worker reports back something like "Done. Profile pic updated." in ~150 tokens. Main context preserved for actual conversation.
Real measurements from a quick test (visiting xgrippro.com, reporting headline / CTA / price / one observation):
- ~31K tokens consumed inside the worker
- ~450 tokens returned to main
- ~70× per-task savings; observed up to ~175× on simpler tasks
Additional Context
This pattern is functional today using only existing primitives (skills + Agent tool + Read/Write for the handoff folder). Bundling it as official would:
- Avoid every user reinventing the same setup
- Codify a recommended pattern instead of leaving it as folklore
- Complement #43057 / #52142 — together those layers solve both definition-bloat (config) and result-bloat (workflow)
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗