# Marker Sync

> Keep Marker.io and your issue tracker (GitHub, Linear, Jira) in sync. Use when asked to pull new Marker.io issues into a tracker, enrich tracker tickets with Marker context, mark issues resolved or ready-to-test in both places, or reconcile status mismatches between Marker.io and the tracker.

- **Type:** Skill
- **Install:** `agentstack add skill-marker-io-mcp-skills-marker-sync`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [marker-io](https://agentstack.voostack.com/s/marker-io)
- **Installs:** 0
- **Category:** [Developer Tools](https://agentstack.voostack.com/c/developer-tools)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [marker-io](https://github.com/marker-io)
- **Source:** https://github.com/marker-io/mcp-skills/tree/main/claude/skills/marker-sync
- **Website:** https://marker.io

## Install

```sh
agentstack add skill-marker-io-mcp-skills-marker-sync
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# marker-sync

Keep Marker.io and an external tracker (GitHub Issues, Linear, Jira) consistent: full diagnostic
context flows into the tracker, resolution flows back to Marker. Eliminates the "closed in the tracker,
still open in Marker.io" mismatch.

## When to use

"Pull new marker issues into <tracker>", "enrich these tickets with marker context", "mark the done
ones ready to test in github and resolved in marker", "are marker and linear out of sync".

## Prerequisites

A connected tracker. Use whatever the user has: GitHub via the `gh` CLI, Linear via `mcp__linear__*`,
Jira via its MCP/CLI. If none is connected, say so and stop.

## Matching issues across systems

Match a Marker.io issue to its tracker item by, in order: an explicit Marker link/ID in the tracker
item, the issue URL, then a close title match. When unsure, list the candidate pairs and ask.

## Steps

1. Pull new/updated Marker.io issues (`issues_list`, recent window). Pull the corresponding tracker
   items in one pass.
2. Enrich thin tracker items: for any tracker ticket missing diagnostic context, add the Marker
   screenshot link, console errors, failing network requests, and browser/OS from `issue_get_context`
   (plus drill-downs). Propose the edit before writing to the tracker.
3. Reconcile status both ways. Build a table of every pair and its two statuses. Flag mismatches
   (resolved on one side, open on the other).
4. On close: when a fix has landed, set the tracker state (e.g. "Ready to Test") and the Marker.io
   status to its resolved equivalent (`issue_update_status`, discovered via `project_get`), and
   document the root cause + fix as a comment on both sides (`comment_create` on Marker).

## Gating

Every write (tracker edits, Marker status changes, comments) is proposed as a table first and applied
only after confirmation. Never close an issue on one side without updating the other.

## Operating rules

This skill drives the Marker.io MCP. Read tools: `projects_list`, `project_get`, `project_list_users`,
`list_issue_types`, `issues_list`, `issue_get`, `issue_get_context`, `issue_get_screenshot`,
`issue_get_attachments`, `issue_get_console_log`, `issue_get_network_request`. Write tools:
`issue_update_status`, `issue_update_assignee`, `issue_update_priority`, `issue_update_type`,
`comment_create`.

1. **Resolve the project first.** Call `projects_list` (filter with `searchText`). If more than one
   could match, show the candidates and ask which one. Never guess a `projectId`.
2. **Discover before you write.** Status and issue-type strings are project-specific. Call
   `list_issue_types` and `project_get` for valid values before any `issue_update_*`. Get user IDs
   from `project_list_users` before assigning or @mentioning.
3. **Read cheap, drill deep only when it matters.** Start from `issue_get_context` summaries; fetch a
   specific `issue_get_console_log(logIndex)` / `issue_get_network_request(requestIndex)` or
   `issue_get_screenshot` only when it changes a decision.
4. **Propose, then apply.** Before any write, print a table of the planned changes (issue, field,
   old to new). Apply via the `*_update_*` / `comment_create` tools only after the user confirms.
   Default comment visibility to `Member-only` unless the reporter should see it.
5. **Respect the limits.** `issues_list` does not return assignee (fetch per-issue via `issue_get`).
   The MCP cannot create Marker.io issues. Never embed tokens; rely on the configured MCP auth.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [marker-io](https://github.com/marker-io)
- **Source:** [marker-io/mcp-skills](https://github.com/marker-io/mcp-skills)
- **License:** MIT
- **Homepage:** https://marker.io

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-marker-io-mcp-skills-marker-sync
- Seller: https://agentstack.voostack.com/s/marker-io
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.