Uselink report
Skill compilet-dev/agent-skill-uselink/skills/uselink-report
Agent skills for publishing engineering docs, repo summaries, PR digests, changelogs, API docs, onboarding guides, and specs to Uselink.
npx -y skills add compilet-dev/agent-skill-uselink --skill uselink-reportAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Generate formatted HTML reports and publish them to uselink. Use when the user asks for a code review report, architecture overview, sprint summary, daily standup report, or any structured report they want shared via a link.
SKILL.md
3.7 KB, as published. Nobody here has run it
Uselink Report Generator
See
report-templates.mdfor HTML templates and per-report-type data gathering commands.
Prerequisites
Before generating any report, verify:
- CLI installed --
which uselinkmust resolve. If not, tell the user to runnpm install -g uselink. - CLI configured --
~/.uselink/config.jsonmust exist withapi_key. If not, tell the user to runuselink loginin 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
- Determine report type from the user's request.
- Gather data using the commands and file reads listed in
report-templates.mdfor that report type. - Generate HTML by filling the matching template from
report-templates.md. Write to/tmp/uselink-report-<type>-<timestamp>.html. - Publish with
uselink publish <file> --title "<Report Title>" --format html. - Return the URL as the primary output.
Key Rules
- Always use
--format html. Reports are HTML, not markdown. - Title format:
<Type> Report -- <Project> -- <Date>. 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 logoutput, not guesses about what was worked on. - Keep reports concise. A 200-line HTML report is better than a 2000-line one.
Gotchas
uselink loginis 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
<link>and<style>tags that reference external files. All styles go instyleattributes or a single<style>block in<head>. See templates inreport-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 --statfirst to scope the work, then read only the files with meaningful changes. git logdate 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.