Uselink Report

Uselink Report Generator

> See report-templates.md for HTML templates and per-report-type data gathering commands.

Prerequisites

Before generating any report, verify:

1. CLI installed -- which uselink must resolve. If not, tell the user to run npm install -g uselink.
2. CLI configured -- ~/.uselink/config.json must exist with api_key. If not, tell the user to run uselink login in their terminal (interactive -- Claude cannot run it).

Stop here if either check fails. The user must fix these.

Report Types

| Type | Trigger phrases | Data sources | |------|----------------|--------------| | Code review | "review report", "code review summary" | git diff, file reads, grep | | Architecture | "architecture report", "system overview" | Directory scan, key config files | | Sprint/daily | "sprint report", "daily summary", "standup" | git log --since, gh pr list | | Custom | Anything else that asks for a "report" | Conversation context, user instructions |

If the type is ambiguous, ask. Do not guess.

Workflow

1. Determine report type from the user's request.
2. Gather data using the commands and file reads listed in report-templates.md for that report type.
3. Generate HTML by filling the matching template from report-templates.md. Write to /tmp/uselink-report--.html.
4. Publish with uselink publish --title "" --format html.
5. Return the URL as the primary output.

Key Rules

• Always use --format html. Reports are HTML, not markdown.
• Title format: Report -- -- . Example: Code Review -- my-project -- 2026-05-25.
• Infer project name from the git remote or directory name.
• Date in titles uses YYYY-MM-DD.
• Do not ask the user which template to use -- pick based on the report type.
• The temp file is not cleaned up so the user can re-publish after edits.

Content Rules

• Use real data from the repo. Never fabricate commits, file names, or findings.
• For code review reports, run the actual diff and analyze it. Do not summarize from memory.
• For sprint reports, use git log output, not guesses about what was worked on.
• Keep reports concise. A 200-line HTML report is better than a 2000-line one.

Gotchas

• uselink login is interactive. Claude cannot run it. If config is missing, tell the user to run it themselves and stop.
• HTML must use inline CSS only. Uselink strips ` and tags that reference external files. All styles go in style attributes or a single block in . See templates in report-templates.md`.
• Publishing always creates a new document. There is no upsert. If the user wants to update an existing report, they need to publish again and get a new URL.
• The CLI prints the URL to stdout. Capture full stdout from the publish command. The URL is typically the last line.
• Large diffs can exceed context. For code review reports on big PRs, summarize by file rather than including every line. Use git diff --stat first to scope the work, then read only the files with meaningful changes.
• git log date formats matter. Use --format="%H|%an|%s|%ai" for parseable output. Do not rely on the default pretty format.
• Sprint "since" needs a sane default. If the user does not specify a date range, default to 7 days for sprint reports and 1 day for daily summaries.

Source & license

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

• Author: compilet-dev
• Source: compilet-dev/agent-skill-uselink
• License: MIT
• Homepage: https://uselink.app

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