ak-chrome-profile

name	ak:chrome-profile
description	Target a real Google Chrome profile for browser automation through Chrome DevTools MCP. Provides the chrome-profile CLI, profile discovery, live DevTools probing guidance, setup playbooks, and URL-anchor tab selection.
user-invocable	true
when_to_use	Invoke when browser automation needs the user's real Chrome profile, cookies, account, or a deterministic profile target.
category	dev-tools
keywords	["chrome","browser","profile","mcp","devtools","automation","cookies"]
license	MIT
allowed-tools	["Bash(bash:*)","Bash(chrome-profile:*)","Bash(python3:*)","mcp__chrome-devtools__list_pages","mcp__chrome-devtools__select_page","mcp__chrome-devtools__take_snapshot","mcp__chrome-devtools__evaluate_script"]
metadata	{"author":"agentkit","version":"1.0.0","compatibility":"Requires Python 3.9+ and Google Chrome stable. Works on macOS, Linux, and Windows."}

Chrome Profile

Profile-aware browser automation path when the agent needs the user's real Chrome state: the right Google account, cookies, workspace, tenant, or logged-in product session.

This is not the default for ordinary browser testing. Use ak:agent-browser when a fresh or tool-managed browser is enough. Use project-native Playwright or ak:web-testing for repeatable CI tests. Use this skill when the user's actual Chrome profile state matters.

What This Skill Provides

• chrome-profile <key> <url> opens a URL in a configured Chrome profile.
• chrome-profile open --json <key> <url> emits machine-readable binding data for agents.
• Profile keys resolve by Google account email or display-name substring, not brittle Profile 17 directory names.
• chrome-profile doctor tells the agent and user whether the opened tab will be readable through a browser bridge.
• The opened URL gets #cdp-profile=<key>&cdp-open=<token> so the agent can bind to the exact tab from a flat MCP tab list.
• Setup playbooks cover both required layers: the browser bridge and Chrome profile mapping.

Agent Contract

When this skill is invoked, the agent must lead the user through setup if anything is missing. Do not just say "configure MCP." Run the checks, explain the failing layer, and give the next concrete command or browser action.

Do not treat chrome-profile doctor as the only source of truth. It is a static setup heuristic. Before telling the user that the browser bridge is unavailable, make one live probe through Chrome DevTools MCP if those tools are exposed by the current agent runtime.

Required readiness:

1. Profile mapping exists: chrome-profile list resolves the requested key.
2. Browser read path exists: a live Chrome DevTools MCP probe can list or read Chrome pages.
3. Runtime tab selection works: after opening, MCP page listing contains the exact cdp-open=<token> from the CLI output or JSON payload.

If the profile mapping fails, pause and guide chrome-profile setup. If the bridge check fails, run the live probe below before asking the user to change MCP setup, relaunch Chrome, or close active tabs.

If doctor reports chrome_devtools_mcp_auto_connect or chrome_devtools_mcp_runtime_probe_required, treat that as a configured bridge candidate and run the live MCP probe; open does not need --force for that state. Use only when the user explicitly wants a tab opened for themselves without agent read-back, or when a live MCP probe succeeds but this older or mismatched CLI still cannot classify the bridge.