Linear

Overview

This skill provides a structured workflow for managing issues, projects & team workflows in Linear. It ensures consistent integration with the Linear MCP server, which offers natural-language project management for issues, projects, documentation, and team collaboration.

Prerequisites

• Linear MCP server must be connected and accessible via OAuth
• Confirm access to the relevant Linear workspace, teams, and projects

Required Workflow

Follow these steps in order. Do not skip steps.

Step 0: Set up Linear MCP (if not already configured)

If any MCP call fails because Linear MCP is not connected, pause and set it up:

1. Add the Linear MCP:
   • codex mcp add linear --url https://mcp.linear.app/mcp
2. Enable remote MCP client:
   • Set [features] rmcp_client = true in config.toml or run codex --enable rmcp_client
3. Log in with OAuth:
   • codex mcp login linear

After successful login, the user will have to restart codex. You should finish your answer and tell them so when they try again they can continue with Step 1.

Windows/WSL note: If you see connection errors on Windows, try configuring the Linear MCP to run via WSL:

{"mcpServers": {"linear": {"command": "wsl", "args": ["npx", "-y", "mcp-remote", "https://mcp.linear.app/sse", "--transport", "sse-only"]}}}

Step 1

Clarify the user's goal and scope (e.g., issue triage, sprint planning, documentation audit, workload balance). Confirm team/project, priority, labels, cycle, and due dates as needed.

Step 2

Select the appropriate workflow (see Practical Workflows below) and identify the Linear MCP tools you will need. Confirm required identifiers (issue ID, project ID, team key) before calling tools.

Step 3

Execute Linear MCP tool calls in logical batches:

• Read first (list/get/search) to build context.
• Create or update next (issues, projects, labels, comments) with all required fields.
• For bulk operations, explain the grouping logic before applying changes.

Step 4

Summarize results, call out remaining gaps or blockers, and propose next actions (additional issues, label changes, assignments, or follow-up comments).

Available Tools

Issue Management: list_issues, get_issue, create_issue, update_issue, list_my_issues, list_issue_statuses, list_issue_labels, create_issue_label

Project & Team: list_projects, get_project, create_project, update_project, list_teams, get_team, list_users

Documentation & Collaboration: list_documents, get_document, search_documentation, list_comments, create_comment, list_cycles

Practical Workflows

• Sprint Planning: Review open issues for a target team, pick top items by priority, and create a new cycle (e.g., "Q1 Performance Sprint") with assignments.
• Bug Triage: List critical/high-priority bugs, rank by user impact, and move the top items to "In Progress."
• Documentation Audit: Search documentation (e.g., API auth), then open labeled "documentation" issues for gaps or outdated sections with detailed fixes.
• Team Workload Balance: Group active issues by assignee, flag anyone with high load, and suggest or apply redistributions.
• Release Planning: Create a project (e.g., "v2.0 Release") with milestones (feature freeze, beta, docs, launch) and generate issues with estimates.
• Cross-Project Dependencies: Find all "blocked" issues, identify blockers, and create linked issues if missing.
• Automated Status Updates: Find your issues with stale updates and add status comments based on current state/blockers.
• Smart Labeling: Analyze unlabeled issues, suggest/apply labels, and create missing label categories.
• Sprint Retrospectives: Generate a report for the last completed cycle, note completed vs. pushed work, and open discussion issues for patterns.

Tips for Maximum Productivity

• Batch operations for related changes; consider smart templates for recurring issue structures.
• Use natural queries when possible ("Show me what John is working on this week").
• Leverage context: reference prior issues in new requests.
• Break large updates into smaller batches to avoid rate limits; cache or reuse filters when listing frequently.

Troubleshooting

• Authentication: Clear browser cookies, re-run OAuth, verify workspace permissions, ensure API access is enabled.
• Tool Calling Errors: Confirm the model supports multiple tool calls, provide all required fields, and split complex requests.
• Missing Data: Refresh token, verify workspace access, check for archived projects, and confirm correct team selection.
• Performance: Remember Linear API rate limits; batch bulk operations, use specific filters, or cache frequent queries.

ClawSweeper

ClawSweeper lives at ~/Projects/clawsweeper. It is the one OpenClaw maintenance bot for sweeping, commit review, repair jobs, and guarded fix PRs. Use this skill whenever Peter asks about reports, findings, dispatch health, repair/cloud PR creation, comment commands, automerge, permissions, or gates.

Start

cd ~/Projects/clawsweeper
git status --short --branch
git pull --ff-only
pnpm run build:all

Do not overwrite unrelated edits. If the tree is dirty, inspect first and keep read-only report work read-only unless Peter asked to commit.

One Bot, One App

Use the ClawSweeper repo and the clawsweeper GitHub App. Use only CLAWSWEEPER_* configuration for this automation. Do not use legacy apps, variables, labels, or skills.

Required app setup:

• CLAWSWEEPER_APP_CLIENT_ID: public app client ID for clawsweeper.
• CLAWSWEEPER_APP_PRIVATE_KEY: private key used only inside actions/create-github-app-token steps.
• Target app permissions: read target scan context; write issues and pull requests; contents write for report commits, repair branches, and workflow inputs; Actions write on openclaw/clawsweeper for comment-router re-review dispatch, workflow dispatch, run cancellation, and self-heal; optional Checks write for commit Check Runs.

Token boundary:

• Codex workers do not get mutation credentials.
• Review workers run with stripped secret/token env.
• Deterministic scripts own comments, labels, branch pushes, PR creation, closes, and merges through short-lived GitHub App tokens.
• Merge and write gates default closed.

Commit Reports

Canonical commit reports:

records/<repo-slug>/commits/<40-char-sha>.md

Use the lister:

pnpm commit-reports -- --since 6h
pnpm commit-reports -- --since "24 hours ago" --findings
pnpm commit-reports -- --since 7d --non-clean
pnpm commit-reports -- --repo openclaw/openclaw --author steipete --since 7d
pnpm commit-reports -- --since 24h --json

Results: nothing_found, findings, inconclusive, failed, skipped_non_code. One report per SHA; reruns overwrite the SHA-named report.

Manual rerun/backfill:

gh workflow run commit-review.yml --repo openclaw/clawsweeper \
  -f target_repo=openclaw/openclaw \
  -f commit_sha=<end-sha> \
  -f before_sha=<start-or-parent-sha> \
  -f create_checks=false \
  -f enabled=true

Use create_checks=true only when Peter explicitly wants target commit Check Runs. Add -f additional_prompt="..." for focused one-off review instructions.

Sweep Reports

Issue/PR reports live at:

records/<repo-slug>/items/<number>.md
records/<repo-slug>/closed/<number>.md

Lead with counts, concrete findings, and report links. Do not post unsolicited GitHub comments from report-reading work. Public surfaces are markdown reports, durable ClawSweeper review comments, and optional checks.

PR reports include Codex /review-style reviewFindings with priority, confidence, repository-relative file, and line range. Public PR comments show a short Review findings: list when findings exist; full review comments, evidence links, likely owners, and runtime details stay inside the collapsed Review details block.

Useful commands:

pnpm run status
pnpm run audit
pnpm run reconcile
pnpm run apply-decisions -- --dry-run

Create One Repair Job

Create a job from issue/PR refs and a maintainer prompt:

pnpm run repair:create-job -- \
  --repo openclaw/openclaw \
  --refs 123,456 \
  --prompt-file /tmp/clawsweeper-prompt.md

Create from an existing ClawSweeper report:

pnpm run repair:create-job -- \
  --from-report ../clawsweeper/records/openclaw-openclaw/items/123.md

The job creator checks for an existing open PR, body match, or remote clawsweeper/<cluster-id> branch before writing another job. Use --dry-run to inspect. Use --force only after deciding the duplicate guard is stale.

Validate, commit, then dispatch:

pnpm run repair:validate-job -- jobs/openclaw/inbox/clawsweeper-openclaw-openclaw-123.md
pnpm run repair:dispatch -- jobs/openclaw/inbox/clawsweeper-openclaw-openclaw-123.md \
  --mode autonomous \
  --runner blacksmith-4vcpu-ubuntu-2404 \
  --execution-runner blacksmith-16vcpu-ubuntu-2404 \
  --model gpt-5.5

Do not dispatch a just-created job before the job file is committed and pushed; the workflow reads the job path from GitHub.

Replacement PRs

For a useful but uneditable/stale/unsafe source PR, make the maintainer prompt explicit:

Treat #123 as useful source work. If the source branch cannot be safely updated
because it is uneditable, stale, draft-only, unmergeable, or unsafe, create a
narrow ClawSweeper replacement PR instead of waiting. Preserve the source PR
author as co-author, credit the source PR in the replacement PR body, and close
only that source PR after the replacement PR is opened.

The worker should emit repair_strategy=replace_uneditable_branch and list the source PR URL in source_prs. The deterministic executor opens or updates clawsweeper/<cluster-id>, adds non-bot source authors as Co-authored-by trailers, and closes superseded source PRs only after replacement exists.

Gates

Open execution windows intentionally and close them after the run:

gh variable set CLAWSWEEPER_ALLOW_EXECUTE --repo openclaw/clawsweeper --body 1
gh variable set CLAWSWEEPER_ALLOW_FIX_PR --repo openclaw/clawsweeper --body 1
gh variable set CLAWSWEEPER_ALLOW_MERGE --repo openclaw/clawsweeper --body 1
gh variable set CLAWSWEEPER_ALLOW_AUTOMERGE --repo openclaw/clawsweeper --body 1

Reset gates only when Peter asks; the active maintainer window may intentionally leave them at 1.

Important gates:

• CLAWSWEEPER_ALLOW_EXECUTE: allows deterministic write lanes.
• CLAWSWEEPER_ALLOW_FIX_PR: allows branch repair/replacement PRs.
• CLAWSWEEPER_ALLOW_MERGE: allows merge-capable applicators.
• CLAWSWEEPER_ALLOW_AUTOMERGE: allows comment-router automerge.
• CLAWSWEEPER_COMMENT_ROUTER_EXECUTE: lets scheduled comment routing post replies and dispatch repair.

Maintainer Mentions

Prefer @clawsweeper comments for all maintainer-facing control. Slash commands still parse as compatibility aliases, but examples and live guidance should use mentions.

@clawsweeper status
@clawsweeper re-review
@clawsweeper review
@clawsweeper fix ci
@clawsweeper address review
@clawsweeper rebase
@clawsweeper autofix
@clawsweeper automerge
@clawsweeper approve
@clawsweeper explain
@clawsweeper stop
@clawsweeper <question or safe action request>
@clawsweeper[bot] re-review
@openclaw-clawsweeper fix ci
@openclaw-clawsweeper[bot] fix ci

Accepted aliases: review, re-review, rereview, review again, rerun review, and run review. review and re-review dispatch a fresh ClawSweeper issue/PR review without starting repair. fix ci, address review, and rebase dispatch the repair worker only for ClawSweeper PRs or PRs opted into clawsweeper:autofix or clawsweeper:automerge. autofix runs the bounded review/fix loop without merging. automerge runs the bounded review/fix/merge loop, but draft PRs stay fix-only until GitHub marks them ready for review.

Freeform maintainer mentions such as @clawsweeper why did automerge stop? or @clawsweeper: can you explain this failure? dispatch a read-only assist review with the mention text as one-off instructions. The answer lands in the next public ClawSweeper review comment. Action-looking prose does not directly mutate GitHub; it must map to existing structured recommendations and pass the normal deterministic gates.

Default accepted maintainers: OWNER, MEMBER, COLLABORATOR; fallback repository permission accepts admin, maintain, or write. Contributor comments are ignored without a reply.

Run router manually:

pnpm run repair:comment-router -- --repo openclaw/openclaw --lookback-minutes 180
pnpm run repair:comment-router -- --repo openclaw/openclaw --execute --wait-for-capacity

Scheduled routing stays dry unless CLAWSWEEPER_COMMENT_ROUTER_EXECUTE=1.

Trusted Autofix And Automerge

@clawsweeper autofix opts an existing PR into the bounded review/fix loop. @clawsweeper automerge opts an existing PR into the bounded review/fix/merge loop. The router:

• verifies maintainer authorization;
• labels the PR clawsweeper:autofix or clawsweeper:automerge;
• dispatches ClawSweeper review for the current head SHA;
• creates or reuses a durable adopted job;
• repairs at most the configured caps;
• never merges autofix PRs or draft PRs;
• merges automerge PRs only when ClawSweeper passed the exact current head, checks are green, GitHub says mergeable, no human-review label is present, the PR is not draft, and both merge gates are open.

If ClawSweeper passes while merge gates are closed, it labels clawsweeper:merge-ready and comments instead of merging. @clawsweeper stop adds clawsweeper:human-review.

Repair caps:

CLAWSWEEPER_MAX_REPAIRS_PER_PR=10
CLAWSWEEPER_MAX_REPAIRS_PER_HEAD=1

Security Boundary

Do not stage security-sensitive work for ClawSweeper Repair. Route vulnerability reports, CVE/GHSA/advisory work, leaked secrets/tokens/keys, plaintext secret storage, SSRF, XSS, CSRF, RCE, auth bypass, privilege escalation, and sensitive data exposure to central OpenClaw security handling.

For adopted automerge jobs, trust deterministic ClawSweeper security markers, labels, and job frontmatter; do not infer security handling from vague prose.

Monitoring

Receiver workflows:

gh run list --repo openclaw/clawsweeper --workflow "ClawSweeper Commit Review" \
  --limit 12 --json databaseId,displayTitle,event,status,conclusion,createdAt,updatedAt,url
gh run list --repo openclaw/clawsweeper --workflow "repair cluster worker" \
  --limit 12 --json databaseId,displayTitle,event,status,conclusion,createdAt,updatedAt,url
gh run list --repo openclaw/clawsweeper --workflow "repair comment router" \
  --limit 12 --json databaseId,displayTitle,event,status,conclusion,createdAt,updatedAt,url

Target dispatcher:

gh run list --repo openclaw/openclaw --workflow "ClawSweeper Dispatch" \
  --event push --limit 8 --json databaseId,displayTitle,event,status,conclusion,headSha,url

Target commit check:

gh api "repos/openclaw/openclaw/commits/<sha>/check-runs?per_page=100" \
  --jq '.check_runs[] | select(.name=="ClawSweeper Commit Review") | [.status,.conclusion,.details_url] | @tsv'

Reading Output

For findings or failures, summarize:

• target repo, item/PR/commit, run, report path
• result, confidence, severity, and exact blocker
• affected files or cluster refs
• validation commands and whether they passed
• whether mutation gates were open or closed
• next deterministic action

Keep the broom small: one cluster, one branch, one PR, narrow proof, clear owner-visible evidence.