# Paperzilla Monitor > Discuss and triage papers from one Paperzilla project and produce weekday research briefs. Use when users want recent papers, metadata, markdown-based summaries, why a paper matters for current work, feed triage in chat, or a recurring weekday brief. - Skill: `paperzilla-ai/paperzilla-monitor` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add paperzilla-ai/paperzilla-monitor` - Raw SKILL.md: https://api.skillmd.com/api/skills/paperzilla-ai/paperzilla-monitor/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Docs & Writing - License: MIT - Author: paperzilla-ai (https://skillmd.com/u/paperzilla-ai) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/paperzilla-ai/paperzilla-monitor --- # Paperzilla research briefs Use this skill when the user wants one of these two workflows: - `on_demand_discussion`: discuss the latest papers from one Paperzilla project, inspect one paper, fetch markdown, summarize it, explain why it matters for "our work", and continue the discussion - `weekday_brief`: produce one concise weekday research brief for one Paperzilla project This is a workflow skill built on top of the same Paperzilla access layer as the core `paperzilla` skill. It should feel opinionated and repeatable. ## What this skill needs - One Paperzilla project - One short sentence for "our work" if that context is not already known If either is missing, ask once and then reuse it for the rest of the workflow. Examples: - `Project: Agents evaluation` - `Our work: we build evaluation infrastructure for coding agents.` ## Transport rules Follow the transport required by the current profile. ### CLI profiles Use the Paperzilla CLI (`pz`). Core commands: ```bash pz project list pz project pz feed --limit 20 --json pz rec --json pz rec --markdown pz paper --json pz paper --markdown pz paper --project pz feedback upvote pz feedback star pz feedback downvote --reason not_relevant pz feedback downvote --reason low_quality pz feedback clear ``` Use `--json` whenever you need structured feed or metadata parsing. Keep the Paperzilla object model straight: - `pz paper ` = canonical paper - `pz rec ` = recommendation inside one project - `pz feedback ...` = project-specific feedback on that recommendation When an item comes from `pz feed --json`, prefer `pz rec` and `pz feedback` over `pz paper`. CLI markdown behavior differs by command: - `pz rec --markdown` can queue markdown generation and prints a friendly retry message when it is still being prepared - `pz paper --markdown` only returns markdown when it is already ready ### MCP profiles Use the Paperzilla MCP tools directly. Core tools: - `projects_list` - `projects_get` - `feed_get` - `paper_get` - `paper_markdown` Preferred sequence: 1. `projects_list` when the project is missing or ambiguous 2. `projects_get` to confirm project identity when needed 3. `feed_get` to pull the latest feed items 4. `paper_get` for one paper's metadata 5. `paper_markdown` for markdown-backed analysis Handle `paper_markdown` statuses correctly: - `ready`: use the markdown - `queued`: tell the user it is still being prepared and suggest retrying shortly - `unavailable`: report that markdown is not currently available ## Shared behavior rules - Treat Paperzilla relevance and ranking as a strong prior, not the final answer. - Use Paperzilla terms exactly: `project`, `feed`, `Must Read`, `Related`. - Name the exact paper or recommendation identifier you used when you inspect one paper. - Separate metadata from interpretation. - Explain relevance in terms of the user's actual work, not generic importance. - Do not dump full markdown unless the user explicitly asks for it. - Do not switch to arXiv HTML/abs links as the default fallback when the request was specifically for Paperzilla markdown. ## Mode 1: on-demand discussion Use this mode when the user wants an interactive paper conversation in chat. ### Workflow 1. Resolve the project and the "our work" context. 2. Pull the latest papers from that project's feed. 3. Show a short list of the newest or strongest candidates. 4. When the user picks one paper, return metadata first. 5. Fetch markdown for that paper or recommendation. 6. Summarize: - contribution - method - results - limits - why it matters for our work 7. Continue the discussion and make a recommendation such as: - read now - keep as Related - ignore this week ### Output contract For the first feed reply, include: - project name - the papers you checked - per paper: title, date, source, and whether it looks `Must Read` or `Related` For the metadata reply, include: - title - authors - publication date - source - URL - the exact Paperzilla paper ID or project-paper ID used For the markdown reply, include: - contribution - method - results - limits - why it matters for our work ## Mode 2: weekday brief Use this mode when the user wants one concise recurring brief for one project. ### Workflow 1. Resolve the project and the "our work" context. 2. Load the per-project history of papers already proposed in earlier weekday briefs. 3. Pull the newest papers from the feed. 4. Exclude papers that were already proposed in earlier weekday briefs unless the user explicitly asked to revisit them. 5. Select the remaining papers worth mentioning. 6. For each selected paper, give: - one short summary - one sentence on why it is relevant to our work 7. After drafting or sending the brief, append the exact Paperzilla IDs used for the selected papers to that project's proposed-paper history. 8. If no new papers qualify, say that explicitly. ### Output contract Every weekday brief should include: - project name - date - how many new papers were checked - for each selected paper: - title - one short summary - one sentence on why it is relevant to our work - a clear `No new papers today.` line when nothing new qualifies Keep the brief concise and easy to scan. For recurring runs, the agent must keep a persistent per-project record of the exact Paperzilla IDs already proposed in earlier briefs. Do not propose the same paper again in a later recurring brief unless the user explicitly asked to revisit it. ## Edge cases - **No project given:** ask once, then continue. - **No "our work" context:** ask once for one short sentence, then reuse it. - **No prior brief history:** treat the run as the first brief for that project, initialize an empty proposed-paper history, and persist the papers selected this time. - **No new papers:** report that clearly instead of padding the brief. - **Large feed:** use a sensible limit first, then expand only if needed. - **Markdown delay:** retry more than once when the user explicitly asked for markdown. Prefer a short polling loop over an immediate fallback. - **Ambiguous paper ID:** fall back to the full UUID or clearly restate the paper you selected. - **Canonical vs recommendation confusion:** if an ID came from `pz feed --json`, assume it is a recommendation ID unless shown otherwise. ## Agent-specific rules Read and follow any packaged `AGENT.md` file for the current profile. The profile file defines the chat surface, delivery surface, and scheduling behavior.