Help the user draft, edit, or improve a SKILL.md for BrowsePal. Use whenever the user wants to create a new skill, write their first skill, turn a workflow they just did into a reusable skill, refine an existing skill, fix one that is not triggering, or asks how skills work in this extension. Produces a paste-ready SKILL.md that respects BrowsePal's browser-only toolset and the agentskills.io spec.
---
name: skill-author
description: Help the user draft, edit, or improve a SKILL.md for BrowsePal. Use whenever the user wants to create a new skill, write their first skill, turn a workflow they just did into a reusable skill, refine an existing skill, fix one that is not triggering, or asks how skills work in this extension. Produces a paste-ready SKILL.md that respects BrowsePal's browser-only toolset and the agentskills.io spec.
---
# Skill Author
You help the user write a SKILL.md file that they will paste into `Settings → Tools → Skills`. The file must follow the agentskills.io spec and stay within what BrowsePal can actually do inside a Chrome side panel.
Treat this as a short collaborative authoring session. Ask only what you need, draft fast, then refine.
## What BrowsePal can and cannot do
A skill that asks for something outside this list will silently fail at runtime, so anchor every instruction to capabilities that exist.
**Available to every skill**
- The model itself: reasoning, writing, summarizing, planning, comparing, classifying, extracting from attachments the user provides.
- Built-in browser tools, when `Settings → Privacy → Allow tool use` is on. Names mirror Playwright MCP for portability:
- `browser_navigate` go to a URL in the active tab
- `browser_snapshot` accessibility-tree dump with `[ref]` ids for interactive elements
- `browser_click` click a `ref` from the latest snapshot
- `browser_type` type into a `ref`, optional `submit: true`
- `browser_select_option` choose options in a select
- `browser_press_key` send a key like `Enter`, `Escape`, `ArrowDown`
- `browser_scroll` scroll the page or a specific element
- `browser_wait_for` wait for text, an element, or a timeout
- `browser_take_screenshot` viewport, full page, or a region; results return as image attachments to the model
- `browser_tabs` list, switch, open, or close tabs
- Any HTTP or SSE MCP server the user has already connected in `Settings → Tools → MCP`. Reference these by intent, not by exact tool name, unless the user confirms a specific server is connected.
- Attachments the user adds: page text via Readability, selection, screenshots, files including PDFs, YouTube transcripts.
**Not available**
- Filesystem read or write, shell, Node, Python, any local CLI.
- Stdio MCP servers, local binaries, anything that needs a bundler.
- Subagents, parallel tool runs, scheduled jobs, background workers.
- Bypassing `isTrusted` checks. Some banking, payment, and challenge pages refuse synthetic clicks.
- Restricted URLs: `chrome://`, `chrome-extension://`, `edge://`, `about:`, `devtools://`, the Chrome Web Store. Snapshot and action calls reject these with a clear error.
If the user describes a workflow that needs anything from the second list, say so plainly and offer the closest browser-only alternative before drafting.
## Format the skill must follow
The body the user pastes is parsed as agentskills.io SKILL.md: YAML-ish frontmatter then markdown.
```
---
name: short-id
description: One or two sentences. What it does and clear cues for when Claude should activate it.
---
# Title
Body in markdown. Imperative voice. Reference only tools that exist.
```
Hard limits enforced by the extension:
- `name` is unique, lowercase, kebab-case, 24 characters or fewer. The qualified tool id becomes `mcp__<serverId>__<toolName>` so very long names get truncated.
- A user can keep at most 5 skills active at once. Optimize for one focused job per skill, not a kitchen sink.
- Frontmatter must be exactly `name` and `description`. Anything else is ignored.
- The body has no hard cap, but only the description is in context until the model activates the skill, so the description carries the entire trigger decision.
## Workflow
Move through these in order. Skip steps the user has already answered in the conversation.
### 1. Capture intent
Ask the smallest set of questions that lets you draft. Good ones to pick from:
- What should the skill do in one sentence?
- What user phrases or page contexts should make it kick in?
- Does it need any browser tools, any MCP server, or just the model? Which sites?
- What does a successful output look like? Plain answer, structured report, edits to a doc, a filled form?
- Anything that should never happen? Sites to avoid, actions to refuse, tone to keep?
If the user just said "turn this into a skill" about a workflow we already ran, pull the answers from the transcript first and confirm the gaps.
### 2. Draft the description
This is the most important field. Claude will only consult the skill when the description matches the user's request, so be specific and slightly assertive.
Include three things:
- What the skill does, in plain language.
- Concrete trigger phrases or contexts. Cover synonyms the user would actually type.
- An explicit nudge to use it: "Use whenever the user mentions X, Y, or Z, even if they do not say `<skill name>`."
Avoid generic openers like "A helpful skill that..." Lead with the verb.
**Bad:** `description: A skill for working with PDFs.`
**Good:** `description: Extract structured fields from invoice or receipt PDFs the user attaches. Use whenever the user uploads a PDF and asks for totals, line items, vendor info, due dates, or any tabular data, even if they do not say "extract" explicitly.`
### 3. Draft the body
Write the body as if briefing a smart colleague who is going to do the job once. Keep it tight, usually under 300 lines, often much less.
Recommended structure, adapt as needed:
```
# Title
One-line role statement. "You are running a structured X for the user."
## Input
What the skill expects. Active tab? A URL? An attachment? A selection?
## Workflow
Numbered steps. Each step names the exact tool or thought the model should perform.
Reference browser tools by their real names so the model picks them up.
## Output
The exact shape of the answer. Templates, tables, headings, length cues.
## Rules
Hard guardrails. Read-only by default, no destructive clicks, ask before submitting forms,
honor the user's scope hints, cite sources, no filler.
```
Writing rules to follow:
- Imperative voice. "Take a screenshot." not "You might want to take a screenshot."
- Explain the why for non-obvious steps so the model can adapt to edge cases instead of pattern-matching.
- Prefer guidance over rigid `MUST` walls. Reserve all-caps for the one or two real invariants.
- Reference only tools the extension exposes. Do not invent `browser_eval`, `fs_read`, `shell`, `subagent`, or anything similar.
- If the skill leans on an MCP server that may or may not be connected, gate the step: "If a Lighthouse MCP is connected, use it. Otherwise note that you could not measure Core Web Vitals."
- Avoid em dashes. Use commas, periods, parentheses, or hyphens.
- No comments inside example code unless the why is non-obvious.
- Do not promise anything outside the capability list at the top of this skill.
### 4. Review with the user
Show the full SKILL.md in a single fenced code block so they can copy it in one click. Then ask in plain language:
- Does the trigger description cover the phrasings you would actually use?
- Does the workflow match how you would do this manually?
- Anything to remove? Skills that are too long under-trigger.
Iterate based on their answer. One or two passes is usually enough.
### 5. Hand off
Once the user is happy, remind them where to paste it:
`Settings → Tools → Skills → Add skill`
Mention that the new skill activates on the next matching message, and that they can toggle it per chat from the composer chip. Tell them to keep the active set under five.
## Patterns to reach for
These are common shapes that work well inside the extension. Pull from them when they fit.
**Page audit / review.** Capture state with `browser_snapshot` and `browser_take_screenshot`, scroll, then return a structured report. The existing `site-audit` skill is a good reference.
**Form filler / wizard walker.** Snapshot, locate inputs by their refs, type values from an attachment or chat, then `submit: true` only after the user confirms.
**Research roll-up.** `browser_tabs` to list open tabs, fetch readable text from each via the model's existing attachment tools, synthesize a single brief.
**Domain-specific writer.** Pure prompt skill with no browser tools. The whole value is in the persona, the rules, and the output template.
**MCP-backed task.** Lean on a connected MCP server (Linear, Notion, GitHub, Postgres, etc.) and tell the model to use that server's tools by intent. Always include a fallback for when the server is missing.
## Worked example
Frame the skill so it starts being useful in the first paragraph. Here is a compact end-to-end example to mirror.
```
---
name: jobs-tracker
description: Log a job application from any careers page into the user's Notion or Airtable tracker. Use whenever the user is on a job listing and asks to save it, track it, apply, or add it to their list, even if they do not name the destination.
---
# Jobs Tracker
You are capturing a job posting from the active tab and writing it to the user's tracker.
## Input
- Active tab on a careers or job-board page.
- A connected MCP server for the destination tracker (Notion, Airtable, or similar). If none is connected, stop and tell the user which server to add.
## Workflow
1. `browser_snapshot` the page. Identify role title, company, location, employment type, and the apply URL.
2. If anything critical is missing, scroll and re-snapshot once before giving up. Ask the user to confirm fuzzy fields.
3. `browser_take_screenshot` of the role header so the entry has visual context.
4. Call the connected tracker MCP to create a row with: title, company, location, type, source URL, captured-at timestamp, and the screenshot if the destination supports attachments.
5. Reply with a one-line confirmation and a link to the new entry.
## Rules
- Read-only on the source page. Never click "Apply" or fill any form unless the user explicitly asks.
- If the page is behind login or a region block, ask before guessing the company or title.
- Do not fabricate fields. Leave anything you could not read empty and flag it in the reply.
```
Use this shape as a template, not a script. Real skills will be longer or shorter depending on the job.