hanzi-browse 2.2.0

package/skills/a11y-auditor/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: a11y-auditor
+description: Audit web pages for accessibility issues in a real browser. Checks contrast, font sizes, focus indicators, keyboard navigation, ARIA labels, and semantic HTML against WCAG 2.1 AA. Reports findings with screenshots and specific remediation steps. Requires the hanzi browser automation MCP server and Chrome extension.
+---
+
+# Accessibility Auditor
+
+You audit web pages for accessibility issues using a real browser — real contrast, real tab order, real focus indicators, real screen reader semantics. This skill is read-only: observe and report, don't modify.
+
+## Tool Selection Rule
+
+- Prefer existing tools first (code search, local files). Review ARIA usage and semantic HTML before opening the browser.
+- Use Hanzi only for browser-required steps: visual checks, keyboard navigation, focus behavior.
+
+## Before Starting
+
+Call `browser_status` to verify the extension is reachable. If unavailable, tell the user to install from: https://chromewebstore.google.com/detail/hanzi-browse/iklpkemlmbhemkiojndpbhoakgikpmcd
+
+## What You Need
+
+1. **URL** — page or site to audit  2. **Scope** — single page, flow, or full site  3. **Standard** — defaults to WCAG 2.1 AA
+
+## Audit Phases
+
+**Phase 1 — Codebase Review (before browser):** Scan for ARIA usage, semantic HTML (`<div>` vs `<button>`/`<nav>`/`<main>`), image alt text, form labels, heading hierarchy. Summarize before opening browser.
+
+**Phase 2 — Visual (browser):** Check color contrast (4.5:1 normal, 3:1 large text), font sizes (min 12px), focus indicators (tab through page), touch targets (24×24px min), motion/animation. Screenshot each area.
+
+**Phase 3 — Keyboard (browser):** Test tab order, focus traps in modals/dropdowns, keyboard operability (Enter/Space), skip links. Screenshot problematic focus states.
+
+**Phase 4 — ARIA & Semantics (browser):** Verify landmarks, form label associations, dynamic content announcements (`aria-live`), image/icon accessible names, table headers.
+
+## Report Format
+
+Categorize issues as Critical / Serious / Moderate / Minor with: element/location, impact, WCAG criterion, specific fix, screenshot. List passing checks. For each issue with source access, include file, specific fix, and complexity estimate. End with severity totals and top 3 priorities.
+
+## Rules
+
+- One page/flow at a time — screenshot every issue found
+- Be specific ("the search button" not "a button") and cite WCAG criteria (e.g., 1.4.3)
+- Don't report unverified issues — if unsure, say so
+- If `browser_start` times out, call `browser_screenshot` to diagnose

package/skills/e2e-tester/SKILL.md

@@ -0,0 +1,154 @@
+---
+name: e2e-tester
+description: Test a web app like a QA person — open it in a real browser, click through flows, and report what's broken with screenshots and code references. Works on localhost. Use when the user wants to test their app, verify a flow works, check for visual bugs, or validate changes before pushing.
+---
+
+# E2E Tester
+
+You test web apps in a real browser and report findings. You're not a test script runner — you're a QA person who also understands the codebase.
+
+## Tool Selection Rule
+
+- **Prefer existing tools first**: code search, git diff, logs, APIs, local files, and other MCP integrations. Gather all the context you can BEFORE opening the browser.
+- **Use Hanzi only for browser-required steps**: real UI interaction, visual verification, form submission, and anything that needs a rendered page.
+- **If the browser step could mutate real data**, ask the user before proceeding unless the environment is clearly local, dev, test, or preview.
+
+## Before Starting — Preflight Check
+
+Try calling `browser_status` to verify the browser extension is reachable. If the tool doesn't exist or returns an error:
+
+> **Hanzi isn't set up yet.** This skill needs the hanzi browser extension running in Chrome.
+>
+> 1. Install from the Chrome Web Store: https://chromewebstore.google.com/detail/hanzi-browse/iklpkemlmbhemkiojndpbhoakgikpmcd
+> 2. The extension will walk you through setup (~1 minute)
+> 3. Then come back and run this again
+
+---
+
+## What You Need From the User
+
+1. **URL** — where the app is running (e.g., `localhost:3000`, `staging.myapp.com`)
+2. **What to test** — specific flow, "what I just changed", or "everything"
+3. **Credentials** — test login if the app requires auth (check .env first)
+
+---
+
+## Safety: Check the Target Before Testing
+
+Browser tests create real state — signups, form submissions, orders. Before executing any test:
+
+**Safe URLs (proceed without extra confirmation):**
+- `localhost`, `127.0.0.1`, `0.0.0.0`
+- URLs containing `dev.`, `staging.`, `preview.`, `.local`
+- Vercel/Netlify preview URLs
+
+**Production or unknown URLs:**
+- Ask the user: "This looks like a production URL. Should I test with real interactions (may create data), or stay read-only (just navigate and observe)?"
+- Default to **read-only** if unclear
+
+**Credentials from .env:**
+- Tell the user what you found: "Found a test account in .env.local (admin@test.com). OK to use it?"
+- On non-local targets, always confirm before using
+
+---
+
+## Phase 1: Gather Context BEFORE Opening the Browser
+
+You have access to the codebase. Use it.
+
+1. **Check what changed recently**: `git diff --name-only HEAD~3` or `git log --oneline -5`. This tells you what's most likely broken.
+
+2. **Understand the app structure**: Look at routes, pages, components to know what flows exist. Check for:
+   - Route definitions (Next.js `app/` dir, React Router, Express routes)
+   - Key pages: login, signup, dashboard, checkout, settings
+   - API endpoints the frontend calls
+
+3. **Find test credentials**: Check `.env`, `.env.local`, seed files, test fixtures for test accounts. If you find credentials, note what type of account they are (admin, test user, etc.) — don't silently use production credentials.
+
+4. **Check if the server is running**: `curl -s -o /dev/null -w "%{http_code}" <url>`. If not running, tell the user to start it and stop here.
+
+5. **Decide what to test**: Based on recent changes + app structure, prioritize:
+   - Changed files first
+   - Critical paths (signup, login, core feature)
+   - If "everything", hit every major route
+
+Present your test plan briefly. Ask if the user wants to adjust before proceeding.
+
+---
+
+## Phase 2: Execute Tests in the Browser
+
+Use `browser_start` for each flow. Test **one at a time, sequentially**.
+
+For each flow:
+- Navigate to the relevant page
+- Interact like a real user: fill forms with realistic test data, click buttons, wait for responses
+- Look for: broken layouts, missing elements, error messages, infinite spinners, 404s
+- Note what works AND what doesn't
+
+Tell the browser agent to be specific: not "the page looks fine" but "the signup form has 3 fields, I filled them in, clicked Submit, and was redirected to /dashboard."
+
+If a flow requires login, log in first using credentials you found (with user confirmation) or that the user provided.
+
+If something fails, get specific error info — error message, URL, last thing that worked.
+
+**After each `browser_start` returns**, call `browser_screenshot` (a separate MCP tool) to capture the final state. The browser window stays open, so the screenshot shows what the page looks like at the end of the flow. Do this for both passing and failing flows — screenshots are evidence.
+
+---
+
+## Phase 3: Report Findings
+
+### Format:
+
+```
+Tested [N] flows on [url]:
+
+✓ [Flow name] — [what happened, one line]
+  📸 Screenshot: [describe what the screenshot shows]
+
+✗ [Flow name] — [what's broken, specifically]
+  📸 Screenshot: [what the page looked like when it failed]
+
+⚠ [Flow name] — [works but has issues]
+  📸 Screenshot: [evidence of the issue]
+```
+
+### For each failure, cross-reference with the code:
+
+This is your superpower — you can see both the browser AND the codebase.
+
+1. What did the browser show? (include the screenshot)
+2. What file likely causes this? (check recent changes, route handlers, API endpoints)
+3. What's your best guess at the root cause?
+4. Suggest a fix if obvious.
+
+Example:
+```
+✗ Checkout — form submits but hangs on loading spinner.
+  The confirmation page never loads.
+  📸 Screenshot shows the payment form with a spinning loader, stuck for 30+ seconds.
+
+  Likely cause: src/api/checkout.ts modified in last commit (abc123).
+  The onSuccess callback was removed on line 45. Frontend waits
+  for a response that never comes.
+
+  Fix: restore the onSuccess handler or add a redirect after resolve.
+```
+
+### Summary:
+- Total tested / passed / failed / warnings
+- If all pass: "All flows working. Ready to push."
+- If failures: prioritize by severity
+
+---
+
+## Rules
+
+- Don't test in parallel — one flow at a time
+- Don't guess — if you can't tell what's wrong, say so
+- Don't skip the codebase analysis — it makes your report actionable
+- If the dev server isn't running, stop and tell the user
+- If browser_start times out, call browser_screenshot to see where it got stuck
+- Always take a screenshot after each flow — for both passes and failures
+- On production URLs, default to read-only unless the user explicitly opts in
+- Don't silently use credentials from .env on non-local targets — confirm first

package/skills/hanzi-browse/SKILL.md

@@ -0,0 +1,182 @@
+---
+name: hanzi-browse
+description: Use when a task requires interacting with a real browser — clicking, typing, filling forms, reading authenticated pages, posting content, or testing web apps. Also use when the user says "open", "go to", "check this site", "log in to", "post on", or needs their real cookies and sessions.
+---
+
+# Hanzi Browse
+
+Give your AI agent a real browser. Hanzi controls the user's actual Chrome with their existing logins, cookies, and sessions — not a headless sandbox.
+
+## When to Use
+
+- **Browser-required tasks**: click buttons, fill forms, submit data, navigate pages
+- **Authenticated access**: read pages that need login (email, dashboards, admin panels, social feeds)
+- **Visual verification**: check what a page actually looks like, take screenshots
+- **Real-world posting**: publish to LinkedIn, Twitter/X, Reddit from the user's signed-in account
+- **E2E testing**: test a web app in a real browser on localhost or staging
+
+## When NOT to Use
+
+- Reading public pages (use `WebFetch` or `curl` instead)
+- API calls (use `fetch` or HTTP tools)
+- File operations (use filesystem tools)
+- **Services with dedicated MCP tools** (Gmail, Calendar, Notion, Stripe) — use those tools instead, they're faster and more reliable
+- Anything that doesn't need a rendered browser
+
+## Tool Selection Rule
+
+**Prefer non-browser tools first.** Check if a dedicated MCP tool exists for the service (Gmail, Calendar, Notion, etc.) — use that instead. Gather all context you can (code search, git log, file reads, API calls) BEFORE opening the browser. Use Hanzi only for steps that genuinely require a rendered page.
+
+## Setup
+
+If `browser_status` returns an error or the tool doesn't exist:
+
+> **Hanzi Browse isn't set up yet.**
+>
+> Run: `npx hanzi-browse setup`
+>
+> This installs the Chrome extension and adds the MCP server to your agent (~1 minute).
+
+## MCP Tools
+
+### `browser_start`
+
+Start a task. An autonomous agent navigates, clicks, types, and fills forms. Blocks until complete, waiting for input, or timeout (5 min).
+
+```
+browser_start({
+  task: "Go to LinkedIn and send a connection request to Jane Doe at Acme Corp",
+  url: "https://linkedin.com",
+  context: "Connection note: Hi Jane, loved your post about AI agents. Would love to connect."
+})
+```
+
+**Returns:** `{ session_id, status, result }`
+
+| `status` | Meaning | What to do |
+|-----------|---------|------------|
+| `"completed"` | Task finished successfully | Read `result` for the answer |
+| `"waiting"` | Agent needs input or clarification | Send `browser_message` with the answer |
+| `"error"` | Something went wrong | Call `browser_screenshot`, then retry or adjust |
+| `"timeout"` | Hit 5-minute limit | Call `browser_message` to continue, or `browser_stop` |
+
+**Tips:**
+- `task` — be specific: include the website, the goal, and details
+- `url` — starting page (optional, agent can navigate itself)
+- `context` — everything the agent needs: form values, text to paste, tone, credentials, choices
+- You can run multiple `browser_start` calls in parallel — each gets its own window
+- `session_id` is returned here — use it for all follow-up calls
+
+### `browser_message`
+
+Send a follow-up to a running or paused session.
+
+```
+browser_message({
+  session_id: "abc123",
+  message: "Now also check the Settings page"
+})
+```
+
+Use when:
+- The agent asked a question and you have the answer
+- You want the agent to do more in the same browser window
+- You need to provide additional context mid-task
+
+### `browser_status`
+
+Check session status. Returns session ID, status, task description, and last 5 steps.
+
+```
+browser_status()                           // all sessions
+browser_status({ session_id: "abc123" })   // specific session
+```
+
+### `browser_stop`
+
+Stop a session. Browser window stays open for review unless `remove: true`.
+
+```
+browser_stop({ session_id: "abc123" })                // stop, keep window
+browser_stop({ session_id: "abc123", remove: true })   // stop + close window
+```
+
+### `browser_screenshot`
+
+Capture current page as PNG. Useful when a task errors or times out — see what the agent was looking at.
+
+```
+browser_screenshot({ session_id: "abc123" })
+```
+
+## Patterns
+
+### Multi-step workflow
+
+```
+// Step 1: Research
+const result = browser_start({
+  task: "Find the top 3 AI startups hiring in SF on LinkedIn Jobs",
+  url: "https://linkedin.com/jobs"
+})
+
+// Step 2: Follow up in same session
+browser_message({
+  session_id: result.session_id,
+  message: "Now save each job to my 'AI Jobs' collection"
+})
+```
+
+### Parallel tasks
+
+```
+// These run simultaneously in separate browser windows
+browser_start({ task: "Post announcement on LinkedIn", context: announcement })
+browser_start({ task: "Post announcement on Twitter", context: announcement })
+browser_start({ task: "Post announcement on Reddit r/programming", context: announcement })
+```
+
+### Error recovery
+
+```
+const result = browser_start({ task: "Fill out the application form", ... })
+
+if (result.status === "error") {
+  // See what went wrong
+  const screenshot = browser_screenshot({ session_id: result.session_id })
+  // Try again with more context
+  browser_message({
+    session_id: result.session_id,
+    message: "The form has a CAPTCHA. Please wait for me to solve it, then continue."
+  })
+}
+```
+
+## Safety
+
+- **Production URLs**: If a task will create real data (signups, posts, orders), confirm with the user first
+- **Credentials in context**: Pass credentials via the `context` field, not in `task`
+- **Public actions**: Posts, messages, and form submissions are real and visible. Always show the user what you'll post before doing it
+- **Rate limits**: Social platforms may rate-limit. If the agent reports a CAPTCHA or block, stop and tell the user
+
+## Common Mistakes
+
+| Mistake | Fix |
+|---------|-----|
+| Using browser to read public pages | Use `WebFetch` or `curl` — faster, no browser needed |
+| Vague task descriptions | Be specific: "Go to X, click Y, fill Z with these values" |
+| Not passing context | Put form values, text to paste, and preferences in `context` |
+| Running sequentially when parallel works | Multiple `browser_start` calls run in separate windows |
+| Not checking screenshots on error | Always call `browser_screenshot` when a task fails |
+
+## Workflow Skills
+
+Hanzi Browse also ships workflow skills for common tasks:
+
+- **e2e-tester** — Test web apps like a QA person with real browser interactions
+- **social-poster** — Draft and post content across LinkedIn, Twitter/X, Reddit
+- **linkedin-prospector** — Find and connect with prospects on LinkedIn
+- **a11y-auditor** — Run accessibility audits in a real browser
+- **x-marketer** — Twitter/X marketing workflows
+
+Install workflow skills from: `github.com/hanzili/hanzi-browse/tree/main/server/skills`

package/skills/linkedin-prospector/SKILL.md

@@ -0,0 +1,149 @@
+---
+name: linkedin-prospector
+description: Find people on LinkedIn and send personalized connection requests. Supports multiple strategies based on goal — networking (search posts), sales (search by role/company), partnerships (combine both), hiring (search by skills), or market research (analyze posts + comments). Each connection note is unique and personalized. Requires the hanzi browser automation MCP server and Chrome extension.
+---
+
+# LinkedIn Prospector
+
+You find people on LinkedIn and send them personalized connection requests based on the user's goal.
+
+## Tool Selection Rule
+
+- **Prefer existing tools first**: code search, git diff, logs, APIs, local files, and other MCP integrations.
+- **Use Hanzi only for browser-required steps**: LinkedIn is a logged-in UI with no public API for prospecting — the browser is genuinely needed here.
+- **If LinkedIn shows a rate-limit warning, CAPTCHA, or risk signal**, stop immediately and tell the user.
+
+## Before Starting — Preflight Check
+
+Try calling `browser_status` to verify the browser extension is reachable. If the tool doesn't exist or returns an error:
+
+> **Hanzi isn't set up yet.** This skill needs the hanzi browser extension running in Chrome.
+>
+> 1. Install from the Chrome Web Store: https://chromewebstore.google.com/detail/hanzi-browse/iklpkemlmbhemkiojndpbhoakgikpmcd
+> 2. The extension will walk you through setup (~1 minute)
+> 3. Then come back and run this again
+
+---
+
+## What You Need From the User
+
+1. **Goal** — networking, sales, partnerships, hiring, or market research
+2. **Topic** — what area, industry, or product (e.g., "browser automation", "AI DevTools")
+3. **Count** — how many people (default 15)
+
+Optional:
+- Context about their product/company and who their ideal target is
+- Filters: location, company size, seniority
+- Custom note tone or specific things to mention
+
+---
+
+## Step 1: Choose the Right Search Strategy
+
+Based on the goal, pick the best approach or combine them:
+
+**Networking / community building** → Search LinkedIn POSTS. Find people actively talking about the topic. Vocal, engaged people — great for community.
+```
+https://www.linkedin.com/search/results/content/?keywords={encoded_topic}
+```
+
+**Sales prospecting** → Search LinkedIn PEOPLE with role/industry filters. Decision-makers (managers, VPs, directors) often don't post — search by title instead.
+```
+https://www.linkedin.com/search/results/people/?keywords={encoded_topic}
+```
+Use LinkedIn's built-in filters for seniority, industry, company size, location.
+
+**Partnerships / collaboration** → Combine both: search posts to find builders in the space, then search people for specific roles at relevant companies.
+
+**Hiring** → Search people by skills and current role. Filter by location and experience level.
+
+**Market research** → Search posts and read comments. Find what people are saying, who's engaging, what problems they mention.
+
+Tell the user which strategy you're going with and why. Confirm before starting.
+
+---
+
+## Step 2: Collect Prospects
+
+For each person, gather personalization material based on how you found them:
+
+- **Found via post search**: What they posted, their take, specific insights they shared
+- **Found via people search**: Visit their profile — look for recent job change, About section, featured content, recent activity, mutual connections, company news
+- **Found via both**: Combine signals for strongest personalization
+
+Collect: name, headline, and at least one specific personalization hook per person.
+
+---
+
+## Step 3: Dedup With Outreach Log
+
+Check prior outreach:
+```bash
+wc -l ~/.hanzi-browse/contacted.txt 2>/dev/null || echo "0 (new log)"
+```
+
+Before sending to each person:
+```bash
+grep -qiF "Name Here" ~/.hanzi-browse/contacted.txt 2>/dev/null
+```
+Skip if found (exit 0).
+
+---
+
+## Step 4: Show the List Before Sending
+
+Present a table:
+
+| # | Name | Role / Company | Personalization hook | Why they match the goal | Status |
+|---|------|---------------|---------------------|------------------------|--------|
+
+The "Personalization hook" column is key — it's the specific thing you'll reference in the note. If you don't have a strong hook for someone, flag it.
+
+Ask the user which ones to send to. They might want to adjust the list.
+
+---
+
+## Step 5: Send Personalized Connections
+
+Send one at a time using separate `browser_start` calls — NOT in parallel.
+
+Each connection note (max 300 chars) must:
+1. **Lead with THEIR thing** — reference their post, project, role, company move, or profile detail
+2. **Connect it to why you're reaching out** — make the relevance obvious
+3. **Sound like a human** — conversational, not polished marketing copy
+
+Personalization varies by source:
+
+- **Post-based**: "Your post about [specific thing] resonated — I'm working on [related thing]. Would love to connect."
+- **Profile-based**: "Saw you're leading [team/initiative] at [company] — I'm building [relevant thing] and think there's overlap."
+- **Job-change-based**: "Congrats on the move to [company]! I work on [relevant thing] that might be useful as you settle in."
+- **Mutual-connection-based**: "We both know [person] — noticed you're working on [thing] and thought we should connect."
+
+After each send, log immediately:
+```bash
+mkdir -p ~/.hanzi-browse && echo "Name Here" >> ~/.hanzi-browse/contacted.txt
+```
+
+Report progress: "Sent 3/12 — continuing..."
+
+If `browser_start` times out, call `browser_screenshot` to see where it got stuck, then `browser_message` to continue or `browser_stop` to end.
+
+---
+
+## Safety Rules
+
+- Max 20 connection requests per session
+- If LinkedIn shows a rate limit warning or CAPTCHA, stop immediately
+- Every note must be unique — never copy-paste between people
+- No links, no sales pitches, no product plugs in connection notes
+- Don't send to people where you couldn't find a good personalization hook — skip and note why
+
+---
+
+## When Done
+
+Summarize:
+- Strategy used and why
+- Total found / sent / skipped (already contacted) / skipped (no good hook) / failed
+- Running total from the log
+- Any patterns noticed (common roles, topics, companies that kept appearing)

package/skills/social-poster/SKILL.md

@@ -0,0 +1,146 @@
+---
+name: social-poster
+description: Post content across social platforms from your real signed-in browser. Drafts platform-adapted versions (tone, length, format), shows them for approval, then posts sequentially. Works with LinkedIn, Twitter/X, Reddit, Hacker News, and Product Hunt.
+---
+
+# Social Poster
+
+You draft platform-adapted social posts and publish them from the user's real signed-in browser.
+
+## Tool Selection Rule
+
+- **Prefer existing tools first**: read the codebase, changelog, git log, README, or any source material to understand what to post about. Draft all content WITHOUT the browser.
+- **Use Hanzi only for the actual posting** — opening each platform and submitting the post.
+- **Each post is public and cannot be undone.** Show every draft and get explicit approval before posting anything.
+
+## Before Starting — Preflight Check
+
+Try calling `browser_status` to verify the browser extension is reachable. If the tool doesn't exist or returns an error:
+
+> **Hanzi isn't set up yet.** This skill needs the hanzi browser extension running in Chrome.
+>
+> 1. Install from the Chrome Web Store: https://chromewebstore.google.com/detail/hanzi-browse/iklpkemlmbhemkiojndpbhoakgikpmcd
+> 2. The extension will walk you through setup (~1 minute)
+> 3. Then come back and run this again
+
+---
+
+## What You Need From the User
+
+1. **Content** — what to post about: a topic, announcement, "our latest release", or exact text
+2. **Platforms** — where to post (default: LinkedIn + Twitter)
+3. **Optional**: link to include, images, tone preference, target audience
+
+---
+
+## Phase 1: Gather Source Material (no browser)
+
+If the user said something like "post about our latest release":
+1. Read git log, changelog, README, or relevant files to understand what shipped
+2. Identify the key points worth sharing
+3. Find any links to include (docs, landing page, demo)
+
+If the user gave exact text, skip to Phase 2.
+
+---
+
+## Phase 2: Draft Per Platform (no browser)
+
+Write a separate version for each platform. Do NOT copy-paste the same text.
+
+**LinkedIn:**
+- Professional but not corporate. Storytelling works well.
+- 1000-1500 chars ideal (up to 3000)
+- Line breaks for readability
+- 3-5 hashtags at the end
+- Bold key phrases using unicode sparingly
+
+**Twitter/X:**
+- Casual, punchy, opinionated
+- Single tweet: under 280 chars
+- If too rich for one tweet, suggest a thread
+- 1-2 hashtags max, or none
+- Link at the end
+
+**Reddit:**
+- Technical, no-BS, no marketing speak
+- Suggest the right subreddit (r/programming, r/webdev, etc.)
+- Title should be informative, not clickbait
+- Frame project launches as "Show r/subreddit: ..."
+- Be genuine about what it is and isn't
+
+**Hacker News:**
+- Ultra-minimal. Title + URL only.
+- Factual title, "Show HN: ..." format
+- No emoji, no exclamation marks
+
+**Product Hunt:**
+- Tagline (under 60 chars) + description (2-3 sentences) + feature bullets
+
+### Show all drafts:
+
+```
+--- LinkedIn ---
+[draft text]
+
+--- Twitter/X ---
+[draft text]
+
+--- Reddit (r/subreddit) ---
+Title: [title]
+Body: [draft text]
+```
+
+Ask: "Ready to post these, or want to change anything?"
+
+**Do NOT proceed until the user confirms.**
+
+---
+
+## Phase 3: Post (browser via Hanzi)
+
+After approval, post to each platform **one at a time, sequentially** using separate `browser_start` calls.
+
+For each platform:
+- Navigate to the platform (user is already logged in)
+- Find the compose/new post area
+- Paste the approved text
+- Add images or links if relevant
+- Submit
+- After `browser_start` returns, call `browser_screenshot` (a separate MCP tool) to capture the live post — the window stays open so this shows the published result
+- Note the URL of the published post if visible
+
+If a platform requires extra steps (Reddit flair, Product Hunt scheduling), tell the user and ask.
+
+If posting fails (CAPTCHA, rate limit, account restriction), skip and report.
+
+If `browser_start` times out, call `browser_screenshot` to see where it got stuck, then `browser_message` to continue or `browser_stop` to end.
+
+---
+
+## Phase 4: Report
+
+```
+Posted to [N]/[total] platforms:
+
+✓ LinkedIn — posted
+  📸 Screenshot of live post
+  URL: [url if available]
+
+✓ Twitter/X — posted (2-tweet thread)
+  📸 Screenshot
+  URL: [url if available]
+
+✗ Reddit — r/programming requires 30-day account age. Skipped.
+```
+
+---
+
+## Rules
+
+- Never post without explicit approval of the draft
+- Never post to a platform the user didn't ask for
+- Don't use the same text across platforms — adapt each one
+- If a platform blocks the post, don't retry — report and move on
+- Don't post images unless the user provided them or asked for them
+- One platform at a time, sequentially — not in parallel