القائمة
Interactive browser automation via playwright-cli. Use when you need to navigate a site, click elements, fill forms, take snapshots, or triage a live app.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | craft:browser |
| description | Interactive browser automation via playwright-cli. Use when you need to navigate a site, click elements, fill forms, take snapshots, or triage a live app. |
| when_to_use | Triggers: user says 'open browser', 'check this site', 'triage the app', 'test this flow', 'look at this page', or '/craft:browser'. Also when needing visual inspection of a running app, before/after screenshots of UI changes, or interactive site exploration. |
| allowed-tools | ["Read","Bash","Glob","Grep","Agent","SendMessage"] |
Interactive browser automation powered by playwright-cli. Launches a persistent playwright-browser agent that owns a live browser session. You steer it via SendMessage - the agent remembers what it's seen and done across turns.
Chrome DevTools MCP works but has limitations: no persistent agent session between tool calls, no interactive steering, and full accessibility trees streamed into context (~114k tokens per task). playwright-cli saves snapshots to disk as YAML (~27k tokens per task, ~4x cheaper) and supports named sessions that persist across agent turns.
This skill is purely additive. It does not replace or modify Chrome DevTools MCP, the walkthrough-analyzer, or any existing analyzer agent.
Requires playwright-cli installed globally:
npm install -g @playwright/cli && playwright-cli install-browser
The skill checks prerequisites at every invocation and fails with copy-pasteable instructions if missing.
command -v playwright-cli >/dev/null 2>&1 || { echo "PREREQ_MISSING: playwright-cli. Run: npm install -g @playwright/cli && playwright-cli install-browser"; exit 2; }
If the check fails, report the error with the install command. Do not proceed.
Arguments follow this pattern:
/craft:browser <url> [goal] [--headless] [--session=name]
CRITICAL: Session names must be <= 12 characters, lowercase alphanumeric only. macOS has a 104-char Unix socket path limit. Long names cause silent socket lookup failures, which spawn duplicate browsers instead of erroring.
Auto-derive a short session name:
# Simple counter-based naming
SESSION="craft$(date +%H%M)"
If --session=name was provided explicitly, use that (after validating length <= 12).
DO NOT derive session names from story/cycle slugs. Those are too long and contain dashes. Use short, opaque names.
Check for and kill any existing craft sessions before launching:
playwright-cli list 2>/dev/null
If sessions are listed that match a craft* pattern, close them:
playwright-cli kill-all 2>/dev/null
Only run kill-all if stale sessions are detected. For a clean state, this is a no-op.
Invoke the playwright-browser agent with full context. The agent handles browser open, navigation, and initial snapshot internally.
Agent({
subagent_type: "craft:playwright-browser",
description: "Browser session: {url}",
prompt: "SESSION: {session_name}
URL: {url}
GOAL: {goal or 'Interactive exploration - wait for instructions'}
HEADED: {true unless --headless}
Open the browser with the URL in a single command, check the console, and report what you see. Then wait for instructions unless a specific goal was provided."
})
IMPORTANT: Use subagent_type: "craft:playwright-browser" (with the craft: prefix).
The agent returns its agentId. Report this to the user so they know they can continue the session.
When the agent returns from its first pass:
playwright-cli -s=$SESSION open --headed $URLplaywright-cli -s=$SESSION close before exiting--headless only when explicitly requested.open called exactly once. The agent opens the browser once with the URL. Never re-opens on failure - checks list first.Adhoc workflow for small targeted changes to existing behavior or appearance, without the full story ceremony. Use when the orchestrator encounters a bug with a clear root cause and surgical solution, OR a small enhancement to something already built (a different icon, wording, spacing, color). Triggers on: 'fix this', 'this is broken', 'the alignment is off', 'that button doesn't work', 'quick fix', 'patch this', 'tweak this', 'change the icon', 'adjust the wording', post-story corrections, or any situation where the write gate blocks a small targeted change. Acts NOW - deferred work belongs in the notebook. Do NOT use for new features, design exploration, or changes requiring creative spark.
This skill should be used when the user asks to "plan chunks", "break this down", "plan the implementation", or when a story has status planning and needs implementation details before building. Required before any story can be implemented. Transforms story sparks into detailed chunk-by-chunk implementation plans with full technical specifics, file lists, and risk analysis. Supports parallel planning of multiple stories via batch mode.
This skill should be used when the user asks to "brainstorm", "explore options", "get creative", "what if we...", or selects "Let's get creative" during story or cycle creation. Also appropriate when the user describes a vague feature idea without clear direction. Generates 2-3 creative options with trade-offs, visual direction for UI stories, and wireframes.
Use this skill when the user wants to discover, define, or refine their product's aesthetic identity. Triggers on "what should this feel like?", "help me figure out the vibe", "something feels off visually", "I want it to feel like [X]", "define the visual language", or when a project has no established design direction. This is the art director skill - it helps users articulate something they can feel but can't name. Also handles quick cohesion checks when the orchestrator needs one during cycle planning.
This skill should be used when the user says "lock it", "go with that", "approved", "that's the standard", or explicitly establishes a project-wide pattern like "from now on all forms should use this approach". Formalizes approved decisions into locked standards that the system enforces going forward. Not needed for story-scoped decisions — only for project-wide patterns.
This skill should be used when validate-chunk reports errors or failures, when the user asks to "fix these errors", "resolve validation issues", "refine this chunk", or when specific build, lint, or type errors need surgical fixes. Makes precise, targeted edits to resolve specific validation issues without over-engineering.