Streamlit is a Python framework that turns scripts into interactive web applications for data exploration, dashboards, reports, and chat interfaces. Data scientists, machine-learning practitioners, and developers use it to build and share data apps without implementing the web interface from scratch. The catalogue add-ons support coding-agent workflows for Streamlit applications.
Borrowing it
Nothing to install: this file belongs to streamlit/streamlit. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/streamlit/streamlit/develop/.claude/skills/reviewing-pr-description/SKILL.mdgit clone --depth 1 https://github.com/streamlit/streamlitWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/streamlit/streamlit/reviewing-pr-description)<a href="https://agentmods.dev/skills/streamlit/streamlit/reviewing-pr-description"><img src="https://agentmods.dev/badge/skills/streamlit/streamlit/reviewing-pr-description/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/streamlit/streamlit/reviewing-pr-description"><img src="https://agentmods.dev/badge/skills/streamlit/streamlit/reviewing-pr-description.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00081 | $0.00922 |
| Opus 5.5 | $0.00032 | $0.00369 |
| Sonnet 5.5 | $0.00016 | $0.00184 |
| Haiku 4.5 | $0.00008 | $0.00092 |
Grade A, and why
reviewing-pr-description scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 56 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Reviewing PR Description
Review a PR's title and description for readability: do they clearly and concisely tell a reviewer what changed and why? Focus on the prose — checking the format (title pattern, required template sections) is a secondary, lighter concern.
This skill only evaluates: it produces findings with concrete proposed rewrites and does not apply them. The caller decides whether to apply the rewrites or present them as feedback.
Audience
The reader is a reviewer or teammate skimming the PR to understand what changed and why. They may not know the implementation context, and later readers will find this text via the commit log or changelog. The title and description should stand on their own.
Principles
- Lead with the change and its purpose — the first sentence should state what changed and why, not setup, process, or a description of the problem area.
- Explain intent, not mechanics — say what the change enables or why it was made; don't narrate the diff step by step.
- Cut what the diff already shows — omit routine, obvious changes (added tests, updated types, fixed lint). Call out only what's non-obvious or decision-worthy.
- Concise wins — fewer, denser bullets beat many thin ones. If a bullet restates the title or another bullet, drop it.
- Explain non-obvious decisions — deprecations, unit choices, fallback behavior, and trade-offs deserve a sentence on why.
- Avoid jargon without context — spell out internal terms or acronyms a newcomer wouldn't know.
- Active voice; name the actor — "Deprecates
use_container_width" or "The server now rejects oversized uploads" reads more directly than passive or vague phrasing. - The title stands alone — it should convey the change on its own in a commit list or changelog, without the body.
- No meta-commentary — cut "This PR...", "We have...", "I added..."; state what changed directly.
Evaluation Process
- Gather the PR title and description (
gh pr view <n> --json title,body). - For each, ask:
- Does the title convey the change on its own, or does it need the body to make sense?
- Does the description lead with the main change and its purpose, or bury it under context/mechanics?
- Does it explain why for non-obvious decisions, or only list what?
- Is there jargon or an acronym a newcomer wouldn't understand?
- Could it be shorter — are there obvious or duplicated points to cut?
- Is it in passive or vague voice where naming the actor would read more directly?
- Is there meta-commentary that adds no information?
- Also confirm the format briefly (secondary): title matches
[type] Descriptionwithin ~63 chars, and the required template sections from.github/pull_request_template.mdare present. For the full standards, seecreating-pull-requestsandwiki/pull-requests.md. - Report the findings per the Output Format below.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2mo ago First seen · 56 lines · 81 tokens per session scan A 3e20bc9e97f8
reviewing-pr-description is a skill published in the GitHub repository streamlit/streamlit (46,171 stars, last pushed today), licensed Apache-2.0. It adds 81 tokens to every session and 922 once invoked, about $0.0003 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
marimo-pair
Work inside the user's live marimo notebook from the code editor: run Python in the same kernel the user does, inspect live notebook state, and commit durable notebook changes through code mode. Use whenever you create, analyze, or improve the user's marimo notebook.
fill-model-descriptions
Curate descriptions and provider-specific reasoning options and token limits in packages/llm-info/data/models.yml using models.dev, OpenRouter, and provider documentation. Use when the user asks to populate model descriptions, enrich the model catalog, or curate descriptions after running pnpm sync-models.
lepton-cli
Operate NVIDIA DGX Cloud Lepton through the globally installed lep CLI. Use when the user asks to inspect or manage Lepton workspaces, endpoints/deployments, dev pods, batch jobs, fine-tuning jobs, Ray clusters, Slurm clusters, Dynamo endpoints, storage, secrets, nodes, ingress, templates, logs, authentication, or…
perforatedai
Expert in PerforatedAI library for adding artificial dendrites to PyTorch neural networks. Triggers: 'Perforate my model' (start interactive setup), 'debug my perforated model' (debug/optimize existing integration), 'load my perforated model for inference' (deploy trained models), 'export my perforated model'…
cnsplots
Create, revise, and troubleshoot publication-ready scientific plots in Python with cnsplots, including distribution, regression, heatmap, genomics, survival, set, flow, and multi-panel figures. Use when a user asks for cnsplots code, Cell/Nature/Science-style visualization, precise physical figure dimensions…
fast-dash
Build a Fast Dash web app from a Python function. Use when the user wants to turn a function into an interactive app, add a UI to an existing function, build a dashboard / form / wizard, add a chat assistant to an app, or make an app that AI agents can drive over MCP. Fast Dash infers UI components from type hints, so…