pardump

Set up a local skill for me for uploading to pardump. When you upload something, give me the link instead of a local file path.

Have the skill draw one distinction before anything else: sometimes I'm pointing at something that already exists, and sometimes I'm asking you to make something. If I say "put this on pardump" or "dump this", the content is already there — a message you just sent, a file, an artifact you already built, text I pasted — and "this" with no clearer referent means your last message. Upload it exactly as it is: don't rework it to stand alone, restructure its code blocks, or add context or frontmatter; if it's html, the --md companion is the one thing you still write fresh. The format and writing guidance below is for when you're the author, making something that doesn't exist yet.

Either way, keep sensitive data out of uploads — the document, any --md companion, and attachments alike: no credentials or tokens, no real people's personal information, no production records like database rows or raw logs. Build on sanitized, aggregate, or synthetic data instead, and if the real thing seems necessary — or something I asked you to upload contains it — flag it and let me decide before uploading.

Have the skill spell out how to pick the format when authoring, since that choice happens before anything gets built. Markdown is the default: writeups, reports, and investigations are prose, and pardump renders a markdown dump as a clean typeset page — asking to share something is not a request for an html artifact. Fenced mermaid blocks use the same syntax as GitHub, render as responsive diagrams, and automatically follow pardump's light/dark theme, so prefer Mermaid for architecture maps, flows, sequences, and state machines that should remain easy for an agent to revise. Fenced vega-lite blocks render declarative JSON charts as responsive, theme-aware SVG, so prefer Vega-Lite for time series, comparisons, and statistical plots; keep the underlying data in an attached CSV or JSON file and reference its exact filename from data.url. Arbitrary network data URLs, image marks, and chart links are unavailable. Use an attached image only when neither declarative format can express the visual cleanly. Markdown dumps also render math: put `$$` on its own line above and below a display equation, and write `$$...$$` for math inside a sentence. A single `$` is never math, so prices and shell variables stay text. In markdown prose, diff, task, SEV, and Phabricator paste numbers written bare (D81234567, T198765432, S512345, P1876543210) link to their internal pages, so there is no need to build those URLs by hand. Build html when the content genuinely needs bespoke interaction or layout beyond those primitives, and when you upload html, also write a markdown version of the same content and attach it with --md: humans open the link and see the html, and an agent handed the link reads the markdown. If the artifact is a surface you'll keep updating (a dashboard, a status page), put `<meta name="pardump-live">` in its head and push revisions to the same slug — open tabs swap each new revision in automatically. Don't also add reload timers; the viewer blocks an artifact from reloading itself. If my request doesn't settle the format and I could plausibly want either a plain writeup or an interactive artifact, ask me before building.

When a deliverable comes with data artifacts (a csv of results, raw json, an image), attach them to the upload with --attach instead of pasting large tables into the prose or sharing the artifacts as separate dumps. Readers download them from the page, and attachments stay with the dump when it's updated later. Write the markdown knowing it can reference them: a link or image whose target is exactly the attachment's filename ([full data](results.csv), ![](chart.png)) resolves to the file on the rendered page, with images shown inline. Image syntax aimed at an attached video renders a native player (`![Demo](demo.mp4)`; mp4, m4v, mov, ogv, and webm). HTML artifacts can reference attachments the same way, in attributes written literally in the markup: a src or poster attribute whose value is exactly the attached filename (`<img src="chart.png">`, `<video src="demo.mp4" controls>`) renders the media inline on the served page, and an href with an attached filename becomes a download link — so put media in attachments instead of data URIs; scripts and styles still need to be self-contained. When someone hands you a link, reading it with pardump lists any attached files, and pardump save <slug> <filename> downloads one to your current directory. The document and --md companion must fit in 4.5MB; attachments upload directly to private Blob storage and may be up to 5GB each and 10GB total per dump.

Documents you author go to coworkers and their agents who weren't in our conversation, so write them to stand alone. When a line of framing would help, start a markdown dump with a frontmatter block carrying the prompt it answers (a first line of ---, then prompt: <the question>, then ---); the viewer renders it above the document. It's an optional exposition aid — paraphrasing is fine.

When we iterate on a document, push revisions to the same slug so the link stays stable. When someone gives you a pardump link, read it with pardump rather than fetching the URL.

A dump can also keep itself current after our conversation ends: `pardump live <slug> "<assignment>"` hands it to a hidden worker that re-derives the content and revises the same slug on the interval the assignment states (hourly by default). Reach for it when I ask for a dashboard or status page that should stay fresh on its own — and write the assignment as a standalone brief (what to watch, where the data lives, what "current" means), because the worker sees only that text, never our chat. The worker reads internal data through the approved query lanes only — scuba datasets, tasks, oncall, sev and people lookups via the meta tools, plus the dump itself; no public web, no other services, no actions — so don't promise it anything beyond reading and republishing. Going live needs my account to be enrolled and holds one slot from a shared pool until stopped: `pardump lives` shows what's live, and `pardump live stop <slug>` ends the updates, keeps the last content at the same link, and frees the slot.

Uploads take a random slug by default, and --as <name> puts a name in front of it (1 to 57 lowercase letters, digits, and single dashes between words): --as deploy-runbook shares at pardump.par-msl.dev/deploy-runbook-k3m9x2. The random tail stays, so a name never collides with anything and never has to be negotiated — have the skill name the dump after the document rather than after our conversation, and keep it short enough to read at a glance. Worth doing when the link is going into a doc or a message someone reads later; skip it on a one-off share, where the name is just noise. The slug that comes back, tail and all, is what to reuse when we revise the dump.

If I'm clearly about to read the result right away (one document, asked for now), add --open to the upload so it comes up in my browser. Leave it off for batches, or when the link is for someone else.

Run `pardump --help` and document the skill's usage from what it prints, so it matches the installed version. If pardump isn't installed, stop and ask me to install it from https://pardump.par-msl.dev. pardump signs in as me, and only I can do that: if a command says sign-in is expired or missing, have the skill stop and ask me to run `pardump auth` in my own terminal (it opens a browser login and asks me to paste a token back), then re-run once I confirm. The skill should never try to sign in itself, and never ask me to paste the token to it.

If I already have this skill installed, just look through the above and make sure it's all captured, as new functionality may have been added since.