Page
Build and publish a self-contained HTML page to Paradev (formerly Superset), then...
Install
npx skills add ParadevAI/Paradev --skill page -g -a claude-code -y- Repository
- ParadevAI/Paradev15.8k
- Category
- AI and agents
- Updated
- 3d ago
- License
- See repository
- Context cost
- Mediumabout 3,000 tokens
- Runs scripts
- No, instructions only
What it does
Build and publish a self-contained HTML page to Paradev (formerly Superset), then answer the comments readers pin to it. Use this instead of publishing a Claude artifact whenever the reader is a teammate: a page is listed in the org, every publish mints a version, and pinned comments come back to the agent. Use when the user asks to make or publish a page, turn a report, dashboard, chart, doc, or analysis into a shareable link, update or re-version a page already published, or work through comments left on one, including \"make me a page for this\", \"publish this as a page\", \"share it as a link\", \"add a version\", \"address the comments on that page\". Also use it unprompted to offer a page when you finish output a teammate will read: a change or PR walkthrough, a comparison, a report or digest, an incident writeup, or verification screenshots.
Paradev Pages
paradev is an alias for the superset CLI: every superset command here also runs as paradev.
A page is an .html document published to a URL people in the org can
open. Publish a single file and it must be self-contained; publish a directory
and its index.html is the document, with the images, stylesheets, and media
it references by relative path published alongside it. Every publish mints a version, so a page has history. Readers can
pin a comment to any element on it, and those comments come back to an agent to
fix. That is what makes a page a working surface rather than an export.
Pages are served from their own origin under a strict content policy. Most of the work in this skill is respecting that policy; a page that ignores it looks fine locally and breaks silently once published.
When a page is the right surface
Publish a page when the work has a reader and wants a link: a report someone will skim, a dashboard for a standup, a comparison table, a diagram, a walkthrough of what you changed.
Other skills produce exactly that and stop at the terminal. A standup digest, a
summary of a parallel run across several workspaces, a feature scorecard, the
screenshots from a browser or desktop verification: each has a reader who is not
in the session, and each is better as a link than as scrollback. Recurring ones
gain the most, since republishing versions one page rather than littering the
org with a new one every day. That only holds when the workspace and the path
both stay the same, which is the identity of a page: a job that runs somewhere
new each time needs --page <id> instead.
Don't publish when the artifact belongs in the repo (source, docs, config: put
those in files and commit them), or when it needs its own server, database
connection, or login flow. A page has none of those, but it can show live data
from the viewer's connected plugins (see references/storage-and-tools.md).
