marker-bug-to-fix
Take a single Marker.io issue and turn it into a ready-to-review code change in the current repo.
Cuts the report-to-fix round-trip from a manual context hunt to a minimal diff in minutes.
When to use
The user points at one Marker.io issue and wants it fixed or root-caused in this codebase: "fix marker
issue <id>", "what's causing this bug", "investigate <marker link>". For triaging many issues at
once, use marker-triage.
Steps
- Load the issue:
issue_get (full) and issue_get_context (browser/OS/screen + console + network
summaries). Read the reporter's description and the page URL.
- Pull the evidence that localizes the bug:
issue_get_screenshot for the visual state, the failing
issue_get_console_log(logIndex) entries (stack traces), the failing/slow
issue_get_network_request(requestIndex) (status, payload, response), and issue_get_attachments
if any.
- Map signals to code: from the URL/route, error messages, stack frames, and failing endpoints, use
Grep/Glob/Read to find the responsible component, handler, or query in the working repo.
- State the root cause in one or two sentences. If you cannot localize it, say what extra info is
needed (and consider posting a gated
comment_create asking the reporter).
- Propose a minimal fix as a diff. Prefer the smallest change that addresses the root cause. Show it
for review before changing files.
- Verify with the project's own tooling: hand off to the
/verify skill, or run the relevant test,
to confirm the fix behaves.
- Open the PR via the
/pr skill.
Marker writes (gated)
Propose, then apply after confirmation:
- Set the issue to an in-progress status (
issue_update_status, using a status discovered via
project_get).
- Post a root-cause + fix summary as a
comment_create (link the PR). Keep it Member-only unless the
reporter should see it.
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.
- 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.
- 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.
- 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.
- 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.
- 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.
1---2name: marker-bug-to-fix3description: Take one Marker.io bug report and produce a ready-to-review code fix. Use when asked to fix, investigate, reproduce, or find the root cause of a specific Marker.io issue in the current repository. Pulls the issue's screenshot, console errors, network requests and DOM, locates the cause in code, proposes a minimal diff, and drafts a PR.4---56# marker-bug-to-fix78Take a single Marker.io issue and turn it into a ready-to-review code change in the current repo.9Cuts the report-to-fix round-trip from a manual context hunt to a minimal diff in minutes.1011## When to use1213The user points at one Marker.io issue and wants it fixed or root-caused in this codebase: "fix marker14issue <id>", "what's causing this bug", "investigate <marker link>". For triaging many issues at15once, use `marker-triage`.1617## Steps18191. Load the issue: `issue_get` (full) and `issue_get_context` (browser/OS/screen + console + network20 summaries). Read the reporter's description and the page URL.212. Pull the evidence that localizes the bug: `issue_get_screenshot` for the visual state, the failing22 `issue_get_console_log(logIndex)` entries (stack traces), the failing/slow23 `issue_get_network_request(requestIndex)` (status, payload, response), and `issue_get_attachments`24 if any.253. Map signals to code: from the URL/route, error messages, stack frames, and failing endpoints, use26 Grep/Glob/Read to find the responsible component, handler, or query in the working repo.274. State the root cause in one or two sentences. If you cannot localize it, say what extra info is28 needed (and consider posting a gated `comment_create` asking the reporter).295. Propose a minimal fix as a diff. Prefer the smallest change that addresses the root cause. Show it30 for review before changing files.316. Verify with the project's own tooling: hand off to the `/verify` skill, or run the relevant test,32 to confirm the fix behaves.337. Open the PR via the `/pr` skill.3435## Marker writes (gated)3637Propose, then apply after confirmation:3839- Set the issue to an in-progress status (`issue_update_status`, using a status discovered via40 `project_get`).41- Post a root-cause + fix summary as a `comment_create` (link the PR). Keep it `Member-only` unless the42 reporter should see it.4344## Operating rules4546This skill drives the Marker.io MCP. Read tools: `projects_list`, `project_get`, `project_list_users`,47`list_issue_types`, `issues_list`, `issue_get`, `issue_get_context`, `issue_get_screenshot`,48`issue_get_attachments`, `issue_get_console_log`, `issue_get_network_request`. Write tools:49`issue_update_status`, `issue_update_assignee`, `issue_update_priority`, `issue_update_type`,50`comment_create`.51521. **Resolve the project first.** Call `projects_list` (filter with `searchText`). If more than one53 could match, show the candidates and ask which one. Never guess a `projectId`.542. **Discover before you write.** Status and issue-type strings are project-specific. Call55 `list_issue_types` and `project_get` for valid values before any `issue_update_*`. Get user IDs56 from `project_list_users` before assigning or @mentioning.573. **Read cheap, drill deep only when it matters.** Start from `issue_get_context` summaries; fetch a58 specific `issue_get_console_log(logIndex)` / `issue_get_network_request(requestIndex)` or59 `issue_get_screenshot` only when it changes a decision.604. **Propose, then apply.** Before any write, print a table of the planned changes (issue, field,61 old to new). Apply via the `*_update_*` / `comment_create` tools only after the user confirms.62 Default comment visibility to `Member-only` unless the reporter should see it.635. **Respect the limits.** `issues_list` does not return assignee (fetch per-issue via `issue_get`).64 The MCP cannot create Marker.io issues. Never embed tokens; rely on the configured MCP auth.
marker-io