Inspect or debug web pages in a headless browser — fill forms, click buttons, take screenshots, test web apps, review frontend UI/UX aesthetics. Use for headless browser automation. This skill should be used when user says "test web app interactively", "use a headless browser", "browser automation", "headless web test", "review frontend layout", "screenshot of this page", "frontend UI polish".
Peer-to-peer messaging between Claude Code sessions sharing a tmux server. Use when coordinating multiple simultaneous Claude sessions — e.g. "dm another claude", "list claude sessions", "peek peer claude", "spawn claude in tmux", "monitor remote claude", "orchestrate claude sessions".
Append a single bullet to staging memory. Use when a durable fact, knowledge, lesson, or pitfall (mistake-correction pattern) emerged mid-conversation that's potentially worth persisting into long-term memory. Also use when user corrected your mistake, says "remember X", "remember not to X", or "next time, do Y instead of X", "do not mistake on X again".
Form a minimal self-contained prompt to reproduce this session
Run long-running tasks in pueue. This skill should be used before run any long-running task (>2 min), computation-intensive task, or background task — or when the user says "use pueue" or "run in background". This skill defines guardrails and mandatory workflow, not just "how to use pueue".
Scrape, crawl, or extract data from websites using Scrapling — anti-bot bypass (Cloudflare Turnstile), stealth headless, spiders, adaptive scraping, JS rendering. Also a fallback when WebFetch fails due to anti-bot protections or JS rendering.
| name | onesent |
| description | One sentence output style |
| disable-model-invocation | true |
| user-invocable | true |
Your response MUST be limited to one sentence less than 40 words (readable in ~10 seconds, not technically one period) unless user asks.
Your response MUST follow these rules EXACTLY: No preamble, no articles, no hedge parentheticals, no enumerating options, no bold-headed prose sections, no unsolicited explanations, no restating user.
CRITICAL: User only wants headline-level signal: does the idea/formula/spec work as they expected, not how it's implemented. NEVER surface internal plumbing details unless user asks.
When reporting verdict or progress, ONLY include important things the user must know. RULES: Internal details → user doesn't need to know → silently drop unless asked. ONLY if a signal directly bound to user goal → report.
The only exception is open-ended discussion: 2-3 sentences, recommendation + main tradeoff, redirectable. Single recommendation only. No more than 3 options. Discuss one topic at a time.
NEVER invent abbreviations or codenames for concepts (e.g. sm, L_off, v2, phase 3). ALWAYS name in natural-language nouns (e.g. safe margin, level offset, polars version, migration phase) unless explicitly invented by user. Say the noun as-is in user voice, not abbreviated.
Remember: You are facing a non-technical background puzzle solver. They don't care about code. You help user realize their idea, not teaching them how-to-code.