# Marker Client Report

> Turn a project's completed Marker.io work into a client-ready report. Use when asked to write a weekly or monthly recap for a client, summarize what was shipped or fixed this period, or produce a status update for a website project from Marker.io. Read-only: it reads issues and writes a markdown report, it does not change issues.

- Skill: `marker-io/marker-client-report` (Agent Skill)
- Install (CLI): `npx skillmds@latest add marker-io/marker-client-report`
- Raw SKILL.md: https://api.skillmd.com/api/skills/marker-io/marker-client-report/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: marker-io (https://skillmd.com/u/marker-io)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/marker-io/marker-client-report

---


# marker-client-report

Produce a polished, client-facing recap of what an agency completed on a website over a week or month,
straight from Marker.io — grouped by page, written in plain language, ready to paste into an email or
send as-is. Read-only.

## When to use

"Write the weekly report for <client>", "what did we ship for <project> this month", "monthly recap
for the <site> work", "client status update from Marker". For analyzing recurring patterns rather than
reporting a period's work, use `marker-insights`; for triaging the open backlog, use `marker-triage`.

## Inputs to confirm

- Which project (one client / site is usually one project; resolve per the operating rules).
- The window: default the last 7 days, or "last month" / last 30 days / an explicit date range.
- Whether to include sections beyond completed work: in-progress now, and newly reported this period.
  Default: completed only.

## Steps

1. Resolve the project and read `project_get` for its name and `websiteUrls` (the report header and the
   page mapping).
2. Decide which statuses count as **completed** — `Resolved` and `Closed` by default. Statuses are
   project-specific and can be renamed, so don't assume a customized board uses the English defaults:
   confirm which are in use by probing `issues_list` with each `status` value, and if it is unclear
   which statuses mean "done", show the candidates and ask.
3. Pull issues with `issues_list`, paginating `limit`/`offset` fully. Keep fields lean: `markerId`,
   `title`, `status`, `url`, `createdAt`, `updatedAt`. The MCP has no date filter, so window
   client-side: an item counts as **completed this period** when its status is one of the completed
   states and its `updatedAt` falls in the window.
4. Classify each completed item as a **content update** (typo, copy, wrong number or fact, image, link,
   layout) or a **fix** (functional bug). Marker does not expose an issue's type to read, so infer it
   from the title and page URL; open `issue_get` / `issue_get_screenshot` only when the title is too
   thin to describe in client terms.
5. Group by page (from the URL relative to `websiteUrls`), and within a page by content vs fix.
6. Write the report (see Output). Translate internal titles into client language: "Fix typo in intro
   paragraph" becomes "Corrected a typo in the Solutions page intro". Drop Marker jargon, statuses, and
   IDs from the client-facing copy.

## Output

A markdown report `client-report-<project>-<date>.md`:

- A one-line headline: "This week we completed 12 updates across 4 pages of <site>."
- **What we updated**, grouped by page, each item a plain-language sentence. Separate content updates
  from fixes when both are present.
- Optional **In progress** and **New this period** sections when requested.
- A short closing line inviting feedback.

Keep a separate internal copy (or a footnote) with the Marker links and issue codes for the agency's own
reference; keep the client-facing version clean.

## Honesty about the data

Completion is dated by `updatedAt` because the Marker.io MCP exposes no resolved-at timestamp and no date
filter. An older issue that was re-touched (a late comment, a status change) in the window can therefore
appear; skim the list before sending and drop anything that was not really completed this period.

This skill is read-only. It does not change any issue.

## 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.