Linear Browser Automation

Automate Linear.app workflows in the OpenClaw-managed browser profile using browser tool actions (open, navigate, snapshot, act). Use when users want UI-base...

Security Scan

The skill's instructions and requirements match its stated purpose (UI automation of Linear in the managed OpenClaw browser); it requests no extra credentials or installs and is internally consistent.

Purpose & Capability

The name/description (Linear UI automation) align with the SKILL.md: it uses the OpenClaw-managed browser profile, snapshots, tab reuse, and browser actions. There are no unrelated environment variables, binaries, or installs requested.

Instruction Scope

The instructions stay within the stated scope (open/reuse Linear tabs, snapshot DOM, click/type, verify). They require collecting required fields before acting and demand confirmations for create/move/destructive actions. One behavioral note: the skill will 'resume automatically' after the user completes an interactive login (it will continue the task in the same tab). Create-issue explicitly asks for a final 'Proceed? (yes/no)', while edit/move-state flows require unambiguous target resolution and confirmations but do not include an identical explicit final 'Proceed' prompt in every example — this means an automated continuation after login could execute actions once input is resolved. This is coherent with UI automation but worth reviewing if you want a final explicit consent for every action.

Install Mechanism

Instruction-only skill with no install spec and no code files; nothing is written to disk by the skill bundle. This is the lowest-risk install profile.

Credentials

No environment variables, credentials, or external endpoints are requested — appropriate for the described UI automation. However, the skill requires access to the managed browser profile ('openclaw') and will inspect open tabs and page DOMs. That implies it can read session state, cookies/DOM content, and open-tab URLs within that profile (which is expected for a browser-automation skill but is sensitive access).

Persistence & Privilege

The skill is not 'always: true' and does not request persistent/system-wide configuration changes. It uses autonomous invocation (default) which is normal; no elevated privileges or modifications to other skills are requested.

Assessment

This skill appears coherent for automating Linear via the OpenClaw-managed browser. Before installing or using it, consider: (1) it will operate inside the managed browser profile ('openclaw') and can inspect open tabs and page content — only install if you're comfortable the agent having that level of access; (2) it will navigate to Linear and can resume tasks automatically after you complete an interactive login — if you want an extra explicit 'final proceed' for edits/moves, test the flows and confirm the prompts behave as you expect; (3) test first on non-sensitive or test issues to verify the behavior, and keep an eye on any automated actions the agent takes after login; (4) there are no external downloads, no environment secrets requested, and nothing in the files points to hidden endpoints. If you need stricter consent controls, ask the developer to add an explicit final confirmation prompt to every action (not just create) and to log actions before executing them.

Automate Linear workflows through UI interactions in the OpenClaw-managed browser.

Execution mode

• Always use browser profile: openclaw
• Always run actions against host browser control
• Reuse an already-open, logged-in Linear tab in the managed browser whenever available.
• Do not open a new Linear tab if an existing authenticated Linear tab can be reused.
• Keep actions in one tab unless explicitly opening a new tab is required by user request.

Standard workflow

1. Ensure managed browser is running (profile="openclaw").
2. Check existing open tabs in managed browser and prefer a tab already on Linear.
3. If an existing Linear tab is found:
   • focus and reuse that tab
   • snapshot and detect auth state
4. If no Linear tab exists, open/navigate to https://linear.app/.
5. If on public landing page / unauthenticated state:
   • automatically navigate to /login
   • show a browser alert asking the user to log in to continue
   • wait for authenticated dashboard/workspace state
6. After login is complete and dashboard is visible, continue automatically from the same task context and same tab.
7. Resolve references from the snapshot.
8. Execute deterministic actions (click/type/select/press).
9. Re-snapshot and verify expected state before finishing.

Required-input policy (hard rule)

For all Linear actions, always collect and confirm required details in chat before executing.

1) Create issue

Required fields:

1. Team (or project context that implies team)
2. Title

Optional fields (prompt if missing): description, priority, assignee, labels, due date.

Before submission, always present a summary block and ask:

• Proceed? (yes/no)

Only proceed on explicit yes. Any other response (no/cancel/edit/silence) means do not submit.

2) Edit issue and comment on issue

Required fields:

1. Team name
2. Issue number/identifier (e.g., POW-123)

Hard rule:

• Do not run these automations when either team name or issue number is missing.
• If the user gives only title text or a partial reference, ask for the team name and issue number.
• Resolve and open the exact issue from the provided team + issue number before making changes.

3) Move issue state

Non-negotiable required fields:

1. Team name
2. Issue number/identifier (e.g., POW-123)
3. New state/status (e.g., Todo, In Progress, Done)
4. Comment text to add on the issue

Valid issue statuses (only these are accepted):

• Backlog
• Todo
• In Progress
• Done
• Canceled
• Duplicate

Hard rule:

• Do not run move-state automation when any one of these is missing.
• If state is not explicitly provided, ask for it and wait.
• If comment text is not explicitly provided, ask for it and wait.
• Reject any state value not in the valid-status list and ask user to pick one valid option.
• Do not infer or auto-pick a state unless user explicitly instructs you to choose one.
• Resolve the exact issue from team + issue number first, then apply the requested new state and add the comment.

Priority validation rule

For any automation that sets or updates issue priority, only accept these values:

• Urgent
• High
• Medium
• Low

Hard rule:

• Reject any other priority value and ask for one valid option.

Required-input conversation contract

When user requests a new issue:

1. Check whether required fields are already provided.
2. Ask only for missing required fields first.
3. Ask optional fields (or accept defaults).
4. Present final summary:
   • Team/Project
   • Title
   • Description
   • Priority
   • Assignee
   • Labels
   • Due date
5. Ask Proceed? (yes/no).
6. Submit only after yes.

When user requests edit/comment:

1. Check for team name and issue number first.
2. Ask for whichever is missing.
3. Confirm target in one line (e.g., Target issue: POW-123 (Powerhouse)).
4. Execute only after target resolution is unambiguous.

When user requests move-state:

1. Check for team name, issue number, explicit new state, and comment text.
2. Ask for whichever is missing.
3. Confirm target, destination, and comment in one line (e.g., Target issue: POW-123 (Powerhouse) → In Progress | Comment: <text>).
4. Execute only after target resolution, new state, and comment are unambiguous.

Safety + reliability rules

• Prefer stable selectors/refs from fresh snapshot before acting.
• Re-snapshot after major UI transitions.
• If unauthenticated state appears, auto-navigate to login and trigger an in-browser alert instructing the user to log in.
• After user login completes and dashboard is detected, resume the task automatically.
• For destructive actions (delete/archive), require explicit confirmation.
• If team/project context is ambiguous, ask before acting.

Supported automations

• Open Linear and verify dashboard loaded
• Search/filter issues (team, assignee, state, label)
• Create new issue (with required-input policy)
• Edit issue fields (title, description, priority, due date, labels)
• Move issue state (Backlog/In Progress/Done)
• Add comments
• Bulk triage (limited batch with confirmation)
• Visual verification (post-action snapshot checks)

Example test prompts (one per supported automation)

Use these prompts verbatim (or with your own team/issue values) to test each supported automation.

1) Open Linear and verify dashboard loaded

"Using the linear-browser-automation skill in the OpenClaw-managed browser, open Linear and verify the workspace dashboard is loaded for team <team_name>. Return the current page URL, visible workspace/team name, and whether auth is active."

2) Search/filter issues

"Using the linear-browser-automation skill in the OpenClaw-managed browser, list issues for team <team_name> filtered by assignee <assignee_name>, state <state_name>, and label <label_name>. Return issue identifier, title, state, assignee, labels, due date, and URL. If no issues match, say No matching issues found."

3) Create new issue

"Using the linear-browser-automation skill in the OpenClaw-managed browser, create a new issue in team <team_name> with title <issue_title>. Set priority <priority_name>, assignee <assignee_name>, label <label_name>, and due date <due_date_yyyy-mm-dd>. Show a summary and ask Proceed? (yes/no) before submitting."

4) Edit issue fields

"Using the linear-browser-automation skill in the OpenClaw-managed browser, edit issue <issue_number> in team <team_name>. Update title to <updated_issue_title>, set priority to <priority_name>, set due date to <due_date_yyyy-mm-dd>, and ensure label <label_name> is applied. Return issue identifier, updated title, state, priority, assignee, labels, due date, and URL."

5) Move issue state

"Using the linear-browser-automation skill in the OpenClaw-managed browser, move issue <issue_number> in team <team_name> to state <new_state> and add this comment: <comment_text>. Return issue identifier, title, previous state, new state, assignee, labels, due date, comment posted, and URL."

6) Add comments

"Using the linear-browser-automation skill in the OpenClaw-managed browser, add this comment to issue <issue_number> in team <team_name>: <comment_text>. Return issue identifier, title, assignee, current state, comment text posted, and URL."

7) Bulk triage

"Using the linear-browser-automation skill in the OpenClaw-managed browser, triage up to <max_items> issues in team <team_name> where state is <source_state> and assignee is empty. For each selected issue, set priority to <priority_name> and add label <label_name>. Show the candidate list first, ask for confirmation, then apply updates and return the changed issues with before/after fields."

8) Visual verification

"Using the linear-browser-automation skill in the OpenClaw-managed browser, open issue <issue_number> in team <team_name> and perform visual verification only (no edits). Return what is visible for title, state, priority, assignee, labels, due date, and URL, and explicitly state whether each verification check passed or failed."

Suggested command patterns (agent-side)

Open Linear in managed profile

• start browser (profile="openclaw")
• open https://linear.app/

Reuse existing tab

• navigate current targetId to target URL

Interaction cycle

• snapshot (refs=aria preferred)
• act (click/type/select/press)
• snapshot and verify

Failure handling

• Missing element/ref:
  • refresh snapshot
  • retry once with updated refs
• Navigation/login interruption:
  • pause and ask user to complete auth/MFA
• Ambiguous target:
  • ask for disambiguation (team/project/issue)
• Missing required issue fields:
  • keep prompting until provided or user cancels
• No explicit yes on submit confirmation:
  • do not submit

Completion report format

Return:

• actions performed
• items changed (issue IDs/titles if visible)
• verification checks passed/failed
• any manual follow-up needed